Personnaliser le plan de migration pour les services IIS Windows
Examinez le fichier de plan de migration renseigné lors de la création de la migration. Vous pouvez le personnaliser avant de poursuivre l'exécution de la migration. Les informations de votre plan de migration servent à l'extraction des artefacts de conteneur de charge de travail de la VM source.
Cette section décrit le contenu du plan de migration et les types de personnalisations que vous pouvez envisager avant d'exécuter la migration et de générer des artefacts de déploiement.
Avant de commencer
- Cet article suppose que vous avez déjà créé une migration et que vous disposez du fichier de plan de migration qui en résulte.
Structure du plan de migration
Voici la structure complète du plan de migration. Dans les sections suivantes, nous aborderons cette structure, expliquerons chaque partie et comment la modifier.
globalSettings:
globalIis:
enablegmsa: string
apppools:
- enable32bitapponwin64: bool
identitytype: string
managedruntimeversion: string
name: string
connectionStrings:
add:
- connectionstring: string
name: string
providername: string
security:
authentication:
windowsAuthentication:
enabled: bool
providers:
- value: string
authorization:
add:
- access_type: string
roles: string
users: string
verbs: string
remove:
- roles: string
users: string
verbs: string
image:
extraFeatures:
- string
target:
baseVersion: string
requirements:
- string
warnings:
- string
msvcRuntimes:
- string
pathEnvVarAdditionalEntries:
- string
images:
- name: string
probes:
livenessProbe:
probehandler:
exec:
command:
- string
- string
initialdelayseconds: int
timeoutseconds: int
periodseconds: int
successthreshold: int
failurethreshold: int
terminationgraceperiodseconds: optional[int]
readinessProbe:
probehandler:
exec:
command:
- string
- string
initialdelayseconds: int
timeoutseconds: int
periodseconds: int
successthreshold: int
failurethreshold: int
terminationgraceperiodseconds: optional[int]
useractions:
files:
- source: string
target: string
registry:
currentcontrolset:
- path: string
software:
- path: string
workloads:
sites:
site:
- applications:
- applicationpool: string
path: string
virtualdirectories:
- path: string
physicalpath: string
bindings:
- port: int
protocol: string
sslflags: int
connectionstrings:
- connectionstring: string
name: string
providername: string
name: string
security:
authentication:
windowsAuthentication:
enabled: bool
providers:
- value: string
authorization:
add:
- access_type: string
roles: string
users: string
verbs: string
remove:
- roles: string
users: string
verbs: string
serverautostart: bool
version: string
globalSettings
La section "globalSettings" décrit les exigences de base pour les pods exécutant des sites IIS à partir de cette VM. Le processus de découverte recherche les configurations générales dans la VM source et les utilise pour renseigner cette section. Ces configurations contiennent des champs présents dans les configurations d'image spécifiques, comme décrit dans la section suivante, et affectent toutes les images en même temps.
image
La section image
, qui fait suite à globalSettings
, contient la liste des fonctionnalités Windows à installer sur les pods.
Le processus de découverte remplit cette section avec toutes les fonctionnalités Windows qui existent sur la VM d'origine et peuvent être installées sur un conteneur Windows.
msvcRuntimes
Les applications Windows IIS peuvent comporter des installations de versions d'environnement d'exécution Microsoft Visual C++. Ces environnements d'exécution sont automatiquement détectés sur la VM source et inclus dans le plan de migration. Vous pouvez modifier la liste des environnements d'exécution dans le plan de migration en modifiant les membres de msvcRuntimes
:
msvcRuntimes:
- MSVC2012_x64
- MSVC2013_x64
- MSVC2015_x64
- MSVC2012_x86
- MSVC2013_x86
- MSVC2015_x86
pathEnvVarAdditionalEntries
Les applications Windows IIS peuvent inclure des entrées de variable d'environnement PATH
qui ne sont pas par défaut, qui sont automatiquement détectées sur la VM source et incluses dans le plan de migration. Vous pouvez modifier les variables d'environnement PATH
en modifiant les membres de pathEnvVarAdditionalEntries
:
pathEnvVarAdditionalEntries:
- "C:\\myDllsFolder"
- "C:\\ProgramData\\SomeSoftware"
Modifier la section "Image"
Vous pouvez modifier la section image
si :
certaines fonctionnalités suggérées ne sont pas requises par les sites migrés (ce qui peut se produire si la VM source cible des usages autres que l'hébergement de sites IIS) ;
vous avez modifié les sections d'IIS dans le plan de migration et ajouté des configurations qui dépendent de fonctionnalités Windows supplémentaires (par exemple, l'authentification Windows dépend de la fonctionnalité d'authentification Windows).
target
La section cible indique l'image Windows de base qui est utilisée (par exemple, 1909). Ce champ a rarement besoin d'être modifié.
images
Chaque sous-élément de la section images
spécifie une seule image de sortie.
Dans le fichier ZIP des artefacts, chaque image possède un sous-répertoire distinct, avec ses propres fichiers Dockerfile
et deployment_spec.yaml
(consultez la section Déployer l'image du conteneur).
name
Le champ name
décrit le nom de l'image.
Il affecte le nom du sous-répertoire de l'image et le fichier deployment_spec.yaml
dans les artefacts.
probes
Le champ probes
décrit la configuration de la vérification d'état de l'image. Pour en savoir plus sur les vérifications du kubelet, consultez la section Configurer des vérifications d'activité, d'aptitude et de démarrage dans la documentation de Kubernetes.
Modifier les vérifications d'état IIS
Les vérifications d'état peuvent surveiller le temps d'arrêt et l'état de préparation de vos conteneurs gérés. La surveillance de l'état peut réduire les temps d'arrêt des conteneurs migrés et améliorer la surveillance.
Des états de santé inconnus peuvent entraîner une dégradation des disponibilités, une surveillance des disponibilités suggérant un faux positif et une perte potentielle de données. Sans vérification d'état, kubelet ne peut supposer que l'état d'un conteneur et peut envoyer du trafic vers une instance de conteneur qui n'est pas prête. Si l'instance n'est pas prête, vous risquez de perdre du trafic. Kubelet peut également ne pas détecter les conteneurs dans un état figé et ne les redémarrera pas.
Une vérification de l'état fonctionne en exécutant une petite instruction scriptée au démarrage du conteneur.
Le script recherche les conditions de réussite, qui sont définies par le type de vérification utilisé, à chaque période. La période est définie dans le plan de migration par un champ periodSeconds
.
Vous pouvez définir ces vérifications manuellement lors de la personnalisation du plan de migration.
Vous avez le choix entre trois types de vérifications. Toutes reposent sur la vérification probe-v1-core, définie dans la documentation de référence sur probe-v1-core, et partagent la même fonction que les champs correspondants de container-v1-core.
Une fois la détection effectuée, la configuration de la vérification est ajoutée au plan de migration. Les vérifications peuvent être utilisées dans leur configuration par défaut, comme indiqué dans l'exemple suivant. La configuration par défaut utilise la commande exec
pour les vérifications d'activité et d'aptitude. Toutes deux utilisent un script PowerShell appelé probe.ps1
, qui appelle l'outil de ligne de commande IIS appcmd pour vérifier l'état des sites IIS.
Pour désactiver les vérifications, supprimez la section probes
du fichier yaml.
images: name: IMAGE_NAME probes: livenessProbe: probehandler: exec: command: - powershell.exe - C:\m4a\probe.ps1 initialdelayseconds: 0 timeoutseconds: 1 periodseconds: 10 successthreshold: 1 failurethreshold: 3 terminationgraceperiodseconds: null readinessProbe: probehandler: exec: command: - powershell.exe - C:\m4a\probe.ps1 initialdelayseconds: 0 timeoutseconds: 1 periodseconds: 10 successthreshold: 1 failurethreshold: 3 terminationgraceperiodseconds: null
useractions
useractions
spécifie des fichiers et des clés de registre supplémentaires à migrer.
Exemple useractions
-
useractions: files: - source: DRIVE:\FOLDER-OR-FILE-PATH target: DRIVE:\FOLDER-OR-FILE-PATH - source: C:\myfolder target: C:\myfolder - source: D:\myfile target: D:\myfile - source: D:\myfile target: C:\myfile ... registry: currentcontrolset: - path: KEY ... software: - path: KEY ...
Les chemins d'accès spécifiés pour currentcontrolset
et software
correspondent à des clés dans le registre Hive HKEY_LOCAL_MACHINE\System\CurrentControlSet
ou HKEY_LOCAL_MACHINE\Software
.
Modifier useractions
Par défaut, les seuls fichiers copiés dans l'image sont les répertoires virtuels de sites dans l'image spécifiée.
Si votre code ou vos configurations importent des fichiers depuis l'extérieur de ce répertoire, vous devez les ajouter aux actions utilisateur.
De plus, toutes les valeurs de registre dont dépend votre code doivent être ajoutées en modifiant la section useractions
registry
.
Paramètres spécifiques au serveur IIS
Les paramètres liés à IIS sont divisés en paramètres liés à des sites spécifiques, qui font partie de la spécification de l'image, et en paramètres liés à tous les sites, qui sont placés à la suite de la section gloabalIis
.
sites
La section sites décrit les sites qui sont migrés vers une image spécifique. Il est possible que plusieurs images contiennent le même site.
apppools
La section apppools
décrit les pools d'applications créés sur les pods migrés.
enablegmsa
Le champ enablegmsa
joue le rôle de sucre syntaxique du plan de migration. Il s'agit d'un raccourci pour écraser le champ identity du pool d'applications. Pour en savoir plus, consultez la section gMSA.
Chaînes de connexion
Les chaînes de connexion définissent une connexion entre la charge de travail de conteneur migrée et un fournisseur de données du framework .NET.
Migrate to Containers accepte les chaînes de connexion au niveau du site et du champ d'application global.
Pour ajouter une chaîne de connexion à un site, modifiez la définition de site
dans le fichier AppXGenerateArtifactsFlow, qui représente le plan de migration, afin de définir la propriété connectionstrings
:
sites: site: # Add the site connection strings here. connectionstrings: - name: connectionname1 providername: System.Data.SqlClient connectionstring: Database=connectedDB1;Password=Welcome1;User=admin; - name: connectionname2 providername: System.Data.OleDb connectionstring: Database=connectedDB2;Password=Welcome2;User=admin; - applications: - path: / virtualdirectories: ...
Pour ajouter une chaîne de connexion au niveau global (la rendant accessible à tous les sites), modifiez les chaînes de connexion placées directement à la suite de globalIis :
globalIis: enablegmsa: auto connectionStrings: connectionstring: - name: connectionname3 providername: System.Data.SqlClient connectionstring: Database=connectedDB3;Password=Welcome3;User=admin; applicationhost: ...
Où :
name
spécifie le nom de la connexion.providername
spécifie éventuellement le type de fournisseur de données. Migrate to Containers n'accepte que la valeurSystem.Data.SqlClient
. est compatible avec le fournisseur de données .NET Framework :System.Data.SqlClient
System.Data.OleDb
System.Data.Odbc
System.Data.OracleClient
connectionstring
spécifie les chaînes de connexion utilisées pour se connecter au fournisseur de données.
Modifier les sections des chaînes de connexion
Migrate to Containers copie automatiquement les chaînes de connexion détectées dans la VM migrée vers le plan de migration.
Certaines chaînes de connexion peuvent ne pas être détectées et doivent être ajoutées en modifiant le plan de migration comme indiqué ci-dessus (à savoir, si les chaînes de connexion se trouvent dans une section cryptée de applicationhost.config).
Pour savoir comment déterminer les chaînes de connexion à ajouter à votre plan de migration, consultez la section Extraction de chaînes de connexion au moment de l'exécution dans la documentation Microsoft.
Dépendances externes de chaîne de connexion
- Les chaînes de connexion peuvent contenir des dépendances, telles qu'une référence à un fichier sur le site, ou à un utilisateur Windows associé au site. Vous pouvez ajouter au plan de migration des actions utilisateur personnalisées pour copier un fichier supplémentaire dans le système de fichiers. Modifiez manuellement le Dockerfile pour ajouter un utilisateur Windows.
- Les chaînes de connexion peuvent contenir des dépendances, telles qu'une référence à une source de données externe. Ces dépendances doivent être migrées manuellement pour vous assurer que la charge de travail du conteneur migré a bien accès à la source de données.
security
Les sections security contiennent les sous-sections relatives à l'authentification et à l'autorisation.
- L'authentification Windows valide les utilisateurs Active Directory.
- L'autorisation Windows est le mécanisme qui permet de spécifier les utilisateurs autorisés à accéder à un site IIS en fonction du type d'accès. Les types d'accès sont les verbes HTTP (POST, GET, PUT, PATCH, DELETE) ;
Comme pour les chaînes de connexion, pour définir l'autorisation ou l'authentification pour tous les sites, modifiez globalIis
comme dans l'exemple suivant. Pour définir l'autorisation ou l'authentification pour un site spécifique, modifiez l'élément de site.
globalIis: security: authentication: windowsAuthentication: providers: - NTLM authorization: - add: user:John access: role: - remove: user:Jane access: GET role: ...
Où :
providers
spécifie le fournisseur de vos protocoles de sécurité ;user
correspond au nom d'utilisateur ;access
indique les autorisations de l'utilisateur. Les types d'accès sont les verbes HTTP (POST, GET, PUT, PATCH, DELETE) ;role
correspond à un rôle d'autorisation spécifique.
Rubriques avancées
Les sections suivantes traitent de sujets plus larges. Chacune peut nécessiter de modifier le plan de migration.
Configurer SSL
Il n'est pas facile d'extraire des certificats SSL d'une VM source. Il n'est pas non plus recommandé d'installer des certificats SSL et des clés privées dans une image Docker. Dans ce contexte, Migrate to Containers offre plusieurs façons de gérer SSL pour Windows.
Utiliser un certificat autosigné généré automatiquement
Par défaut, un conteneur Windows disposant d'une liaison HTTPS se voit attribuer un certificat autosigné qui est automatiquement généré lors de l'initialisation du conteneur Docker. Cette configuration vous permet de tester la charge de travail migrée, mais ne peut pas être utilisée dans un environnement de production. Le certificat est autosigné et regénéré à chaque nouvelle exécution du conteneur.
Recommandé : utiliser Cloud Load Balancing, Ingress ou Anthos Service Mesh
Vous pouvez personnaliser les liaisons du plan de migration pour utiliser le protocole HTTP. Utilisez ensuite Cloud Load Balancing, Ingress ou Anthos Service Mesh en tant qu'interface HTTPS pour sécuriser l'accès externe. Cette option vous permet de sécuriser la communication externe sans inclure de certificats au sein du cluster.
Pour personnaliser la liaison, modifiez la définition de site
dans l'objet AppXGenerateArtifactsFlow qui représente la migration pour définir protocol
sur http
:
sites: site: - applications: - path: / virtualdirectories: - path: / physicalpath: '%SystemDrive%\inetpub\wwwroot' bindings: - port: 8080 protocol: http name: Default Web Site
Vous pouvez ensuite transférer des requêtes depuis l'interface HTTPS vers le chemin HTTP et le port de la charge de travail Windows.
Stocker des certificats SSL en tant que secrets Kubernetes
Il est recommandé d'utiliser Cloud Load Balancing, Ingress ou Anthos Service Mesh en tant qu'interface HTTPS pour sécuriser l'accès externe. Cependant, vous pouvez également stocker des certificats SSL en tant que secrets Kubernetes et les installer lors de l'exécution dans le conteneur.
Pour utiliser des certificats SSL stockés en tant que secrets Kubernetes, vous devez modifier l'image de déploiement du conteneur. Pour en savoir plus, consultez la page Déployer une charge de travail Windows sur un cluster cible.
Configurer des charges de travail migrées pour utiliser un compte de service gMSA
Les charges de travail d'application Windows IIS sont souvent associées à Active Directory (AD) et fonctionnent à l'aide d'identités de domaine. Lorsque vous migrez ces VM vers des conteneurs, les conteneurs eux-mêmes ne sont pas joints au domaine, mais leurs nœuds de cluster Kubernetes hôtes peuvent être associés à un domaine.
Lorsque vous déployez vos conteneurs migrés sur un cluster, vous pouvez utiliser un compte de service géré de groupe (gMSA). Utilisez ce compte de service gMSA pour exécuter le conteneur sous une identité de compte de service spécifique. Vous associez un compte de service gMSA dans un cluster Kubernetes dans le cadre de la configuration du pod plutôt qu'en tant que configuration d'identité statique dans l'image du conteneur.
Pour pouvoir utiliser un compte de service gMSA dans un conteneur Windows migré, vous devez effectuer les tâches suivantes :
Modifier le plan de migration pour définir les propriétés nécessaires à la configuration du conteneur migré pour qu'il utilise un compte de service gMSA. Ce processus de configuration est décrit dans la section suivante.
Pour pouvoir utiliser un compte de service gMSA, configurez le cluster de traitement qui héberge le conteneur déployé. Pour en savoir plus, consultez la page Déployer une charge de travail Windows sur un cluster cible.
À propos du compte de service gMSA
Vous trouverez plus d'informations sur le compte de service gMSA dans la documentation Google Cloud et dans d'autres documentations. Par exemple, consultez les articles suivants :
- Configurer Active Directory pour permettre aux VM de s'associer automatiquement à un domaine dans la documentation de Google Cloud.
- Utiliser un compte de service géré de groupe dans la documentation Google Cloud.
- Configure your app to use a gMSA (Configurer votre application pour utiliser un compte de service administré de groupe) dans la documentation Microsoft.
- Créer un compte de service gMSA et configurer le pod pour l'utiliser dans la documentation de Kubernetes.
Permettre l'utilisation de gMSA dans Migrate to Containers
Lorsque vous migrez des charges de travail depuis des VM vers des conteneurs Windows, vous devez transformer la configuration de l'application IIS et des autres services Windows configurés pour utiliser des identités AD. Cette transformation est nécessaire pour chaque VM source Windows.
Migrate to Containers vous aide à transformer vos charges de travail. Il détecte automatiquement la configuration des pools d'applications IIS et ajoute des recommandations au plan de migration généré. Vous pouvez ensuite évaluer ces recommandations et les modifier en fonction de votre environnement et de vos exigences spécifiques.
Si Migrate to Containers détermine que la configuration d'un pool d'applications ne nécessite pas de compte de service gMSA, il conserve la configuration d'origine du pool d'applications. C'est le cas, par exemple, lorsqu'un type de compte intégré, tel que "ApplicationPoolIdentity", "NetworkService", "LocalSystem" ou "LocalService" est utilisé.
Configurer un compte de service gMSA
Migrate to Containers ajoute les propriétés suivantes, avec les valeurs recommandées, au plan de migration généré. Vous pouvez ensuite les modifier en fonction de vos besoins afin de contrôler le compte de service gMSA :
enablegmsa
: valeurs autorisées :auto
(valeur par défaut) : convertit le conteneur migré pour utiliser un compte de service gMSA lorsque Migrate to Containers détermine que sa configuration actuelle n'est pas autorisée.all
: convertit toujours le conteneur migré pour utiliser un compte de service gMSA et ignorer le paramètreidentitytype
. Dans ce cas,identitytype
est toujours interprété commeNetworkService
.
identitytype
: spécifie l'identité IIS d'un pool d'applications en tant queApplicationPoolIdentity
(valeur par défaut),NetworkService
,LocalSystem
ouLocalService
. Pour en savoir plus, consultez Understanding identities in IIS (Présentation des identités dans IIS) et Application Pool Identities (Identités de pool d'applications).En règle générale, un conteneur ne peut se voir attribuer qu'un seul compte de service gMSA, ce qui signifie que pour pouvoir utiliser l'identité gMSA, vous devez généralement définir
identitytype
surNetworkService
. Pour en savoir plus, consultez Configure your app to use a gMSA (Configurer votre application pour utiliser un compte de service administré de groupe).
Voici un exemple de plan de migration contenant les propriétés enablegmsa
et identitytype
:
migrationPlan: applications: iis: # Allowed values include: auto (default), all enablegmsa: auto|all applicationhost: apppools: - name: DefaultAppPool # Allowed values include: ApplicationPoolIdentity (default), NetworkService, LocalSystem, LocalService identitytype="NetworkService" - managedruntimeversion: v4.0 name: .NET v4.5 Classic - managedruntimeversion: v4.0 name: .NET v4.5
Générer des artefacts pour un compte de service gMSA
Lorsque vous exécutez le plan de migration pour générer les artefacts de conteneur, Migrate to Containers ajoute automatiquement les directives Dockerfile nécessaires pour attribuer le compte NetworkService. Pour en savoir plus, consultez Configurer votre application pour utiliser un compte de service gMSA.
Par exemple, si vous définissez identitytype
sur NetworkService
, l'instruction se présente sous la forme suivante :
RUN c:\windows\system32\inetsrv\appcmd.exe set apppool \"DefaultAppPool\" \"/-processModel.identityType:NetworkService\";
Migrate to Containers ajoute automatiquement des instructions de lecture de LCA aux dossiers du site en fonction du type identitytype
de la cible et pour le compte utilisateur intégré IUSR.
Cela est effectué automatiquement pour les éléments du système de fichiers d'application dans lesquels le compte d'application d'origine a été spécifié soit explicitement, soit par héritage.
Pour en savoir plus sur la configuration des LCA, consultez la section Configurer des listes de contrôle d'accès.
Enregistrement du fichier DLL de l'objet COM
Depuis la version 1.13.0, les fichiers DLL qui exposent des objets COM sont automatiquement analysés et enregistrés. Au cours de la phase d'extraction, tous les fichiers copiés sont analysés afin d'identifier les DLL enregistrées en tant qu'objets COM, qui sont ensuite enregistrés dans le conteneur.
Ce processus se déroule sans entrée utilisateur. Toutefois, vous pouvez influencer ce processus en ajoutant des fichiers DLL à copier. Si nécessaire, ces DLL sont vérifiées à tour de rôle et enregistrées.
Surveillance des services Windows
Les conteneurs Windows créés lors d'une migration exécutent et surveillent un seul service Windows IIS. Toutefois, certaines charges de travail peuvent nécessiter l'exécution de services supplémentaires pour fonctionner correctement (y compris une base de données, un mécanisme de journalisation, un proxy, etc.).
Pour exécuter des services supplémentaires dans le conteneur migré, ajoutez des entrées à la section windowsServices
et copiez les binaires nécessaires dans la section useractions
.
version: v1
globalSettings:
target:
…
globalIIS:
…
images:
- name: migrated-image-zgwb2
workloads:
sites:
site:
- applications:
...
bindings:
- port: 80
protocol: http
name: Default Web Site
…
windowsServices:
- MyService
useractions:
files:
- source: C:\MyProcess
target: C:\MyProcess
Étapes suivantes
Linux
Migrer à l'aide de Google Cloud
Déploiement
- Examiner les artefacts générés.
- Configurer la journalisation.
- Installer des volumes externes.
- Déployer une charge de travail sur un cluster cible.
- Déployer des VM migrées.
- Mettre à jour des images post-migration
- Surveiller la charge de travail migrée.
- Testez votre application à migrer et validez la migration.
Windows
Migrer à l'aide de Google Cloud
Déployer
- Préparer un cluster pour le déploiement.
- Déployer des VM migrées.
- Surveiller la charge de travail migrée.
- Testez votre application à migrer et validez la migration.
Tomcat
Migrer à l'aide d'un ordinateur local
Migrer à l'aide de Google Cloud
Déployer
- Préparer un cluster pour le déploiement.
- Créer et déployer des images de conteneurs.
- Surveiller la charge de travail migrée.
- Testez votre application à migrer et validez la migration.
WebSphere
Migrer à l'aide d'un ordinateur local
Migrer à l'aide de Google Cloud
- Présentation de la migration.
- Conditions requises.
- Avant de commencer.
- Ajouter une source de migration.
- Créer un plan de migration.
- Migrer les données.
- Personnaliser le plan de migration.
- Exécuter la migration.
- Surveiller la migration.
- Créer une image de conteneur d'application.
- Déployer un conteneur d'application sur un cluster cible.
- Supprimer une migration.
- Dépannage.
Déployer
- Préparer un cluster pour le déploiement.
- Créer et déployer des images de conteneurs.
- Surveiller la charge de travail migrée.
- Testez votre application à migrer et validez la migration.
JBoss
Migrer à l'aide d'un ordinateur local
Migrer à l'aide de Google Cloud
Déployer
- Préparer un cluster pour le déploiement.
- Créer et déployer des images de conteneurs.
- Surveiller la charge de travail migrée.
- Testez votre application à migrer et validez la migration.
Apache
Migrer à l'aide d'un ordinateur local
Migrer à l'aide de Google Cloud
Déployer
- Préparer un cluster pour le déploiement.
- Créer et déployer des images de conteneurs.
- Surveiller la charge de travail migrée.
- Testez votre application à migrer et validez la migration.
WordPress
Migrer à l'aide de Google Cloud
Déployer
- Préparer un cluster pour le déploiement.
- Créer et déployer des images de conteneurs.
- Surveiller la charge de travail migrée.
- Testez votre application à migrer et validez la migration.