Containerized MID Server
Summarize
Summary of Containerized MID Server
The Containerized MID Server leverages a Docker image to enable rapid, scalable deployment of MID Servers. These servers are managed through orchestration platforms like OpenShift or Kubernetes, which automate deployment, maintenance, scaling, and container replacement. This solution is designed for efficient MID Server management in dynamic, containerized environments.
Show less
Key Features
- Docker Image and Recipes: Downloadable Linux Docker recipes are provided to build the current release images. These recipes are signed and zipped for security and integrity. Note that they support AlmaLinux and are not backward compatible with older MID Server versions.
- Configuration: Containers are configured using environment variables or secret files, supporting Docker, OpenShift, and Kubernetes secrets for secure parameter management.
- Container Identification: Each containerized MID Server gets a unique container ID, distinguishing it from traditional MID Servers, which have null or empty container ID fields.
- Orphaned Container Cleanup: A scheduled job runs daily to remove downed or orphaned containerized MID Servers after a configurable retention period (default 30 days). Warning notifications occur 7 days before removal.
- Auto-upgrade Management: Auto-upgrade is enabled by default but is recommended to be disabled for containerized MID Servers. Upgrades should be managed by building new images and updating deployment YAML files manually.
- Health Monitoring: A built-in HEALTHCHECK verifies MID Server heartbeat every 5 minutes, marking the container unhealthy after 3 consecutive missed heartbeats (no heartbeat for 30 minutes).
- Basic Container Operations: Standard Docker commands (stop, start, restart) are supported for managing container lifecycle.
- Deployment and Auto-configuration: MID Server Profiles on the ServiceNow instance allow admins to define all required settings and submit deployment requests to the Kubernetes cluster. This process automates creation and configuration of MID Servers, enabling them to be operational within seconds. Profile changes can trigger on-demand updates to running containerized MID Servers.
Practical Implications for ServiceNow Customers
Using Containerized MID Servers enables ServiceNow customers to deploy and manage MID Servers at scale with improved automation, reliability, and security in container orchestration environments. Customers should plan to use the latest Linux recipes, manage configuration via environment variables or secrets, and handle upgrades through image rebuilds and re-deployment rather than relying on automatic upgrades. Scheduled cleanup ensures that stale or failed containers do not linger, maintaining system hygiene. Health checks provide visibility into container status for operational monitoring.
This approach streamlines MID Server management, reduces manual intervention, and supports dynamic scaling needs common in modern IT environments.
Containerized MID Server uses a Docker image of the MID Server that allows you to quickly deploy MID Servers at scale. MID Servers are deployed using orchestration tools like OpenShift or Kubernetes. Orchestration tools can automate their deployment and maintenance and add new containers on demand or replace failed containers automatically.
To use Containerized MID Servers, you can download Docker recipes for Linux from the MID Server download page. Use the recipes to build the Docker images for the current release. The recipes are zipped and signed. Some features have been deprecated for the Washington DC family release. See [KB1559617] Deprecated Containerized MID Server Features in Washington DC for more information.
AlmaLinux is supported.
The recipes cannot be used to build images for previous MID Server versions.
Discovery of NMAP and CyberArk are not supported.
Other applications such as Orchestration and Integration Hub are not certified.
Once the Docker images are available, you can create new MID Server containers and configure them with configuration parameters passed through environment variables or secret files. Docker, Openshift, and Kubernetes secrets are supported. The MID Server application inside the container is run as a process by a non-admin user.
When a containerized MID Server record is first created on the instance, a random UUID is created and set to the container_id column. During the start-up sequence, this value is replaced by the actual container ID. The container ID can be used to differentiate between containerized and regular MID Servers. Non-containerized MID Servers' container ID have a null or empty value.
In order to automatically clean up the down MID Servers on Instance, a scheduled job called Purge Orphaned Containerized MID Servers is scheduled to run daily. This job removes orphaned containerized MID Servers if they are down longer than the value set by the max_retention_days property. The job also creates a warning MID Server issue each day before the removal day, if there are equal to or less than the value of warn_days remaining. The default values for max_retention_days and warn_days are 30 and 7, respectively.
Auto-upgrade
Auto-upgrade works the same way for containerized MID Servers as it does for regular MID Servers. However, it is recommended to disable the auto-upgrade for containerized MID Servers. Whenever a new image is needed, build a new image and deploy it by updating the deployment YAML file then re-apply it.
Containerized MID Server auto-upgrade is controlled by the mid.container.autoupgrade.enabled config parameter and is set to true by default. The config parameter is read-only, therefore it can not be synced down from the instance.
Add the config parameter to a MID Server profile and use it with new deployment requests. The settings are then included in deployment YAML file when the deployment request is exported, or when it is manually added to an existing deployment YAML file and re-applied.
HealthCheck
A HEALTHCHECK rule is implemented to check MID Server health status based on heartbeat every 5 minutes. If there was no heartbeat activity in last 30 minutes, it is considered a failure. After 3 consecutive failures, it becomes unhealthy in the docker ps command output.
To see more HealthCheck details, run the following docker inspection command: docker inspect --format='{{json .State.Health}}' <container-id>
Basic Container Operations
- docker stop <container_id>
- This command shuts down the containerized MID Server.
- docker start <container_id>
- This command starts a containerized MID Server if it is stopped.
- docker restart <container_id>
- This command shuts down a MID Server and restarts it.
Build MID Server Docker Image
Build a MID Server Docker Image with the provided recipes to deploy a Containerized MID Server. Containerized MID Server uses a Docker image of the MID Server that allows you to quickly deploy MID Servers at scale.
Containerized MID Server Deployment and Auto-configuration
With the deployment and auto-configuration feature, an agent admin can enter all required MID Server settings in a MID Server Profile on the instance and then submit a deployment request to K8s cluster. After the request is processed, the new MID servers are automatically created and auto-configured. They are ready to use in seconds. If the MID Server profile is changed, the related Containerized MID Servers can also be updated on demand.