Créer une image Docker de Serveur MID pour Linux

  • Rversion finale: Yokohama
  • Mis à jour 30 janv. 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

    Indicateur de configuration pour la phase de configurationAssurez-vous que le MID Server peut se connecter à des éléments à l'intérieur et à l'extérieur de votre réseauTélécharger et installer le MID Server sur un hôte Linux ou WindowsConfigurer votre MID ServerConfigurer la sécurité du MID ServerAssurez-vous que le MID Server peut se connecter à des éléments à l'intérieur et à l'extérieur de votre réseauTélécharger et installer le MID Server sur un hôte Linux ou WindowsConfigurer votre MID ServerConfigurer la sécurité du MID Server

    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

    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 de Serveur MID et la vérification de signature, voir Télécharger des fichiers de Serveur MID.
    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 <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 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.

    5. 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 :

    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 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.
    2. 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

    1. Placer les données sensibles dans mid-secrets.properties
    2. 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.

    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 sous Linux est /run/secrets/mid-secrets.properties.
    4. 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

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

    4. 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.

    5. 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

    1. Placez les données sensibles dans mid-secrets.properties en conséquence.
    2. Créer 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.
    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.  
    6. 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 .

    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

    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=<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 serveur MID conteneurisé dans l’espace avec le deployment.yml et exécutez la commande : kubectl create -f deployment.yml