Issues setting up connection from Octopus server to Octopus Tentacle

Hi Paul,
After continuing to research on our end we’ve found the error you mentioned is the cert error on the tentacle that we receive when the irule is removed and the F5 directly hits the internal ip. When the irule is removed the request is able to get to the tentacle but does receive that cert error. When we create the irule on the F5, the request tries to direct to the internal ip based on host header. When the iRule is set up, the tentacle does not seem to receive the request as there are no logs on Tentacle that correlate to the request. We would really like to get this setup with a listening tentacle instead of polling since it is more efficient and this matches our dev environment. We must utilize the F5 and iRules as the number of IPs we have is limited. Looking for recommendations on how to get this working with our desired setup. Thanks.

Hi @Dan-303,

Thank you for getting back to us.

Can you elaborate more on the iRules the network team is intending to use in this case?

I’d also like to point out a section from our documentation that you may forward to your network team in case there is still confusion about the TCP requirement for Octopus/Tentacle communication.

From our documentation:

Watch out for proxy servers or SSL offloading…
Octopus and Tentacle use TCP to communicate, with special handling to enable web browsers to connect for diagnostic purposes. Full HTTP is not supported, so network services like SSL offloading are not supported, and proxies are not supported in earlier versions of Octopus Deploy. Make sure there’s a direct connection between the Octopus Server and Tentacle, without an HTTP proxy or a network appliance performing SSL offloading in between.

Let me know about the iRules at your earliest convenience.

Best Regards,
Donny

So we have a number of sites and each of these sites are spread out to multiple VMs and load balanced by our F5. I’ll try to explain what we’re trying to do with Octopus from the perspective of one of the sites.

Site ABC exists on Server 1, Server 2, Server 3 and has an unassigned binding with the same host header for the site. Lets say the host header is www.abc.com. When a user navigates to www.abc.com the F5 will direct the request to one of those servers.

Since we have to deploy the application to Server 1, Server 2, and Server 3 this requires a tentacle to be installed on each of these servers. Lets say the tentacles for those servers are accessible at the following urls -

Server 1 - tentacle1.mayapp.com:10933 - External IP 123.123.123.123
Server 2 - tentacle2.mayapp.com:10933 - External IP 123.123.123.123
Server 3 - tentacle3.mayapp.com:10933 - External IP 123.123.123.123

This means each octopus tentacle will need it’s own public but restricted url for our non prod Octopus Server to access. We will not be able to give all octopus tentacles in our environment their own public IP, but we will still obviously need our Octopus Server to be able to access each tentacle. In order to minimize the number of external IPs that we have to assign to Octopus Tentacles we were planning on dedicating a single or just a few external IPs to tentacles and set up an iRule in our F5 to direct based on host header.

For example when we are in the Octopus Server Admin and we want to deploy our applications to the Deployment Target on Server 1, the iRule will see 123.123.123.123 with host header tentacle1.mayapp.com, and all traffic will be directed to Server 1.

We currently have this setup working with the ping and pong apps and the tentacle test form does respond on port 10933, but as mentioned the health check errors out with Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.

Hi @Dan-303,

Thank you for getting back to me.

Unfortunately, it does not sound like listening tentacles are a good option for your current F5 setup due to the reliance of HTTP headers. From our documentation:

Octopus uses Halibut to communicate. This is based on TCP, not HTTP, it is not possible to add HTTP headers to this communication channel.

As Paul mentioned previously, Polling tentacles would reverse the communication direction making the tentacle the client and the octopus server the TCP server.

Could you try using Polling Tentacles to see if you are able to complete a health check as expected?

Let me know at your earliest convenience.

Best Regards,
Donny

Sounds like we got to the bottom of this. We can explore polling tentacles. Another idea that came up would be to use ports to identify the tentacle which I guess would mean using other ports besides 10933. Do you know if there is a downside to this? What would your recommendation be here?

Hi @Dan-303,

Thank you for the quick response.

Adjusting the port bindings as needed shouldn’t present any issues that I can think of. For this, you should be able to simply use the URL or ping/pong tests so long as you know that TCP communication is possible.

If anything else comes up, don’t hesitate to reach out.

Best Regards,
Donny

Just wanted to update you on the resolution to this issue. We ended up going with listening tentacles identified by port rather than host header. Each tentacle will have it’s own unique port number. Thanks for all your help.

Hi @Dan-303,

Thank you for getting back to me. I’m glad you and your network team were able to work out a solution.

If we can assist with anything else, please let us know.

Best Regards,
Donny

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.