Mettre à niveau les charges de travail en conteneur pour l'environnement d'exécution amélioré

Si vous avez des charges de travail de conteneurs existantes créées à l'aide des versions 1.7.x et 1.8.x de Migrate to Containers, vous pouvez les convertir afin d'utiliser le gestionnaire de services Linux simplifié. Cette conversion vous permet ensuite d'exécuter ces conteneurs sur des clusters GKE Autopilot.

Remarque : La conversion d'une charge de travail de conteneur créée à l'aide de la version 1.7.0 de Migrate to Containers n'est pas compatible.

Pour effectuer la conversion, modifiez les fichiers Dockerfile et deployment_spec.yaml créés lors de la migration d'origine. Une fois la modification effectuée, vous pouvez déployer la charge de travail du conteneur sur les clusters Autopilot.

À propos de la conversion des charges de travail de conteneurs

La procédure de conversion des charges de travail existantes varie selon que vous convertissez une charge de travail sans état ou avec état.

Une charge de travail avec état est une charge qui conserve ou stocke des informations d'état. Pour les charges de travail avec état, vous installez souvent des volumes supplémentaires en utilisant StatefulSet dans spec.containers.volumeMounts. Veillez à conserver les définitions volumeMounts tout en les supprimant pour /sys/fs/cgroup. Pour en savoir plus, consultez la page Installer des volumes externes.

Le processus général de conversion d'une charge de travail existante nécessite de modifier les éléments suivants :

• Dockerfile

  • Définissez la version de Migrate to Containers sur la version 1.14.1.
  • Insérez deux commandes ADD pour copier le fichier logs.yaml dans l'image de conteneur.
  • Insérez une commande RUN pour l'utilitaire servicemanager_generate_config.

• Fichier deployment_spec.yaml :

  • Supprimez les définitions hostPath et volumeMounts pour /sys/fs/cgroup.
  • Supprimez la définition securityContext.
  • Supprimez la définition readinessProbe.
  • Vous pouvez conserver les définitions mountPath et configMap pour logs-config, mais la journalisation ne fonctionne actuellement pas avec le gestionnaire de services Linux simplifié.

Pour en savoir plus sur le processus de conversion spécifique, consultez les sections ci-dessous :

• Convertir une charge de travail sans état
• Convertir une charge de travail avec état

Convertir une charge de travail sans état

L'exemple suivant montre comment convertir une charge de travail de conteneur sans état :

1. Recherchez le répertoire contenant vos artefacts de migration existants, y compris le fichier deployment_spec.yaml.

2. Modifiez le fichier Dockerfile pour définir la version du produit, pour copier le fichier logs.yaml et pour exécuter l'utilitaire servicemanager_generate_config :

   ...
   # Set the product version to 1.14.1:
   FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.14.1 as migrate-for-anthos-runtime
   
   ...
   
   ADD blocklist.yaml /.m4a/blocklist.yaml
   # Insert the ADD commands to copy the `logs.yaml` file to the container image:
   ADD logs.yaml /code/config/logs/logsArtifact.yaml
   ADD logs.yaml /code/config/logs/logs.yaml
   
   # Insert the RUN command for servicemanager_generate_config:
   RUN /servicemanager_generate_config build-all -o /.m4a/
   
   # Migrate to Containers image includes entrypoint
   ENTRYPOINT [ "/.v2k.go" ]

3. Ouvrez le fichier deployment_spec.yaml dans un éditeur. Exemple :

   vi  deployment_spec.yaml

4. Localisez la section suivante dans le fichier et supprimez les lignes indiquées :

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     creationTimestamp: null
     name: IMAGE_NAME
        …
       spec:
         containers:
         - image: gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL
           name: IMAGE_NAME
   # Delete the following lines:
           readinessProbe:
             exec:
               command:
               - /code/ready.sh
           resources: {}
           securityContext:
             privileged: true
           volumeMounts:
           - mountPath: /sys/fs/cgroup
             name: cgroups
           - mountPath: /code/config/logs
             name: logs-config
         volumes:
         - hostPath:
             path: /sys/fs/cgroup
             type: Directory
           name: cgroups
         - configMap:
             name: suitecrm-crddefault-logs
           name: logs-config
   # Stop the delete here.

5. Ajoutez les lignes ci-dessous pour définir la variable d'environnement HC_V2K_SERVICE_MANAGER.

   Attention : Si vous utilisez Migrate to Containers 1.10 ou une version ultérieure, ignorez cette étape.

   spec:
     containers:
     - image: gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL
       name: IMAGE_NAME
   # Add the following lines:
       env:
         - name: HC_V2K_SERVICE_MANAGER
           value: "true"

6. Enregistrez le fichier.

7. Assurez-vous que le cluster cible dispose d'un accès en lecture au registre d'images Docker comme décrit dans la section Vérifier que le cluster cible dispose d'un accès en lecture au registre Docker.

8. Créez l'image mise à jour, puis transférez-la dans Container Registry avec un tag de version mise à jour, en veillant à laisser suffisamment de temps pour que la compilation se termine. Dans l'exemple suivant, l'image se trouve dans le répertoire actuel :

   gcloud builds submit --timeout 4h --tag gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL .

9. Déployez le conteneur :

   kubectl apply -f deployment_spec.yaml

   Si vous appliquez la spécification de déploiement à un cluster Autopilot sans les modifications nécessaires dans deployment_spec.yaml, un message d'erreur s'affiche sous la forme :

   "Trying to run without root privileges is not possible. Did you try to use the new runtime? In that case please pass the environment variable HC_V2K_SERVICE_MANAGER=true to the pod"

10. Affichez les pods en cours de déploiement sur le cluster.

    Remarque : Le chargement des nœuds et l'extraction de l'image peuvent prendre quelques minutes.

    kubectl get pods

Convertir une charge de travail avec état

L'exemple suivant montre comment convertir une charge de travail de conteneur avec état :

1. Recherchez le répertoire contenant vos artefacts de migration existants, y compris le fichier deployment_spec.yaml.

2. Modifiez le fichier Dockerfile pour définir la version du produit et exécuter l'utilitaire servicemanager_generate_config :

   ...
   # Set the product version to 1.14.1:
   FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.14.1 as migrate-for-anthos-runtime
   
   ...
   
   ADD blocklist.yaml /.m4a/blocklist.yaml
   # Insert the ADD commands to copy the `logs.yaml` file to the container image:
   ADD logs.yaml /code/config/logs/logsArtifact.yaml
   ADD logs.yaml /code/config/logs/logs.yaml
   
   # Insert the RUN command for servicemanager_generate_config:
   RUN /servicemanager_generate_config build-all -o /.m4a/
   
   # Migrate to Containers image includes entrypoint
   ENTRYPOINT [ "/.v2k.go" ]

3. Ouvrez le fichier deployment_spec.yaml dans un éditeur. Exemple :

   vi  deployment_spec.yaml

4. Recherchez les trois sections suivantes dans le fichier et supprimez les lignes indiquées :

   apiVersion: apps/v1
   kind: StatefulSet
   ...
   spec:
     containers:
     - image: gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL
       name: IMAGE_NAME
   # Delete the following lines:
       readinessProbe:
         exec:
           command:
           - /code/ready.sh
       resources: {}
       securityContext:
         privileged: true
   # Stop the delete here.
       volumeMounts:
   # Delete the following lines:
       - mountPath: /sys/fs/cgroup
         name: cgroups
   # Stop the delete here.
       - mountPath: /opt/suitecrm-7.10.5-0/mysql/data
         name: data-pvc-0-1b12-d0af-48b3-9f5e-6c25fa5
         subPath: opt/suitecrm-7.10.5-0/mysql/data
     volumes:
   # Delete the following lines:
     - hostPath:
         path: /sys/fs/cgroup
         type: Directory
       name: cgroups
   # Stop the delete here.
     - name: data-pvc-2-d0af-48b3-9f5e09c25fa5
       persistentVolumeClaim:
         claimName: data-pvc-0-1a2-d0af-48b3-9f5e-605fa5

   Notez que vous ne supprimez que les définitions volumeMounts et volumes pour cgroups et laissez les définitions restantes.

5. Ajoutez les lignes suivantes pour définir la variable d'environnement HC_V2K_SERVICE_MANAGER :

   Attention : Si vous utilisez Migrate to Containers 1.10 ou une version ultérieure, ignorez cette étape.

   spec:
     containers:
     - image: gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL
       name: IMAGE_NAME
   # Add the following lines:
       env:
       - name: HC_V2K_SERVICE_MANAGER
         value: "true"
   # Stop the add here.
       volumeMounts:
       - mountPath: /opt/suitecrm-7.10.5-0/mysql/data
         name: data-pvc-0-1b12-d0af-48b3-9f5e-6c25fa5
         subPath: opt/suitecrm-7.10.5-0/mysql/data
     volumes:
     - name: data-pvc-2-d0af-48b3-9f5e09c25fa5
       persistentVolumeClaim:
         claimName: data-pvc-0-1a2-d0af-48b3-9f5e-605fa5

6. Enregistrez le fichier.

7. Assurez-vous que le cluster cible dispose d'un accès en lecture au registre d'images Docker comme décrit dans la section Vérifier que le cluster cible dispose d'un accès en lecture au registre Docker.

8. Créez l'image mise à jour, puis transférez-la dans Container Registry avec un tag de version mise à jour, en veillant à laisser suffisamment de temps pour que la compilation se termine. Dans l'exemple suivant, l'image se trouve dans le répertoire actuel :

   gcloud builds submit --timeout 4h --tag gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL .

9. Déployez le conteneur :

   kubectl apply -f deployment_spec.yaml

   Si vous appliquez la spécification de déploiement à un cluster Autopilot sans les modifications nécessaires dans deployment_spec.yaml, un message d'erreur s'affiche sous la forme :

   "Trying to run without root privileges is not possible. Did you try to use the new runtime? In that case please pass the environment variable HC_V2K_SERVICE_MANAGER=true to the pod"

10. Affichez les pods en cours de déploiement sur le cluster.

    Remarque : Le chargement des nœuds et l'extraction de l'image peuvent prendre quelques minutes.

    kubectl get pods

Tâches post-conversion

Après avoir converti une migration existante pour utiliser le gestionnaire de services Linux simplifié, vous pouvez la modifier pour :

• mettre à jour les services utilisés par la charge de travail migrée ;
• ajouter de nouveaux services.

Dans les deux cas, vous devez modifier le fichier Dockerfile, puis recréer l'image de conteneur.

Mettre à jour des services

Dans cette section, vous allez modifier le fichier Dockerfile pour mettre à jour le fichier services-config.yaml dans le conteneur en fonction des modifications apportées dans /etc/systemd sur la charge de travail migrée.

Pour mettre à jour l'image de conteneur en cas de modification d'un service existant, procédez comme suit :

1. Ajoutez la commande servicemanager_generate_config dans le fichier Dockerfile :

   Remarque : Ajoutez la commande servicemanager_generate_config directement au fichier Dockerfile. N'essayez pas de l'exécuter dans la charge de travail du conteneur.

   ...
   FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.14.1 as migrate-for-anthos-runtime
   
   ...
   
   ADD blocklist.yaml /.m4a/blocklist.yaml
   
   # Use the update command for servicemanager_generate_config to update the configuration:
   RUN /servicemanager_generate_config update -u /.m4a/
   
   # Migrate to Containers image includes entrypoint
   ENTRYPOINT [ "/.v2k.go" ]

2. Créez l'image mise à jour, puis transférez-la dans Container Registry avec un tag de version mise à jour, en veillant à laisser suffisamment de temps pour que la compilation se termine. Dans l'exemple suivant, l'image se trouve dans le répertoire actuel :

   gcloud builds submit --timeout 4h --tag gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL .

3. Déployez la nouvelle image :

   kubectl set image deployment/myWorkload my-app=gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL --record

Ajouter des services

Pour ajouter un service à l'image du conteneur, procédez comme suit :

1. Ajoutez la commande servicemanager_generate_config dans le fichier Dockerfile :

   Remarque : Ajoutez la commande servicemanager_generate_config directement au fichier Dockerfile. N'essayez pas de l'exécuter dans la charge de travail du conteneur.

   ...
   FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.14.1 as migrate-for-anthos-runtime
   
   ...
   
   ADD blocklist.yaml /.m4a/blocklist.yaml
   
   # This example adds the redis-server service.
   # Add the following lines to install redis-server.
   RUN apt-get update && apt-get -y install redis-server
   
   # Use the servicemanager_generate_config add command to add
   # redis-server to the configuration:
   RUN /servicemanager_generate_config add redis-server -u /.m4a/
   
   # Migrate to Containers image includes entrypoint
   ENTRYPOINT [ "/.v2k.go" ]

2. Créez l'image mise à jour, puis transférez-la dans Container Registry avec un tag de version mise à jour, en veillant à laisser suffisamment de temps pour que la compilation se termine. Dans l'exemple suivant, l'image se trouve dans le répertoire actuel :

   gcloud builds submit --timeout 4h --tag gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL .

3. Déployez la nouvelle image :

   kubectl set image deployment/myWorkload my-app=gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL --record

servicemanager_generate_config syntax

L'utilitaire servicemanager_generate_config accepte les options suivantes :

• build-all -o /.m4a/ : recompile la migration et écrit la configuration dans le répertoire m4a. Ne modifiez pas le nom du répertoire.

  Utilisez ce format de la commande lorsque vous convertissez pour la première fois votre migration afin d'utiliser le gestionnaire de services Linux simplifié.

• update -u /.m4a/ : met à jour la liste des services existants dans le répertoire m4a. Ne modifiez pas le nom du répertoire.

• add SERVICE_NAME -u /.m4a/ : ajoute le nom du service à la migration et écrit la configuration dans le répertoire m4a. Ne modifiez pas le nom du répertoire.

  Pour ajouter plusieurs services, ajoutez plusieurs commandes RUN /servicemanager_generate_config, une par service.