This article describes how to replace an Error instance with zero downtime when using containers.
This does not include the complete process, only the steps specific to container deployments.
For an overview of the process and details for other deployment scenarios, see Replacing an Error Instance.
Disable error message ingestion
If migrating from ServiceControl on Windows to containerized deployment, care is needed to ensure that instances can communicate with each other.
- All instances will need access to the message queue infrastructure at all times.
- The active ServiceControl Error instance must be able to communicate over HTTP with all active Audit instances.
This guide assumes this is true, and that the user knows how to create routable URLs to allow the communication, even if one instance is hosted on a virtual machine and another instance is running on containerized infrastructure.
Additionally, if the old Error instance is not deployed on containers, refer to the instructions for ServiceControl Management or PowerShell.
Modify the old Error instance container by specifying the INGESTERRORMESSAGES environment variable with a value of false.
Replace the Error instance
Deploy a new Error instance container with its own database container. The REMOTEINSTANCES environment variable should match the configuration of the old Error instance so that it can communicate to the same Audit instance(s).
Now, the old and new Error instances are both available, but the old Error instance is not ingesting messages.
When confident of a successful upgrade, the old Error instance can be removed. If the old Error instance is not deployed in a container, refer to the instructions for removing the old instance in the ServiceControl Management or PowerShell guides.