Containerized MID Server
Summarize
Summary of Containerized MID Server
Containerized MID Server leverages Docker images to facilitate swift deployment of MID Servers at scale, utilizing orchestration tools like OpenShift or Kubernetes for automation in deployment and maintenance. This enables customers to handle new container demands and replace failed ones easily.
Show less
Key Features
- System Requirements: Supports AlmaLinux; Docker recipes are available for current releases only.
- Container Creation: New MID Server containers can be created with configuration parameters managed via environment variables or secret files.
- Orphaned MID Server Cleanup: A scheduled job purges down MID Servers older than the configured retention days, enhancing system cleanliness.
- Health Monitoring: Implemented health checks every 5 minutes to monitor MID Server statuses; failures are recorded after consecutive missed heartbeats.
- Basic Operations: Standard Docker commands enable starting, stopping, and restarting containers easily.
- Auto-configuration: Allows for rapid deployment and configuration of MID Servers through a MID Server Profile, making them ready for use within seconds.
Key Outcomes
By implementing Containerized MID Servers, customers can expect streamlined and scalable MID Server deployment, improved maintenance automation, and enhanced operational efficiency. The ability to auto-configure and manage containers simplifies the setup process, allowing for quicker response times to changing demands.
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.