Hi there,
I need support with the Azure DevOps integration please.
I was able to install the Octopus service under our Azure subscription, now I would like to know what’s the best way to push artefacts to the Octopus server (self hosted)?
The connector works fine in Azure, I am able to browse the spaces, when I try using the Octo.dll (in my Azure pipeline), to push artefacts to my Octopus instance, I am getting a connectivity error.
I believe there are some IPs that need to be allowed from our side to the Octopus instance, but browsing the Microsoft pages, it looks like there are about 3500 IPs addresses dedicated to the Azure hosts.
I am probably looking this scenario from the wrong side of the table, I think there is something else I can do to avoid exposing our Octopus server to these 3500 IPs??
Thanks for getting in touch! Great question, and a couple of potential options come to mind to avoid having to expose Octopus to these IPs.
Probably the easiest way around this would be to instead set up a repository in Azure to store the packages and set up an external feed in Octopus to point at it and pull packages from it.
Alternatively it might work to put an Azure agent on the Octopus server. That should theoretically prevent having to open IPs to push to Octopus.
Would one of those options help get this working as needed? Let me know what you think or if you have any further questions going forward.
We do something similar, in the end we went for a self hosted Azure Build Agent as that allowed us to control the IP range, in fact we ended up having a secure VPN link and having them talk via private ip for added security.
Hello @Kenneth_Bates
thanks for your reply…
I have created an Azure feed and I can see the uploaded files (from our sel hosted Octopus instance).
Now I am creating the step (in Azure) to create a new-release (using octo.dll) and I am having again the same issues as before - no connection.
What’s the difference between configuring Octopus in Azure (Settings\pipeline\service connections - so I can see spaces and project - working), and the use of Octo.dll (NOT working)?
Aren’t they using both the REST API?
There shouldn’t really be any difference, as they are originating at the same source.
Are you able to attach the log where the error is appearing for us to review?
Hi @paul.calvert , thanks for your reply.
There is actually no log for the error because the connection from the azure machine and the Octopus instance is not established.
I am only seeing the following Azure pipeline error:
System.Exception: Unable to connect to the Octopus Deploy server. See the inner exception for details. —> System.Net.Http.HttpRequestException: An error occurred while sending the request. —> System.IO.IOException: The server returned an invalid or unrecognized response.
at System.Net.Http.HttpConnection.FillAsync()
at System.Net.Http.HttpConnection.ReadNextResponseHeaderLineAsync(Boolean foldedHeadersAllowed)
at System.Net.Http.HttpConnection.SendAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken)
— End of inner exception stack trace —
I can edit that integration, I can browse the spaces and the projects, but I can’t interact with it using the octo.dll
Any idea?
Thank you for your time.
Regards.
L.
Thanks for keeping in touch, and my apologies about the delay in getting back to you on this one.
System.IO.IOException: The server returned an invalid or unrecognized response. seems to imply that something network related is interfering, probably a proxy. Is it possible that’s the cause of this issue in your environment? If it is, you could configure your proxy settings in the Octo.exe create-release command in Azure Devops, under the Additional arguments section. The create-release documentation page outlines all of the arguments, where the proxy specific ones are as follows.
--proxy=VALUE [Optional] The URL of the proxy to use, e.g., 'https://proxy.example.com'.
--proxyUser=VALUE [Optional] The username for the proxy.
--proxyPass=VALUE [Optional] The password for the proxy. If both the username and password are omitted and proxyAddress is specified, the default credentials are used.
To continue troubleshooting from this point, you could use a network monitoring tool such as Wireshark during a release creation attempt to hopefully provide some more information on what could be going on.
I hope this helps, and I look forward to hearing back.
Hello @Kenneth_Bates
Thanks for the reply.
Unfortunately there is no proxy in our network as far as I know.
I strongly believe that the issue is from where I am calling the API.
octo.dll or octo.exe is called from the Azure (build/pipeline) agents
the Octopus connector is configured in the main Azure configuration page
The connector call is working and I can browse Spaces or Projects, the Agent API call (octo.exe or .dll) instead, is not able to connect to the Octopus instance configured in the connector above, and the IT guys here says that the issue could be Azure changing the Agents pool IPs during time…
Thanks for keeping in touch and letting me know the possibility that it could be Azure changing the pool IPs. This is actually the first and only report of behavior like this that I’ve seen at least. I’d be very interested to hear if your IT guys find anything relevant here. Using Wireshark to monitor the network might be a good followup step to hopefully narrow down where the issue could be.
