---
sourceDocument: Options de la plateforme d’IA ServiceNow de Yokohama
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/fr-FR/yokohama/servicenow-platform

 Release :

    - yokohama

ft:locale :

    - fr-FR

ft:publication_title :

    - Options de la plateforme d’IA ServiceNow de Yokohama

ft:clusterId :

    - platcap

bundleId :

    - platcap

workflow :

    - Platform


---

# Déploiement et auto-configuration d'un serveur MID conteneurisé

# Déploiement et auto-configuration d'un serveur MID conteneurisé {#ariaid-title1}

* Rversion finale: Yokohama
* 
* Mis à jour 30 janv. 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 5 minutes de lecture

Un administrateur d'agent peut entrer un profil de serveur MID et créer une demande de déploiement sur l'instance. Il peut ensuite exporter la demande de déploiement vers un fichier YAML et l'utiliser pour déployer des serveurs MID sur un cluster Kubernetes ou OpenShift.

|-|
|   |
[ ]

{#containerized-mid-deployment__table_p53_ms4_nhb} Les serveurs MID conteneurisés utilisent une image Docker du serveur MID qui vous permet de déployer rapidement des serveurs MID. La documentation de [Créer une image Docker de serveur MID pour Linux](https://servicenow-prod.fluidtopics.net/tkM5eBiloYR4A0gU9Z_TeQ#mid-build-docker-linux "Déployez des serveurs MID conteneurisés sur Linux en créant une image Docker avec les recettes fournies. Le serveur MID conteneurisé utilise une image Docker du serveur MID qui vous permet de déployer rapidement des serveurs MID à grande échelle.") fournit des étapes pour la préparation et le déploiement manuels. La configuration automatique du serveur MID conteneurisé ci-dessous simplifie le processus et le rend évolutif.

## Profil du serveur MID {#containerized-mid-deployment__section_jkw_fk3_fsb}

Un profil de serveur MID contient tous les paramètres requis pour configurer un nouveau serveur MID, à l'exclusion des données sensibles telles que les mots de passe et les certificats. Les données sensibles doivent être transmises via les secrets créés sur la grappe K8s. L'utilisateur saisit uniquement des noms et des emplacements secrets dans la demande de déploiement. Un rôle agent_admin est requis pour créer ou modifier les profils. Les profils de serveur MID sont stockés dans les tables suivantes :

* 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}

Pendant le déploiement, les paramètres mid_profile_config et mid_profile_wrapper_config sont envoyés au cluster K8s. Ces paramètres renseignent le `config.xml` et le `fichier wrapper-override.conf` du nouveau serveur MID. Les autres paramètres sont utilisés par l'auto-configuration sur l'instance. L'utilisateur peut accéder au profil du serveur MID à partir du module Profils du serveur MID sur l'instance.

Le nom de serveur MID n'est pas requis dans un profil, car un profil peut être utilisé pour déployer plusieurs serveurs MID. À la place, l'utilisateur est invité à saisir des noms de serveur MID dans le cadre d'une nouvelle demande de déploiement. Pour la mid_profile_wrapper_config, l'utilisateur peut entrer tous les paramètres qu'il souhaite afficher dans `wrapper-override.conf`. Par exemple :

|-|-|
| Nom | Valeur |
| wrapper.java.maxmemory | 2048 |
| wrapper.java.supplémentaire.3 | -Djavax.net.debug=ssl :poignée de main |
[ ]

{#containerized-mid-deployment__table_jv2_nk3_fsb}

Vous pouvez entrer d'autres paramètres de profil de la même manière que sur un enregistrement de serveur MID.

## Demande de déploiement de serveur MID {#containerized-mid-deployment__section_q1k_hzc_3sb}

Après avoir créé un profil de serveur MID, l'utilisateur peut effectuer une nouvelle demande de déploiement pour préparer le processus de déploiement. Une demande de déploiement peut être différente pour différents orchestrateurs de conteneur. Consultez [Demande de déploiement de serveur MID](https://servicenow-prod.fluidtopics.net/io5V1RinF4JuSHZl8OQ4Bg "Après avoir créé un profil de serveur MID, l’utilisateur peut effectuer une nouvelle demande de déploiement pour préparer le processus de déploiement. Une demande de déploiement peut être différente pour différents orchestrateurs de conteneur.") pour plus d'informations.

## Exporter la demande de déploiement MID pour un déploiement manuel {#containerized-mid-deployment__section_jcp_5yc_3sb}

L'utilisateur peut l'exporter vers un fichier YAML de déploiement K8s. L'utilisateur peut télécharger le fichier YAML sur la grappe K8s et déployer de nouveaux serveurs MID à l'aide de la commande suivante : `kubectl apply --f <yaml_file>`

## Préparation de l'image de Docker {#containerized-mid-deployment__section_hdl_zyc_3sb}

Pour préparer une image Docker, créez d'abord une image de serveur MID sur un cluster K8s, comme expliqué dans [Créer une image Docker de serveur MID](https://servicenow-prod.fluidtopics.net/tkM5eBiloYR4A0gU9Z_TeQ#mid-build-docker-linux "Déployez des serveurs MID conteneurisés sur Linux en créant une image Docker avec les recettes fournies. Le serveur MID conteneurisé utilise une image Docker du serveur MID qui vous permet de déployer rapidement des serveurs MID à grande échelle."). Chargez l'image générée dans un registre d'images et extrayez l'image vers une image locale avec la commande : `docker pull registry/mid :<tag>`. Consultez Configuration du [registre Docker pour Serveur MID conteneurisé II : configuration automatique \[KB1001380\]](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1001380) pour plus d'informations sur les limitations liées à l'extraction d'une image directement à partir d'un registre distant.

## Préparation Kubernetes {#containerized-mid-deployment__section_ldl_zyc_3sb}

Voir également [Comment construire et déployer des serveurs MID conteneurisés dans Kubernetes à l'aide de StatefulSets \[KB1325173\].](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1325173)  
Configuration du compte de service Kubernetes  
Assurez-vous que le RBAC approprié est configuré pour le compte de service, afin de créer, supprimer et répertorier les autorisations pour les ressources. L'exemple de fichier YAML suivant utilise le compte de service par défaut :

    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

Vous pouvez choisir un compte de service personnalisé et affecter un ClusterRole à ce compte de service et à cet espace de noms. L'espace de nom par défaut est défini par défaut. L'exemple de fichier YAML suivant utilise un espace de noms personnalisé, 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

Configuration secrète Kubernetes

Des secrets sont créés pour les fichiers mid-secrets.properties ou PEM pour l'authentification réciproque. Pour plus d'informations sur la création d'un secret, reportez-vous à la section .[Serveur MID conteneurisé](https://servicenow-prod.fluidtopics.net/7lJRaSSwj_hlO6fOfF0KnA "Le serveur MID conteneurisé utilise une image Docker du serveur MID qui vous permet de déployer rapidement des serveurs MID à grande échelle. Les serveurs MID sont déployés à l’aide d’outils d’orchestration tels qu’OpenShift ou Kubernetes. Les outils d’orchestration peuvent automatiser leur déploiement et leur maintenance et ajouter de nouveaux conteneurs à la demande ou remplacer automatiquement les conteneurs défaillants.")

## Configurer automatiquement les nouveaux serveurs MID conteneurisés {#containerized-mid-deployment__section_l5p_ym3_fsb}

Lorsqu'un serveur MID est connecté à l'instance pour la première fois, un enregistrement de serveur MID est créé. L'enregistrement du serveur MID contient l'ID de conteneur, l'ID de profil et le nom du déploiement. La règle métier Configurer automatiquement le MID à partir du profil est déclenchée lorsque le nouvel enregistrement de serveur MID est mis à jour avec un ID de profil dans le champ profile_id . La règle métier recherche les paramètres de profil associés à cet ID de profil et configure le nouveau serveur MID en conséquence.

## Synchroniser le profil du serveur MID avec les serveurs MID existants {#containerized-mid-deployment__section_d4j_cn3_fsb}

Le profil du serveur MID peut être désynchronisé avec les paramètres des serveurs MID existants si l'utilisateur met à jour le profil longtemps après que les serveurs MID connexes ont été configurés automatiquement. L'utilisateur peut synchroniser les paramètres de profil avec le serveur MID existant en sélectionnant Synchroniser avec les serveurs MID sur l'instance.  
Remarque :  
Lors de l'application des paramètres de grappe du profil de serveur MID à un serveur MID, l'affectation de grappe échouera si aucune aptitude n'est affectée au serveur MID. Il est contrôlé par la règle métier \<\< valider l'aptitude du serveur MID \>\> sur la table ecc_agent_cluster_member_m2m. Si vous souhaitez affecter un serveur MID à une grappe, assurez-vous que celui-ci dispose de certaines options.

