We have Octopus Deploy running on an Azure VM.
Using remote desktop to connect to the VM, I can browse to http://localhost and see the dashboard.
When I look at Octopus Manager on the VM, I see two portals:
Browsing to the cloudapp URL results in the following response in fiddler:
[Fiddler] The connection to '****.cloudapp.net’ failed.
Error: TimedOut (0x274c).
System.Net.Sockets.SocketException A connection attempt failed because the connected party did not properly respond after a period of time or established connection failed because connected host has failed to respond 191.239..:80
The IP address is an Azure IP.
As far as I can tell, we have port 80 open on the VM. I’ve tried with and without virtual directories.
We are also running teamcity on this VM, plus Seq.
Octopus version onsite is 184.108.40.2061
Have you mapped the endpoint in the Azure portal ?
Yes, endpoint is mapped (HTTP:80)
Well can you get to Seq and TeamCity on the same server ? What IP are they mapped to ?
Yes TeamCity is responding on port 8080 on the same machine.
We’ve disabled Seq for the moment as part of the troubleshooting. It was on port 8081.
You shouldn’t need two mappings on the Octopus Manager, just add localhost 80 and you should be able to connect if you’re being allowed through.
The message you’re getting means that something isn’t responding, but you know Octopus is working.
I’d also double check that the windows firewall has 80 open.
We’ve discovered that we can establish remote access on port 88, provided we are not using the corporate network. Port 80 remains unresponsive no matter how we are on the internet.
Not quite sure what else I can do here. Octopus is working. There something stopping you from getting port 80 through to it.
When you set it up on 88, did you make Octopus respond on 88 and map external 88 to internal 88 ? Or did you map external 88 to internal 80 ?
I’d triple check your azure endpoint mappings, firewall, anything else running on 80 like an IIS site (this is a total long shot because it’s responding locally).
You could also check that the corporate network doesn’t have a block on cloudapp.net sites (again that’s a bit of a longshot).
When we went to 88, we set up Octopus on 88 and mapped external 88 to internal 88.
We’re not running IIS on the VM, and we can access other cloudapp.net sites from our network, but pretty sure we’re going to be OK now. Just weird it won’t work on 80. We can work with 88, however, until we work it out.
I’ll post back if I discover anything momentous.