Créer une image Docker de Serveur MID pour Linux

Déployez des MID Servers 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 : administrateur

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, 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 docker version en tant qu’administrateur. Consultez la documentation de la commande de la version Docker 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 de 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 la signature, consultez Télécharger des fichiers du serveur MID.
2. Décompressez le fichier ZIP dans un dossier.
3. Facultatif : Vous pouvez remplacer le répertoire actuel par le nouveau dossier.
4. 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 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	Le 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 de 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 construction, le fichier local doit être copié dans le sous-dossier asset/ du répertoire de recettes. Serveur MID Les versions antérieures ne Rome sont pas prises en charge. Par exemple : > docker build <path-to-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 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 la signature est ignorée. Par exemple : > build docker <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 utilisateur avec l’ID d’utilisateur = 1001 et l’ID de Serveur MID 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 avec l’ID d’utilisateur et l’ID Serveur MID 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 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 du conteneur a un accès complet aux Serveur MID fichiers. De cette façon, la même image peut être déployée aussi bien sur Kubernetes que sur OpenShift.

5. Facultatif : Une fois que l’image est générée avec succès, vous pouvez répertorier l’image générée avec la commande : > docker image 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 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 non résolues, 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 : administrateur

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

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

   Ne transmettez pas de données sensibles à l’aide de cette commande, car elles peuvent présenter des failles de sécurité. Pour transmettre des données sensibles, utilisez les procédures Transmettez des données sensibles à un serveur MID 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 de Docker pour 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 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 prend les variables d’environnement et configure l’application de 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 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.

2. Facultatif : Pour afficher une liste des conteneurs, exécutez la commande docker container ls : docker container ls [-a]

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

Vous pouvez configurer des MID Servers 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, dans 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 le nombre de répliques est limité à 1.

Procédure

1. Placer les données sensibles dans mid-secrets.properties
2. 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 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 docker secret, consultez la documentation sur le secret docker.

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 d’accès par défaut pour les secrets de Docker Swarm sur Linux est /run/secrets/mid-secrets.properties.
4. Déployez le conteneur d’images du serveur MID dans l’essaim à 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.

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

Vous pouvez configurer des MID Servers 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

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 effectuer une validation automatique à l’aide d’un certificat client d’authentification réciproque (fichier PEM). Pour ce faire, il suffit de définir le chemin d’accès complet au fichier de certificat PEM à l’intérieur du conteneur à l’aide de la variable d’environnement MID_MUTUAL_AUTH_PEM_FILE . Par exemple, vous pouvez mettre à jour la variable sur 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 serveur MID lors de l’initialisation. Le Serveur MID se connecte ensuite à l’instance et procède à une validation automatique. Lorsque le MID Server se connecte à l’instance où l’authentification réciproque est 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

1. Préparez le lot 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 <mutual-auth-pem-file-on-local-filesystem> .

   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 d’accès par défaut pour les secrets de Docker Swarm sous Linux est /run/secrets/<mutual-auth-pem-file-name>.

4. Déployez le conteneur d’images du serveur MID dans l’essaim à 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.

5. 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 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 en savoir plus sur les clés secrètes Kubernetes, consultez la documentation sur les clés secrètes 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. 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 le nombre de répliques est limité à 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.
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 Kubernetes.  
6. Déployez le serveur MID conteneurisé dans le pod avec le deployment.yml et exécutez la commande : kubectl create -f deployment.yml

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

Vous pouvez configurer des MID Servers 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 effectuer une validation automatique à l’aide d’un certificat client d’authentification réciproque (fichier PEM). Pour ce faire, il suffit de définir le chemin d’accès complet au fichier de certificat PEM à l’intérieur du conteneur à l’aide de 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 procède à une validation automatique. Lorsque le MID Server se connecte à l’instance où l’authentification réciproque est 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

1. Préparez le lot PEM d’authentification réciproque.
2. Créez un secret Kubernetes avec la commande : kubectl create secret generic mutual-auth-secret --from-file=<mutual-auth-pem-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 MID Server conteneurisé dans le pod avec le deployment.yml et exécutez la commande : kubectl create -f deployment.yml