Containerized MID Server Deployment and Auto-configuration

Release version: Zurich

Updated July 31, 2025

4 minutes to read

Summarize

Summarized using AI

Summary of Containerized MID Server Deployment and Auto-configuration

This feature enables ServiceNow customers to deploy and manage MID Servers efficiently using container technology such as Kubernetes (K8s) or OpenShift. By leveraging containerized MID Servers based on Docker images, deployment becomes faster, scalable, and easier to automate. The process integrates tightly with ServiceNow instance profiles, enabling automated configuration and management of MID Servers in containerized environments.

Show full answer Show less

Key Features

MID Server Profiles: Profiles store all configuration settings needed for new MID Servers, excluding sensitive data like passwords and certificates, which are managed separately via Kubernetes Secrets. Profiles support multiple MID Server deployments without requiring individual server names.
Deployment Requests: Users with the agentadmin role can create deployment requests based on profiles and export these requests as Kubernetes YAML files to deploy MID Servers seamlessly into container clusters.
Docker Image Preparation: Customers build MID Server Docker images on Kubernetes clusters and upload them to image registries for container deployment. Instructions include pulling images locally for deployment.
Kubernetes Setup: Proper Role-Based Access Control (RBAC) configuration is required to ensure the Kubernetes service account has permissions to manage MID Server resources. Examples for default and custom namespaces are provided.
Secrets Management: Sensitive files such as mid-secrets.properties or PEM certificates are stored as Kubernetes Secrets, enhancing security for mutual authentication.
Auto-Configuration: When a containerized MID Server connects for the first time, the system automatically creates and configures its MID Server record on the instance using the profile settings.
Profile Synchronization: Profiles can be synchronized to existing MID Servers to keep configurations consistent, with the option to manually trigger a sync on the instance.

Practical Benefits for ServiceNow Customers

Accelerated Deployment: Quickly deploy multiple MID Servers using container orchestration tools without manual configuration for each server.
Centralized Configuration Management: Use MID Server profiles to standardize configurations and simplify updates across multiple MID Servers.
Improved Security: Manage sensitive data securely through Kubernetes Secrets rather than embedding them in profiles or deployment manifests.
Scalability and Flexibility: Easily scale MID Server deployments in cloud-native environments like Kubernetes or OpenShift.
Reduced Administrative Overhead: Automated creation and configuration reduce manual tasks and errors during MID Server provisioning.

Important Considerations

Ensure Kubernetes service accounts have appropriate RBAC permissions for MID Server lifecycle operations.
When assigning MID Servers to clusters, make sure each server has at least one capability assigned to avoid assignment failures.
Sensitive credentials must be managed outside profiles in Secrets to maintain security best practices.

An agent admin can enter a MID Server Profile and create a deployment request on the instance. She/he can then export the deployment request to a YAML file and use it to deploy MID Servers to Kubernetes or OpenShift cluster.

Containerized MID Servers use a Docker image of the MID Server that allows you to quickly deploy MID Servers. The documentation for Build MID Server Docker Image for Linux provides steps for manually preparation and deployment. The following Containerized MID Server auto-configuration simplifies the process and makes it scalable.

MID Server profile

A MID Server profile contains all the settings required to configure a new MID Server, excluding sensitive data such as passwords and certificates. Sensitive data should be passed through Secrets created on the K8s cluster. The user only enters secret names and locations in the deployment request. An agent_admin role is required to create or change profiles. MID Server profiles are stored in the following tables:

mid_server_profile
mid_profile_config
mid_profile_wrapper_config
mid_profile_property
mid_profile_application_m2m
mid_profile_capability_m2m
mid_profile_ip_range_m2m
mid_profile_cluster_m2m

During deployment, the mid_profile_config and mid_profile_wrapper_config parameters are sent to the K8s cluster. These parameters populate the config.xml and wrapper-override.conf of the new MID Server. The other parameters are used by the auto-configuration on the instance. The user can access the MID Server profile from the module MID Server Profiles on the instance.

The MID Server name is not required in a profile because a profile can be used to deploy multiple MID Servers. Instead, the user is asked to enter MID Server names as part of a new deployment request. For the mid_profile_wrapper_config, the user can enter any parameters that they want to see in wrapper-override.conf. For example:


Name	Value
wrapper.java.maxmemory	2048
wrapper.java.additional.3	-Djavax.net.debug=ssl:handshake

Other profile settings can be entered the same way as on a MID Server record.

MID Server Deployment Request

After creating a MID server profile, the user can make a new deployment request to prepare the deployment process. A deployment request can be different for different container orchestrators. See MID Server Deployment Request for more information.

Export MID Deployment Request for Manual Deployment

The user can export it to a K8s deployment YAML file. The user can download the YAML file to the K8s cluster and deploy new MID Servers with the following command: kubectl apply –f <yaml_file>

Docker image preparation

To prepare a Docker image, first build a MID Server image on a K8s cluster as explained in Build MID Server Docker Image. Upload the built image to an image registry and pull the image to a local image with the command: docker pull registry/mid:<tag>. Refer to Docker Registry Setup for Containerized MID Server II: Auto Configuration [KB1001380] for information on limitations on pulling an image directly from a remote registry.

Kubernetes preparation

Kubernetes service account setup

Ensure the service account has the proper RBAC set up to create, delete, and list permission for resources. The following example YAML file uses the default service account:

apiVersion: rbac.authorization.k8s.io/v1 
 kind: ClusterRoleBinding 
 metadata:   
    name: default-service-acccount-as-cluster-admin 
 subjects:   

  - kind: ServiceAccount 
    # Reference to upper's `metadata.name`     
    name: default 
    # Reference to upper's `metadata.namespace`     
    namespace: default 
 roleRef:   
    kind: ClusterRole 
    name: cluster-admin 
    apiGroup: rbac.authorization.k8s.io

You may choose a custom service account and assign a ClusterRole to that service account and name space. The default name space is default. The following example YAML file uses a custom name space, mynamespace.

apiVersion: rbac.authorization.k8s.io/v1 
 kind: ClusterRoleBinding 
 metadata:   
    name: custom-serviceacccount-as-cluster-admin 
 subjects:   

  - kind: ServiceAccount 
    # Reference to upper's `metadata.name`     
    name: mycustomserviceaccount 
    # Reference to upper's `metadata.namespace`     
    namespace: mynamespace 
 roleRef:   
    kind: ClusterRole 
    name: cluster-admin 
    apiGroup: rbac.authorization.k8s.io

Kubernetes Secret setup

Secrets are created for mid-secrets.properties or PEM files for mutual authentication. For more information about how to create a Secret, see the section in Containerized MID Server.

Auto-configure new Containerized MID Servers

When a MID server is connected to the instance for the first time, a MID Server record is created. The MID Server record is populated with the container ID, profile ID and deployment name. The Auto-Configure MID from profile business rule is triggered when the new MID Server record is updated with a profile ID in the profile_id field. The business rule looks up the profile settings associated with that profile ID and configures the new MID server accordingly.

Sync MID Server Profile to existing MID Servers

The MID Server profile can be out-of-sync with the settings of existing MID Servers if the user updates the profile long after the related MID Servers were auto-configured. The user can synchronize the profile settings to the existing MID Server by selecting Sync to MID Servers on the instance.

Note:

When applying cluster settings from MID Server profile to a MID Server, the cluster assignment will fail if the MID Server doesn't have any capability assigned. It is controlled by the "validate MID server capability" business rule on the ecc_agent_cluster_member_m2m table. If you want to assign a MID server to a cluster, please make sure it has some capabilities.