À propos des conteneurs système Linux

La CLI Migrate to Containers vous permet de migrer des applications Linux vers des environnements conteneurisés. Elle utilise un conteneur système Linux prédéfini qui sert de bootloader pour les services requis par l'application modernisée. Grâce à Migrate to Containers pour les applications Linux, vous pouvez moderniser une large gamme d'applications sans état pour les exécuter sur Google Kubernetes Engine (GKE), Cloud Run et des clusters GKE.

Pour en savoir plus, consultez la page Architecture de la CLI Migrate to Containers.

Ce document fournit des détails sur les conteneurs système Linux Migrate to Containers utilisés dans le cadre de la solution d'exécution des applications migrées à l'aide de Migrate to Containers.

Migration à l'aide de conteneurs système Linux

Migrate to Containers détecte les fichiers et les processus de l'application source. Il génère ensuite des artefacts, qui incluent un fichier Dockerfile, un fichier manifeste Kubernetes et une configuration Skaffold.

La fonction principale d'un conteneur système Linux consiste à lancer les services qui ont été exécutés à l'origine sur l'instance de machine virtuelle (VM) source, y compris les systèmes d'exploitation et les services d'applications pertinents.

Le fichier Dockerfile est utilisé pour créer l'image pour votre VM migrée. Un fichier Dockerfile de conteneur système Linux se présente généralement comme suit:

# Please refer to the documentation:
# https://cloud.google.com/migrate/anthos/docs/dockerfile-reference

FROM us-docker.pkg.dev/migrate-modernize-public/modernize-plugins-prod/service-manager-runtime:1.0.0 as service-manager-runtime

FROM scratch

# Tar containing data captured from the source VM
ADD vmFiles.tar.gz /

COPY --from=service-manager-runtime / /

ADD blocklist.yaml /.m4a/blocklist.yaml

ADD logs.yaml /code/config/logs/logsArtifact.yaml

ADD services-config.yaml /.m4a/

ADD tempfiles.yaml  /.m4a/

# If you want to update parts of the image, add your commands here.
# For example:
# RUN apt-get update
# RUN apt-get install -y \
#       package1=version \
#       package2=version \
#       package3=version
# RUN yum update
# RUN wget http://github.com

ENTRYPOINT ["/ko-app/service-manager-runtime", "start", "-c", "/.m4a/"]

Lorsque vous exécutez une migration, les instructions Dockerfile suivantes copient ou ajoutent les données de VM de la source d'origine à l'image Docker:

L'instruction suivante ajoute le fichier tar contenant les données capturées par la VM source à l'image Docker:
```
ADD vmFiles.tar.gz /
```
Ce fichier tar est créé par Migrate to Containers. Il contient le système de fichiers racine de la VM source avec tous les éléments fournis dans les filtres du plan de migration et tous les dossiers fournis dans le plan de migration de données filtrés.
L'instruction suivante importe l'environnement d'exécution Migrate to Containers à partir du dépôt Docker vers l'image Docker:
```
FROM us-docker.pkg.dev/migrate-modernize-public/modernize-plugins-prod/service-manager-runtime:1.0.0 as service-manager-runtime
```
L'instruction suivante copie ensuite l'environnement d'exécution Migrate to Containers dans l'image Docker:
```
COPY --from=service-manager-runtime / /
```

Cliquez pour afficher les détails du fichier d'exécution Migrate to Containers

/ko-app/service-manager-runtime est le fichier d'exécution principal de Migrate to Containers. Il s'agit d'un système d'initialisation conçu pour les conteneurs. Il effectue les opérations suivantes :

Il lit le fichier /.m4a/services-config.yaml et exécute les binaires spécifiés dans l'ordre selon la méthode d'exécution spécifiée, telle que daemonize ou non daemonize, attendre la fin.
Collecte les journaux spécifiés dans le fichier /code/config/logs/logsArtifact.yaml et les imprime sur stdout du conteneur. Pour les clusters GKE et GKE, il garantit également que les journaux sont envoyés à Cloud Logging.

Maintenance des charges de travail migrées

Vous pouvez créer un pipeline pour votre application à partir des artefacts migrés. Vous pouvez disposer d'un pipeline différent pour différentes applications. Vous pouvez conserver votre pipeline d'intégration et de déploiement continus existant qui a généré l'application basée sur des VM d'origine, et ajouter les étapes pertinentes qui transforment les exécutables générés en conteneurs système Linux.

Le schéma suivant illustre un exemple de pipeline utilisant Migrate to Containers:

Flux CI/CD automatisé pour le changement de plate-forme d'applications à l'aide de Migrate to Containers

Ce schéma montre le processus de modification d'une application existante.

Une modification du code source ou du nouveau chemin de l'OS est transmise au dépôt Git existant. La source est compilée en fonction de la configuration existante et une nouvelle image est créée. La nouvelle image inclut la couche d'exécution Migrate to Containers.

Dans l'environnement de test, un développeur exécute des tests préliminaires pour vérifier si la nouvelle image fonctionne comme prévu. Après la phase de test, une nouvelle image de conteneur système est créée et transférée vers l'environnement de développement ou de test, qui est ensuite déployé en production.