Manifest settings for load balancers
Overview
This reference doc details all the Manifest settings for load balancers . If you’re unfamiliar with Manifest files and how they work, please follow our getting started guide and detailed how-to guide.
If you’re looking for the Manifest settings for webservers & frameworks or data, caching & storage components, please see our respective reference documents for those components.
Key to table headings
- Option - the name of the setting as used in the YAML of your Manifest file
- Applied on - the type of deployment required to update this setting. In many cases settings only apply when an application (and associated load balancer) is first built, or when new loadbalancers are added or the app is cloned. Hover over the names of each condition to see more info.
AWS load balancer
You can use your Manifest file to customize the AWS load balancer deployed by Cloud 66.
The following settings are available via the Manifest file:
| Option | Applied on | Description |
|---|---|---|
alb_ssl_policy |
Redeploy ⓘChanges to this setting will be applied when you next deploy your application |
The SSL policy to associate with your ALB when performing SSL termination. See the official AWS docs for available ALB SSL policies. (Applies only to Application Load Balancers) |
elb_ssl_policy |
Redeploy ⓘChanges to this setting will be applied when you next deploy your application |
The SSL policy to associate with your ELB when performing SSL termination. See the official AWS docs for available ELB SSL policies. (Applies only to Classic Load Balancers) |
httpchk |
Build-only ⓘThis setting only applies when the app is first built (or cloned) or when new servers are added. |
The URL visited to check your server health |
wait_after_adding_servers |
Redeploy ⓘChanges to this setting will be applied when you next deploy your application |
The time (in seconds) we will wait after adding a server back to the load balancer before we begin routing traffic to that server. Read our in-depth guide on configuration lag for more details. |
wait_after_removing_servers |
Redeploy ⓘChanges to this setting will be applied when you next deploy your application |
The time (in seconds) we will wait after adding a server back to the load balancer before we begin routing traffic to that server. Read our in-depth guide on configuration lag for more details. |
Example YAML for AWS load balancers
load_balancer:
configuration:
httpchk: /
wait_after_adding_servers: 30 # default is 0
wait_after_removing_servers: 10 # default is 0
alb_ssl_policy: ELBSecurityPolicy-FS-1-2-2019-08 # default
elb_ssl_policy: ELBSecurityPolicy-TLS-1-2-2017-01 # default
GCE load balancer
You can use your Manifest file to customize any GCE load balancers deployed by Cloud 66.
The following settings are available via the Manifest file:
| Option | Applied on | Description |
|---|---|---|
balance |
Build-only ⓘThis setting only applies when the app is first built (or cloned) or when new servers are added. |
The load balancing strategy. Valid values: NONE, CLIENT_IP or CLIENT_IP_PROTO |
httpchk |
Build-only ⓘThis setting only applies when the app is first built (or cloned) or when new servers are added. |
The URL visited to check your server health |
wait_after_adding_servers |
Redeploy ⓘChanges to this setting will be applied when you next deploy your application |
The time (in seconds) we will wait after adding a server back to the load balancer before we begin routing traffic to that server. Read our in-depth guide on configuration lag for more details. |
wait_after_removing_servers |
Redeploy ⓘChanges to this setting will be applied when you next deploy your application |
The time (in seconds) we will wait after adding a server back to the load balancer before we begin routing traffic to that server. Read our in-depth guide on configuration lag for more details. |
Refer to the GCE documentation for more detail on these settings.
Example YAML for GCE load balancers
load_balancer:
configuration:
httpchk: /
balance: CLIENT_IP_PROTO
wait_after_adding_servers: 30 # default is 0
wait_after_removing_servers: 10 # default is 0
HAProxy
You can use your Manifest file to configure and define any HAProxy load balancers deployed by Cloud 66. These changes will be either be applied when you redeploy an application with more than one server, rebuild HAProxy or edit HAProxy CustomConfig.
Because HAProxy load balancers are not “cloud native”, you will need to specify the server configuration in the same YAML node as your HAproxy settings. The server configuration settings are :
| Server options | Applied on | Description |
|---|---|---|
key_name |
Build-only ⓘThis setting only applies when the app is first built (or cloned) or when new servers are added. |
Default |
region |
Build-only ⓘThis setting only applies when the app is first built (or cloned) or when new servers are added. |
Digital Ocean’s region |
size |
Build-only ⓘThis setting only applies when the app is first built (or cloned) or when new servers are added. |
The size of the instance |
unique_name |
Build-only ⓘThis setting only applies when the app is first built (or cloned) or when new servers are added. |
Name of the instance |
The following HAproxy settings are available via the Manifest file:
| Option | Applied on | Description |
|---|---|---|
balance |
Redeploy ⓘChanges to this setting will be applied when you next deploy your application |
The load balancing strategy. Valid values: roundrobin, leastconn or source |
errorfile_*ERROR_CODE* |
Build-only ⓘThis setting only applies when the app is first built (or cloned) or when new servers are added. |
Location of your own custom error page(s) to serve in the case of receiving a HTTP error code on the load balancer. You can configure one page per error code. |
haproxy_password |
Redeploy ⓘChanges to this setting will be applied when you next deploy your application |
The password for your HAproxy stats interface. |
haproxy_username |
Redeploy ⓘChanges to this setting will be applied when you next deploy your application |
The username for your HAproxy stats interface. |
httpchk |
Redeploy ⓘChanges to this setting will be applied when you next deploy your application |
The URL visited to check your server health |
wait_after_adding_servers |
Redeploy ⓘChanges to this setting will be applied when you next deploy your application |
The time (in seconds) we will wait after adding a server back to the load balancer before we begin routing traffic to that server. Read our in-depth guide on configuration lag for more details. |
wait_after_removing_servers |
Redeploy ⓘChanges to this setting will be applied when you next deploy your application |
The time (in seconds) we will wait after adding a server back to the load balancer before we begin routing traffic to that server. Read our in-depth guide on configuration lag for more details. |
Refer to the HAProxy documentation for more information
Example YAML for HAproxy load balancers
load_balancer:
servers:
- server:
unique_name: bananana
size: 1gb
region: ams2
vendor: digitalocean
key_name: Default
configuration:
httpchk: HEAD / HTTP/1.1\\r\\nHost:haproxy #default value
balance: roundrobin #default value
errorfile_400: /etc/haproxy/errors/400.http
errorfile_403: /etc/haproxy/errors/403.http
errorfile_500: /etc/haproxy/errors/500.http
errorfile_504: /etc/haproxy/errors/504.https
wait_after_adding_servers: 30 # default is 0
wait_after_removing_servers: 10 # default is 0
Linode Nodebalancer
You can use a manifest file to configure Linode Nodebalancers deployed by Cloud 66.
The following settings are available via the Manifest file:
| Option | Applied on | Description |
|---|---|---|
balance |
Build-only ⓘThis setting only applies when the app is first built (or cloned) or when new servers are added. |
The load balancing strategy. Valid values: roundrobin, leastconn or source |
httpchk |
Build-only ⓘThis setting only applies when the app is first built (or cloned) or when new servers are added. |
The URL visited to check your server health |
wait_after_adding_servers |
Redeploy ⓘChanges to this setting will be applied when you next deploy your application |
The time (in seconds) we will wait after adding a server back to the load balancer before we begin routing traffic to that server. Read our in-depth guide on configuration lag for more details. |
wait_after_removing_servers |
Redeploy ⓘChanges to this setting will be applied when you next deploy your application |
The time (in seconds) we will wait after adding a server back to the load balancer before we begin routing traffic to that server. Read our in-depth guide on configuration lag for more details. |
Refer to the Linode documentation for more detail on these settings.
Example YAML for Linode Nodebalancer
load_balancer:
configuration:
httpchk: /
balance: leastconn
wait_after_adding_servers: 30 # default is 0
wait_after_removing_servers: 10 # default is 0
Rackspace load balancer
Use a manifest file to customize the Rackspace load balancer deployed by Cloud 66.
The following settings are available via the Manifest file:
| Option | Applied on | Description |
|---|---|---|
balance |
Build-only ⓘThis setting only applies when the app is first built (or cloned) or when new servers are added. |
The load balancing strategy. Valid values: ROUND_ROBIN, RANDOM or LEAST_CONNECTIONS |
wait_after_adding_servers |
Redeploy ⓘChanges to this setting will be applied when you next deploy your application |
The time (in seconds) we will wait after adding a server back to the load balancer before we begin routing traffic to that server. Read our in-depth guide on configuration lag for more details. |
wait_after_removing_servers |
Redeploy ⓘChanges to this setting will be applied when you next deploy your application |
The time (in seconds) we will wait after adding a server back to the load balancer before we begin routing traffic to that server. Read our in-depth guide on configuration lag for more details. |
Refer to the Rackspace documentation for more detail on these settings.
Example YAML for Rackspace load balancer
load_balancer:
configuration:
balance: LEAST_CONNECTIONS
wait_after_adding_servers: 30 # default is 0
wait_after_removing_servers: 10 # default is 0
