Containerized MID Server Deployment and Auto-configuration

Release version: Xanadu

Updated August 1, 2024

4 minutes to read

Summarize

Summarized using AI

Summary of Containerized MID Server Deployment and Auto-configuration

This feature enables ServiceNow customers to deploy MID Servers in containerized environments such as Kubernetes or OpenShift using Docker images. It streamlines and scales MID Server deployment by leveraging MID Server profiles and deployment requests that can be exported as YAML files for easy application in container orchestration platforms.

Show full answer Show less

MID Server Profiles

A MID Server profile contains all necessary configuration settings except sensitive data, which must be managed separately using Kubernetes Secrets. Profiles are created or modified by users with the agentadmin role and stored in multiple ServiceNow tables. Profiles exclude the MID Server name, allowing a single profile to be reused for multiple deployments.

During deployment, key configuration parameters from the profile populate the MID Server’s config.xml and wrapper-override.conf files, enabling customization such as memory allocation or Java options.

MID Server Deployment Request

After creating a profile, users generate a deployment request specifying MID Server names and secret locations. This request can be exported as a Kubernetes deployment YAML file, which can then be applied directly to the cluster using kubectl apply. Different container orchestrators may require different deployment request formats.

Docker Image and Kubernetes Setup

Docker Image Preparation: Customers build the MID Server Docker image following documented steps, upload it to a container registry, and pull it locally for deployment.
Kubernetes Preparation: Set up appropriate RBAC permissions for service accounts to manage resources, as illustrated by sample ClusterRoleBinding YAML configurations. Customers can use either the default namespace or custom namespaces with assigned service accounts.
Secrets Management: Sensitive data such as passwords and certificates must be stored in Kubernetes Secrets and referenced in deployment requests to ensure secure authentication and configuration.

Auto-configuration and Synchronization

When a containerized MID Server connects to the ServiceNow instance for the first time, a MID Server record is automatically created and configured based on the associated profile via a business rule. If profile settings are updated after deployment, customers can synchronize changes to existing MID Servers by using the “Sync to MID Servers” option on the instance, ensuring consistent configuration across all servers.

Benefits for ServiceNow Customers

Rapid, scalable deployment of MID Servers in containerized environments using standardized profiles.
Secure handling of sensitive configuration data through Kubernetes Secrets.
Automated configuration reduces manual setup effort and errors.
Flexibility to deploy multiple MID Servers from a single profile and maintain synchronization over time.

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.