Containerized MID Server

  • Release version: Washingtondc
  • Updated February 1, 2024
  • 4 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Containerized MID Server

    Containerized MID Server utilizes Docker images to facilitate rapid deployment and scaling of MID Servers through orchestration tools like OpenShift and Kubernetes. This approach allows for automated deployment, maintenance, and dynamic management of containerized MID Servers.

    Show full answer Show less

    Key Features

    • Deployment and Configuration: Docker recipes for Linux can be downloaded to build images for the current release. Configuration parameters can be set using environment variables or secret files.
    • Identification: Container IDs differentiate between containerized and regular MID Servers, with container IDs assigned upon creation.
    • Purge Process: A scheduled job automatically removes orphaned MID Servers after a specified retention period, with default settings of 30 days for retention and 7 days for warnings.
    • Auto-Upgrade: While auto-upgrade is supported, it is recommended to disable it for containerized MID Servers in favor of manual deployments via updated YAML files.
    • Health Checks: A health check mechanism monitors MID Server status based on heartbeat signals, marking a server as unhealthy after three consecutive failures.

    Key Outcomes

    ServiceNow customers can expect efficient scaling and management of MID Servers using containerized solutions. The deployment process is streamlined, allowing for quick setup and configuration through orchestration tools, enabling enhanced operational efficiency. Additionally, customers can maintain control over MID Server updates and health monitoring, ensuring optimal performance within their 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.

    Setup indicator for configuration phaseEnsure that the MID Server can connect to elements inside and outside your networkDownload and install the MID Server on a Linux or Windows hostConfigure your MID ServerConfigure MID Server securityEnsure that the MID Server can connect to elements inside and outside your networkDownload and install the MID Server on a Linux or Windows hostConfigure your MID ServerConfigure MID Server security

    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.

    Containerized MID Server system requirements:

    • 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

    Basic operations are supported on container side. For example, you can stop, start, or restart a running container using Docker commands.
    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.