Utilisation d'AMI personnalisées - AWS OpsWorks
Comment les AMI personnalisées fonctionnent avec AWS OpsWorks StacksCréation d'une AMI personnalisée pour AWS OpsWorks Stacks

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 d'AMI personnalisé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 ou via le AWS Support Premium.

AWS OpsWorks Stacks propose deux méthodes pour personnaliser les instances : les Amazon Machine Images (AMI) personnalisées et les recettes Chef. Les deux approches vous permettent de contrôler quels sont les packages et versions de package installés, comment ils sont configurés, et ainsi de suite. Cependant, chaque approche ayant différents avantages, la meilleure dépend de vos besoins.

Les principales raisons à prendre en compte pour l'utilisation d'une AMI personnalisée sont les suivantes :

  • Vous voulez regrouper préalablement des packages spécifiques au lieu de les installer une fois que l'instance a démarré.

  • Vous voulez contrôler le moment des mises à jour des packages pour fournir une image de base cohérente à votre couche.

  • Vous voulez que les instances (notamment celles à charge définie) démarrent aussi rapidement que possible.

Les principales raisons à prendre en compte pour l'utilisation des recettes Chef sont les suivantes :

  • Elles sont plus flexibles que les AMI personnalisées.

  • Elles sont plus faciles à mettre à jour.

  • Elles peuvent effectuer des mises à jour sur des instances en cours d'exécution.

En pratique, la solution optimale peut être une combinaison de ces deux approches. Pour plus d'informations sur les recettes, consultez Livres de recettes et recettes.

Comment les AMI personnalisées fonctionnent avec AWS OpsWorks Stacks

Pour spécifier une AMI personnalisée pour vos instances, sélectionnez Utiliser une AMI personnalisée comme système d'exploitation de l'instance lorsque vous créez une nouvelle instance. AWS OpsWorks Stacks affiche ensuite une liste des AMI personnalisées dans la région de la pile et vous sélectionnez celle qui convient dans la liste. Pour plus d’informations, consultez Ajout d'une instance à une couche.

Note

Vous ne pouvez pas spécifier une AMI personnalisée particulier comme système d'exploitation par défaut d'une pile. Vous pouvez définir Use custom AMI comme système d'exploitation par défaut de la pile, mais vous ne pouvez spécifier une AMI particulière que lorsque vous ajoutez de nouvelles instances aux couches. Pour plus d’informations, consultez Ajout d'une instance à une couche et Créer une pile. Bien qu'il soit possible de créer des instances avec d'autres systèmes d'exploitation (par exemple, CentOS 6.x) créés à partir d'AMI personnalisées ou générées par la communauté, celles-ci ne sont pas officiellement prises en charge.

Cette rubrique présente quelques questions générales que vous devez prendre en compte avant de créer ou d'utiliser une AMI personnalisée.

Comportement au démarrage

Lorsque vous démarrez l'instance, AWS OpsWorks Stacks utilise l'AMI personnalisée spécifiée pour lancer une nouvelle instance Amazon EC2. AWS OpsWorks Stacks utilise ensuite cloud-init pour installer l'agent AWS OpsWorks Stacks sur l'instance et l'agent exécute les recettes de configuration de l'instance, suivies des recettes de déploiement. Une fois que l'instance est en ligne, l'agent exécute les recettes Configure pour chaque instance de la pile, y compris l'instance nouvellement ajoutée.

Choix d'une couche

L'agent AWS OpsWorks Stacks n'entre généralement pas en conflit avec les packages installés. Toutefois, l'instance doit être membre d'au moins une couche. AWS OpsWorks Stacks exécute toujours les recettes de cette couche, ce qui peut poser problème. Vous devez bien comprendre ce que font les recettes d'une couche avant d'ajouter à celle-ci une instance avec une AMI personnalisée.

Pour voir quelles recettes un type de couche particulier exécute sur votre instance, ouvrez une pile qui inclut cette couche. Puis, cliquez sur Layers (Couches) dans le panneau de navigation, puis sur Recipes (Recettes) pour la couche qui vous intéresse. Pour voir le code, cliquez sur le nom de la recette.

Note

Pour les AMI Linux, l'un des moyens de réduire les risques de conflits consiste à utiliser AWS OpsWorks Stacks pour approvisionner et configurer l'instance qui constitue la base de votre AMI personnalisée. Pour plus d’informations, consultez Création d'une AMI Linux personnalisée à partir d'une AWS OpsWorks instance Stacks.

Gestion des applications

En plus des packages, il se peut que vous souhaitiez également inclure une application dans l'AMI. Si vous avez une application complexe, son inclusion dans l'AMI peut réduire la durée de démarrage de l'instance. Vous pouvez inclure de petites applications dans votre AMI, mais il n'y a généralement que peu ou pas d'avantage en termes de temps par rapport au déploiement de l'application par AWS OpsWorks Stacks.

Une option consiste à inclure l'application dans votre AMI et également à créer une application qui déploie l'application sur les instances à partir d'un référentiel. Cette approche réduit votre temps de démarrage, mais fournit également un moyen pratique de mettre à jour l'application une fois que l'instance est en cours d'exécution. Notez que, comme les recettes Chef sont idempotentes, les recettes du déploiement ne modifient pas l'application aussi longtemps que la version du référentiel est identique à celle de l'instance.

Création d'une AMI personnalisée pour AWS OpsWorks Stacks

Pour utiliser une AMI personnalisée avec AWS OpsWorks Stacks, vous devez d'abord créer une AMI à partir d'une instance personnalisée. Vous avez le choix entre deux options :

  • Utilisez la console ou l'API Amazon EC2 pour créer et personnaliser une instance, sur la base d'une version 64 bits de l'une des AMI prises en charge par AWS OpsWorks Stacks.

  • Pour les AMI Linux, OpsWorks utilisez-le pour créer une instance Amazon EC2, en fonction de la configuration des couches associées.

Avant de créer une AMI Linux personnalisée, désactivez-la noexec sur la /tmp partition pour permettre à AWS OpsWorks Stacks d'installer son agent sur des instances Linux personnalisées.

Note

Sachez que, comme une AMI peut ne pas fonctionner avec tous les types d'instance, assurez-vous que votre AMI initiale est compatible avec les types d'instance que vous prévoyez d'utiliser. En particulier, les types d'instances R3 nécessitent une AMI de virtualisation à assistance matérielle (HVM).

Vous utilisez ensuite la console ou l'API Amazon EC2 pour créer une AMI personnalisée à partir de l'instance personnalisée. Vous pouvez utiliser vos AMI personnalisées dans n'importe quelle pile de la même région en ajoutant une instance à une couche et en spécifiant votre AMI personnalisée. Pour plus d'informations sur la création d'une instance qui utilise une AMI personnalisée, consultez Ajout d'une instance à une couche.

Note

Par défaut, AWS OpsWorks Stacks installe toutes les mises à jour d'Amazon Linux au démarrage, ce qui vous fournit la dernière version. De plus, Amazon Linux libère une nouvelle version environ tous les six mois, ce qui peut entraîner des modifications importantes. Par défaut, les AMI personnalisées basées sur Amazon Linux sont mises à jour automatiquement avec la nouvelle version quand elle devient disponible. La méthode recommandée consiste à verrouiller votre AMI personnalisée sur une version Amazon Linux spécifique, ce qui vous permet de reporter la mise à jour jusqu'à ce que vous ayez testé la nouvelle version. Pour plus d'informations, consultez Comment verrouiller mon AMI avec une version spécifique ?.

Création d'une AMI personnalisée à l'aide d'Amazon EC2

Le moyen le plus simple de créer une AMI personnalisée (et la seule option pour les AMI Windows) consiste à exécuter la tâche dans son intégralité à l'aide de la console ou de l'API Amazon EC2. Pour plus d'informations sur les étapes suivantes, consultez Création de vos propres AMI.

Pour créer une AMI personnalisée à l'aide de la console ou de l'API Amazon EC2

  1. Créez une instance à l'aide d'une version 64 bits de l'une des AMI prises en charge par AWS OpsWorks Stacks.

  2. Personnalisez l'instance de l'étape 1 en la configurant, en installant les packages, et ainsi de suite. N'oubliez pas que tout ce que vous installez figurera sur chaque instance basée sur l'AMI ; par conséquent, n'incluez pas les éléments qui doivent être spécifiques à une instance particulière.

  3. Arrêtez l'instance et créez une AMI personnalisée.

Création d'une AMI Linux personnalisée à partir d'une AWS OpsWorks instance Stacks

Pour utiliser une instance AWS OpsWorks Stacks Linux personnalisée afin de créer une AMI, sachez que chaque instance Amazon EC2 créée OpsWorks par inclut une identité unique. Si vous créez une AMI personnalisée à partir d'une telle instance, elle inclut cette identité, et toutes les instances basées sur l'AMI ont la même identité. Pour garantir que les instances basées sur votre AMI personnalisée aient une identité unique, vous devez supprimer l'identité de l'instance personnalisée avant de créer l'AMI.

Pour créer une AMI personnalisée à partir d'une AWS OpsWorks instance Stacks

  1. Créez une pile Linux et ajoutez une ou plusieurs couches pour définir la configuration de l'instance personnalisée. Vous pouvez utiliser des couches intégrées, personnalisés selon le cas, aussi bien que des couches entièrement personnalisées. Pour plus d’informations, consultez Personnalisation AWS OpsWorks Piles.

  2. Modifiez les couches et désactivez-les AutoHealing.

  3. Ajoutez une instance avec votre distribution Linux préférée à la couche ou aux couches et démarrez-la. Nous vous recommandons d'utiliser une instance basée sur Amazon EBS. Ouvrez la page de détails de l'instance et enregistrez son identifiant Amazon EC2 pour plus tard.

  4. Lorsque l'instance est en ligne, connectez-vous avec SSH et procédez à l'une des quatre étapes suivantes, selon le système d'exploitation de votre instance.

  5. Pour une instance Amazon Linux dans une pile Chef 11 ou Chef 12, ou une instance Red Hat Enterprise Linux 7 dans une pile Chef 11, procédez comme suit :

    1. sudo /etc/init.d/monit stop

    2. sudo /etc/init.d/opsworks-agent stop

    3. sudo rm -rf /etc/aws/opsworks/ /opt/aws/opsworks/ /var/log/aws/opsworks/ /var/lib/aws/opsworks/ /etc/monit.d/opsworks-agent.monitrc /etc/monit/conf.d/opsworks-agent.monitrc /var/lib/cloud/ /etc/chef

      Note

      Pour les instances d'une pile Chef 12, ajoutez les deux dossiers suivants à la commande :

      • /var/chef

      • /opt/chef

    4. sudo rpm -e opsworks-agent-ruby

    5. sudo rpm -e chef

  6. Pour une instance Ubuntu 16.04 LTS ou 18.04 LTS d'une pile Chef 12, procédez comme suit.

    1. sudo systemctl stop opsworks-agent

    2. sudo rm -rf /etc/aws/opsworks/ /opt/aws/opsworks/ /var/log/aws/opsworks/ /var/lib/aws/opsworks/ /etc/monit.d/opsworks-agent.monitrc /etc/monit/conf.d/opsworks-agent.monitrc /var/lib/cloud/ /var/chef /opt/chef /etc/chef

    3. sudo apt-get -y remove chef

    4. sudo dpkg -r opsworks-agent-ruby

    5. systemctl stop apt-daily.timer

    6. systemctl stop apt-daily-upgrade.timer

    7. rm /var/lib/systemd/timers/stamp-apt-daily.timer

    8. rm /var/lib/systemd/timers/stamp-apt-daily-upgrade.timer

  7. Pour les autres versions Ubuntu prises en charge d'une pile Chef 12, procédez comme suit :

    1. sudo /etc/init.d/monit stop

    2. sudo /etc/init.d/opsworks-agent stop

    3. sudo rm -rf /etc/aws/opsworks/ /opt/aws/opsworks/ /var/log/aws/opsworks/ /var/lib/aws/opsworks/ /etc/monit.d/opsworks-agent.monitrc /etc/monit/conf.d/opsworks-agent.monitrc /var/lib/cloud/ /var/chef /opt/chef /etc/chef

    4. sudo apt-get -y remove chef

    5. sudo dpkg -r opsworks-agent-ruby

  8. Pour une instance Red Hat Enterprise Linux 7 d'une pile Chef 12, procédez comme suit :

    1. sudo systemctl stop opsworks-agent

    2. sudo rm -rf /etc/aws/opsworks/ /opt/aws/opsworks/ /var/log/aws/opsworks/ /var/lib/aws/opsworks/ /etc/monit.d/opsworks-agent.monitrc /etc/monit/conf.d/opsworks-agent.monitrc /var/lib/cloud/ /etc/chef /var/chef

    3. sudo rpm -e opsworks-agent-ruby

    4. sudo rpm -e chef

  9. Cette étape dépend du type d'instance :

    • Pour une instance basée sur Amazon EBS, utilisez la console AWS OpsWorks Stacks pour arrêter l'instance et créer l'AMI comme décrit dans Création d'une AMI Linux basée sur Amazon EBS.

    • Pour une instance basée sur le stockage d'instance, créez l'AMI comme décrit dans Création d'une AMI Linux basée sur le stockage d'instance, puis utilisez AWS OpsWorks la console Stacks pour arrêter l'instance.

      Lorsque vous créez l'AMI, veillez à inclure les fichiers de certificat. Par exemple, vous pouvez appeler la commande ec2-bundle-vol avec l'argument -i défini sur -i $(find /etc /usr /opt -name '*.pem' -o -name '*.crt' -o -name '*.gpg' | tr '\n' ','). Ne supprimez pas les clés publiques lors du regroupement. La commande par défaut ec2-bundle-vol gère la tâche.

  10. Nettoyez votre pile en retournant à la console AWS OpsWorks Stacks et en supprimant l'instance de la pile.

Créer une AMI Windows personnalisée

Les procédures suivantes créent des AMI personnalisées pour Windows Server 2022 Base. Vous pouvez choisir d'autres systèmes d'exploitation Windows Server dans la console de gestion Amazon EC2.

Important

À l'heure actuelle, l'agent AWS OpsWorks Stacks ne peut pas être installé sur des instances Windows qui utilisent une langue d'interface utilisateur système autre que l'anglais - États-Unis (en-US), et AWS OpsWorks Stacks ne peut pas les gérer.

Création d'une AMI Windows personnalisée avec Sysprep

La création d'AMI Windows personnalisées à l'aide de Sysprep se traduit généralement par un lancement d'instance plus lent, mais un processus plus propre. Le premier démarrage d'une instance créée à partir d'une image créée avec Sysprep prend plus de temps en raison des Sysprep activités, des redémarrages, du provisionnement des AWS OpsWorks Stacks et de la première exécution de AWS OpsWorks Stacks, y compris l'installation et la configuration. Suivez les étapes de création d'une AMI Windows personnalisée dans la console Amazon EC2.

Pour créer une AMI Windows personnalisée avec Sysprep

  1. Dans la console Amazon EC2, choisissez Lancer une instance.

  2. Recherchez Microsoft Windows Server 2022 Base, puis choisissez Sélectionner.

  3. Sélectionnez le type d'instance que vous voulez, puis choisissez Configure Instance Details (Configurer les détails de l'instance). Apportez les modifications de configuration à l'AMI, y compris les paramètres de nom de machine, de stockage et de groupes de sécurité. Choisissez Lancer.

  4. Une fois que le processus de démarrage de l'instance a pris fin, obtenez votre mot de passe et connectez-vous à l'instance dans une fenêtre Windows Connexion Bureau à distance.

  5. Sur l'écran de démarrage de Windows, choisissez Démarrer, puis commencez à taper ec2configservice jusqu'à ce que les résultats s'affichent sur la ConfigServiceSettings console EC2. Ouvrez la console.

  6. Dans l'onglet Général, assurez-vous que la case Activer UserData l'exécution est cochée (bien que cette option ne soit pas obligatoireSysprep, elle est nécessaire pour que AWS OpsWorks Stacks installe son agent). Désactivez la case à cocher de l'option Set the computer name of the instance... (Définir le nom d'ordinateur de l'instance…), parce que cette option peut entraîner une boucle de redémarrage avec AWS OpsWorks Stacks.

  7. Dans l'onglet Image, définissez le mot de passe administrateur sur Aléatoire pour permettre à Amazon EC2 de générer automatiquement un mot de passe que vous pouvez récupérer à l'aide d'une clé SSH, ou sur Spécifier pour spécifier votre propre mot de passe. Sysprepenregistre ce paramètre. Si vous spécifiez votre propre mot de passe, stockez le mot de passe dans un endroit pratique. Nous vous recommandons de ne pas choisir Keep Existing (Conserver l'existant).

  8. Choisissez Apply (Appliquer), puis Shutdown with Sysprep (Arrêter avec Sysprep). Lorsque vous êtes invité à confirmer, choisissez Yes (Oui).

  9. Une fois l'instance arrêtée, dans la console Amazon EC2, cliquez avec le bouton droit sur l'instance dans la liste Instances, choisissez Image, puis Create Image.

  10. Sur la page Create Image (Créer une image), fournissez le nom et la description de l'image, et spécifiez la configuration du volume. Lorsque vous avez terminé, choisissez Create Image (Créer une image).

  11. Ouvrez la page Images et attendez que votre image passe de l'état pending (en attente) à l'état available (disponible). Votre nouvelle AMI est prêt à être utilisée.

Création d'une AMI Windows personnalisée sans Sysprep

Suivez les étapes de création d'une AMI Windows personnalisée dans la console Amazon EC2.

Pour créer une AMI Windows personnalisée sans Sysprep

  1. Dans la console Amazon EC2, choisissez Lancer une instance.

  2. Recherchez Microsoft Windows Server 2022 Base, puis choisissez Sélectionner.

  3. Sélectionnez le type d'instance que vous voulez, puis choisissez Configure Instance Details (Configurer les détails de l'instance). Apportez les modifications de configuration à l'AMI, y compris les paramètres de nom de machine, de stockage et de groupes de sécurité. Choisissez Lancer.

  4. Une fois que le processus de démarrage de l'instance a pris fin, obtenez votre mot de passe et connectez-vous à l'instance dans une fenêtre Windows Connexion Bureau à distance.

  5. Sur l'instance, ouvrez C:\Program Files\Amazon\Ec2ConfigService\Settings\config.xml, modifiez les deux paramètres suivants, puis enregistrez le fichier et fermez-le :

    • Ec2SetPassword sur Enabled

    • Ec2HandleUserData sur Enabled

  6. Déconnectez-vous de la session Remote Desktop et revenez à la console Amazon EC2.

  7. Dans la liste Instances, arrêtez l'instance.

  8. Une fois l'instance arrêtée, dans la console Amazon EC2, cliquez avec le bouton droit sur l'instance dans la liste Instances, choisissez Image, puis Create Image.

  9. Sur la page Create Image (Créer une image), fournissez le nom et la description de l'image, et spécifiez la configuration du volume. Lorsque vous avez terminé, choisissez Create Image (Créer une image).

  10. Ouvrez la page Images et attendez que votre image passe de l'état pending (en attente) à l'état available (disponible). Votre nouvelle AMI est prêt à être utilisée.

Ajout d'une nouvelle instance à l'aide d'une AMI Windows personnalisée

Une fois que votre image est passée à l'état available (disponible), vous pouvez créer de nouvelles instances basées sur votre AMI Windows personnalisée. Lorsque vous choisissez Use custom Windows AMI (Utiliser une AMI Windows personnalisée) dans la liste Operating system (Système d'exploitation), AWS OpsWorks Stacks affiche la liste des AMI personnalisées.

Pour ajouter une nouvelle instance basée sur une AMI Windows personnalisée

  1. Lorsque votre nouvelle AMI est disponible, accédez à la console AWS OpsWorks Stacks, ouvrez la page Instances pour une pile Windows et choisissez + Instance en bas de la page pour ajouter une nouvelle instance.

  2. Sous l'onglet New (Nouveau), choisissez Advanced (Avancé).

  3. Dans la liste déroulante Operating system (Système d'exploitation), choisissez Use custom Windows AMI (Utiliser une AMI Windows personnalisée).

  4. Dans la liste déroulante Custom AMI (AMI personnalisée), sélectionnez l'AMI que vous avez créée, puis choisissez Add Instance (Ajouter une instance).

Vous pouvez désormais démarrer et exécuter l'instance.