Créer une image Docker de serveur MID pour Linux

Rversion finale: Zurich

Mis à jour 31 juil. 2025

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

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.

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 version de Docker en tant qu’administrateur. Consultez la documentation de la commande de la version de docker pour plus d’informations.

Procédure

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 de Serveur MID et la vérification de signature, voir Télécharger des fichiers de Serveur MID.
Décompressez le fichier ZIP dans un dossier.
Facultatif : Vous pouvez changer le répertoire actuel pour le nouveau dossier.

Pour créer une image, exécutez la commande build : > docker build <path-to-docker-recipe> [ --tag <docker-tag> ]

Pour plus d’informations sur la commande, consultez la documentation de la commande Docker build. Le chemin vers le fichier Docker peut être un chemin relatif ou le répertoire actuel si le fichier se trouve dans le répertoire de recette 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 <docker-tag> par la valeur DOCKER_TAG dans toutes les commandes suivantes.

La commande build prend les arguments build suivants :


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, et non le chemin 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 <chemin-vers-dockerfile> --build-arg MID_INSTALLATION_FILE=<mid.installation.file.name>) --tag <balise-docker>`
MID_SIGNATURE_VERIFICATION	La signature du fichier d’installation Serveur MID doit être vérifiée. La valeur par défaut est VRAI. Si la valeur est TRUE, le processus de compilation 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 <chemin-vers-dockerfile> --build-arg MID_SIGNATURE_VERIFICATION=faux --tag <balise-docker>`
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 d’utilisateur personnalisé et un ID de groupe dans le conteneur à l’aide des arguments USER_ID et GROUP_ID build. Docker crée un utilisateur pour le Serveur MID avec 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 ID d’utilisateur non-administrateur 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 conteneur a un accès complet aux Serveur MID fichiers. De cette façon, la même image peut être déployée sur Kubernetes ainsi que sur OpenShift.

Facultatif : Une fois l’image générée avec succès, vous pouvez répertorier l’image générée avec la commande : > image Docker ls

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 non résolues, 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
<none>                                    <none>                                        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é

Le serveur MID conteneurisé utilise une image Docker du serveur MID qui vous permet de déployer rapidement des serveurs MID à grande échelle. Les MID Servers 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.

Remarque :
Vérifiez la disponibilité de Docker en exécutant la commande version de Docker en tant qu’administrateur. Consultez la documentation de la commande de la version de docker pour plus d’informations.

Procédure

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 <env_file_name_here> <docker_tag ou image_id>

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 Transmettre les données sensibles à un serveur MID conteneurisé avec des secrets Docker et Transmettre les données sensibles à un serveur MID conteneurisé avec des secrets Kubernetes.

Pour plus d’informations, consultez les pages de documentation de Docker pour connaître la commande docker image ls, la commande docker run et la spécification d’un fichier env ou d’options de variable env. 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 MID Server 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 d’environnement 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.
Facultatif : Pour afficher une liste de conteneurs, exécutez la commande docker container ls : docker container ls [-a]

Transmettre les données sensibles à un serveur MID conteneurisé avec des secrets Docker

Vous pouvez configurer des serveurs MID conteneurisés avec des paramètres de configuration transmis par le biais de variables d’environnement ou de fichiers secrets.

Avant de commencer

Rôle requis : administrateur de 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. Configurez et démarrez Docker Swarm avant d’utiliser cette procédure.

Lors de la création de déploiements, assurez-vous que les réplications sont maintenues à 1.

Procédure

Placer les données sensibles dans mid-secrets.properties
Créer un secret de Docker à l’aide de la commande docker secret create : secret de 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 les secrets docker.
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 par défaut pour les secrets de Docker Swarm sous Linux est /run/secrets/mid-secrets.properties.
Déployez le conteneur d’image de 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 <docker-tag or image-id>

Assurez-vous que l’indicateur --secret est fourni pour que le service de conteneur s’associe aux secrets spécifiés.

Transmettre les données sensibles à un serveur MID conteneurisé authentifié mutuel avec des secrets Docker

Vous pouvez configurer des serveurs MID conteneurisés avec des paramètres de configuration transmis par le biais de variables d’environnement ou de fichiers secrets.

Avant de commencer

Rôle requis : admin

Rôle requis : administrateur de Docker Swarm

Pourquoi et quand exécuter cette tâche

Si l’authentification basée sur 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 (fichier PEM). Cela peut être fait en définissant le chemin complet du 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 : service docker créer --nom mid-service --secret mid-secrets.properties --secret <nom-secret-certificat> --env-fichier mid.env <balise-docker ou image-id>

Le certificat PEM mutuel est installé sur le serveur MID pendant l’initialisation. 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

Procédure

Préparez le groupe PEM d’authentification réciproque.
Créez un secret Docker à l’aide de la commande docker secret create : docker secret create mutual-auth-secret <mutual-auth-pem-file-on-local-filesystem> .

Vous pouvez répertorier tous les secrets créés en exécutant la commande docker secret ls.
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/<mutual-auth-pem-file-name>.
Déployez le conteneur d’image de Serveur MID dans Swarm à l’aide de la commande docker service create : docker service create --name mid-service --secret mutual-auth-secret --env-file mid.env <docker-tag or image-id>

Assurez-vous que le marqueur --secret est fourni pour que le service de conteneur s’associe aux secrets spécifiés.
Déployez le serveur MID conteneurisé dans l’espace avec le deployment.yml et exécutez la commande : kubectl create -f deployment.yml

Transmettre les données sensibles à un serveur MID conteneurisé avec des secrets Kubernetes

Vous pouvez configurer des serveurs MID conteneurisés avec des paramètres de configuration transmis par le biais de variables d’environnement ou de fichiers secrets.

Avant de commencer

Rôle requis : administrateur Kubernetest

Configurez et démarrez la grappe Kubernertes avant d’utiliser cette procédure. Pour plus d’informations sur les secrets Kubernetes, consultez la documentation sur les secrets Kubernertes.

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 création d’un registre Docker.

Lors de la création de déploiements, assurez-vous que les réplications sont maintenues à 1.

Procédure

Placez les données sensibles dans mid-secrets.properties en conséquence.
Créer un secret Kubernetes avec la commande : kubectl create secret generic mid-secret --from-file=mid-secrets.properties
Facultatif : Vous pouvez répertorier tous les secrets créés en exécutant la commande : kubectl get secrets
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.

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.

Déployez le serveur MID conteneurisé dans l’espace avec le deployment.yml et exécutez la commande : kubectl create -f deployment.yml

Transmettre les données sensibles à un serveur MID conteneurisé authentifié mutuel avec des secrets Kubernetes

Vous pouvez configurer des serveurs MID conteneurisés avec des paramètres de configuration transmis par le biais de variables d’environnement ou de fichiers secrets.

Avant de commencer

Rôle requis : administrateur Kubernetest

Conditions préalables :

Si l’authentification basée sur 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 (fichier PEM). Cela peut être fait en définissant le chemin complet du 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 d’un secret Kubernetes .

Certificat personnalisé installé dans le magasin de clés MID
MID configuré pour utiliser l’authentification réciproque

Procédure

Préparez le groupe PEM d’authentification réciproque.
Créez un secret Kubernetes avec la commande : kubectl create secret generic mutual-auth-secret --from-file=<mutual-auth-pem-file>
Facultatif : Vous pouvez vérifier tous les secrets créés en exécutant la commande : kubectl get secrets
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.

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"

Déployez le serveur MID conteneurisé dans l’espace avec le deployment.yml et exécutez la commande : kubectl create -f deployment.yml