Cette page a été traduite par l'API Cloud Translation.

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.

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

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

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.15.0:
FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.15.0 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" ]

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

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.

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

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"

Enregistrez le fichier.
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.
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 .
```
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"
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 :

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

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.15.0:
FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.15.0 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" ]

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

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.

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

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

Enregistrez le fichier.
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.
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 .
```
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"
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 :

Ajoutez la commande servicemanager_generate_config dans le fichier Dockerfile :

...
FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.15.0 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" ]

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

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 :

Ajoutez la commande servicemanager_generate_config dans le fichier Dockerfile :

...
FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.15.0 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" ]

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

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.

Étape suivante

En savoir plus sur le nouveau runtime amélioré