Containerized MID Server Deployment and Auto-configuration

Release version: Yokohama

Updated January 30, 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 containerized MID Servers efficiently using Kubernetes (K8s) or OpenShift clusters. It leverages Docker images for rapid deployment and provides an automated configuration process that scales easily. The system uses MID Server profiles to define configuration settings, excluding sensitive information, which is managed securely via Kubernetes Secrets.

Show full answer Show less

MID Server Profiles

MID Server profiles contain all non-sensitive configuration settings needed to deploy MID Servers.
Passwords and certificates are handled separately through Kubernetes Secrets, referenced by name and location in deployment requests.
Profiles are stored across multiple tables that manage configurations, properties, capabilities, IP ranges, and clustering.
Profiles can be reused to deploy multiple MID Servers; individual MID Server names are specified during deployment requests.
Users with the agentadmin role can create or modify profiles via the MID Server Profiles module.

MID Server Deployment Request and Export

After creating a profile, users submit a deployment request tailored to the container orchestrator.
Deployment requests can be exported as Kubernetes YAML files, which can then be applied directly to the cluster using kubectl apply -f <yamlfile>.

Docker Image and Kubernetes Preparation

Customers must build a MID Server Docker image following documented instructions and upload it to a container registry.
The image is pulled to the Kubernetes cluster before deployment.
Kubernetes service accounts require appropriate RBAC permissions (create, delete, list) to manage MID Server resources; examples provided for default and custom namespaces.
Secrets must be created in Kubernetes to securely provide sensitive MID Server data such as mid-secrets.properties and PEM files for mutual authentication.

Auto-configuration and Synchronization

When a new containerized MID Server connects to ServiceNow for the first time, a MID Server record is automatically created and linked to its profile and deployment.
An automated business rule applies the profile settings to configure the MID Server without manual intervention.
Users can synchronize profile updates to existing MID Servers if changes are made after deployment, ensuring settings remain consistent.
Note: Cluster assignments require MID Servers to have assigned capabilities; otherwise, assignment will fail due to validation rules.

Practical Benefits for ServiceNow Customers

Accelerates deployment of MID Servers in container environments using standardized profiles and automation.
Improves security by separating sensitive credentials into Kubernetes Secrets.
Supports scalable management of multiple MID Servers through reusable profiles and automated synchronization.
Facilitates integration with Kubernetes infrastructure through clear RBAC and secret management guidance.

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.