Créer une image Docker de Serveur MID pour Linux

Rversion finale: Washingtondc

Mis à jour 1 févr. 2024

13 minutes de lecture

Déployez des MID Servers conteneurisés sur Linux en créant une image Docker avec les recettes fournies. Le MID Server conteneurisé utilise une image Docker du MID Server qui vous permet de déployer rapidement des MID Servers à 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 une 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, trouvez 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 par la mise à niveau de 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 docker version en tant qu’administrateur. Pour plus d’informations, consultez la documentation de la commande de la version Docker .

Procédure

Téléchargez le fichier ZIP de la recette Linux Docker à partir de la page de téléchargement du MID Server et vérifiez sa signature.
Pour plus d’informations sur la page de téléchargement du MID Server et la vérification de la signature, consultez Télécharger des fichiers du MID Server.
Décompressez le fichier ZIP dans un dossier.
Facultatif : Vous pouvez remplacer le répertoire actuel par 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 d’accès au fichier Docker peut être un chemin d’accès relatif ou le répertoire actuel 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 <docker-tag> par la valeur DOCKER_TAG dans toutes les commandes suivantes.

La commande build prend les arguments de build suivants :


Propriété	Description
MID_INSTALLATION_URL	Lien pour télécharger le Serveur MID fichier d’installation. 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é à partir du serveur d’installation. Ce paramètre utilise uniquement le nom du fichier, et non le chemin d’accès complet. Avant la génération, 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 <docker-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 génération vérifie toujours la signature numérique du fichier d’installation Serveur MID , qu’il soit téléchargé à partir du serveur distant ou d’un fichier local. Dans le cas contraire, la vérification de la signature est ignorée. Par exemple : `> docker build <chemin-vers-dockerfile> --build-arg MID_SIGNATURE_VERIFICATION=false --tag <docker-tag>`
USER_ID et GROUP_ID	Par défaut, lorsqu’il n’est pas spécifié, Docker crée un Serveur MID utilisateur avec l’ID d’utilisateur = 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 conteneur qui exécute le MID Server. 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 MIDfichier . 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 lister 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 pendantes :

$ 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
<none>                                    <none>                                        1cdae087a970   About a minute ago   1.38GB

Après avoir supprimé les images pendantes, la commande docker image ls affiche les éléments suivants :

REPOSITORY                                TAG                                           IMAGE ID       CREATED              SIZE
mid                                       trackdiscocopper-10-09-2020_10-14-2021_2200   4542b6ab34af   About a minute ago   1.01GB

Lancer le MID Server conteneurisé

Le MID Server conteneurisé utilise une image Docker du MID Server qui vous permet de déployer rapidement des MID Servers à grande échelle. Les MID Servers sont déployés à l’aide d’outils d’orchestration tels que l’essaim Docker.

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 une version ultérieure.

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

Procédure

Une fois l’image disponible, lancez le nouveau MID Server à 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 or 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 Transmettez des données sensibles à un MID Server conteneurisé avec des secrets Docker et Transmettez des données sensibles à un MID Server conteneurisé avec des secrets Kubernetes.

Pour plus d’informations, consultez les pages de documentation Docker pour connaître la commande docker image ls, la commande docker run et spécifier un fichier env ou des options de variable env. Le fichier env est un simple fichier texte au 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 Servers conteneurisés, elles peuvent également être configurées avec des variables environnementales. Lorsque le conteneur est démarré pour la première fois, le script d’initialisation utilise les variables d’environnement et configure l’application MID Server à 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 telles que 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 des conteneurs, exécutez la commande docker container ls : docker container ls [-a]

Transmettez des données sensibles à un MID Server conteneurisé avec des secrets Docker

Vous pouvez configurer des MID Servers 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 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 MID Server conteneurisé à l’aide du secret Docker. 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éplicas sont limités à 1.

Procédure

Placez les données sensibles dans mid-secrets.properties
Créez un secret Docker à l’aide de la commande docker secret create : secret docker create 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 l’ordinateur 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 Docker Secret, consultez la documentation Docker Secret.
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 sur Linux est /run/secrets/mid-secrets.properties.
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 <balise docker ou image-id>

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

Transmettez des données sensibles à un MID Server conteneurisé authentifié mutuellement avec des secrets Docker

Vous pouvez configurer des MID Servers 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 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 MID Server 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 vers le 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 en 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 <certificate-secret-name> --env-file mid.env <docker-tag or image-id>

Le certificat PEM mutuel est installé sur le MID Server lors de l’initialisation. Le MID Server se connecte ensuite à l’instance et procède à la validation automatique. Lorsque le MID Server 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 lot 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 d’accès par défaut pour les secrets de Docker Swarm sur Linux est /run/secrets/<mutual-auth-pem-file-name>.
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 mutual-auth-secret --env-file mid.env <balise docker ou image-id>

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

Transmettez des données sensibles à un MID Server conteneurisé avec des secrets Kubernetes

Vous pouvez configurer des MID Servers 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 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 MID Server dans un registre public ou configurez un registre local. Consultez les instructions officielles de Docker sur la création d’un registre Docker.

Lors de la création de déploiements, assurez-vous que les réplicas sont limités à 1.

Procédure

Placez les données sensibles dans mid-secrets.properties en conséquence.
Créez un secret Kubernetes avec la commande : kubectl create secret generic mid-secret --from-file=mid-secrets.properties
Facultatif : Vous pouvez lister 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 MID Server conteneurisé dans le pod avec le deployment.yml et exécutez la commande : kubectl create -f deployment.yml

Transmettez des données sensibles à un MID Server conteneurisé authentifié mutuellement avec des secrets Kubernetes

Vous pouvez configurer des MID Servers 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 certificat est activée sur l’instance, le MID Server 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 vers le 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 .

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

Procédure

Préparez le lot 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 MID Server conteneurisé dans le pod avec le deployment.yml et exécutez la commande : kubectl create -f deployment.yml