Configuring Ignition 8.3.8 Docker Gateway Redundancy

Both Ignition gateways run, but redundancy configuration fails: the backup records activity while the master shows no incoming connection. Follow the packet from frontend02 to frontend01. The working configuration uses Docker service-name resolution and TCP port 8060, while publishing each gateway web interface separately on host ports 9988 and 9989.

Which redundancy approaches decide this case?

Use frontend01 as the backup gateway's destination. Docker's internal name resolution keeps the connection tied to the Compose service rather than to a manually selected container address. Keep the host web mappings separate from the internal gateway-to-gateway path: 9988:8088 belongs to frontend01, while 9989:8088 belongs to frontend02.

Where does the connection travel?

The web mappings prove only that each administration interface is reachable through the Docker host. They do not prove that frontend02 can resolve frontend01 or open frontend01:8060 across the internal network. Layer one first in a physical system; in this virtual path, begin with container attachment, interface state, and bridge membership before interpreting application logs.

A log entry on the backup does not establish that the request reached the master. Locate the last successful hop: name resolution, TCP establishment, connection approval, or redundancy negotiation. When the master has no incoming connection, prioritize the path before changing redundancy roles.

Why can a fixed bridge address fail?

A fixed address such as 192.168.100.2 works only when it identifies the intended master container from the backup's network namespace. An address conflict, attachment to different Docker networks, an incorrect subnet, or traffic interception can stop the request before Ignition receives it. A reachable host-published web port does not rule out any of those faults because it follows a different path.

Service-name addressing removes dependence on the manually entered bridge address. Within a Compose network, the service name represents the destination service. This is the decisive difference in the working configuration: GATEWAY_NETWORK_0_HOST=frontend01 replaces the unsuccessful master-node address, and GATEWAY_NETWORK_0_PORT=8060 identifies the internal connection port.

Do not substitute host ports 9988 or 9989 for 8060. Those published ports forward browser traffic to container port 8088; they are not the configured Gateway Network destination in this setup.

How should the two services be configured?

Both services also use TZ=America/Los_Angeles, ACCEPT_IGNITION_EULA=Y, GATEWAY_ADMIN_USERNAME=admin, GATEWAY_ADMIN_PASSWORD=password, IGNITION_EDITION=standard, and DISABLE_QUICKSTART=true in the demonstrated environment. Replace the demonstrated administrator password according to the deployment's credential policy.

Remove GATEWAY_NETWORK_SECURITYPOLICY=SpecifiedList and GATEWAY_NETWORK_WHITELIST=frontend02 from the master for this redundancy configuration. They were initially considered for the master but do not match the resulting redundancy identity: after redundancy is configured, the backup uses frontend01-backup as its Gateway Area Network name.

What procedure isolates and fixes the failure?

1. Confirm that both containers are running and attached to the same intended Docker network. Record the network and addresses actually assigned rather than relying on the planned 192.168.100.0/24 layout.
2. Open the two web interfaces through 9988:8088 and 9989:8088. Treat this only as proof that each gateway is alive.
3. From the backup container's network context, resolve frontend01. If it does not resolve to the master service, correct Compose network membership or the service name.
4. Test TCP reachability from the backup to frontend01:8060. If name resolution works but the TCP connection fails, inspect the bridge, container listeners, address conflicts, and any proxy or filtering layer.
5. Set GATEWAY_NETWORK_0_HOST=frontend01 and GATEWAY_NETWORK_0_PORT=8060 on frontend02.
6. Leave the corresponding outbound Gateway Network target off frontend01 for this two-node arrangement. Remove the stated specified-list policy and frontend02 whitelist entries from the master.
7. Start the services with gateway names frontend01 and frontend02, configure frontend01 as master and frontend02 as backup, then approve the pending connection in the gateway interface where it appears.

How do you verify the corrected path?

Verify each layer in order. First, confirm that frontend01 resolves inside the backup container. Second, confirm a TCP connection to frontend01:8060. Third, check that the master now displays the incoming gateway connection. Fourth, confirm that the redundancy configuration completes and that the backup's resulting Gateway Area Network name is frontend01-backup.

If the backup continues logging connection attempts while the master remains empty, the request is still stopping before master-side application processing. Return to service-name resolution and TCP reachability; repeated approval changes cannot repair a failed network hop.

FAQ