Octopus Deploy can work with any http/https load balancer technology. There are plenty of options when it comes to choosing a load balancer to direct user traffic between each of the Octopus Server nodes.
Load Balancer Basics
Octopus Server provides a health check endpoint for your load balancer to ping: /api/octopusservernodes/ping.
Making a standard HTTP GET request to this URL on your Octopus Server nodes will return:
- HTTP Status Code
200 OKas long as the Octopus Server node is online and not in drain mode. - HTTP Status Code
418 I'm a teapotwhen the Octopus Server node is online, but it is currently in drain mode preparing for maintenance. - Anything else indicates the Octopus Server node is offline, or something has gone wrong with this node.
The Octopus Server node configuration is also returned as JSON in the HTTP response body.
We typically recommend using a round-robin (or similar) approach for sharing traffic between the nodes in your cluster, as the Octopus Web Portal is stateless.
All package uploads are sent as a POST to the REST API endpoint /api/[SPACE-ID]/packages/raw. Because the REST API will be behind a load balancer, you’ll need to configure the following on the load balancer:
- Timeout: Octopus is designed to handle 1 GB+ packages, which takes longer than the typical http/https timeout to upload.
- Request Size: Octopus does not have a size limit on the request body for packages. Some load balancers only allow 2 or 3 MB files by default.
Polling Tentacles
Polling tentacles deserve special attention due to how they work with Octopus Deploy. Each node that processes tasks must be registered with every polling tentacle.
We recommend having a dedicated URL for each node in the primary region and routing all traffic through a load balancer or a traffic manager. When you have to fail over to the secondary region, update the dedicated URLs to point to a corresponding node in the secondary region.
Important! You must configure the traffic to be “pass through” with no SSL off-loading. The tentacles and Octopus Deploy establish a two-way trust via certificates. If a third unknown certificate is introduced, the tentacle and Octopus deploy will reject the connection.
Third Party Load Balancers
This section contains information on how to set up third-party load balancers for use with Octopus High Availability:
- Local Options
- AWS Load Balancers
- Azure Load Balancers
- GCP Load Balancers
Help us continuously improve
Please let us know if you have any feedback about this page.
Page updated on Wednesday, May 22, 2024