Utilisation de l' AWS OpsWorks Stacks outil Detach in Place - AWS OpsWorks
Comment fonctionne le processusLimitesPremiers pas

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Utilisation de l' AWS OpsWorks Stacks outil Detach in Place

Important

Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible.

Cette section décrit comment utiliser l'outil AWS OpsWorks Stacks Detach in Place pour détacher vos OpsWorks instances du service OpsWorks Stacks.

Les instances que vous détachez resteront dans le vôtre Compte AWS, mais vous ne pourrez plus les gérer à l'aide OpsWorks de. Vous utiliserez plutôt Amazon EC2 ou toute autre approche compatible avec EC2 pour configurer et gérer les instances. AWS Systems Manager

À un niveau élevé, le processus de détachement comprend les étapes suivantes :

  1. L'outil effectue des contrôles de validation pour s'assurer que les ressources sont prêtes à être détachées.

  2. L'outil exporte le code JSON personnalisé depuis votre OpsWorks pile et le stocke sous forme d'objet dans Amazon S3.

  3. L'outil crée des documents Systems Manager Automation représentant chaque événement du cycle de vie de OpsWorks Stacks.

  4. L'outil crée un AWS Service Catalog AppRegistry catalogue pour toutes les instances qui sont détachées et détache les équilibreurs de charge Elastic Load Balancing (ELB) des couches. OpsWorks

  5. Enfin, l'outil détache et désenregistre d'autres ressources, notamment les instances Amazon Relational Database Service (Amazon RDS).

Comment fonctionne le processus

L'outil Detach In Place fournit les 3 commandes suivantes et une expérience semblable à celle d'un assistant qui vous guide à travers une série d'étapes pour vérifier et configurer vos instances avant de procéder au détachement de votre couche.

Command Description

handle-prerequisites

Cette commande analyse si toutes les instances d'une couche sont éligibles au détachement et résout les conditions préalables. Les instances doivent être en bon état OpsWorks, elles ne peuvent pas être équipées de scalers automatiques basés sur le temps ou la charge, et la dernière version de l' OpsWorks agent doit être installée.

En outre, la commande vérifie si toutes les instances disposent des autorisations requises pour prendre en charge l'agent SSM et si la dernière version de l'agent SSM est installée. La commande installera l'agent SSM s'il n'est pas présent et mettra à jour l'agent SSM s'il n'utilise pas la dernière version. La commande ajoutera également les autorisations nécessaires.

detach

Cette commande détache toutes les OpsWorks instances de la couche spécifiée.

Tout d'abord, la commande exécutera une vérification des conditions préalables pour s'assurer que la couche est éligible au détachement. Si vous ne souhaitez pas résoudre les conditions préalables, vous avez la possibilité de forcer le détachement.

Ensuite, la commande indiquera que toutes les balises ajoutées à vos instances via des API de OpsWorks balisage ou par la propagation de balises à partir de vos couches et piles seront conservées. Vous pouvez supprimer n'importe laquelle de ces balises à l'aide des API EC2 appropriées une fois le détachement terminé.

Ensuite, la commande vérifiera si vous souhaitez exporter la configuration associée à Chef vers les paramètres SSM.

Si un Classic Load Balancer est attaché à la couche, la commande vous demandera s'il peut détacher l'équilibreur de charge afin d'éviter tout temps d'arrêt.

cleanup

Cette commande supprime toutes les entités OpsWorks de votre compte. Cela mettra fin aux instances et supprimera toutes les piles. Cela doit être utilisé pour les ressources qui ne sont plus nécessaires comme dernière étape pour nettoyer le compte.

Note

Nous vous recommandons d'exécuter la nouvelle installation pendant quelques jours avant d'exécuter la cleanup commande. Cela garantit que toutes les configurations nécessaires issues de la pile sont facilement disponibles en cas de besoin.

Limites

L'objectif principal de l'outil Detach In Place est de détacher les instances OpsWorks Stacks en toute sécurité. Cette section résume les limites de l'outil.

  • Agent SSM Windows : si l'agent SSM n'est pas installé sur l'instance, vous devez l'installer manuellement. Il en va de même si l'agent n'est pas mis à jour vers la dernière version.

  • Instances Time/Load Auto Scaling : l'outil de détachement ne prend pas en charge les instances pour lesquelles Auto Scaling est activé. Vous devez désactiver Auto Scaling sur les instances que vous souhaitez détacher.

  • Autorisations : l'outil de détachement ne crée ni ne génère les entités IAM spécifiées sur la page Autorisations de la OpsWorks console.

  • Applications : l'outil de détachement ne crée ni ne génère d'applications en dehors de OpsWorks.

Premiers pas

Étape 1 : vérifier que les conditions préalables sont remplies

Les 3 commandes de l'outil Detach In Place sont des scripts Python, que vous pouvez exécuter localement, sur une instance EC2 ou en utilisant. AWS CloudShell

AWS CloudShell est un shell basé sur un navigateur qui vous permet d'accéder en ligne de commande aux AWS ressources du fichier sélectionné. Région AWS AWS CloudShell est préinstallé avec des outils populaires (tels que AWS CLI Python). Lors de l'utilisation AWS CloudShell, vous utilisez les mêmes informations d'identification que celles que vous utilisez pour vous connecter à la console.

Cette procédure pas à pas suppose que vous utilisez AWS CloudShell.

Étape 2 : Téléchargez le script

  1. Téléchargez le fichier zip qui contient le script de migration et tous les fichiers pertinents en exécutant la commande suivante :

    aws s3api get-object \
--bucket detach-in-place-bucket-prod-us-east-1 \
--key detach_in_place_script.zip detach_in_place_script.zip

  2. Décompressez le fichier en exécutant la commande suivante.

    unzip detach_in_place_script.zip

    Une fois le fichier décompressé, les fichiers suivants sont disponibles :

    • Lisez-moi .md

    • LICENCE

    • NOTICE

    • requirements.txt

    • TODO.py

  3. Si nécessaire, installez pipenv en exécutant la commande suivante.

    pip install pipenv

Étape 3 : Exécuter le script

Configurez d'abord votre environnement de manière à pouvoir exécuter le script en exécutant les commandes suivantes.

pipenv install -r requirements.txt
pipenv shell

Passez ensuite en revue les paramètres du script.

Command Paramètre Description Type Obligatoire Par défaut

handle-prerequisites

--layer-id

ID de la couche que vous souhaitez détacher.

Chaîne

Oui

-

--region

La région de la OpsWorks pile. Si votre région de OpsWorks pile et votre région de point de terminaison d'API sont différentes, utilisez la région de pile. Il s'agit de la même région que les autres ressources de votre OpsWorks pile (par exemple, les instances et les sous-réseaux EC2).

Chaîne

Non

us-east-1

detach

--layer-id

ID de la couche que vous souhaitez détacher.

Chaîne

Oui

-

--batch-size

Nombre d'instances à détacher d'une couche (par exemple, 5).

Chaîne

Non

-

--region

La région de la OpsWorks pile. Si votre région de OpsWorks pile et votre région de point de terminaison d'API sont différentes, utilisez la région de pile. Il s'agit de la même région que les autres ressources de votre OpsWorks pile (par exemple, les instances et les sous-réseaux EC2).

Chaîne

Non

us-east-1

cleanup

--stack-id

ID de la pile que vous souhaitez supprimer.

Chaîne

Non

S'excluant mutuellement, vous devez spécifier un ID de couche ou un ID de pile

--layer-id

ID de la couche que vous souhaitez supprimer

Chaîne

Non

--region

La région de la OpsWorks pile. Si votre région de OpsWorks pile et votre région de point de terminaison d'API sont différentes, utilisez la région de pile. Il s'agit de la même région que les autres ressources de votre OpsWorks pile (par exemple, les instances et les sous-réseaux EC2).

Chaîne

Non

us-east-1

Vous pouvez voir les options disponibles pour les cleanup commandesdetach, handle-prerequisites et en exécutant les commandes avec l'--helpoption comme suit :

python3 layer_detacher.py detach --help
python3 layer_detacher.py handle-prerequisites --help
python3 layer_detacher.py cleanup --help

Vous êtes maintenant prêt à commencer. Les exemples suivants montrent comment exécuter les commandes pour différents cas d'utilisation.

Exemple 1 : vérifier si une couche remplit toutes les conditions requises et est éligible au détachement

La commande suivante lit les informations relatives à une OpsWorks couche (et aux instances qu'elle inclut) et vérifie si les conditions préalables suivantes sont remplies :

  • Toutes les instances sont en ligne.

  • Il n'existe aucune instance Load/Time Auto Scaling.

  • Toutes les instances disposent de la dernière version de OpsWorks l'agent.

  • La dernière version de l'agent SSM est installée et configurée sur toutes les instances.

  • Toutes les instances possèdent une paire de clés SSH.

  • Chaque instance appartient exactement à une couche.

python3 layer_detacher.py handle-prerequisites \
--layer-id opsworks-layer-id \
--region opsworks-stack-region

Exemple 2 : détacher toutes les instances d'une couche

La commande suivante va itérer sur toutes les instances de la couche, vérifier si les instances répondent aux prérequis et essayer de détacher en parallèle toutes les instances qui répondent aux prérequis. Si un ou plusieurs prérequis ne sont pas remplis, la commande fournira une option de détachement forcé pour les instances non conformes restantes.

Avant de détacher une instance, la commande doit :

  1. Enregistrez le code JSON personnalisé et téléchargez-le dans S3.

  2. Créez des documents d'automatisation SSM pour chaque événement OpsWorks du cycle de vie de la couche et téléchargez les journaux d'exécution des documents d'automatisation sur S3.

  3. Créez une AppRegistry application pour toutes les instances qui seront détachées. L'application est associée à un groupe de ressources qui contient toutes les instances et ressources détachées. Les ressources incluent des documents SSM Automation et des paramètres SSM contenant des informations sur les événements du cycle de vie et des recettes Chef personnalisées.

  4. Détache le Classic Load Balancer de la couche, s'il en existe un.

Cette commande modifiera uniquement OpsWorks les ressources. Le statut des instances EC2 restera le même.

python3 layer_detacher.py detach \
--layer-id opsworks-layer-id \
--region opsworks-stack-region

Exemple 3 : détacher toutes les instances d'une couche par lots

La commande suivante fait la même chose que dans l'exemple précédent. La seule différence est qu'il détache les instances par lots.

Cette commande modifiera uniquement OpsWorks les ressources. Le statut des instances EC2 restera le même.

python3 layer_detacher.py detach \
--layer-id opsworks-layer-id \
--region opsworks-stack-region \
--batch-size 5

Exemple 4 : nettoyer toutes les ressources d'une couche et supprimer la couche

La commande suivante va itérer toutes les ressources d'une couche et les supprimer. Plus en détail, il arrêtera et supprimera toutes les instances dans EC2, détachera l'équilibreur de charge OpsWorks et annulera l'enregistrement des instances, des adresses IP élastiques et des volumes Amazon RDS. Après avoir nettoyé les ressources, la couche sera supprimée.

Cette commande supprimera les OpsWorks ressources et les instances EC2. Si vous souhaitez que vos instances EC2 restent intactes, utilisez la detach commande avant de l'cleanuputiliser. De cette façon, la cleanup commande supprimera toutes les ressources restantes.

python3 layer_detacher.py cleanup \
--layer-id opsworks-layer-id \
--region opsworks-stack-region

Exemple 5 : nettoyer toutes les ressources d'une pile et supprimer la pile

La commande suivante va itérer sur toutes les couches, puis sur les ressources de chaque couche. Pour chaque couche, la commande arrête et supprime toutes les instances dans OpsWorks et EC2, détache les équilibreurs de charge et annule l'enregistrement des instances Amazon RDS, des adresses IP élastiques et des volumes. Ensuite, la commande supprimera la couche. Le même processus sera effectué dans chaque couche appartenant à cette pile. Enfin, une fois toutes les couches supprimées, la pile sera supprimée.

Cette commande supprimera les OpsWorks ressources et les instances EC2. Si vous souhaitez que vos instances EC2 restent intactes, utilisez la detach commande avant de l'cleanuputiliser. De cette façon, la cleanup commande supprimera toutes les ressources restantes.

python3 layer_detacher.py cleanup \
--stack-id opsworks-stack-id \
--region opsworks-stack-region

Étape 4 : Continuez à exploiter vos ressources après vous être détaché de OpsWorks

Après avoir exécuté la detach commande, l'outil crée une nouvelle AWS Service Catalog AppRegistry application correspondant à la couche détachée. Le nom de l'application suit le formatlayer-name---layer-id. Il ajoute également la OpsWorksLayerId balise pour identifier de manière unique l'application correspondant à la couche détachée.

Pour ajouter de nouvelles AWS ressources à cette application (par exemple, de nouvelles instances EC2), vous pouvez effectuer l'une des opérations suivantes :

  1. Marquez la ressource avec le tag d'application unique de l' AppRegistryapplication :

    Clé du tag : awsApplication

    Valeur : arn:aws:resource-groups:region:account-id:group/application-name/application-id>

  2. Exécutez la commande associate-resource.

En outre, pour chaque AppRegistry application, un groupe de ressources est créé. Le groupe de ressources contient les balises suivantes.

Clé de balise Valeur

EnableAWSServiceCatalogAppRegistry

TRUE

aws:servicecatalog:applicationName

application-name

aws:servicecatalog:applicationId

application-id

aws:servicecatalog:applicationArn

arn:aws:servicecatalog:region:account-id:/applications/application-id

Exécution de tâches après le détachement

Le tableau suivant fournit des informations sur la manière d'effectuer des tâches après le détachement :

Tâche Description

Exécution d'événements liés au cycle

Après avoir exécuté la detach commande et si vous avez sélectionné l'option, le script crée 5 documents d'automatisation correspondant aux 5 événements OpsWorks du cycle de vie.

Le nom de chaque document d'automatisation suit ce format :layer-id_lifecycle-event_automation_document.

Pour simuler OpsWorks le comportement dans Systems Manager, vous devez déclencher manuellement des exécutions d'automatisation lors du provisionnement, de la résiliation d'instances EC2 ou du déploiement/de la suppression de recettes.

Mise à jour du JSON personnalisé

Les fichiers JSON personnalisés pour la pile et la couche sont stockés dans un compartiment S3 spécifié lors du détachement, ou bien dans un nouveau compartiment S3 créé.

Les noms de fichiers enregistrés pour les fichiers JSON sont les suivants :

  • layercustomjson.json

  • stackcustomjson.json

Modification de votre liste de courses pour les événements du cycle de vie

La liste des exécutions pour chaque événement du cycle de vie est définie dans le document d'automatisation correspondant. Pour modifier la liste des exécutions, recherchez les documents d'automatisation dans l' AppRegistry application et modifiez le RunList paramètre.

Le processus de mise à jour des recettes et des livres de recettes est inchangé carAWS-ApplyChefRecipes, celui déclenché par les documents d'automatisation, prend en charge la même source que OpsWorks.

Gestion de la guérison automatique et de la mise à l'échelle automatique

Lorsque vous détachez une instance, l' OpsWorks agent est désinstallé. Sans l'agent, vous OpsWorks ne pouvez pas réparer ou remplacer automatiquement les instances défectueuses, pas plus qu'il ne peut faire évoluer automatiquement votre flotte. Pour continuer à effectuer le dimensionnement automatique et à remplacer les instances défaillantes, créez un groupe Amazon EC2 Auto Scaling. Le groupe lancera de nouvelles instances pour maintenir la capacité souhaitée lorsqu'Amazon EC2 détectera des instances défectueuses qui doivent être remplacées.

Gestion du Load Balancer

Si votre couche utilise un Classic Load Balancer, la detach commande le détachera avant de désenregistrer les instances. Cela permet de garantir que toutes les associations d'instances ELB restent préservées sur Amazon EC2 tout au long du détachement, ce qui permet d'éviter toute interruption de service. Une fois le processus terminé, vous pourrez gérer votre ELB sur EC2.

Connexion aux instances

Lorsque vous exécutez la detach commande handle-prerequisites or, deux vérifications sont effectuées :

  • Version de l'agent SSM et autorisations

  • Clés SSH

Les commandes vous offrent également la possibilité de mettre à jour l'agent SSM et d'ajouter les autorisations requises afin que vous puissiez vous connecter aux instances à l'aide du gestionnaire de session. Si des clés SSH existent, vous avez également la possibilité d'accéder à l'instance en SSH.

Utilisation de l'onglet Instances du gestionnaire d'applications Systems Manager

Après le détachement, vous pourrez consulter et gérer vos instances dans l'onglet Instances d'Application Manager.

L'onglet Instances fournit des informations agrégées sur les instances EC2 d'une application, telles que leur statut, leur état de santé et le statut de la dernière commande. Cet onglet vous permet de consulter des informations détaillées sur les instances individuelles, telles que l'historique des commandes, les états des alarmes, l'état de santé des agents Systems Manager, etc. L'onglet Instances propose également diverses actions, telles que la possibilité d'appliquer des recettes Chef, de démarrer ou d'arrêter une instance, ou d'ajouter ou de supprimer une instance d'un groupe Auto Scaling.