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 des ressources de calcul créées en dehors d' OpsWorks Stacks
**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. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
**Note**
Cette fonctionnalité est prise en charge uniquement pour les piles Linux.
[instances](workinginstances.md)décrit comment utiliser OpsWorks Stacks pour créer et gérer des groupes d'instances Amazon Elastic Compute Cloud (Amazon EC2). Vous pouvez également intégrer des ressources informatiques Linux dans une pile créée en dehors de OpsWorks Stacks :
+ EC2 Instances Amazon que vous avez créées directement à l'aide de la EC2 console, de la CLI ou de l'API Amazon.
+ Instances *locales* s'exécutant sur votre propre matériel, y compris les instances s'exécutant dans les machines virtuelles.
Ces ressources informatiques deviennent des instances OpsWorks gérées par Stacks, et vous pouvez les gérer de la même manière que les instances Stacks classiques OpsWorks :
+ **Gérer les autorisations des utilisateurs** : vous pouvez utiliser la [gestion des utilisateurs de OpsWorks Stacks](opsworks-security-users.md) pour spécifier quels utilisateurs sont autorisés à accéder à vos piles, quelles actions ils sont autorisés à effectuer sur les instances de la pile et s'ils disposent d'un accès SSH et de privilèges sudo.
+ **Automatiser les tâches** : vous pouvez demander à OpsWorks Stacks d'exécuter des recettes Chef personnalisées pour effectuer des tâches telles que l'exécution de scripts sur une ou toutes les instances d'une pile à l'aide d'une seule commande.
Si vous attribuez l'instance à une [couche](workinglayers.md), OpsWorks Stacks exécute automatiquement un ensemble spécifique de recettes Chef sur l'instance à des moments clés de son [cycle de vie](workingcookbook-events.md), y compris vos recettes personnalisées. Notez que vous ne pouvez attribuer des EC2 instances Amazon enregistrées qu'à [des couches personnalisées](workinglayers-custom.md).
+ **Gestion des ressources** : une pile vous permet de regrouper et de gérer les ressources dans un Région AWS, et le OpsWorks tableau de bord indique l'état de vos piles dans toutes les régions.
+ **Installer des packages** — Vous pouvez utiliser des recettes Chef pour installer des packages sur n'importe quelle instance d'une pile.
+ **Mettre à jour le système d'exploitation** — OpsWorks Stacks fournit un moyen simple d'installer les correctifs de sécurité et les mises à jour du système d'exploitation sur les instances d'une pile.
+ **Déployer des applications** : OpsWorks Stacks déploie les applications de manière cohérente sur toutes les instances de serveur d'applications de la pile.
+ **Surveillance** — OpsWorks Stacks crée des [CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatch.html)métriques personnalisées pour surveiller toutes les instances de votre stack.
Pour plus d'informations sur les tarifs, consultez la section [ OpsWorks Tarification AWS](https://aws.amazon.com/opsworks/stacks/pricing/).
Voici la procédure de base pour utiliser une instance enregistrée.
1. Enregistrez l'instance auprès d'une pile.
L'instance fait désormais partie de la pile et est gérée par OpsWorks Stacks.
1. Le cas échéant, assignez l'instance à une couche.
Cette étape vous permet de tirer pleinement parti des fonctionnalités de gestion de OpsWorks Stacks. Vous pouvez attribuer des instances sur site enregistrées à n'importe quelle couche ; les EC2 instances Amazon enregistrées ne peuvent être attribuées qu'à des couches personnalisées.
1. Utilisez OpsWorks Stacks pour gérer l'instance.
1. Lorsque vous n'avez plus besoin de l'instance dans la pile, désenregistrez-la, ce qui la supprime de OpsWorks Stacks.
Les sections suivantes décrivent le processus en détail.
**Topics**
+ [
# Enregistrement d'une instance auprès d'un OpsWorks Stacks Stacks
](registered-instances-register.md)
+ [
# Gestion des instances enregistrées
](registered-instances-manage.md)
+ [
# Attribution d'une instance enregistrée à une couche
](registered-instances-assign.md)
+ [
# Annulation de l'enregistrement d'une instance
](registered-instances-unassign.md)
+ [
# Annulation de l'enregistrement d'une instance
](registered-instances-deregister.md)
+ [
# Cycle de vie des instances enregistrées
](registered-instances-lifecycle.md)
# Enregistrement d'une instance auprès d'un OpsWorks Stacks Stacks
**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. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
**Note**
Cette fonctionnalité est prise en charge uniquement pour les piles Linux.
Pour enregistrer une instance en dehors de OpsWorks Stacks, vous devez exécuter la AWS CLI **aws opsworks register** commande. Vous pouvez exécuter cette commande à partir de l'instance que vous souhaitez enregistrer, ou à partir d'un autre ordinateur. Vous appliquez les `AWSOpsWorksRegisterCLI_OnPremises` politiques `AWSOpsWorksRegisterCLI_EC2` OR à un utilisateur ou à un groupe pour accorder les autorisations requises pour l'enregistrement EC2 ou AWS CLI pour les instances sur site, respectivement. Ces politiques nécessitent la version 1.16.180 AWS CLI ou une version ultérieure.
**Note**
Pour empêcher les utilisateurs ou les rôles d'enregistrer des instances, mettez à jour le profil d'instance pour refuser l'accès à la **register** commande.
Le processus d'enregistrement installe un agent sur une instance que vous souhaitez gérer à l'aide de OpsWorks Stacks et enregistre l'instance auprès d'une OpsWorks pile que vous spécifiez. Après l’enregistrement de l’instance, celle-ci fait partie de la pile et est gérée par OpsWorks Stacks. Pour de plus amples informations, veuillez consulter [Gestion des instances enregistrées](registered-instances-manage.md).
**Note**
Bien qu'[AWS Tools for PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-welcome.html) inclue l'[https://docs.aws.amazon.com/powershell/latest/reference/items/Register-OPSInstance.html](https://docs.aws.amazon.com/powershell/latest/reference/items/Register-OPSInstance.html)applet de commande, qui appelle l'action d'`register`API, nous vous recommandons d'utiliser plutôt le AWS CLI pour exécuter la `register` commande.
Le schéma suivant montre les deux approches pour enregistrer une EC2 instance Amazon. Vous pouvez utiliser les mêmes approches pour enregistrer une instance sur site.
![\[Two diagrams showing EC2 instance registration: from workstation and from instance itself.\]](http://docs.aws.amazon.com/fr_fr/opsworks/latest/userguide/images/on-prem-provision.png)
**Note**
Vous pouvez utiliser la [console OpsWorks Stacks](https://console.aws.amazon.com/opsworks/) pour gérer une instance enregistrée, mais vous devez exécuter une commande `register` de l'interface de ligne de commande AWS pour enregistrer l'instance. La raison est que le processus d'enregistrement doit être exécuté à partir de l'instance, ce qui ne peut pas être effectué par la console.
Les sections suivantes décrivent la procédure en détail.
**Topics**
+ [
# Procédure pas à pas : enregistrer une instance à partir de votre station de travail
](registered-instances-register-walkthrough.md)
+ [
# Enregistrement d'Amazon EC2 et d'instances sur site
](registered-instances-register-registering.md)
# Procédure pas à pas : enregistrer une instance à partir de votre station de travail
**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. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
**Note**
Cette fonctionnalité est prise en charge uniquement pour les piles Linux.
Le processus d'enregistrement prend en charge plusieurs scénarios. Cette section vous présente un end-to-end exemple de scénario : comment utiliser votre poste de travail pour enregistrer une EC2 instance Amazon. Les autres scénarios d'enregistrement utilisent une procédure similaire. Pour de plus amples informations, veuillez consulter [Enregistrement d'Amazon EC2 et d'instances sur site](registered-instances-register-registering.md).
**Note**
Vous souhaitez généralement enregistrer une EC2 instance Amazon existante. Cependant, vous pouvez juste créer une nouvelle instance et une nouvelle pile pour la procédure pas à pas et les supprimer lorsque vous avez terminé.
**Topics**
+ [
## Étape 1 : Créer une pile et une instance
](#registered-instances-register-walkthrough-prepare)
+ [
## Étape 2 : Installation et configuration de l'interface AWS CLI
](#registered-instances-register-walkthrough-cli)
+ [
## Étape 3 : enregistrer l'instance auprès de EC2 Register Stack
](#registered-instances-register-walkthrough-register)
## Étape 1 : Créer une pile et une instance
Pour commencer, vous avez besoin d'une pile et d'une EC2 instance Amazon pour être enregistrées auprès de cette pile.
**Pour créer la pile et l'instance**
1. Utilisez la [console OpsWorks Stacks](https://console.aws.amazon.com/opsworks/) pour [créer une pile](workingstacks-creating.md) nommée **EC2Register**. Vous pouvez accepter les valeurs par défaut pour les autres paramètres de la pile.
1. Lancez une nouvelle instance depuis la [ EC2 console Amazon](https://console.aws.amazon.com/ec2/). Remarques :
+ L'instance doit être dans la même région et le même VPC que la pile.
Si vous utilisez un VPC, choisissez un sous-réseau public pour cette procédure pas à pas.
+ Si vous devez créer une clé SSH, sauvegardez le fichier de clé privée sur votre station de travail et enregistrez le nom et l'emplacement du fichier.
Si vous utilisez une clé existante, enregistrez le nom et l'emplacement du fichier de clé privée. Vous aurez besoin de ces valeurs plus tard.
+ L'instance doit être basée sur l'un des [systèmes d'exploitation Linux pris en charge](workinginstances-os-linux.md). Par exemple, si votre stack se trouve dans l'ouest des États-Unis (Oregon), vous pouvez l'utiliser `ami-35501205` pour lancer une instance Ubuntu 14.04 LTS dans cette région.
Sinon, acceptez les valeurs par défaut.
Tandis que l'instance démarre, vous pouvez passer à la section suivante.
## Étape 2 : Installation et configuration de l'interface AWS CLI
L'enregistrement est effectué à l'aide de la AWS CLI **aws opsworks register** commande. Avant d'enregistrer votre première instance, vous devez exécuter la version 1.16.180 AWS CLI ou une version plus récente. Les détails de l'installation dépendent du système d'exploitation de votre station de travail. Pour plus d'informations sur l'installation de AWS CLI, consultez [Installation de l'interface de ligne de commande AWS](https://docs.aws.amazon.com/cli/latest/userguide/installing.html). Pour vérifier la version de l’ AWS CLI que vous exécutez, entrez `aws --version` dans une session shell.
**Note**
Pour empêcher les utilisateurs ou les rôles d'enregistrer des instances, mettez à jour le profil d'instance pour refuser l'accès à la **register** commande.
Nous vous recommandons vivement de ne pas sauter cette étape, même si vous l'exécutez déjà AWS CLI sur votre poste de travail. Utiliser la version actuelle de AWS CLI est une bonne pratique de sécurité.
Vous devez fournir `register` avec un ensemble d'informations d'identification AWS disposant des autorisations appropriées. La méthode recommandée pour ce faire, afin d'éviter d'installer des informations d'identification directement sur une instance, consiste à enregistrer les instances lancées avec un profil d'instance, puis à ajouter le `--use-instance-profile` commutateur à votre commande. `register` Si vous obtenez des informations d'identification à partir d'un profil d'instance, passez directement à [Étape 3 : enregistrer l'instance auprès de EC2 Register Stack](#registered-instances-register-walkthrough-register) dans cette rubrique. Toutefois, si votre instance n'a pas été lancée avec un profil d'instance, vous pouvez créer un utilisateur IAM. La procédure suivante crée un nouvel utilisateur avec les autorisations appropriées, en installant les informations d'identification de l'utilisateur sur le poste de travail, puis en les transmettant à`register`.
**Avertissement**
Les utilisateurs IAM disposent d’informations d’identification à long terme, ce qui présente un risque de sécurité. Pour atténuer ce risque, nous vous recommandons de ne fournir à ces utilisateurs que les autorisations dont ils ont besoin pour effectuer la tâche et de supprimer ces autorisations lorsqu’elles ne sont plus nécessaires.
**Pour créer l'utilisateur**
1. Dans la [console IAM](https://console.aws.amazon.com/iam/), choisissez **Utilisateurs** dans le volet de navigation, puis **Ajoutez un utilisateur**.
1. Ajoutez un utilisateur nommé **EC2Register**.
1. Choisissez **Suivant**.
1. Sur la page **Définir les autorisations**, choisissez **Joindre directement les politiques**.
1. Entrez **OpsWorks** dans le champ Filtre de **politique d'autorisations** pour afficher les OpsWorks politiques, sélectionnez l'une des politiques suivantes, puis choisissez **Suivant : révision**. Cette stratégie accorde à votre utilisateur les autorisations requises pour exécuter `register`.
+ Choisissez `AWSOpsWorksRegisterCLI_EC2` d'autoriser l'utilisateur à enregistrer des EC2 instances utilisant des profils d'instance.
+ Choisissez `AWSOpsWorksRegisterCLI_OnPremises` pour accorder à l'utilisateur les autorisations pour enregistrer des instances sur site.
1. Choisissez **Suivant**.
1. Sur la page **Review (Vérification)**, choisissez **Create user (Créer un utilisateur)**.
1. Créez maintenant des clés d'accès pour votre utilisateur. Dans le volet de navigation, choisissez **Utilisateurs**, puis choisissez l'utilisateur pour lequel vous souhaitez créer des clés d'accès.
1. Choisissez l'onglet **Informations d'identification de sécurité**, puis choisissez **Créer une clé d'accès**.
1. Choisissez les **meilleures pratiques et alternatives relatives aux clés d'accès** qui correspondent le mieux à votre tâche.
1. Choisissez **Suivant**.
1. (Facultatif) entrez un tag pour identifier les clés d'accès.
1. Choisissez **Suivant**.
1. Choisissez **Télécharger le fichier .csv**, enregistrez le fichier d'informations d'identification à un emplacement approprié sur votre système, puis cliquez sur **OK**.
Vous devez fournir les informations d'identification de l'utilisateur IAM à `register`. Cette procédure pas à pas gère la tâche en installant les informations d'identification du EC2 registre dans le `credentials` fichier de votre poste de travail. Pour plus d'informations sur les autres méthodes de gestion des informations d'identification pour le AWS CLI, consultez la section [Fichiers de configuration et d'identification](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-config-files).
**Pour installer les informations d'identification de l'utilisateur**
1. Créez ou ouvrez le fichier `credentials` de votre station de travail. Le fichier se trouve dans `~/.aws/credentials` (Linux, Unix et OS X) ou `C:\Users\User_Name\.aws\credentials` (systèmes Windows).
1. Ajoutez un profil pour l'utilisateur EC2 Register au `credentials` fichier, en utilisant le format suivant.
```
[ec2register]
aws_access_key_id = access_key_id
aws_secret_access_key = secret_access_key
```
Remplacez *access\$1key\$1id* et *secret\$1access\$1key* par les clés de EC2 registre que vous avez téléchargées précédemment.
## Étape 3 : enregistrer l'instance auprès de EC2 Register Stack
Vous êtes maintenant prêt à enregistrer l'instance.
**Pour enregistrer l'instance**
1. Dans OpsWorks Stacks, revenez à la pile EC2 Register, choisissez **Instances** dans le volet de navigation, puis choisissez **Register une instance**.
1. Sélectionnez **EC2 Instances**, choisissez **Next : Select Instances**, puis sélectionnez votre instance dans la liste.
1. Choisissez **Next : Install AWS CLI**, et **Next : Register Instances**. OpsWorks Stacks utilise automatiquement les informations disponibles, telles que l'ID de pile et l'ID d'instance pour créer un modèle de `register` commande, qui est affiché sur la page **Enregistrer les instances**. Pour cet exemple, comme `register` devra se connecter à l'instance avec une clé SSH et spécifier explicitement le fichier de clé, définissez **J'utilise les clés SSH pour me connecter à mes instances.** sur **Oui**. Le modèle de commande doit se présenter comme suit :
```
aws opsworks register --infrastructure-class ec2 --region region endpoint ID
--stack-id 247be7ea-3551-4177-9524-1ff804f453e3 --ssh-username [username]
--ssh-private-key [key-file] i-f1245d10
```
**Note**
Vous devez définir la région sur la région du point de terminaison du service OpsWorks Stacks, et non sur la région de la pile, si la pile se trouve dans une région classique associée au point de terminaison `us-east-1` régional. OpsWorks Stacks détermine la région de la pile à partir de l'ID de la pile.
1. Le modèle de commande contient plusieurs valeurs d'argument spécifiques à l'utilisateur : elles sont indiquées par des crochets et doivent être remplacées par les valeurs appropriées. Copiez le modèle de commande dans un éditeur de texte et modifiez-le comme suit.
**Important**
L'utilisateur IAM créé au cours du processus d'enregistrement est requis pendant toute la durée de vie d'une instance enregistrée. La suppression de l'utilisateur empêche l'agent OpsWorks Stacks de communiquer avec le service. Pour éviter les problèmes liés à la gestion des instances enregistrées en cas de suppression accidentelle de l'utilisateur, ajoutez le `--use-instance-profile` paramètre à votre `register` commande pour utiliser le profil d'instance intégré de l'instance à la place. L'ajout du `--use-instance-profile` paramètre permet également d'éviter que des erreurs ne se produisent lorsque vous alternez les clés d'accès au AWS compte tous les 90 jours (une bonne pratique recommandée), car cela évite les incohérences entre les clés d'accès disponibles pour l' OpsWorks agent et l'utilisateur IAM requis.
+ Remplacez-le *key file* par le chemin complet du fichier de clé privée de la paire de EC2 clés Amazon que vous avez enregistrée lors de la création de l'instance.
Vous pouvez utiliser un chemin relatif, si vous préférez.
+ Remplacez *username* par le nom d'utilisateur de l'instance.
Pour cet exemple, le nom d'utilisateur est `ubuntu` pour une instance Ubuntu ou `ec2-user` pour une instance Red Hat Enterprise Linux (RHEL) ou Amazon Linux.
+ Ajouter`--use-instance-profile`, qui s'exécute `register` avec le profil d'instance pour éviter les erreurs lors de la rotation des touches ou si l'utilisateur IAM principal est supprimé accidentellement.
Votre commande doit se présenter comme suit :
```
aws opsworks register --use-instance-profile --infrastructure-class ec2 \
--region us-west-2 --stack-id 247be7ea-3551-4177-9524-1ff804f453e3 --ssh-username ubuntu \
--ssh-private-key "./keys/mykeys.pem" i-f1245d10
```
1. Ouvrez une fenêtre terminal sur votre station de travail, collez la commande `register` à partir de votre éditeur et exécutez la commande.
L'enregistrement prend généralement environ cinq minutes. Une fois l'opération terminée, revenez à la console OpsWorks Stacks et choisissez **OK**. Ensuite, choisissez **Instances** dans le panneau de navigation. Votre instance doit être répertoriée sous **Instances non attribuées**. Vous pouvez ensuite [assigner l'instance à une couche](registered-instances-assign.md) ou la laisser où elle est, en fonction de la façon dont vous avez l'intention de gérer l'instance.
1. Lorsque vous avez terminé, [arrêtez l'instance](workinginstances-starting.md#workinginstances-starting-stop), puis [supprimez-la](workinginstances-starting.md#workinginstances-starting-stop) à l'aide de la console ou des commandes OpsWorks Stacks. Cela met fin à l' EC2instance Amazon, de sorte que vous n'avez pas à payer de frais supplémentaires.
# Enregistrement d'Amazon EC2 et d'instances sur site
**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. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
**Note**
Cette fonctionnalité est prise en charge uniquement pour les piles Linux.
Cette section explique comment enregistrer une instance Amazon EC2 ou sur site auprès d'une OpsWorks pile Stacks.
**Topics**
+ [
# Préparation de l'instance
](registered-instances-register-registering-prepare.md)
+ [
# Installation et configuration de l’ AWS CLI
](registered-instances-register-registering-cli.md)
+ [
# Enregistrement de l'instance
](registered-instances-register-registering-register.md)
+ [
# Utilisation de la commande `register`
](registered-instances-register-registering-command.md)
+ [
# Exemples de commande register
](registered-instances-register-registering-examples.md)
+ [
# Stratégies d'enregistrement d'instance
](registered-instances-register-registering-template.md)
# Préparation de l'instance
**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. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
**Note**
Cette fonctionnalité est prise en charge uniquement pour les piles Linux.
Avant d'enregistrer une instance, vous devez vous assurer qu'elle est compatible avec OpsWorks Stacks. Les détails varient selon que vous enregistrez une EC2 instance sur site ou Amazon.
## Instances locales
Une instance sur site doit satisfaire aux critères suivants :
+ L'instance doit exécuter l'un des [systèmes d'exploitation Linux pris en charge](workinginstances-os-linux.md). Bien qu'il soit possible de créer ou d'enregistrer des instances avec d'autres systèmes d'exploitation (tels que CentOS 6). *x*) qui ont été créés à partir de données personnalisées ou générées par la communauté AMIs, ils ne sont pas officiellement pris en charge.
Vous devez installer le package `libyaml` sur l'instance. Pour les instances Ubuntu, le package se nomme `libyaml-0-2`. Pour les instances CentOS et Red Hat Enterprise Linux, le package se nomme `libyaml`.
+ L'instance doit avoir un type d'instance pris en charge (parfois appelé taille d'instance). Les types d'instance pris en charge peuvent varier selon le système d'exploitation et si votre pile se trouve dans un VPC. Pour obtenir la liste des types d'instances pris en charge, consultez les valeurs de la liste déroulante **Taille** affichées dans la console OpsWorks Stacks lorsque vous essayez de créer une nouvelle instance dans votre pile cible. Si un type d'instance apparaît en grisé et ne peut pas être créé dans votre pile cible, vous ne pouvez pas enregistrer d'instance de ce type.
+ L'instance doit disposer d'un accès Internet lui permettant de communiquer avec le point de terminaison du service OpsWorks Stacks,`opsworks.us-east-1.amazonaws.com (HTTPS)`. L'instance doit également prendre en charge les connexions sortantes vers les ressources AWS telles qu'Amazon S3.
+ Si vous avez l'intention d'enregistrer l'instance à partir d'une station de travail distincte, l'instance enregistrée doit prendre en charge la connexion SSH à partir de la station de travail.
La connexion SSH n'est pas obligatoire si vous exécutez la commande d'enregistrement à partir de l'instance.
+ La clé AWS d'accès est utilisée pour l'authentification entre l' OpsWorks agent et le service OpsWorks Stacks. Si vous alternez les clés d'accès comme recommandé tous les 90 jours, mettez à jour l' OpsWorks agent manuellement pour qu'il utilise la nouvelle clé. Sur un ordinateur ou une instance sur site, modifiez le `/etc/aws/opsworks/instance-agent.yml` fichier avec la nouvelle clé d'accès et la nouvelle clé secrète. La commande suivante illustre la clé d'accès et la clé secrète dans ce fichier. Un agent utilisant d'anciennes clés peut entraîner des erreurs.
```
cat /etc/aws/opsworks/instance-agent.yml | egrep "access_key|secret_key"
:access_key_id: AKIAIOSFODNN7EXAMPLE
:secret_access_key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
```
## EC2Instances Amazon
Une EC2 instance Amazon doit répondre aux critères suivants :
+ L'AMI doit être basée sur l'un des systèmes d'exploitation Linux pris en charge. Pour obtenir la liste actuelle, consultez [OpsWorks Systèmes d'exploitation Stacks](workinginstances-os.md).
Pour de plus amples informations, veuillez consulter [Utilisation de Custom AMIs](workinginstances-custom-ami.md).
Si l'instance est basée sur une AMI personnalisée qui dérive d'une AMI standard supportée, ou si l'instance contient une installation minimale, vous devez installer le package `libyaml` sur l'instance. Pour les instances Ubuntu, le package se nomme `libyaml-0-2`. Pour les instances Amazon Linux et Red Hat Enterprise Linux, le package est nommé`libyaml`.
+ L'instance doit avoir un type d'instance pris en charge (parfois appelé taille d'instance). Les types d'instance pris en charge peuvent varier selon le système d'exploitation et si votre pile se trouve dans un VPC. Pour obtenir la liste des types d'instances pris en charge, consultez les valeurs de la liste déroulante **Taille** affichées dans la console OpsWorks Stacks lorsque vous essayez de créer une nouvelle instance dans votre pile cible. Si un type d'instance apparaît en grisé et ne peut pas être créé dans votre pile cible, vous ne pouvez pas enregistrer d'instance de ce type, non plus.
+ L’instance doit être dans l’état `running`.
+ L'instance ne doit pas faire partie d'un [groupe Auto scaling](https://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/WhatIsAutoScaling.html).
Pour plus d'informations, consultez [Detach EC2 Instances From Your Auto Scaling Group](https://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/detach-instance-asg.html).
+ L'instance peut faire partie d'un [VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Introduction.html), mais elle doit se trouver dans le même VPC que la pile et le VPC doit être configuré pour fonctionner correctement avec Stacks. OpsWorks
+ [Les instances Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/how-spot-instances-work.html) ne sont pas prises en charge, car elles ne fonctionnent pas avec la [réparation automatique](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html).
Lorsque vous enregistrez une EC2 instance Amazon, OpsWorks Stacks ne modifie pas les [groupes de sécurité](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) ou les règles de l'instance. Assurez-vous que les règles du groupe de sécurité de l'instance répondent aux exigences OpsWorks Stacks suivantes.
**Règles d'entrée**
Les règles d'entrée doivent autoriser les actions suivantes :
+ Connexion SSH.
+ Trafic à partir des couches appropriées.
Par exemple, un serveur de base de données autorise généralement le trafic entrant à partir des couches serveur d'applications de la pile.
+ Trafic vers les ports appropriés.
Par exemple, les instances serveur d'applications autorisent généralement tout le trafic entrant sur les ports 80 (HTTP) et 443 (HTTPS).
**Règles de sortie**
Les règles d'entrée doivent autoriser les actions suivantes :
+ Trafic vers le service OpsWorks Stacks depuis les applications exécutées sur l'instance.
+ Trafic permettant d'accéder aux ressources AWS telles qu'Amazon S3 à partir d'applications utilisant l'API AWS.
Une approche courante consiste à ne pas spécifier de règles de sortie, ce qui n'impose aucune restriction sur le trafic sortant.
# Installation et configuration de l’ AWS CLI
**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. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
Avant d'enregistrer votre première instance, vous devez exécuter la version 1.16.180 AWS CLI ou une version plus récente sur l'ordinateur à partir duquel vous l'exécutez. `register` Les détails de l'installation dépendent du système d'exploitation de votre station de travail. Pour plus d'informations sur l'installation de AWS CLI, consultez les sections [Installation de l'interface de ligne de commande AWS](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) et [Configuration de l'interface de ligne de commande AWS](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html). Pour vérifier la version de l’ AWS CLI que vous exécutez, entrez `aws --version` dans une session shell.
**Note**
Bien qu'[AWS Tools for PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-welcome.html) inclue l'[https://docs.aws.amazon.com/powershell/latest/reference/items/Register-OPSInstance.html](https://docs.aws.amazon.com/powershell/latest/reference/items/Register-OPSInstance.html)applet de commande, qui appelle l'action d'`register`API, nous vous recommandons d'utiliser plutôt le AWS CLI pour exécuter la `register` commande.
Vous devez exécuter `register` avec les autorisations appropriées. Vous pouvez obtenir des autorisations en utilisant un rôle IAM, ou de manière moins optimale, en installant les informations d'identification utilisateur avec les autorisations appropriées sur le poste de travail ou l'instance à enregistrer. Vous pouvez ensuite exécuter `register` avec ces informations d'identification, comme décrit ci-après. Spécifiez les autorisations en associant une politique IAM à l'utilisateur ou au rôle. En `register` effet, vous utilisez les `AWSOpsWorksRegisterCLI_OnPremises` politiques `AWSOpsWorksRegisterCLI_EC2` ou, qui accordent des autorisations pour enregistrer des instances Amazon EC2 ou sur site, respectivement.
**Note**
Si vous exécutez `register` sur une EC2 instance Amazon, vous devez idéalement utiliser un rôle IAM pour fournir des informations d'identification. Pour plus d'informations sur la façon d'associer un rôle IAM à une instance existante, consultez [Attacher un rôle IAM à une instance ou Remplacer un](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role) [rôle IAM dans](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#replace-iam-role) le guide de l'utilisateur *Amazon EC2 *.
Pour voir des exemples d’extraits de stratégies `AWSOpsWorksRegisterCLI_EC2` et `AWSOpsWorksRegisterCLI_OnPremises`, consultez [Stratégies d'enregistrement d'instance](registered-instances-register-registering-template.md). Pour plus d'informations sur la création et la gestion des informations d'identification AWS, consultez [Informations d'identification de sécurité AWS](https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html).
**Topics**
+ [
## Utilisation d'un rôle IAM
](#registered-instances-register-registering-cli-role)
+ [
## Utilisation des informations d'identification installées
](#registered-instances-register-registering-cli-creds)
## Utilisation d'un rôle IAM
Si vous exécutez la commande depuis l' EC2 instance Amazon que vous souhaitez enregistrer, la stratégie préférée pour fournir des informations d'identification `register` consiste à utiliser un rôle IAM associé à la `AWSOpsWorksRegisterCLI_EC2` politique ou à des autorisations équivalentes. Cette approche vous permet d'éviter l'installation de vos informations d'identification sur l'instance. Pour ce faire, vous pouvez utiliser la commande **Attacher/Remplacer le rôle IAM** dans la EC2 console, comme illustré dans l'image suivante.
![\[AWS EC2 console showing Instance Settings menu with Attach/Replace IAM Role option highlighted.\]](http://docs.aws.amazon.com/fr_fr/opsworks/latest/userguide/images/instance_register_attachrole.png)
Pour plus d'informations sur la façon d'associer un rôle IAM à une instance existante, consultez [Attacher un rôle IAM à une instance ou Remplacer un](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role) [rôle IAM dans](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#replace-iam-role) le guide de l'utilisateur *Amazon EC2 *. Pour les instances lancées avec un profil d'instance (recommandé), ajoutez le `--use-instance-profile` commutateur à votre commande `register` pour fournir vos informations d'identification, ne pas utiliser le paramètre `--profile`.
Si l'instance est en cours d'exécution et a un rôle, vous pouvez accorder les autorisations requises en associant la stratégie `AWSOpsWorksRegisterCLI_EC2` au rôle. Le rôle fournit à l'instance un ensemble d'informations d'identification par défaut. Tant que vous n'avez pas installé d'informations d'identification sur l'instance, `register` assume automatiquement le rôle et s'exécute avec ses autorisations.
**Important**
Nous vous recommandons de ne pas installer d'informations d'identification sur l'instance. En plus de créer un risque de sécurité, le rôle de l'instance se situe à la fin de la chaîne de fournisseurs par défaut qu'elle AWS CLI utilise pour localiser les informations d'identification par défaut. Les informations d'identification installées peuvent avoir priorité sur le rôle et, par conséquent, `register` pourrait ne pas avoir les autorisations requises. Pour plus d'informations, consultez [Démarrer avec le AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#config-settings-and-precedence).
Si une instance en cours d'exécution n'a pas de rôle, vous devez installer les informations d'identification avec les autorisations requises sur l'instance, comme décrit dans [Utilisation des informations d'identification installées](#registered-instances-register-registering-cli-creds). Il est recommandé, plus facile et plus fiable d'utiliser les instances lancées avec un profil d'instance.
## Utilisation des informations d'identification installées
Il existe plusieurs manières d'installer les informations d'identification utilisateur sur un système et de les fournir à une AWS CLI commande. Ce qui suit décrit une approche qui n'est plus recommandée, mais qui peut être utilisée si vous enregistrez des EC2 instances lancées sans profil d'instance. Vous pouvez aussi utiliser les informations d'identification d'un utilisateur existant, aussi longtemps que les stratégies attachées accordent les autorisations requises. Pour plus d'informations, y compris la description des autres façons d'installer les informations d'identification, consultez [Fichiers de configuration et d'informations d'identification](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-config-files).
**Pour utiliser les informations d'identification installées**
1. [Créez un utilisateur IAM](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-config-files) et enregistrez l'ID de la clé d'accès et la clé d'accès secrète dans un emplacement sécurisé.
**Avertissement**
Les utilisateurs IAM disposent d’informations d’identification à long terme, ce qui présente un risque de sécurité. Pour atténuer ce risque, nous vous recommandons de ne fournir à ces utilisateurs que les autorisations dont ils ont besoin pour effectuer la tâche et de supprimer ces autorisations lorsqu’elles ne sont plus nécessaires.
1. [Attachez la AWSOpsWorksRegisterCLI\$1OnPremises politique](https://docs.aws.amazon.com/IAM/latest/UserGuide/ManagingPolicies.html) à l'utilisateur. Si vous préférez, vous pouvez attacher une stratégie qui accorde des autorisations de plus grande ampleur, à partir du moment où elle comporte les autorisations `AWSOpsWorksRegisterCLI_OnPremises`.
1. Créez un profil pour l'utilisateur dans le fichier `credentials` du système. Le fichier se trouve dans `~/.aws/credentials` (Linux, Unix et OS X) ou `C:\Users\User_Name\.aws\credentials` (systèmes Windows). Le fichier contient un ou plusieurs profils au format suivant, chacun contenant l'ID de clé d'accès et la clé d'accès secrète d'un utilisateur.
```
[profile_name]
aws_access_key_id = access_key_id
aws_secret_access_key = secret_access_key
```
Remplacez les informations d'identification IAM que vous avez enregistrées précédemment par les *secret\$1access\$1key* valeurs *access\$1key\$1id* et. Vous pouvez spécifier le nom de votre choix pour un nom de profil, avec deux limites : le nom doit être unique et le profil par défaut doit se nommer `default`. Vous pouvez aussi utiliser un profil existant, aussi longtemps qu'il possède les permissions requises.
1. Utilisez le paramètre `register` de la commande `--profile` pour spécifier le nom du profil. La commande `register` exécute les autorisations accordées aux informations d'identification associées.
Vous pouvez également ignorer `--profile`. Dans ce cas, `register` s'exécute avec les informations d'identification par défaut. Sachez que comme il ne s'agit pas nécessairement des informations d'identification du profil par défaut, vous devez vous assurer que les informations d'identification par défaut disposent des autorisations requises. Pour plus d'informations sur la façon dont les AWS CLI informations d'identification par défaut sont déterminées, consultez [Configuration de l'interface de ligne de commande AWS](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html).
# Enregistrement de l'instance
**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. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
**Note**
Cette fonctionnalité est prise en charge uniquement pour les piles Linux.
Vous enregistrez une instance en exécutant la commande AWS CLI `register` à partir de votre station de travail ou de l'instance. La façon la plus simple de gérer l'opération consiste à utiliser l'Assistant d'enregistrement de la [console OpsWorks Stacks](https://console.aws.amazon.com/opsworks/), ce qui simplifie le processus de construction de la chaîne de commande. Une fois que vous êtes familiarisé avec la procédure d'enregistrement, vous pouvez ignorer l'Assistant si vous le souhaitez et exécuter la commande `register`.
Ce qui suit décrit comment utiliser l'Assistant d'enregistrement pour enregistrer une instance auprès d'une pile existante.
**Note**
Pour enregistrer une instance auprès d'une nouvelle pile, vous pouvez le faire en choisissant **Enregistrer les instances dans** le tableau de bord OpsWorks Stacks. Un Assistant, identique à celui des piles existantes, à l'exception d'une page supplémentaire qui configure la nouvelle pile, démarre alors.
**Pour utiliser l'Assistant d'enregistrement pour enregistrer une instance**
1. Dans la [console OpsWorks Stacks](https://console.aws.amazon.com/opsworks/), créez une pile ou ouvrez une pile existante.
1. Dans le volet de navigation, sélectionnez **Instances**, puis choisissez **register an instance (enregistrer une instance)**.
1. Sur la page **Choisissez un type d'instance**, indiquez si vous souhaitez enregistrer une instance Amazon EC2 ou une instance sur site :
+ Si vous enregistrez une EC2 instance Amazon, choisissez **Next : Select Instances**.
+ Si vous enregistrez une instance sur site, choisissez **Next : Install AWS CLI**, puis passez à l'étape 5.
1. Si vous enregistrez une EC2 instance Amazon, ouvrez la page **Select Instances** pour sélectionner l'instance à enregistrer. OpsWorks Stacks collecte les informations nécessaires à la création de la commande. Lorsque vous avez terminé, choisissez **Next:Install AWS CLI (Suivant : Installer l'interface de ligne de commande)**.
1. L'instance sur laquelle vous comptez exécuter `register` doit exécuter la version 1.16.180 AWS CLI ou une version ultérieure. Pour installer ou mettre à jour l’ AWS CLI, la page de l'Assistant d'enregistrement fournit des liens vers les instructions d'installation et de configuration. Après avoir vérifié l'installation de l’ AWS CLI , spécifiez si vous exécutez la commande à partir de l'instance à enregistrer ou d'une station de travail distincte, puis choisissez **Next: Register Instances (Suivant : Enregistrer des instances)**.
1. La page **Register Instances (Enregistrer des instances)** affiche un modèle pour une chaîne de commande `register` qui intègre vos options choisies. Par exemple, si vous enregistrez une EC2 instance Amazon à partir d'un poste de travail distinct, le modèle par défaut ressemble au suivant.
```
aws opsworks register --infrastructure-class ec2 --region us-west-2
--stack-id 247be7ea-3551-4177-9524-1ff804f453e3 --ssh-username [username] i-f1245d10
```
**Important**
L'utilisateur IAM créé au cours du processus d'enregistrement est requis pendant toute la durée de vie d'une instance enregistrée. La suppression de l'utilisateur empêche l'agent OpsWorks Stacks de communiquer avec le service. Pour éviter les problèmes liés à la gestion des instances enregistrées en cas de suppression accidentelle de l'utilisateur, ajoutez le `--use-instance-profile` paramètre à votre `register` commande pour utiliser le profil d'instance intégré de l'instance à la place. L'ajout du `--use-instance-profile` paramètre permet également d'éviter que des erreurs ne se produisent lorsque vous alternez les clés d'accès au AWS compte tous les 90 jours (une bonne pratique recommandée), car cela évite les incohérences entre les clés d'accès disponibles pour l' OpsWorks agent et l'utilisateur IAM requis.
Si vous définissez **I use SSH keys** sur **Oui**, OpsWorks Stacks ajoute l'`--ssh-private-key`argument à la chaîne, que vous pouvez utiliser pour spécifier un fichier de clé SSH privé.
**Note**
Si vous souhaitez vous `register` connecter avec un mot de passe, réglez **I use SSH keys** sur **Non**. Lorsque vous exécutez`register`, le mot de passe vous est demandé.
Copiez cette chaîne dans un éditeur de texte et modifiez-la si nécessaire. Remarques :
+ Le texte entre crochets représente les informations que vous devez fournir, telles que l'emplacement de votre fichier de clé SSH.
+ Le modèle présume que vous exécutez `register` avec les informations d'identification AWS par défaut. Dans le cas contraire, ajoutez un argument `--profile` à la chaîne de commande, puis spécifiez le nom du profil d'informations d'identification que vous souhaitez utiliser.
Pour les autres scénarios, vous devrez peut-être modifier la commande ultérieurement. Pour obtenir une explication des arguments `register` disponibles et des autres moyens de construire la chaîne de commande, consultez [Utilisation de la commande `register`](registered-instances-register-registering-command.md). Vous pouvez aussi afficher la documentation de la commande en exécutant `aws opsworks help register` à partir de la ligne de commande. Pour obtenir des exemples de chaînes de commande, consultez [Exemples de commande register](registered-instances-register-registering-examples.md).
1. Une fois que vous avez terminé de modifier la chaîne de commande, ouvrez une fenêtre de terminal sur votre station de travail, ou utilisez SSH pour vous connecter à l'instance et exécutez la commande. L'opération complète nécessite généralement cinq minutes environ, pendant lesquelles l'instance se trouve dans l'état **Registering (Enregistrement en cours)**.
1. Une fois l'opération terminée, choisissez **Done (Terminé)**. L'instance est à présent dans l'état **Registered (Enregistré)** et apparaît comme instance non assignée sur la page **Instances** de la pile.
La commande `register` exécute les opérations suivantes :
1. Si `register` s'exécute sur une station de travail, la commande utilise d'abord SSH pour se connecter à l'instance à enregistrer.
Le reste du processus se déroule sur l'instance et demeure le même, quel que soit l'endroit où vous avez exécuté la commande.
1. Télécharge le package de l'agent OpsWorks Stacks depuis Amazon S3.
1. Décompresse et installe l'agent et ses dépendances, telles que le [Kit de développement logiciel (SDK) AWS pour Ruby](https://aws.amazon.com/documentation/sdk-for-ruby/).
1. Crée les éléments suivants :
+ Un utilisateur IAM qui démarre l'agent avec le service OpsWorks Stacks pour garantir une communication sécurisée.
Les autorisations de l'utilisateur ne permettent que l'action `opsworks:RegisterInstance` et expirent après 15 minutes.
+ Un groupe IAM pour la pile, qui contient les utilisateurs des instances enregistrées.
1. Crée une paire de clés RSA et envoie la clé publique à OpsWorks Stacks.
Cette paire de clés est utilisée pour chiffrer les communications entre l'agent et OpsWorks Stacks.
1. Enregistre l'instance auprès de OpsWorks Stacks. La pile exécute ensuite un ensemble de recettes de configuration initiale pour configurer l'instance, ce qui inclut les actions suivantes :
+ Remplacement du fichier hôtes de l'instance.
En enregistrant l'instance, vous avez transféré la gestion des utilisateurs à OpsWorks Stacks, qui doit disposer de son propre fichier d'hôtes pour contrôler les autorisations de connexion SSH.
+ Pour les EC2 instances Amazon, la configuration initiale inclut également l'enregistrement de tous les volumes Amazon EBS ou adresses IP Elastic attachés auprès de la pile.
Vous devez vous assurer que les volumes Amazon EBS ne sont pas montés sur des points de montage réservés, y compris `/var/www` les points de montage réservés par les couches de l'instance. Pour plus d'informations sur la gestion des ressources d'une pile, consultez [Gestion des ressources](resources.md). Pour plus d'informations sur les points de montage d'une couche, consultez [OpsWorks Référence de la couche Stacks](layers.md).
Pour obtenir la description complète des modifications de la configuration initiale, consultez [Modifications de la configuration d'installation initiale](registered-instances-lifecycle.md#registered-instances-lifecycle-setup-config).
**Note**
La configuration initiale ne met pas à jour le système d'exploitation d'une instance enregistrée ; vous devez gérer cette tâche vous-même. Pour de plus amples informations, veuillez consulter [Gestion des mises à jour de sécurité](workingsecurity-updates.md).
# Utilisation de la commande `register`
**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. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
**Note**
Cette fonctionnalité est prise en charge uniquement pour les piles Linux.
Pour enregistrer une instance, assurez-vous que vous exécutez au moins la version 1.16.180 de AWS CLI. Ce qui suit montre la syntaxe générale de la commande `register`.
```
aws opsworks register \
[--profile profile_name] \
[--region region_name] \
--infrastructure-class instance_type \
--stack-id stack ID \
[--local] | [--ssh-private-key key_file --ssh-username username] | [--override-ssh command_string] \
[--override-hostname hostname] \
[--debug] \
[--override-public-ip public IP] \
[--override-private-ip private IP] \
..[--use-instance-profile] \
[ [IP address] | [hostname] | [instance ID]
```
Les arguments suivants sont communs à toutes les AWS CLI commandes.
**`--profile`**
(Facultatif) Nom de profil des informations d'identification. Si vous omettez cet argument, la commande s'exécute avec vos informations d'identification par défaut. Pour plus d'informations sur la façon dont les AWS CLI informations d'identification par défaut sont déterminées, consultez [Configuration de l'interface de ligne de commande AWS](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html).
**`--region`**
(Facultatif) Région du point de terminaison du service OpsWorks Stacks. Ne définissez pas `--region` la région de la pile. OpsWorks Stacks détermine automatiquement la région de la pile à partir de l'ID de la pile.
Si votre région par défaut est déjà définie, vous pouvez omettre cet argument. Pour plus d'informations sur la manière de spécifier une région par défaut, consultez [Configuration de l'interface de ligne de commande AWS](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html).
Utilisez les arguments suivants pour Amazon EC2 et les instances sur site.
**`--infrastructure-class`**
(Obligatoire) Ce paramètre doit être défini sur `ec2` ou `on-premises` pour indiquer si vous enregistrez une instance Amazon EC2 ou sur site, respectivement.
**`--stack-id`**
(Obligatoire) ID de la pile auprès de laquelle l'instance doit être enregistrée.
Pour trouver un ID de pile, sur la page **Pile**, choisissez **Paramètres**. L'ID de pile est étiqueté **OpsWorks ID**. Il s'agit d'un GUID qui ressemble à quelque chose comme`ad21bce6-7623-47f1-bf9d-af2affad8907`.
**Arguments de connexion SSH**
Utilisez les arguments suivants pour spécifier comment `register` doit se connecter à l'instance.
**`--local`**
(Facultatif) Utilisez cet argument pour enregistrer l'instance sur laquelle vous exécutez la commande.
Dans ce cas, `register` n'a pas besoin de se connecter à l'instance.
**`--ssh-private-key` et `--ssh-username`**
(Facultatif) Utilisez ces arguments si vous enregistrez l'instance à partir d'une station de travail distincte et que vous voulez spécifier explicitement le nom d'utilisateur ou le fichier de clé privée.
+ `--ssh-username`— Utilisez cet argument pour spécifier un nom d'utilisateur SSH.
Si vous omettez `--ssh-username`, `ssh` utilise le nom d'utilisateur par défaut.
+ `--ssh-private-key`— Utilisez cet argument pour spécifier explicitement un fichier de clé privée.
Si vous omettez `--ssh-private-key`, `ssh` tente de se connecter à l'aide des techniques d'authentification ne nécessitant pas un mot de passe, y compris l'utilisation de la clé privée par défaut. Si aucune de ces techniques n'est prise en charge, `ssh` interroge votre mot de passe. Pour plus d'informations sur la façon dont `ssh` gère l'authentification, consultez [The Secure Shell (SSH) Authentication Protocol](https://www.ietf.org/rfc/rfc4252.txt).
**`--override-ssh`**
(Facultatif) Utilisez cet argument si vous enregistrez l'instance à partir d'une station de travail distincte et que vous souhaitez spécifier une chaîne de commande [http://linux.about.com/od/commands/l/blcmdl1_ssh.htm](http://linux.about.com/od/commands/l/blcmdl1_ssh.htm) personnalisée. La commande `register` utilise cette chaîne de commande pour se connecter à l'instance enregistrée.
Pour plus d'informations sur `ssh`, consultez [SSH](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/slogin.1).
**`--override-hostname`**
(Facultatif) Spécifie un nom d'hôte pour l'instance, qui est utilisé uniquement par OpsWorks Stacks. La valeur par défaut est le nom d'hôte de l'instance.
**`--debug`**
(Facultatif) Fournit les informations de débogage en cas d'échec du processus d'enregistrement. Pour plus d’informations sur le dépannage, consultez [Dépannage de l'enregistrement des instances](common-issues.md#common-issues-instance-registration).
**`--use-instance-profile`**
(Facultatif, mais fortement recommandé pour les EC2 instances Amazon) Permet à la `register` commande d'utiliser un profil d'instance attaché, au lieu de créer un utilisateur IAM. L'ajout de ce paramètre permet d'éviter que des erreurs ne se produisent si vous essayez de gérer une instance enregistrée lorsque l'utilisateur IAM a été supprimé accidentellement.
L'utilisateur IAM créé au cours du processus d'enregistrement est requis pendant toute la durée de vie d'une instance enregistrée. La suppression de l'utilisateur empêche l'agent OpsWorks Stacks de communiquer avec le service. Pour éviter les problèmes liés à la gestion des instances enregistrées en cas de suppression accidentelle de l'utilisateur, ajoutez le `--use-instance-profile` paramètre à votre `register` commande pour utiliser le profil d'instance intégré de l'instance à la place. L'ajout du `--use-instance-profile` paramètre empêche également les erreurs de se produire lorsque vous alternez les clés d'accès au AWS compte tous les 90 jours (une bonne pratique recommandée), car cela permet d'éviter les incohérences entre les clés d'accès disponibles pour l' OpsWorks agent et celles de l'utilisateur requis.
**Cible**
(Conditionnel) Si vous exécutez cette commande à partir d'une station de travail, la valeur finale de la chaîne de commande spécifie la cible d'enregistrement de l'une des façons suivantes.
+ Adresse IP publique de l'instance.
+ Nom d'hôte de l'instance.
+ Pour les EC2 instances Amazon, l'ID de l'instance.
OpsWorks Stacks utilise l'ID de l'instance pour obtenir la configuration de l'instance, y compris l'adresse IP publique de l'instance. Par défaut, OpsWorks Stacks utilise cette adresse pour créer la chaîne de `ssh` commande qu'il utilise pour se connecter à l'instance. Si vous avez besoin de vous connecter à une adresse IP privée, vous devez utiliser `--override-ssh` pour fournir une chaîne de commande personnalisée. Pour obtenir un exemple, consultez [Enregistrer une instance locale à partir d'une station de travail](registered-instances-register-registering-examples.md#registered-instances-register-registering-examples-workstation-onprem).
Si vous spécifiez un nom d'hôte, `ssh` dépend du serveur DNS pour résoudre le nom en une instance particulière. Si vous n'êtes pas certain que le nom d'hôte soit unique, utilisez `ssh` pour vérifier que le nom d'hôte se résout en l'instance correcte.
Si vous exécutez cette commande à partir de l'instance à enregistrer, omettez l'identifiant d'instance et utilisez à la place l'argument `--local`.
Les arguments suivants concernent uniquement les instances locales.
**`--override-public-ip`**
(Facultatif) OpsWorks Stacks affiche l'adresse spécifiée en tant qu'adresse IP publique de l'instance. Il ne change pas l'adresse IP publique de l'instance. Toutefois, si un utilisateur utilise la console pour se connecter à l'instance, par exemple en choisissant l'adresse sur la page **Instances**, OpsWorks Stacks utilise l'adresse spécifiée. OpsWorks Stacks détermine automatiquement la valeur par défaut de l'argument.
**`--override-private-ip`**
(Facultatif) OpsWorks Stacks affiche l'adresse spécifiée en tant qu'adresse IP privée de l'instance. Cela ne modifie pas l'adresse IP privée de l'instance. OpsWorks Stacks détermine automatiquement la valeur par défaut de l'argument.
# Exemples de commande register
**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. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
**Note**
Cette fonctionnalité est prise en charge uniquement pour les piles Linux.
Cette section contient des exemples de chaînes de commande `register`.
**Enregistrer une EC2 instance Amazon depuis un poste de travail**
L'exemple suivant enregistre une EC2 instance Amazon depuis un poste de travail. La chaîne de commande utilise les informations d'identification par défaut et identifie l'instance par son identifiant d' EC2 instance Amazon. Vous pouvez utiliser cet exemple pour les instances sur site en passant `ec2` à`on-premises`.
```
aws opsworks register \
--region us-west-2 \
--use-instance-profile \
--infrastructure-class ec2 \
--stack-id ad21bce6-7623-47f1-bf9d-af2affad8907 \
--ssh-user-name my-sshusername \
--ssh-private-key "./keys/mykeys.pem" \
i-2422b9c5
```
**Enregistrer une instance locale à partir d'une station de travail**
L'exemple suivant enregistre une instance locale à partir d'une station de travail distincte. La chaîne de commande utilise les informations d'identification par défaut et se connecte à l'instance avec la chaîne de commande `ssh` spécifiée. Si votre instance nécessite un mot de passe, `register` vous invite à le saisir. Vous pouvez utiliser l'exemple pour les EC2 instances Amazon en passant `on-premises` à`ec2`.
```
aws opsworks register \
--region us-west-2 \
--infrastructure-class on-premises \
--stack-id ad21bce6-7623-47f1-bf9d-af2affad8907 \
--override-ssh "ssh your-user@192.0.2.0"
```
Vous pouvez l'utiliser `--override-ssh` pour spécifier n'importe quelle chaîne de commande SSH personnalisée. OpsWorks Stacks utilise ensuite la chaîne spécifiée pour se connecter à l'instance au lieu de construire une chaîne de commande. Pour obtenir un autre exemple, consultez [Enregistrer une instance à l'aide d'une chaîne de commande SSH personnalisée](#registered-instances-register-registering-examples-custom-ssh).
**Enregistrer une instance à l'aide d'une chaîne de commande SSH personnalisée**
L'exemple suivant enregistre une instance locale à partir d'un poste de travail et utilise l'`--override-ssh`argument pour spécifier une commande SSH personnalisée qui `register` permet de se connecter à l'instance. Cet exemple utilise `sshpass` pour se connecter avec un nom d'utilisateur et un mot de passe, mais vous pouvez spécifier n'importe quelle chaîne de commande `ssh` valide.
```
aws opsworks register \
--region us-west-2 \
--infrastructure-class on-premises \
--stack-id 2f92ff9d-04f2-4728-879b-f4283b40783c \
--override-ssh "sshpass -p 'mypassword' ssh your-user@192.0.2.0"
```
**Enregistrer une instance en exécutant `register` à partir de l'instance**
L'exemple suivant montre comment enregistrer une EC2 instance Amazon en l'exécutant `register` à partir de l'instance elle-même. La chaîne de commande dépend des informations d'identification par défaut pour ses autorisations. Pour utiliser l'exemple pour une instance locale, passez `--infrastructure-class` à`on-premises`.
```
aws opsworks register \
--region us-west-2 \
--infrastructure-class ec2 \
--stack-id ad21bce6-7623-47f1-bf9d-af2affad8907 \
--local
```
**Enregistrer une instance avec une adresse IP privée**
Par défaut, `register` utilise l'adresse IP publique de l'instance pour se connecter à l'instance. Pour enregistrer une instance avec une adresse IP privée, telle qu'une instance du sous-réseau privé d'un VPC, vous devez utiliser `--override-ssh` pour spécifier une chaîne de commande `ssh` personnalisée.
```
aws opsworks register \
--region us-west-2 \
--infrastructure-class ec2 \
--stack-id 2f92ff9d-04f2-4728-879b-f4283b40783c \
--override-ssh "ssh -i mykey.pem ec2-user@10.183.201.93" \
i-2422b9c5
```
# Stratégies d'enregistrement d'instance
**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. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
Les `AWSOpsWorksRegisterCLI_OnPremises` politiques `AWSOpsWorksRegisterCLI_EC2` et fournissent les autorisations appropriées pour les instances d'enregistrement EC2 et sur site, respectivement. Vous ajoutez `AWSOpsWorksRegisterCLI_EC2` à votre utilisateur IAM pour enregistrer des EC2 instances, mais vous ajoutez `AWSOpsWorksRegisterCLI_OnPremises` à votre utilisateur pour enregistrer des instances sur site. Pour utiliser ces politiques, vous devez exécuter au moins la version 1.16.180 AWS CLI ou une version plus récente.
## La stratégie `AWSOpsWorksRegisterCLI_EC2`
Ajoutez `AWSOpsWorksRegisterCLI_EC2` à votre utilisateur pour enregistrer EC2 des instances. Vous devez utiliser ce profil si vous prévoyez d'enregistrer uniquement EC2 des instances. Lorsque vous utilisez cette politique, les autorisations sont fournies par le profil d' EC2instance de l'instance.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"opsworks:AssignInstance",
"opsworks:CreateLayer",
"opsworks:DeregisterInstance",
"opsworks:DescribeInstances",
"opsworks:DescribeStackProvisioningParameters",
"opsworks:DescribeStacks",
"opsworks:UnassignInstance"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances"
],
"Resource": [
"*"
]
}
]
}
```
------
## (Obsolète) La stratégie `AWSOpsWorksRegisterCLI_OnPremises`
Ajoutez `AWSOpsWorksRegisterCLI_OnPremises` à votre utilisateur pour enregistrer des instances sur site. Cette politique inclut les autorisations IAM, par exemple`AttachUserPolicy`, mais les ressources sur lesquelles ces autorisations s'appliquent sont limitées.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"opsworks:AssignInstance",
"opsworks:CreateLayer",
"opsworks:DeregisterInstance",
"opsworks:DescribeInstances",
"opsworks:DescribeStackProvisioningParameters",
"opsworks:DescribeStacks",
"opsworks:UnassignInstance"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"iam:CreateGroup",
"iam:AddUserToGroup"
],
"Resource": [
"arn:aws:iam::*:group/AWS/OpsWorks/OpsWorks-*"
]
},
{
"Effect": "Allow",
"Action": [
"iam:CreateUser",
"iam:CreateAccessKey"
],
"Resource": [
"arn:aws:iam::*:user/AWS/OpsWorks/OpsWorks-*"
]
},
{
"Effect": "Allow",
"Action": [
"iam:AttachUserPolicy"
],
"Resource": [
"arn:aws:iam::*:user/AWS/OpsWorks/OpsWorks-*"
],
"Condition": {
"ArnEquals":
{
"iam:PolicyARN": "arn:aws:iam::aws:policy/AWSOpsWorksInstanceRegistration"
}
}
}
]
}
```
------
## (Obsolète) La stratégie `AWSOpsWorksRegisterCLI`
**Important**
La stratégie `AWSOpsWorksRegisterCLI` est obsolète et ne peut pas être utilisée pour enregistrer de nouvelles instances. Elle est disponible uniquement pour la rétrocompatibilité sur des instances qui ont déjà été enregistrées. La `AWSOpsWorksRegisterCLI` politique inclut de nombreuses autorisations IAM`CreateUser`, notamment`PutUserPolicy`, et`AddUserToGroup`. Comme il s'agit d'autorisations de niveau administrateur, vous ne devez attribuer la stratégie `AWSOpsWorksRegisterCLI` qu’aux utilisateurs administratifs approuvés.
# Gestion des instances enregistrées
**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. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
**Note**
Cette fonctionnalité est prise en charge uniquement pour les piles Linux.
Lorsque vous enregistrez une instance, elle devient une instance OpsWorks Stacks, et vous pouvez la gérer de la même manière que les instances créées avec OpsWorks Stacks. Il existe deux différences principales :
+ Les instances enregistrées n'ont pas à être attribuées à une couche.
+ Vous pouvez annuler l'enregistrement d'une instance et la retourner sous votre contrôle direct.
Une fois que vous avez enregistré une instance, elle passe à l'état Enregistré. OpsWorks Stacks fournit les fonctionnalités de gestion suivantes à toutes les instances enregistrées :
+ **Health checks** — OpsWorks Stacks surveille l'agent pour évaluer si l'instance continue de fonctionner.
Si le bilan de santé d'une instance échoue, OpsWorks Stacks [répare automatiquement les EC2 instances Amazon enregistrées](workinginstances-autohealing.md) et change le statut des instances sur site enregistrées en. `connection lost`
+ **[CloudWatch surveillance](monitoring-cloudwatch.md)** : CloudWatch la surveillance est activée pour l'instance enregistrée.
Vous pouvez surveiller les métriques, telles que l'utilisation de l'UC et la mémoire disponible, et le cas échéant recevoir une notification si une métrique dépasse un seuil défini.
+ **Gestion des utilisateurs** — OpsWorks Stacks fournit un moyen simple de spécifier quels utilisateurs peuvent accéder à l'instance et quelles opérations ils sont autorisés à effectuer. Pour de plus amples informations, veuillez consulter [Gestion des autorisations utilisateur](opsworks-security-users.md).
+ **Exécution** de [recettes — Vous pouvez utiliser la commande Execute Recipes stack](workingstacks-commands.md) pour exécuter des recettes Chef sur l'instance.
+ **Mises à jour du système d'exploitation** : vous pouvez utiliser la [commande Update Dependencies stack](workingstacks-commands.md) pour mettre à jour le système d'exploitation de l'instance.
Pour tirer pleinement parti de la fonctionnalité de gestion des OpsWorks Stacks, vous pouvez attribuer l'instance à une couche. Pour de plus amples informations, veuillez consulter [Attribution d'une instance enregistrée à une couche](registered-instances-assign.md).
Il existe des différences entre la façon dont OpsWorks Stacks gère Amazon EC2 et les instances sur site.
EC2 Instances Amazon
+ Si vous arrêtez une EC2 instance Amazon enregistrée, OpsWorks Stacks met fin aux instances sauvegardées par le stockage d'instance et arrête les instances soutenues par Amazon EBS.
Comme l'instance est toujours enregistrée auprès de la pile et assignée à ses couches, vous pouvez la redémarrer si nécessaire. Vous devez annuler l'enregistrement d'une instance pour la supprimer d'une pile, [explicitement](registered-instances-deregister.md) ou [en supprimant l'instance](workinginstances-delete.md), ce qui annule l'enregistrement l'automatiquement.
+ Si vous redémarrez une EC2 instance Amazon enregistrée ou si l'instance échoue et est réparée automatiquement, le résultat est le même que l'arrêt et le redémarrage de l'instance à l'aide d'Amazon. EC2 Notez ces différences :
+ Instances basées sur le stockage d'instances : OpsWorks Stacks démarre une nouvelle instance avec la même AMI.
Notez que OpsWorks Stacks n'a connaissance d'aucune opération que vous avez effectuée sur l'instance avant son enregistrement, comme l'installation de packages logiciels. Si vous souhaitez que OpsWorks Stacks installe des packages ou effectue d'autres tâches de configuration au démarrage, vous devez fournir des recettes Chef personnalisées qui effectuent les tâches requises et les affecter aux événements de configuration des couches appropriées.
+ Instances basées sur Amazon EBS : OpsWorks Stacks démarre une nouvelle instance avec la même AMI et rattache le volume racine, ce qui rétablit la configuration précédente de l'instance.
+ Si vous annulez l'enregistrement d'une EC2 instance Amazon enregistrée, elle redevient une instance Amazon EC2 normale.
Instances locales
+ OpsWorks Stacks ne peut pas arrêter ou démarrer une instance locale enregistrée.
L'annulation de l'attribution d'une instance locale enregistrée déclenche un événement Shutdown. Cependant, cet événement exécute simplement les recettes Shutdown des couches affectées. Elles effectuent des tâches telles que l'arrêt des services, mais n'arrêtent pas l'instance.
+ OpsWorks Stacks ne peut pas réparer automatiquement une instance locale enregistrée en cas de défaillance, mais l'instance est marquée comme étant perdue.
+ Les instances sur site ne peuvent pas utiliser les services d'adresse IP Elastic Load Balancing, Amazon EBS ou Elastic.
# Attribution d'une instance enregistrée à une couche
**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. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
**Note**
Cette fonctionnalité est prise en charge uniquement pour les piles Linux.
Une fois que vous enregistrez une instance, vous pouvez l'affecter à une ou à plusieurs couches. L'avantage d'affecter une instance à une couche au lieu de la laisser non affectée est que vous pouvez attribuer des recettes personnalisées aux événements du [cycle de vie](workingcookbook-events.md) de la couche. OpsWorks Stacks les exécute ensuite automatiquement au moment opportun, après les recettes de la couche pour cet événement.
+ Vous pouvez assigner n'importe quelle instance enregistrée à une [couche personnalisée](workinglayers-custom.md). Comme une couche personnalisée possède un ensemble minimal de recettes qui n'installent pas de packages, elle ne doit créer aucun conflit avec la configuration existante de l'instance.
+ Vous pouvez attribuer des instances locales aux couches [intégrées](workinglayers.md) de OpsWorks Stacks.
Chaque couche intégrée inclut des recettes qui installent automatiquement un ou plusieurs packages. Par exemple, les recettes de configuration du serveur d'applications Java installent Apache et Tomcat. Les recettes de la couche peuvent également effectuer d'autres opérations telles que le redémarrage de services et le déploiement d'applications. Avant d'attribuer une instance locale à une couche intégrée, vous devez vous assurer que les recettes de la couche ne créent aucun conflit, par exemple en essayant d'installer une version de serveur d'applications différente de celle qui se trouve actuellement sur l'instance. Pour plus d’informations, consultez [Layers](workinglayers.md) et [OpsWorks Référence de la couche Stacks](layers.md).
**Pour attribuer une instance enregistrée à une couche**
1. Ajoutez à la pile les couches que vous souhaitez utiliser, si ce n'est déjà fait.
1. Choisissez **Instances** dans le volet de navigation, puis cliquez sur **attribuer** dans la colonne **Actions** de l'instance.
1. Sélectionnez les couches appropriées et choisissez **Enregistrer**.
Lorsque vous attribuez une instance à une couche, OpsWorks Stacks effectue les opérations suivantes.
+ Exécute les recettes Setup de la couche.
+ Ajoute les adresses IP élastiques ou les volumes Amazon EBS attachés aux ressources de la pile.
Vous pouvez ensuite utiliser OpsWorks Stacks pour gérer ces ressources. Pour de plus amples informations, veuillez consulter [Gestion des ressources](resources.md).
Une fois qu'elles sont terminées, l'instance passe en ligne et est entièrement intégrée à la pile. OpsWorks Stacks exécute ensuite les recettes attribuées à la couche chaque fois qu'un événement du cycle de vie se produit.
# Annulation de l'enregistrement d'une instance
**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. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
**Note**
Cette fonctionnalité est prise en charge uniquement pour les piles Linux.
Vous pouvez annuler l'attribution d'une instance enregistrée à ses couches à l'aide de la OpsWorks console ou de AWS CLI l'opération du SDK.
Lorsque vous annulez l'attribution d'une instance, OpsWorks Stacks exécute les recettes Shutdown de la couche sur l'instance. Ces recettes effectuent des tâches telles que l'arrêt des services, mais n'arrêtent pas l'instance. Si l'instance est attribuée à plusieurs couches, l'annulation s'applique à chaque couche ; vous ne pouvez pas annuler l'enregistrement d'une instance à partir d'un sous-ensemble de ses couches. Cependant, l'instance est toujours enregistrée auprès de la pile et vous pouvez l'affecter à une autre couche si vous le souhaitez.
**Pour annuler l'attribution d'une instance enregistrée à l'aide de la console**
1. Dans le panneau de navigation, choisissez **Instances**.
1. Choisissez l'instance dont vous souhaitez annuler l'attribution.
1. Sur la page **Détails** de l'instance, choisissez Annuler l'**attribution**.
![\[annuler l'attribution d'une instance enregistrée sur la page de détails de l'instance\]](http://docs.aws.amazon.com/fr_fr/opsworks/latest/userguide/images/unassign-instance.png)
**Pour annuler l'attribution d'une instance enregistrée à l'aide du AWS CLI**
Exécutez la [https://docs.aws.amazon.com/cli/latest/reference/opsworks/unassign-instance.html](https://docs.aws.amazon.com/cli/latest/reference/opsworks/unassign-instance.html)commande pour annuler l'attribution d'une instance enregistrée à toutes les couches qui l'utilisent.
```
aws opsworks unassign-instance --region region --instance-id instance-id
```
# Annulation de l'enregistrement d'une instance
**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. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
Vous pouvez annuler l'enregistrement d'une instance à l'aide de la OpsWorks console ou du SDK. AWS CLI
**
**Pour désenregistrer une instance à l'aide de la console**
1. Dans le panneau de navigation, choisissez **Instances**.
1. Choisissez l'instance que vous souhaitez désenregistrer.
1. Sur la page **Détails** de l'instance, choisissez **Désenregistrer**.
![\[annuler l'enregistrement d'une instance sur la page de détails de l'instance\]](http://docs.aws.amazon.com/fr_fr/opsworks/latest/userguide/images/deregister-instance.png)
**Pour annuler l'enregistrement d'une instance à l'aide du AWS CLI**
Exécutez la [https://docs.aws.amazon.com/cli/latest/reference/opsworks/deregister-instance.html](https://docs.aws.amazon.com/cli/latest/reference/opsworks/deregister-instance.html)commande pour désenregistrer une instance de sa pile.
```
aws opsworks deregister-instance --region region --instance-id instance-id
```
Lorsque vous annulez l'enregistrement d'une instance, OpsWorks Stacks effectue les opérations suivantes :
+ Supprime l'instance de la pile.
+ Annule l'enregistrement de l'instance à partir de couches assignées.
+ Arrête et désinstalle l'agent.
+ Désenregistre toutes les ressources associées (adresses IP élastiques et volumes Amazon EBS).
Cette procédure inclut les ressources qui étaient attachées à l'instance avant l'enregistrement, ainsi que les ressources que vous avez utilisées OpsWorks pour associer à l'instance alors qu'elle faisait partie de la pile. Après l'annulation de l'enregistrement, les ressources ne font plus partie des ressources de la pile, mais demeurent attachées à l'instance.
+ Pour les instances sur site, arrête les frais.
+ Supprime toutes les balises OpsWorks ajoutées à l'instance.
L'instance reste en cours d'exécution, mais elle est sous votre contrôle direct et n'est plus gérée par OpsWorks Stacks.
**Note**
L'enregistrement et le désenregistrement d'ordinateurs ou d'instances ne sont entièrement pris en charge que dans les piles Linux. Pour les piles Windows, le désenregistrement des instances est autorisé, mais cela ne désinstalle pas l' OpsWorks agent de l'instance. L'annulation de l'enregistrement ne supprime pas tous les fichiers modifiés et ne restaure pas intégralement les copies sauvegardées de certains fichiers. Cette liste s'applique à la fois aux piles Chef 11.10 et Chef 12 ; les différences entre les deux versions sont mentionnées ici.
`/etc/hosts` est sauvegardé dans `/var/lib/aws/opsworks/local-mode-cache/backup/etc/`, mais n'est pas restauré.
Les entrées demeurent pour `aws` et `opsworks` dans les fichiers passwd, group et shadow, etc.
`/etc/sudoers`contient une référence à un répertoire OpsWorks Stacks.
Les fichiers suivants peuvent être ignorés en toute sécurité ; à long terme, pensez à supprimer `/var/lib/aws/opsworks`.
`/var/log/aws/opsworks` demeure sur les instances des piles Chef 11.10.
`/var/lib/aws/opsworks` demeure sur les instances des piles Chef 11.10 et Chef 12.
`/var/chef` demeure sur les instances des piles Chef 12.
Autres fichiers ignorés :
`/etc/logrotate.d/opsworks-agent`
`/etc/cron.d/opsworks-agent-updater`
`/etc/ld.so.conf.d/opsworks-user-space.conf`
`/etc/motd.opsworks-static`
`/etc/aws/opsworks`
`/etc/sudoers.d/opsworks`
`/etc/sudoers.d/opsworks-agent`
# Cycle de vie des instances enregistrées
**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. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
**Note**
Cette fonctionnalité est prise en charge uniquement pour les piles Linux.
Le cycle de vie d'une instance enregistrée commence une fois que l'agent est installé et en cours d'exécution. À ce stade, il demande à OpsWorks Stacks d'enregistrer l'instance auprès de la pile. Le schéma d'état suivant résume les éléments clés du cycle de vie.
![\[State diagram showing lifecycle of registered instances with various states and transitions.\]](http://docs.aws.amazon.com/fr_fr/opsworks/latest/userguide/images/on-prem-state.png)
Chaque état correspond à un statut d'instance. Les arêtes représentent l'une des commandes OpsWorks Stacks suivantes. Les détails sont détaillés dans les sections suivantes.
+ **Configuration** : cette commande correspond à l'[événement du cycle](workingcookbook-events.md) de vie de l'installation et exécute les recettes de configuration de l'instance.
+ **Configurer** — Cette commande correspond à l'événement Configurer le cycle de vie.
OpsWorks Stacks déclenche cet événement sur chaque instance de la pile lorsqu'une instance entre ou quitte l'état en ligne. Les instances exécutent leurs recettes Configure, qui effectuent les modifications requises pour accueillir la nouvelle instance.
+ **Shutdown** — Cette commande correspond à l'événement Shutdown Lifecycle, qui exécute les recettes d'arrêt de l'instance.
Ces recettes effectuent des tâches telles que l'arrêt des services, mais elles n'arrêtent pas l'instance.
+ **Désenregistrer** — Cette commande annule l'enregistrement d'une instance et ne correspond pas à un événement du cycle de vie.
**Note**
Pour des raisons de simplicité, le schéma n'affiche pas les états Deregistering et Deleted. Vous pouvez annuler l'enregistrement d'une instance à partir de l'un des états du diagramme, ce qui envoie une commande Deregister à l'instance et la passe à l'état Deregistering.
Si vous annulez l'enregistrement d'une instance en ligne, OpsWorks Stacks envoie une commande Configure aux instances restantes de la pile pour les informer que l'instance est en train de se déconnecter.
Après la confirmation de la commande Deregister, l'instance continue à s'exécuter, mais elle est dans l'état Deleted et ne fait plus partie de la pile. Si vous souhaitez intégrer à nouveau l'instance dans la pile, vous devez la réenregistrer.
**Topics**
+ [
## Inscription en cours
](#registered-instances-lifecycle-registering)
+ [
## Running Setup
](#registered-instances-lifecycle-running-setup)
+ [
## Membre
](#registered-instances-lifecycle-registered)
+ [
## Assigning
](#registered-instances-lifecycle-assigning)
+ [
## En ligne
](#registered-instances-lifecycle-online)
+ [
## Setup Failed
](#registered-instances-lifecycle-setup-failed)
+ [
## Unassigning
](#registered-instances-lifecycle-unassigning)
+ [
## Modifications de la configuration d'installation initiale
](#registered-instances-lifecycle-setup-config)
## Inscription en cours
Une fois que l'agent a envoyé une demande d'enregistrement, OpsWorks Stacks démarre le cycle de vie de l'instance en envoyant une commande de configuration à l'instance, en la plaçant dans l'état d'enregistrement. Une fois que l'instance reconnaît la commande Setup, elle passe à l'état [Running Setup](#registered-instances-lifecycle-running-setup).
## Running Setup
L'état Running Setup exécute les recettes Setup de l'instance. Le fonctionnement de Setup dépend de l'état précédent.
**Note**
Si vous annulez l'attribution de l'instance alors qu'elle est dans l'état Running Setup, OpsWorks Stacks envoie une commande Shutdown, qui exécute les recettes d'arrêt de l'instance mais n'arrête pas l'instance. L’instance passe à l’état [Unassigning](#registered-instances-lifecycle-unassigning).
**Topics**
+ [
### Inscription en cours
](#registered-instances-lifecycle-running-setup-registering)
+ [
### Assigning
](#registered-instances-lifecycle-running-setup-assigning)
+ [
### Setup Failed
](#registered-instances-lifecycle-running-setup-failed)
### Inscription en cours
Au cours du processus d'enregistrement, le programme d'installation crée une instance OpsWorks Stacks pour représenter l'instance enregistrée dans la pile et exécute un ensemble de recettes de configuration de base sur l'instance.
Un changement clé effectué par la configuration initiale est le remplacement du fichier hosts de l'instance. En enregistrant l'instance, vous avez transmis la gestion des utilisateurs à OpsWorks Stacks, qui doit avoir son propre fichiers hôtes pour contrôler les autorisations de connexion SSH. La configuration initiale crée ou modifie également un certain nombre de fichiers et, sur les systèmes Ubuntu, modifie les sources des packages et installe un ensemble de packages. Pour en savoir plus, consultez [Modifications de la configuration d'installation initiale](#registered-instances-lifecycle-setup-config).
Lors de l'enregistrement, le processus appelle l'IAM `AttachUserPolicy` qui fait partie des autorisations associées à l'utilisateur IAM que vous créez comme condition préalable. Si `AttachUserPolicy` n'existe pas (probablement parce que vous exécutez une ancienne version de l'interface de ligne de commande AWS), le processus revient à l'appel `PutUserPolicy`.
**Note**
Pour des raisons de cohérence, OpsWorks Stacks exécute toutes les recettes de configuration de base. Cependant, comme certaines d'entre elles n'effectuent tout ou partie de leurs tâches que si une instance a été affectée à une couche au moins, elles n'affectent pas nécessairement la configuration initiale.
+ Si la commande Setup se déroule avec succès, l'instance passe à l'état [Membre](#registered-instances-lifecycle-registered).
+ Si la commande Setup échoue, l'instance passe à l'état [Setup Failed](#registered-instances-lifecycle-setup-failed).
### Assigning
Au moins une couche est attribuée à l'instance. OpsWorks Stacks exécute les recettes de configuration de chaque couche, y compris les recettes personnalisées que vous avez [attribuées à l'événement de configuration des couches](workingcookbook-executing.md).
+ Si la commande Setup se déroule avec succès, l'instance passe à l'état online (en ligne) et OpsWorks Stacks déclenche un événement de cycle de vie Configure sur chaque instance de la pile afin de les informer de la nouvelle instance.
+ Si la commande Setup échoue, l'instance passe à l'état Setup Failed.
**Note**
Ce processus d'installation exécute les recettes de base une deuxième fois. Toutefois, comme les recettes Chef sont idempotentes, elles ne répètent pas les tâches qui ont déjà été effectuées.
### Setup Failed
Si le processus d'installation d'une instance dans l'état [Assigning](#registered-instances-lifecycle-assigning) échoue, vous pouvez réessayer en utilisant la [commande de pile Setup](workingstacks-commands.md) afin de relancer manuellement les recettes Setup de l'instance.
+ Si la commande réussit, l'instance assignée passe à l'état [En ligne](#registered-instances-lifecycle-online) et OpsWorks Stacks déclenche un événement de cycle de vie Configure sur chaque instance de la pile pour les informer de la nouvelle instance.
+ Si la commande échoue, l'instance revient à l'état Setup Failed.
## Membre
Les instances à l'état Enregistré font partie de la pile et sont gérées par OpsWorks Stacks mais ne sont attribuées à aucune couche. Elles peuvent rester indéfiniment dans cet état.
Si vous attribuez l'instance à une ou plusieurs couches, OpsWorks Stacks envoie une commande de configuration à l'instance et elle passe à l'[Assigning](#registered-instances-lifecycle-assigning)état.
## Assigning
Une fois que l'instance reconnaît la commande Setup, elle passe à l'état [Running Setup](#registered-instances-lifecycle-running-setup).
Si vous annulez l'attribution de l'instance alors qu'elle est dans l'état Assignation, OpsWorks Stacks met fin au processus de configuration et envoie une commande d'arrêt. L’instance passe à l’état [Unassigning](#registered-instances-lifecycle-unassigning).
## En ligne
L'instance est désormais membre d'au moins une couche et est traitée comme une instance OpsWorks Stacks régulière. Elle peut demeurer indéfiniment dans cet état.
Si vous annulez l'attribution de l'instance alors qu'elle est en ligne, OpsWorks Stacks envoie une commande d'arrêt à l'instance et une commande de configuration aux autres instances de la pile. L’instance passe à l’état [Unassigning](#registered-instances-lifecycle-unassigning).
## Setup Failed
La commande Setup a échoué.
+ Vous pouvez réessayer en choisissant la [commande de pile Setup](workingstacks-commands.md).
L'instance retourne à l'état [Running Setup](#registered-instances-lifecycle-running-setup).
+ Si vous annulez l'attribution de l'instance, OpsWorks Stacks envoie une commande d'arrêt à l'instance.
L’instance passe à l’état [Unassigning](#registered-instances-lifecycle-unassigning).
## Unassigning
Une fois que la commande Shutdown est terminée, l'instance n'est plus affectée à quelque couche que ce soit et retourne à l'état [Membre](#registered-instances-lifecycle-registered).
**Note**
Si une instance est attribuée à plusieurs couches, l'annulation de l'attribution s'applique à chaque couche ; vous ne pouvez pas annuler l'attribution d'un sous-ensemble des couches assignées. Si vous souhaitez un autre ensemble de couches assignées, annulez l'attribution de l'instance, puis réassignez les couches souhaitées.
## Modifications de la configuration d'installation initiale
L'installation initiale crée ou modifie les fichiers et répertoires suivants sur toutes les instances enregistrées.
**Fichiers créés**
```
/etc/apt/apt.conf.d/99-no-pipelining
/etc/aws/
/etc/init.d/opsworks-agent
/etc/motd
/etc/motd.opsworks-static
/etc/sudoers.d/opsworks
/etc/sudoers.d/opsworks-agent
/etc/sysctl.d/70-opsworks-defaults.conf
/opt/aws/opsworks/
/usr/sbin/opsworks-agent-cli
/var/lib/aws/
/var/log/aws/
/vol/
```
**Fichiers modifiés**
```
/etc/apt/apt.conf.d/99-no-pipelining
/etc/crontab
/etc/default/monit
/etc/group
/etc/gshadow
/etc/monit/monitrc
/etc/passwd
/etc/security/limits.conf (removing limits only for EC2 micro instances)
/etc/shadow
/etc/sudoers
```
La configuration initiale crée également un fichier d'échange sur les EC2 micro-instances Amazon.
L'installation initiale apporte les modifications suivantes aux systèmes Ubuntu.
Sources de packages
L'installation initiale modifie les sources de packages comme suit :
+ `deb http://archive.ubuntu.com/ubuntu/ ${code_name} main universe`
À : `deb-src http://archive.ubuntu.com/ubuntu/ ${code_name} main universe`
+ `deb http://archive.ubuntu.com/ubuntu/ ${code_name}-updates main universe`
À : `deb-src http://archive.ubuntu.com/ubuntu/ ${code_name}-updates main universe`
+ `deb http://archive.ubuntu.com/ubuntu ${code_name}-security main universe`
À : `deb-src http://archive.ubuntu.com/ubuntu ${code_name}-security main universe`
+ `deb http://archive.ubuntu.com/ubuntu/ ${code_name}-updates multiverse`
À : `deb-src http://archive.ubuntu.com/ubuntu/ ${code_name}-updates multiverse`
+ `deb http://archive.ubuntu.com/ubuntu ${code_name}-security multiverse`
À : `deb-src http://archive.ubuntu.com/ubuntu ${code_name}-security multiverse`
+ `deb http://archive.ubuntu.com/ubuntu/ ${code_name} multiverse`
À : `deb-src http://archive.ubuntu.com/ubuntu/ ${code_name} multiverse`
+ `deb http://security.ubuntu.com/ubuntu ${code_name}-security multiverse`
À : `deb-src http://security.ubuntu.com/ubuntu ${code_name}-security multiverse`
Forfaits
L'installation initiale désinstalle `landscape` et installe les packages suivants.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opsworks/latest/userguide/registered-instances-lifecycle.html)