Load balancers

09/02/2026 11:23 am
- Infrastructure

Use a load balancer if you want more than one server to share the same incoming traffic.

A single VM with a public IP is enough for a first server. A load balancer sits in front of a pool of servers, spreads requests across them, and can fail over if a member is unhealthy. Gozunga Cloud load balancers are OpenStack Octavia. They support health checks, TLS termination, and layer-7 rules. Create the servers and security groups first.

When you need this

You run two or more application servers and want one hostname in front of them.
You want to take a member out of service without changing DNS.
You want HTTPS on that hostname, with TLS ending on the load balancer.

If you have one server, point DNS at its public IP. See DNS zones and Creating and Managing Virtual Machines.

Create a load balancer

Open Cloud → Networking, then the Load Balancers tab. Click + Create load balancer. The table shows Name, IP, Operating Status, Provisioning Status, Created At, and Region. Wait until provisioning is complete before you point DNS at the address.

Networking Load Balancers tab with Create load balancer

TLS listeners and certificates use the OpenStack CLI. Authenticate with application credentials from Cloud → Access. See API Authentication. You need python-openstackclient, python-octaviaclient, and python-barbicanclient.

After every create or set, wait until provisioning_status is ACTIVE:

openstack loadbalancer show lb-app -f value -c provisioning_status

Serve HTTPS from the load balancer

Point the hostname at the load balancer IP, then terminate TLS on the balancer so browsers see HTTPS and the application servers keep speaking HTTP. Store the certificate in Key Manager and create a TERMINATED_HTTPS listener on port 443. See DNS zones.

If you already have a certificate, convert it to PKCS#12 with no passphrase and skip to loading it below. If you want a Let's Encrypt certificate over HTTP-01, issue it on a small extra instance first. The load balancer does not issue Let's Encrypt certificates; you load the cert after certbot writes it.

Issue a Let's Encrypt certificate

Launch a tiny Ubuntu 26.04 server (gp.nano1) on the same network as the load balancer members. Attach a security group that allows SSH from you and TCP 80 from the load balancer. Name it acme-01. Under Cloud Configuration (portal) or --user-data (CLI), paste this cloud-init. It installs certbot as a standalone HTTP-01 server and enables the renew timer. It does not request a certificate at first boot: DNS and the HTTP listener are not ready yet.

#cloud-config
package_update: true
packages:
  - certbot
write_files:
  - path: /etc/letsencrypt/cli.ini
    permissions: '0600'
    content: |
      authenticator = standalone
      preferred-challenges = http
      agree-tos = true
      non-interactive = true
      email = you@example.com
runcmd:
  - systemctl enable --now certbot.timer

Change the email. Create-server details are in Creating and Managing Virtual Machines. Same #cloud-config style as other Gozunga user-data (see the cloud-init collection). CLI: --user-data ./acme-01.yaml on openstack server create.

When the instance is Active, note its private IP. Point an A record for app.example.com at the load balancer IP. If the VIP is on a private subnet, attach a floating IP to the VIP port first.

Create an HTTP listener on port 80 whose only member is acme-01. Do not add a health monitor: port 80 is only open while certbot is running.

openstack loadbalancer listener create \
  --name http-listener --protocol HTTP --protocol-port 80 lb-app

openstack loadbalancer pool create \
  --name pool-acme --lb-algorithm ROUND_ROBIN --protocol HTTP \
  --listener http-listener

openstack loadbalancer member create \
  --subnet-id SUBNET_ID --address ACME_IP --protocol-port 80 pool-acme

On acme-01:

sudo certbot certonly -d app.example.com

Certbot binds port 80, answers Let's Encrypt, then exits. Files land in /etc/letsencrypt/live/app.example.com/.

Load the certificate

Pack the cert as a PKCS#12 with no passphrase, store it in Key Manager, and create the HTTPS listener. Application members speak HTTP to the balancer. They do not need a certificate.

sudo openssl pkcs12 -export \
  -inkey /etc/letsencrypt/live/app.example.com/privkey.pem \
  -in /etc/letsencrypt/live/app.example.com/fullchain.pem \
  -out /tmp/app.example.com.p12 \
  -passout pass:

openstack secret store --name=tls-app.example.com \
  -t 'application/octet-stream' -e 'base64' \
  --payload="$(base64 < app.example.com.p12)"

SECRET=$(openstack secret list -f value -c 'Secret href' -c Name | awk '/tls-app.example.com/ {print $1}')

openstack loadbalancer listener create \
  --name https-listener --protocol TERMINATED_HTTPS --protocol-port 443 \
  --default-tls-container-ref "$SECRET" lb-app

openstack loadbalancer pool create \
  --name pool-app --lb-algorithm ROUND_ROBIN --protocol HTTP \
  --listener https-listener

openstack loadbalancer member create \
  --subnet-id SUBNET_ID --address APP1_IP --protocol-port 80 pool-app

openstack loadbalancer member create \
  --subnet-id SUBNET_ID --address APP2_IP --protocol-port 80 pool-app

If listener create fails because Octavia cannot read the secret, grant the Octavia service user an ACL on that secret and retry. Application security groups must allow TCP 80 from the load balancer. See Using Security Groups.

Renew

Let's Encrypt certificates last 90 days. certbot.timer runs certbot renew on the extra instance. After a successful renew, store a new Key Manager secret and point the listener at it:

openstack loadbalancer listener set \
  --default-tls-container-ref "$NEW_SECRET" https-listener

Leave acme-01 and the HTTP listener in place. Application traffic uses 443. If you later redirect HTTP to HTTPS, send /.well-known/acme-challenge to acme-01 first (one L7 policy) or renewal fails.