Tentacle initial handshake over port 80?

Hi,

We’re running into a problem while installing a tentacle on a off side location.
Our Octopus server is behind a firewall and we want to keep the webportal inaccessible from the outside world.
This means we’re not allowing port 80/443 towards the octopus server.
We do want the tentacle to access the server so we allow port 10933/10943 towards the octopus server.
But when installing the tentacle and selecting polling mode I ran into the issue that the tentacle needs to do a handshake with the octopus server via it’s URL.

Does this mean it needs to do the handshake over port 80?
If so why is this? I thought the whole point of port 10933 was that you don’t need to open other ports.

Cheers,
Andy

Hi Andy,

Thanks for getting in touch! The installation wizard uses the Octopus REST API (port 80/443) to “register” the Tentacle with the Octopus server. After that, all communication happens on port 10943.

As an alternative, you could:

  1. Go through the wizard on another machine, and at the end, export the script (“Show script” on the last page of the wizard).
  2. Skip the “register-with” line in the Tentacle setup script.
  3. Manually add the machine via the Octopus web UI.

Hope that helps!

Paul

Hi Paul,

Thanks for your answer but this isn’t really a solution for us.
We want use an automated installation on EC2 machines so we can use autoscaling.
This happens without us knowing it so we can’t manually add the servers.
Is this really the only way to do it.
I love octopus deploy but this is a big showblocker for us to use it and I think we won’t be the only one.

Thanks,
Andy

Hi Andy! We’ve got a good repertoire of cat-skinning techniques at our disposal, but I’m having trouble coming up with a quick-and-easy alternative; about the best option seems to be to create your own provisioning service, on whatever port you choose, and behind that automate machine configuration via the Octopus API.

If we opened up the configuration API on the 10943 port, instead of restricting access to trusted SSL certificates, would there still be an advantage blocking the machines from getting to Octopus on 443?

I.e. currently that’s the difference between the API port (can do all admin actions) and the deployment port (extremely limited access targeting low-trust clients).

Regards,
Nick