Cloud server with HA on-premise targets

I am currently trialling the Octopus cloud solution but want to configure deployment targets (specifically using the listening tentacles) that are behind a load balancer. I checked the documentation but there is only information regarding on-premise server configurations. Essentially the hostname(s) that I enter during initial configuration never succeeds when trying to establish a connection to the tentacle.

Can someone please advise on the standard setup required in this scenario?

Thanks in advance.

As a temporary workaround I have installed a polling tentacle (instead of listening) on the development targets so that I can create a rule outbound to enable traffic to Octopus cloud. However, having a polling tentacle is not ideal so if there are any other recommendations then it would be great to hear from you.

Hi Simon,

Sorry to see you are having issues with this.

Tentacle configuration for High availability and Octopus without the load balancer are the same to some degree.

“Listening Tentacles require no special configuration for High Availability.”

I would look at this Documentation:

This Guide here will help you with troubleshooting:

When you install Tentacle onto the Machine you are using, can you see the Tentacle installed and running?

The issues start when you are trying to connect via the Octopus server?

Also, what type of load balancer are you using so I can best guide you. Is it an AWS ELB?

Furthermore, have you checked the Firewall or routing configurations.

It would be interesting to know what happens if you go to the machine behind the load balancer, and browse to the Octopus server’s listening port directly? (E.g. https://your-octopus:10933)

In C:\Octopus\Logs on the Tentacle you’ll find some log files Could you please attach them.

I hope this information has been useful to you.

I look forward to your reply.

Kind regards,

Hi Ziaul,

Firstly, thanks for your response.

An F5 sits in front of two web servers and the firewalls were reconfigured to allow the traffic. On that point, is it common practice to allow inbound traffic on port 10933?

The reason I started to consider the polling tentacles instead was because I feel it is insecure to allow inbound traffic on any port when it can be avoided, and since it is from a cloud server there is no way to easily identify a single source address that I can restrict it to.

Regarding your other points, if I browse to the listening port I get a message saying “Octopus Tentacle configured successfully” so I’m assuming that there aren’t any issues from that perspective.

Reading the Octopus documentation I believe the issue is that our network configuration does not publically expose either of the servers and instead has routes in place to filter traffic to the load balancer which in turn determines which server should be accessed. Without exposing the servers that sit behind the firewall (we use palo alto) the only way I can understand it would work with a listening tentacle is to use a reverse proxy - that seems messy to me.

Let me know your thoughts.

Kind Regards,

Hi Simon,

Thank you for your reply.

To answer the question directly yes you would need to allow Inbound traffic from port 10933 to flow through to enable the server to access the Tentacle.

And I see your point in regards to this matter - I would have personally recommended Polling Tentacles given your current predicament you are in.

I hope this answers your question.

If you have any further questions, please let me know.

Kind regards,

Hi Ziaul,

Ok that makes sense, I really appreciate your help with this.

Have a great day!

Kind Regards,

1 Like