--- 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 --- # Créer une image Docker de serveur MID pour Linux # Créer une image Docker de serveur MID pour Linux {#ariaid-title1} * Rversion finale: Yokohama * * Mis à jour 30 janv. 2025 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 13 minutes de lecture 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. ## Avant de commencer Rôle requis : admin |-| | | [ ] {#mid-build-docker-linux__table_p53_ms4_nhb} Conditions préalables : L'hôte doit utiliser le [moteur Docker et l'interface de ligne de commande (CLI) 20.10.4 ou version ultérieure](https://docs.docker.com/desktop/install/linux-install/). Mettez à jour la bibliothèque vers la version la plus récente disponible, ou au moins la version la plus élevée avec un correctif de sécurité. Si les problèmes identifiés font partie d'une dépendance transitive, recherchez une version de la bibliothèque dépendante qui inclut une version transitive plus récente. Si la dépendance transitive ne peut pas être mise à niveau en mettant à niveau la bibliothèque dépendante, envisagez d'exclure la dépendance et d'inclure directement une version sécurisée. Remarque : Vérifiez la disponibilité de Docker en exécutant la commande de version de Docker en tant qu'administrateur. Voir la [documentation de la commande docker version](https://docs.docker.com/engine/reference/commandline/version/) pour plus d'informations. ## Procédure 1. Téléchargez le fichier ZIP de la recette Linux Docker à partir de la page de téléchargement du serveur MID et vérifiez sa signature. Pour plus d'informations sur la page de téléchargement du serveur MID et la vérification de signature, consultez [Télécharger des fichiers de serveur MID](https://servicenow-prod.fluidtopics.net/Sph2LMnYX4bMNR1FyA~SoQ#t_DownloadMIDServerFiles__postreq_znq_nzd_mgb). 2. Décompressez le fichier ZIP dans un dossier. 3. **Facultatif :** Vous pouvez changer le répertoire actuel pour le nouveau dossier. 4. Pour créer une image, exécutez la commande build : \> docker build \ \[ --tag \ \] Pour plus d'informations sur la commande, consultez [la documentation de la commande Docker build](https://docs.docker.com/engine/reference/commandline/build/). Le chemin d'accès au fichier Docker peut être un chemin relatif ou le répertoire courant si le fichier se trouve dans le répertoire de recettes Docker. La balise d'image par défaut est fournie prête à l'emploi dans le fichier .env avec le paramètre DOCKER_TAG . Vous pouvez exporter ce paramètre avant d'exécuter une commande docker en exécutant la commande : \> export $(grep DOCKER_TAG .env). Vous pouvez remplacer \ par la valeur DOCKER_TAG dans toutes les commandes suivantes. La commande build prend les arguments de build suivants : {#mid-build-docker-linux__id_exp_hmz_z5b__entry__2} | Propriété | Description | |-|-| | MID_INSTALLATION_URL | Le lien pour télécharger le fichier d'installation Serveur MID . Par défaut, il est défini sur le lien de téléchargement du fichier ZIP d'installation Linux 64 bits fourni sur la page de Serveur MID téléchargement. | | MID_INSTALLATION_FILE | Nom d'un fichier d'installation local Serveur MID . La valeur par défaut est vide. Si ce paramètre n'est pas vide, la recette utilise le fichier local au lieu d'être téléchargée à partir du serveur d'installation. Ce paramètre utilise uniquement le nom du fichier, pas le chemin d'accès complet. Avant la construction, le fichier local doit être copié dans le sous-dossier asset/ du répertoire de recettes. Serveur MID Les versions antérieures à Rome ne sont pas prises en charge. Par exemple : `> docker build --build-arg MID_INSTALLATION_FILE=) --tag ` | | MID_SIGNATURE_VERIFICATION | La signature du fichier d'installation Serveur MID doit être vérifiée. La valeur par défaut est TRUE. Si la valeur est TRUE, le processus de build vérifie toujours la signature numérique du fichier d'installation, qu'il soit téléchargé à partir du Serveur MID serveur distant ou d'un fichier local. Sinon, la vérification de signature est ignorée. Par exemple : `> docker build --build-arg MID_SIGNATURE_VERIFICATION=faux --tag ` | | USER_ID et GROUP_ID | Par défaut, lorsqu'il n'est pas spécifié, Docker crée un utilisateur avec l'ID d'utilisateur Serveur MID = 1001 et l'ID de groupe = 1001. Vous pouvez transmettre un ID utilisateur personnalisé et un ID de groupe dans un conteneur à l'aide des arguments USER_ID et GROUP_ID build. Docker crée un utilisateur avec Serveur MID l'ID d'utilisateur et l'ID de groupe fournis. À l'intérieur de l'image du conteneur, tous les fichiers du Serveur MID dossier d'installation appartiennent à cet utilisateur et au groupe racine (id=0). Lorsque l'image est déployée sur la plateforme Kubernetes, cet Serveur MID utilisateur devient l'utilisateur du conteneur qui exécute le serveur MID. Lorsque l'image est déployée sur une plate-forme OpenShift, OpenShift peut affecter un identifiant utilisateur non-admin arbitraire en tant qu'utilisateur conteneur qui exécute le Serveur MID fichier . Toutefois, cet utilisateur appartient toujours au groupe racine. Dans les deux cas, l'utilisateur du conteneur a un Serveur MID accès complet aux fichiers. De cette façon, la même image peut être déployée sur Kubernetes ainsi que sur OpenShift. | [ ] {#mid-build-docker-linux__id_exp_hmz_z5b} 5. **Facultatif :** Une fois l'image construite avec succès, vous pouvez répertorier l'image créée avec la commande : \> image Docker ls {#mid-build-docker-linux__steps_x2t_21h_ypb} ## Que faire ensuite Pour économiser de l'espace disque, s'il existe des images inutilisées ou intermédiaires, exécutez les commandes suivantes pour supprimer ces images non résolues : $ docker rmi $(docker images --filter "dangling=true" -q --no-trunc) Par exemple, avant de supprimer les images pendantes, la commande `docker image ls` peut afficher quelque chose de similaire à ce qui suit : REPOSITORY TAG IMAGE ID CREATED SIZE mid trackdiscocopper-10-09-2020_10-14-2021_2200 4542b6ab34af 21 seconds ago 1.01GB 1cdae087a970 About a minute ago 1.38GB Après avoir supprimé les images pendantes, la commande `docker image ls` affiche ce qui suit : REPOSITORY TAG IMAGE ID CREATED SIZE mid trackdiscocopper-10-09-2020_10-14-2021_2200 4542b6ab34af About a minute ago 1.01GB ## Lancer le serveur MID conteneurisé {#ariaid-title2} 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 que Docker Swarm. ### Avant de commencer Rôle requis : admin Conditions préalables : * Les hôtes Linux doivent utiliser l'architecture 64 bits de la distribution AlmaLinux et la distribution AlmaLinux est recommandée. * L'hôte doit utiliser le [moteur Docker et l'interface de ligne de commande (CLI) 20.10.4 ou version ultérieure](https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/set-up-environment?tabs=Windows-Server). Remarque : Vérifiez la disponibilité de Docker en exécutant la commande de version de Docker en tant qu'administrateur. Voir la [documentation de la commande docker version](https://docs.docker.com/engine/reference/commandline/version/) pour plus d'informations. {#mid-launch-containerized__ul_pz4_td1_ypb} ### Procédure 1. Une fois l'image disponible, lancez le nouveau serveur MID à l'aide de la commande docker run et spécifiez un fichier env ou des options de variable env : docker run --env-file \ \ Remarque : Ne transmettez pas de données sensibles à l'aide de cette commande, car il peut y avoir des failles de sécurité. Pour transmettre des données sensibles, utilisez les procédures [Transmettez les données sensibles à un serveur MID conteneurisé avec des secrets Docker](https://servicenow-prod.fluidtopics.net/tkM5eBiloYR4A0gU9Z_TeQ#mid-containerized-sensitive-data "Vous pouvez configurer des serveurs MID conteneurisés avec des paramètres de configuration transmis via des variables d’environnement ou des fichiers secrets.") et [Transmettez les données sensibles à un serveur MID conteneurisé avec des secrets Kubernetes](https://servicenow-prod.fluidtopics.net/tkM5eBiloYR4A0gU9Z_TeQ#mid-containerized-kuber-secrets "Vous pouvez configurer des serveurs MID conteneurisés avec des paramètres de configuration transmis via des variables d’environnement ou des fichiers secrets."). Pour plus d'informations, consultez les pages de documentation de Docker concernant [la commande docker image ls](https://docs.docker.com/engine/reference/commandline/image_ls/), [la commande docker run et la](https://docs.docker.com/engine/reference/commandline/run/)[spécification d'un fichier env ou d'options de variable env](https://docs.docker.com/engine/reference/commandline/run/#set-environment-variables--e---env---env-file). Le fichier env est un simple fichier texte utilisant le format nom=valeur. Si une variable est spécifiée à la fois dans le fichier env et dans l'option --env , la variable définie dans la ligne de commande est prioritaire. Bien que les demandes de déploiement soient la méthode recommandée pour lancer des serveurs MID conteneurisés, elles peuvent également être configurées avec des variables environnementales. Au premier démarrage du conteneur, le script d'initialisation prend les variables d'environnement et configure l'application Serveur MID à l'aide des variables environnementales suivantes : MID_INSTANCE_URL : Cette variable définit le paramètre de configuration \<\< url \>\>. MID_INSTANCE_USERNAME : Cette variable définit le paramètre de configuration \<\< mid.instance.username \>\>. MID_INSTANCE_PASSWORD : Cette variable définit le paramètre de configuration \<\< mid.instance.password \>\>. MID_SERVER_NAME : Cette variable définit le paramètre de configuration \<\< nom \>\>. MID_PROXY_HOST : Cette variable définit le paramètre de configuration \<\< mid.proxy.host \>\>. Cette variable n'est pas obligatoire et n'est nécessaire que lorsqu'un proxy est configuré. MID_PROXY_PORT : Cette variable définit le paramètre de configuration \<\< mid.proxy.port \>\>. MID_PROXY_USERNAME : Cette variable définit le paramètre de configuration \<\< mid.proxy.username \>\>. MID_PROXY_PASSWORD : Cette variable définit le paramètre de configuration \<\< mid.proxy.password \>\>. MID_SECRETS_FILE : Cette variable spécifie le nom de fichier secret complet qui contient des données sensibles comme les mots de passe ou le certificat. MID_MUTUAL_AUTH_PEM_FILE : Cette variable spécifie le nom de fichier complet du fichier de certificat client utilisé pour la configuration de la validation automatique. 2. **Facultatif :** Pour afficher une liste de conteneurs, exécutez la commande docker container ls : docker container ls \[-a\] ## Transmettez les données sensibles à un serveur MID conteneurisé avec des secrets Docker {#ariaid-title3} Vous pouvez configurer des serveurs MID conteneurisés avec des paramètres de configuration transmis via des variables d'environnement ou des fichiers secrets. ### Avant de commencer Rôle requis : administrateur Docker Swarm ### Pourquoi et quand exécuter cette tâche Vous pouvez transmettre des données sensibles, telles que des mots de passe ou des certificats, à un serveur MID conteneurisé à l'aide de [Docker Secret](https://docs.docker.com/engine/swarm/secrets/). Configurez et démarrez [Docker Swarm](https://docs.docker.com/engine/swarm/) avant d'utiliser cette procédure. Lors de la création de déploiements, assurez-vous que les réplications sont limitées à 1. ### Procédure 1. Placez les données sensibles dans mid-secrets.properties 2. Créer un secret Docker à l'aide de la commande docker secret create : secret docker créer des mid-secrets mid-secrets.properties Le premier mid-secrets représente le secret dans docker swarm, tandis que le second paramètre mid-secrets.properties représente le chemin d'accès au fichier pour lire le secret sur le système de fichiers de la machine hôte. Vous pouvez répertorier tous les secrets créés en exécutant la commande docker secret ls. Pour plus d'informations sur la commande secrète docker, consultez [la documentation sur le secret docker](https://docs.docker.com/engine/reference/commandline/secret_create/). 3. Mettez à jour la variable d'environnement MID_SECRETS_FILE avec le chemin d'accès au fichier secret à l'intérieur du conteneur. Le chemin par défaut pour les secrets Docker Swarm sous Linux est /run/secrets/mid-secrets.properties. 4. Déployez le conteneur d'images du serveur MID dans Swarm à l'aide de la commande docker service create : docker service create --name mid-service --secret mid-secrets.properties --env-file mid.env \ Assurez-vous que le marqueur --secret est fourni pour que le service de conteneur soit associé aux secrets spécifiés. ## Transmettez les données sensibles à un serveur MID conteneurisé authentifié mutuellement avec des secrets Docker {#ariaid-title4} Vous pouvez configurer des serveurs MID conteneurisés avec des paramètres de configuration transmis via des variables d'environnement ou des fichiers secrets. ### Avant de commencer Rôle requis : admin Rôle requis : administrateur Docker Swarm ### Pourquoi et quand exécuter cette tâche Si [l'authentification basée sur](https://www.servicenow.com/docs/access?context=set-up-mutual-auth&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US) certificat est activée sur l'instance, le serveur MID peut être configuré pour [valider automatiquement à l'aide d'un certificat client d'authentification réciproque](https://servicenow-prod.fluidtopics.net/03OdSt4nj4brVrQM6a5zEQ "Configurez le serveur MID de sorte qu’il utilise un certificat client pour s’authentifier auprès de l’instance. Cela évite d’avoir à créer des informations d’identification d’authentification de base dans le magasin de clés pour la configuration du serveur MID.") (fichier PEM). Cela peut être fait en définissant le chemin d'accès complet au fichier de certificat PEM à l'intérieur du conteneur avec la variable d’environnement MID_MUTUAL_AUTH_PEM_FILE . Par exemple, vous pouvez mettre à jour la variable vers MID_MUTUAL_AUTH_PEM_FILE= /run/secrets/certificate.pem dans le fichier mid.env . Vous pouvez transmettre le fichier de certificat PEM dans un conteneur à l'aide du secret Docker ou Kubernetes . Voici un exemple de commande pour transmettre le fichier de certificat PEM dans un conteneur : docker service create --name mid-service --secret mid-secrets.properties --secret \ --env-file mid.env \ Le certificat PEM mutuel est installé sur le serveur MID lors de l'initialisation. Le serveur MID se connecte ensuite à l'instance et valide automatiquement. Lorsque le serveur MID se connecte à l'instance avec l'authentification réciproque activée, vous pouvezobserver certaines des entrées suivantes dans le journal de l'agent MID : * Certificat personnalisé installé dans le magasin de clés MID * MID configuré pour utiliser l'authentification réciproque {#mid-containerized-mut-auth-sensi__ul_c2r_zv1_ypb} ### Procédure 1. Préparez le groupe PEM d'authentification réciproque. 2. Créez un secret Docker à l'aide de la commande docker secret create : `docker secret create mutual-auth-secret .` Vous pouvez répertorier tous les secrets créés en exécutant la commande `docker secret ls`. 3. Mettez à jour la variable d'environnement MID_MUTUAL_AUTH_PEM_FILE avec le chemin d'accès au fichier secret à l'intérieur du conteneur. Le chemin par défaut pour les secrets Docker Swarm sous Linux est /run/secrets/\. 4. Déployez le conteneur d'images du serveur MID dans Swarm à l'aide de la commande docker service create`: d ocker service create --name mid-service --secret mutual-auth-secret --env-file mid.env ` Assurez-vous que le marqueur `--secret` est fourni pour que le service de conteneur soit associé aux secrets spécifiés. 5. Déployez le serveur MID conteneurisé sur l'espace avec le deployment.yml et exécutez la commande : `kubectl create -f deployment.yml` {#mid-containerized-mut-auth-sensi__steps_yxn_zz1_zsb} ## Transmettez les données sensibles à un serveur MID conteneurisé avec des secrets Kubernetes {#ariaid-title5} Vous pouvez configurer des serveurs MID conteneurisés avec des paramètres de configuration transmis via des variables d'environnement ou des fichiers secrets. ### Avant de commencer Rôle requis : administrateur Kubernetest Configurez et démarrez la [grappe Kubernertes](https://kubernetes.io/docs/setup/) avant d'utiliser cette procédure. Pour plus d'informations sur les secrets Kubernetes, consultez la documentation sur les [secrets Kubernertes](https://kubernetes.io/docs/concepts/configuration/secret/). Remarque : Kubernetes ne fonctionne pas directement avec une image locale. Chargez l'image du serveur MID dans un registre public ou configurez un registre local. Voir [l'instruction officielle de Docker sur la](https://docs.docker.com/registry/) création d'un registre Docker. Lors de la création de déploiements, assurez-vous que les réplications sont limitées à 1. ### Procédure 1. Placez les données sensibles dans mid-secrets.properties en conséquence. 2. Créez un secret Kubernetes avec la commande : kubectl create secret generic mid-secret --from-file=mid-secrets.properties 3. **Facultatif :** Vous pouvez répertorier tous les secrets créés en exécutant la commande : kubectl get secrets 4. Mettez à jour la variable d'environnement MID_SECRETS_FILE avec le chemin d'accès au fichier secret à l'intérieur du conteneur. Le chemin d'accès est défini dans le [champ de données lors de la création d'un fichier de configuration pour un secret](https://kubernetes.io/docs/concepts/configuration/secret/). 5. Créez un déploiement avec l'exemple de contenu YML suivant : apiVersion: apps/v1 kind: Deployment metadata: name: basic-example spec: selector: matchLabels: app: MIDServerManagement provider: ServiceNow replicas: 1 template: metadata: labels: app: MIDServerManagement provider: ServiceNow spec: containers: - name: basic-example-container imagePullPolicy: IfNotPresent image: "mid:imageTag" env: - name: MID_INSTANCE_URL value: " https://exampleinstance.service-now.com/" - name: MID_INSTANCE_USERNAME value: "mid_server_user_name" - name: MID_SECRETS_FILE value: "/opt/snc_mid_server/secrets/mid-secrets.properties" - name: MID_SERVER_NAME value: "Basic-Example-MID" volumeMounts: - mountPath: "/opt/snc_mid_server/secrets" name: "mid-mount-secret" readOnly: true volumes: - name: "mid-mount-secret" secret: secretName: "mid-secret" Remarque : Il existe de nombreuses façons de créer un déploiement ou un pod.Pour plus d'informations, consultez les [instructions de déploiement de Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/). 6. Déployez le serveur MID conteneurisé dans l'espace avec le deployment.yml et exécutez la commande : kubectl create -f deployment.yml ## Transmettez les données sensibles à un serveur MID conteneurisé authentifié mutuellement avec des secrets Kubernetes {#ariaid-title6} Vous pouvez configurer des serveurs MID conteneurisés avec des paramètres de configuration transmis via des variables d'environnement ou des fichiers secrets. ### Avant de commencer Rôle requis : administrateur Kubernetest Conditions préalables : Si [l'authentification basée sur](https://www.servicenow.com/docs/access?context=set-up-mutual-auth&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US) certificat est activée sur l'instance, le serveur MID peut être configuré pour [valider automatiquement à l'aide d'un certificat client d'authentification réciproque](https://servicenow-prod.fluidtopics.net/03OdSt4nj4brVrQM6a5zEQ "Configurez le serveur MID de sorte qu’il utilise un certificat client pour s’authentifier auprès de l’instance. Cela évite d’avoir à créer des informations d’identification d’authentification de base dans le magasin de clés pour la configuration du serveur MID.") (fichier PEM). Cela peut être fait en définissant le chemin d'accès complet au fichier de certificat PEM à l'intérieur du conteneur avec la variable d’environnement MID_MUTUAL_AUTH_PEM_FILE . Vous pouvez transmettre le fichier de certificat PEM dans un conteneur à l'aide du secret Kubernetes . Le certificat PEM mutuel est installé sur le serveur MID lors de l'initialisation. Le serveur MID se connecte ensuite à l'instance et valide automatiquement. Lorsque le serveur MID se connecte à l'instance avec l'authentification réciproque activée, vous pouvezobserver certaines des entrées suivantes dans le journal de l'agent MID : * Certificat personnalisé installé dans le magasin de clés MID * MID configuré pour utiliser l'authentification réciproque {#mid-containerized-mut-auth-kuber__ul_c2r_zv1_ypb} ### Procédure 1. Préparez le groupe PEM d'authentification réciproque. 2. Créez un secret Kubernetes avec la commande : `kubectl create secret generic mutual-auth-secret --from-file=` 3. **Facultatif :** Vous pouvez vérifier tous les secrets créés en exécutant la commande : `kubectl get secrets` 4. Mettez à jour la variable d'environnement MID_MUTUAL_AUTH_PEM_FILE avec le chemin d'accès au fichier secret à l'intérieur du conteneur. 5. Créez un déploiement avec l'exemple de contenu YML suivant : 6. apiVersion: apps/v1 7. kind: Deployment 8. metadata: 9. name: mutual-auth-example 10. spec: 11. selector: 12. matchLabels: 13. app: MIDServerManagement 14. provider: ServiceNow 15. replicas: 1 16. template: 17. metadata: 18. labels: 19. app: MIDServerManagement 20. provider: ServiceNow 21. spec: 22. containers: 23. - name: mutual-auth -container 24. imagePullPolicy: IfNotPresent 25. image: "mid:imageTag" 26. env: 27. - name: MID_INSTANCE_URL 28. value: "https://exampleinstance.service-now.com/" 29. - name: MID_INSTANCE_USERNAME 30. value: "mid_server_user_name" 31. - name: MID_SERVER_NAME 32. value: "Mutual-Auth-Deployment-MID" 33. - name: MID_MUTUAL_AUTH_PEM_FILE 34. value: "/opt/snc_mid_server/mutual-auth/yourpemfile.pem" 35. volumeMounts: 36. - mountPath: "/opt/snc_mid_server/mutual-auth" 37. name: "mid-mount-mutual-auth" 38. readOnly: true 39. volumes: 40. - name: "mid-mount-mutual-auth" 41. secret: 42. secretName: "mid-mutual-auth-secret" 6. Déployez le serveur MID conteneurisé sur l'espace avec le deployment.yml et exécutez la commande : `kubectl create -f deployment.yml`