--- sourceDocument: Australia ServiceNow AI Platform Capabilities sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/de-DE/servicenow-platform Release : - australia ft:locale : - de-DE ft:publication_title : - Australia ServiceNow AI Platform Capabilities ft:clusterId : - platcap bundleId : - platcap workflow : - Platform --- # Containerized MID Server Deployment and Auto-configuration # Containerized MID Server Deployment and Auto-configuration {#ariaid-title1} * Freigeben Version: Australia * * Aktualisiert 12. März 2026 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 Minuten Lesedauer 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-deployment__table_p53_ms4_nhb} 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](https://servicenow-prod.fluidtopics.net/wPUMpvoswSZaf3dwOApWLA#mid-build-docker-linux "Deploy Containerized MID Servers on Linux by creating a Docker image with the provided recipes. Containerized MID Server uses a Docker image of the MID Server that allows you to quickly deploy MID Servers at scale.") provides steps for manually preparation and deployment. The following Containerized MID Server auto-configuration simplifies the process and makes it scalable. ## MID Server profile {#containerized-mid-deployment__section_jkw_fk3_fsb} 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 {#containerized-mid-deployment__ul_u3y_kdd_3sb} 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 | [ ] {#containerized-mid-deployment__table_jv2_nk3_fsb} Other profile settings can be entered the same way as on a MID Server record. ## MID Server Deployment Request {#containerized-mid-deployment__section_q1k_hzc_3sb} 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](https://servicenow-prod.fluidtopics.net/pkYkk38LM2g31uhn_D7OZw "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.") for more information. ## Export MID Deployment Request for Manual Deployment {#containerized-mid-deployment__section_jcp_5yc_3sb} 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 ` ## Docker image preparation {#containerized-mid-deployment__section_hdl_zyc_3sb} To prepare a Docker image, first build a MID Server image on a K8s cluster as explained in [Build MID Server Docker Image](https://servicenow-prod.fluidtopics.net/wPUMpvoswSZaf3dwOApWLA#mid-build-docker-linux "Deploy Containerized MID Servers on Linux by creating a Docker image with the provided recipes. Containerized MID Server uses a Docker image of the MID Server that allows you to quickly deploy MID Servers at scale."). Upload the built image to an image registry and pull the image to a local image with the command: `docker pull registry/mid:`. Refer to [Docker Registry Setup for Containerized MID Server II: Auto Configuration \[KB1001380\]](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1001380) for information on limitations on pulling an image directly from a remote registry. ## Kubernetes preparation {#containerized-mid-deployment__section_ldl_zyc_3sb} See also [How to build and deploy Containerized MID Servers in Kubernetes using StatefulSets \[KB1325173\]](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1325173). 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](https://servicenow-prod.fluidtopics.net/GTFC57oWge8MP9PgOgVLDg "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."). ## Auto-configure new Containerized MID Servers {#containerized-mid-deployment__section_l5p_ym3_fsb} 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 {#containerized-mid-deployment__section_d4j_cn3_fsb} 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. Hinweis: 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.