FAQ

Les FAQ suivantes fournissent des réponses aux questions les plus fréquemment posées.

Quelles AWS OpsWorks Stacks versions puis-je migrer ?

Vous ne pouvez migrer que les stacks Chef 11.10 et Chef 12, Amazon Linux, Amazon Linux 2, Ubuntu et Red Hat Enterprise Linux 7.

Quelles versions de Chef peuvent utiliser mes instances migrées ?

Les instances migrées peuvent utiliser les versions 11 à 14 de Chef.

Note

La migration vers Windows Stack n'est pas prise en charge.

Quels types de référentiels puis-je migrer ?

Vous pouvez migrer les types de référentiels S3, Git et HTTP.

Puis-je continuer à utiliser un dépôt Git privé ?

Oui, vous pouvez continuer à utiliser un dépôt Git privé.

Si vous utilisez un GitHub dépôt privé, vous devez créer une nouvelle clé d'Ed25519hôte pour SSH. Cela est dû au fait que les clés prises en charge par SSH ont été GitHub modifiées et le protocole Git non chiffré a été supprimé. Pour plus d'informations sur la clé Ed25519 d'hôte, consultez le billet de GitHub blog Améliorer la sécurité du protocole Git sur GitHub. Après avoir généré une nouvelle clé Ed25519 d'hôte, créez un SecureString paramètre Systems Manager pour cette clé SSH et utilisez le nom du paramètre comme valeur du --repo-private-key paramètre. Pour plus d'informations sur la création d'un SecureString paramètre Systems Manager, voir Create a SecureString parameter (AWS CLI) dans le Guide de AWS Systems Manager l'utilisateur.

Pour tout autre type de dépôt Git, créez un SecureString paramètre Systems Manager pour cette clé SSH et utilisez le nom du paramètre comme valeur du --repo-private-key paramètre du script.

Quelles clés SSH puis-je utiliser pour accéder à mes instances ?

Lorsque vous exécutez le script, celui-ci migre les clés SSH et les instances configurées dans la pile. Vous pouvez utiliser les clés SSH pour accéder à votre instance. Si des clés SSH sont fournies pour la pile et l'instance, le script utilise les clés de la pile. Si vous ne savez pas quelles clés SSH utiliser, consultez les instances dans la console EC2 (https://console.aws.amazon.com/ec2/). La page Détails de la console EC2 affiche les clés SSH de votre instance.

Pourquoi mes instances évoluent-elles automatiquement vers l'avant et vers l'extérieur ?

Auto Scaling redimensionne les instances en fonction des règles de dimensionnement du groupe Auto Scaling. Vous pouvez définir les valeurs de capacité minimale, maximale et souhaitée pour votre groupe. Le groupe Auto Scaling adapte automatiquement votre capacité en conséquence lorsque vous mettez à jour ces valeurs.

Puis-je désactiver Auto Scaling ?

Vous pouvez désactiver Auto Scaling en définissant les valeurs de capacité minimale, maximale et souhaitée du groupe Auto Scaling sur le même nombre. Par exemple, si vous souhaitez toujours avoir dix instances, définissez les valeurs de capacité minimale, maximale et souhaitée sur dix.

Puis-je effectuer des mises à jour du noyau et des packages sur les instances EC2 lancées ?

Par défaut, les mises à jour du noyau et des packages ont lieu au démarrage de l'instance EC2. Procédez comme suit pour effectuer des mises à jour du noyau ou du package sur une instance EC2 lancée. Par exemple, vous souhaiterez peut-être appliquer des mises à jour après avoir exécuté des recettes de déploiement ou de configuration.

1. Connectez-vous à votre instance  EC2.

2. Créez la perform_upgrade fonction suivante et exécutez-la sur votre instance.

   perform_upgrade() {
       #!/bin/bash
       if [ -e '/etc/system-release' ] || [ -e '/etc/redhat-release' ]; then
        sudo yum -y update
       elif [ -e '/etc/debian_version' ]; then
        sudo apt-get update
        sudo apt-get dist-upgrade -y
       fi
   }
   perform_upgrade

3. Après les mises à jour du noyau et du package, vous devrez peut-être redémarrer votre instance EC2. Pour vérifier si un redémarrage est nécessaire, créez la reboot_if_required fonction suivante et exécutez-la sur votre instance EC2.

   reboot_if_required () {
    #!/bin/bash
    if [ -e '/etc/debian_version' ]; then
      if [ -f /var/run/reboot-required ]; then
        echo "reboot is required"
      else
        echo "reboot is not required"
      fi
    elif [ -e '/etc/system-release' ] || [ -e '/etc/redhat-release' ]; then
     export LC_CTYPE=en_US.UTF-8
     export LC_ALL=en_US.UTF-8
     LATEST_INSTALLED_KERNEL=`rpm -q --last kernel | perl -X -pe 's/^kernel-(\S+).*/$1/' | head -1`
     CURRENTLY_USED_KERNEL=`uname -r`
     if [ "${LATEST_INSTALLED_KERNEL}" != "${CURRENTLY_USED_KERNEL}" ];then
        echo "reboot is required"
     else
        echo "reboot is not required"
     fi
    fi
   }
   reboot_if_required            

4. Si les reboot_if_required résultats sont affichés dans un reboot is required message, redémarrez l'instance EC2. Si vous recevez un reboot is not required message, il n'est pas nécessaire de redémarrer l'instance EC2.

Pourquoi les volumes EBS de mes instances ne contiennent-ils aucune donnée ?

Lorsque vous exécutez le script, celui-ci migre la configuration des volumes EBS, créant ainsi une architecture de remplacement pour votre OpsWorks pile et votre couche. Le script ne migre pas les instances réelles ni les données qu'elles contiennent. Le script migre uniquement la configuration des volumes EBS au niveau de la couche et attache les volumes EBS vides aux instances EC2 lancées.

Procédez comme suit pour extraire les données des volumes EBS de vos instances précédentes.

1. Prenez un instantané des volumes EBS de vos instances précédentes. Pour plus d'informations sur la création d'un instantané, consultez la section Créer un instantané Amazon EBS dans le guide de l'utilisateur Amazon EC2.

2. Créez un volume à partir de votre instantané. Pour plus d'informations sur la création d'un volume à partir d'un instantané, consultez la section Créer un volume à partir d'un instantané dans le guide de l'utilisateur Amazon EC2.

3. Attachez le volume que vous avez créé aux instances. Pour plus d'informations sur l'attachement de volumes, consultez la section Attacher un volume Amazon EBS à une instance dans le guide de l'utilisateur Amazon EC2.

Pourquoi les volumes EBS décrits dans mon modèle de lancement ne sont-ils pas montés ?

Si vous fournissez un ID de modèle de lancement pour le --launch-template paramètre avec les volumes EBS, le script attache les volumes EBS, mais ne les monte pas. Vous pouvez monter les volumes EBS attachés en exécutant le MountEBSVolumes RunCommand document créé par le script pour l'instance EC2 lancée.

Si vous ne définissez aucun --launch-template paramètre, le script crée un modèle, et lorsque le groupe Auto Scaling lance une nouvelle instance EC2, le groupe Auto Scaling attache automatiquement les volumes EBS, puis exécute la SetupAutomation commande pour monter les volumes attachés sur les points de montage configurés dans les paramètres de couche.

Où puis-je trouver les journaux de volume des recettes Chef et Mount EBS ?

OpsWorks fournit les journaux dans un compartiment S3 que vous pouvez spécifier en fournissant une valeur pour le --command-logs-bucket paramètre. Le nom du compartiment S3 par défaut est au format :aws-opsworks-stacks-application-manager-logs-account-id. Les journaux de recettes du chef sont stockés dans le ApplyChefRecipes préfixe. Les journaux du volume Mount EBS sont stockés dans le MountEBSVolumes préfixe. Toutes les couches migrées à partir d'une pile fournissent des journaux vers le même compartiment S3.

Note

• La configuration du cycle de vie du compartiment S3 inclut une règle permettant de supprimer les journaux après 30 jours. Si vous souhaitez conserver les journaux pendant plus de 30 jours, vous devez mettre à jour la règle dans la configuration du cycle de vie du compartiment S3.

• Actuellement, il enregistre OpsWorks uniquement le chef setup et les terminate recettes.

Où puis-je trouver le journal de débogage du script de migration ?

Le script place les journaux de débogage dans un compartiment nomméaws-opsworks-stacks-transition-logs-account-id. Les journaux de débogage se trouvent dans le migration_script dossier du compartiment S3, sous les dossiers qui correspondent au nom de la couche que vous avez migrée.

Le script de migration prend-il en charge le versionnement des CloudFormation modèles ?

Le script génère des documents Systems Manager de type CloudFormation qui remplacent la couche ou la pile que vous souhaitez migrer. La réexécution du script, même avec les mêmes paramètres, permet d'exporter une nouvelle version du modèle de couche précédemment exporté. Les versions du modèle sont stockées dans le même compartiment S3 que les journaux de script.

Puis-je migrer plusieurs couches ?

Le --layer-id paramètre du script est transmis dans une seule couche. Pour migrer plusieurs couches, réexécutez le script et transmettez-en un autre--layer-id.

Les couches faisant partie d'une même OpsWorks pile sont répertoriées sous la même application dans Application Manager.

1. Ouvrez la console Systems Manager à l'adresse https://console.aws.amazon.com/systems-manager/.

2. Dans le volet de navigation, choisissez Application Manager.

3. Dans la section Applications, sélectionnez Applications personnalisées.

4. Choisissez votre application. Le nom de l'application commence parapp-stack-name-first-six-characters-stack-id.

5. L'élément de niveau supérieur, commençant par app, montre tous les composants qui correspondent à votre OpsWorks pile. Cela inclut les composants correspondant à votre OpsWorks couche.

6. Choisissez le composant correspondant à la couche pour afficher les ressources de la couche. Les composants représentant les OpsWorks couches sont également visibles dans la section Applications personnalisées en tant qu'applications individuelles.

Comment créer un SecureString paramètre ?

Vous pouvez utiliser Systems Manager pour créer un SecureString paramètre. Pour plus d'informations sur la création d'un SecureString paramètre Systems Manager, voir Create a SecureString parameter (AWS CLI) ou Create a Systems Manager parameter (console) dans le Guide de AWS Systems Manager l'utilisateur.

Vous devez fournir un SecureString paramètre comme valeur pour les --repo-private-key paramètres --http-username--http-password, ou.

Comment puis-je protéger les instances du nouveau groupe Auto Scaling contre les événements de résiliation ?

Vous pouvez protéger les instances en définissant le --enable-instance-protection paramètre sur TRUE et en ajoutant une clé de protected_instance balise à chaque instance EC2 que vous souhaitez protéger contre les événements de résiliation. Lorsque vous définissez le --enable-instance-protection paramètre sur TRUE et ajoutez une clé de protected_instance balise, le script ajoute une politique de résiliation personnalisée à votre nouveau groupe Auto Scaling et suspend le ReplaceUnhealthy processus. Les instances dotées de la clé de protected_instance balise sont protégées contre les événements de terminaison suivants :

• Échelle des événements

• Actualisation d'instance

• Rééquilibrage

• Durée de vie maximale de l'instance

• Autoriser la résiliation de l'instance de référencement

• Résiliation et remplacement d'instances défectueuses

Note

Vous devez définir la clé de protected_instance balise sur les instances que vous souhaitez protéger. La clé du tag distingue les majuscules et minuscules. Toute instance dotée de cette clé de balise est protégée quelle que soit la valeur de la balise.

Pour réduire la durée d'exécution de la politique de résiliation personnalisée, vous pouvez augmenter le nombre d'instances par défaut utilisées par la fonction Lambda pour filtrer les instances protégées en mettant à jour la valeur de la variable de code de default_sample_size fonction. La valeur par défaut est 15. Si vous augmentez ledefault_sample_size, vous devrez peut-être augmenter la mémoire allouée à la fonction Lambda, ce qui augmentera le coût de votre fonction Lambda. Pour plus d'informations sur la tarification AWS Lambda , consultez Tarification AWS Lambda.

Quels équilibreurs de charge sont disponibles avec le script de migration ?

Le script propose trois options d'équilibreur de charge.

• (Recommandé) Créez un nouvel Application Load Balancer. Par défaut, le script crée un nouvel Application Load Balancer. Vous pouvez également définir le --lb-type paramètre surALB. Pour plus d'informations sur les équilibreurs de charge d'application, voir Qu'est-ce qu'un équilibreur de charge d'application ? dans le guide de l'utilisateur d'Elastic Load Balancing.

• Si un Application Load Balancer n'est pas une option, créez un Classic Load Balancer en définissant le paramètre --lb-type sur. Classic Si vous sélectionnez cette option, votre Classic Load Balancer existant attaché à votre OpsWorks couche est séparé de votre application. Pour plus d'informations sur les équilibreurs de charge d'application, voir Qu'est-ce qu'un Classic Load Balancer ? dans le guide de l'utilisateur d'Elastic Load Balancing : Classic Load Balancers.

• Vous pouvez associer un équilibreur de charge existant en définissant le --lb-type paramètre surNone.

  Important

  Nous vous recommandons de créer de nouveaux équilibreurs de charge Elastic Load Balancing pour vos couches AWS OpsWorks Stacks. Si vous choisissez d'utiliser un équilibreur de charge Elastic Load Balancing existant, vous devez d'abord vérifier qu'il n'est pas utilisé à d'autres fins et qu'aucune instance n'est attachée. Une fois que l'équilibreur de charge est attaché à la couche, il OpsWorks supprime toutes les instances existantes et configure l'équilibreur de charge pour qu'il gère uniquement les instances de la couche. Bien qu'il soit techniquement possible d'utiliser la console ou l'API Elastic Load Balancing pour modifier la configuration d'un équilibreur de charge après l'avoir attaché à une couche, vous ne devez pas le faire ; les modifications ne seront pas permanentes.

Pour associer votre équilibreur de charge de OpsWorks couche existant à votre groupe Auto Scaling

1. Exécutez le script de migration avec le --lb-type paramètre défini surNone. Lorsque la valeur est définie surNone, le script ne clone ni ne crée d'équilibreur de charge.

2. Une fois que le script a déployé la CloudFormation pile, mettez à jour les groupes Min Max et les Desired capacity valeurs d'Auto Scaling, puis testez votre application.

3. Choisissez Link to the template affiché dans la sortie du script. Si vous avez fermé votre terminal, procédez comme suit pour accéder au modèle.

   1. Ouvrez la console Systems Manager à l'adresse https://console.aws.amazon.com/systems-manager/.

   2. Dans le volet de navigation, choisissez Application Manager.

   3. Choisissez des CloudFormation piles, puis choisissez Bibliothèque de modèles.

   4. Choisissez Owned by me et localisez votre modèle.

4. Dans le CloudFormation modèle, choisissez Modifier dans le menu Actions.

5. Mettez à jour la LabelBalancerNames propriété dans la section des ApplicationAsg ressources du CloudFormation modèle.

   ApplicationAsg:
      DependsOn: CustomTerminationLambdaPermission
      Properties:
      #(other properties in ApplicationAsg to remain unchanged)
         LoadBalancerNames:
           - load-balancer-name 
         HealthCheckType: ELB
                       

6. Si vous souhaitez que la vérification de l'état de vos instances de groupe Auto Scaling utilise également celle de l'équilibreur de charge, supprimez la section ci-dessous HealthCheckType et entrezELB. Si vous n'avez besoin que de bilans de santé EC2, il n'est pas nécessaire de modifier le modèle.

7. Enregistrez vos modifications. L'enregistrement crée une nouvelle version par défaut du modèle. Si c'est la première fois que vous exécutez le script pour la couche et que vous enregistrez des modifications dans la console, la version la plus récente est 2.

8. Dans Actions, sélectionnez Provision stack.

9. Confirmez que vous souhaitez utiliser la version par défaut du modèle. Assurez-vous que l'option Sélectionner une pile existante est sélectionnée et choisissez la CloudFormation pile à mettre à jour.

10. Choisissez Suivant pour chacune des pages suivantes jusqu'à ce que la page Révision et mise à disposition apparaisse. Sur la page Révision et mise à disposition, sélectionnez à la fois Je reconnais que cela AWS CloudFormation peut créer des ressources IAM avec des noms personnalisés et je comprends que les modifications apportées au modèle sélectionné peuvent entraîner la mise AWS CloudFormation à jour ou la suppression de AWS ressources existantes.

11. Sélectionnez Approvisionner une pile.

Si vous devez annuler vos mises à jour, procédez comme suit.

1. Choisissez Actions, puis Provision stack.

2. Choisissez l'une des versions existantes, puis choisissez la version précédente du modèle.

3. Choisissez Sélectionner une pile existante, puis choisissez la CloudFormation pile à mettre à jour.

Les recettes de configuration de livres de recettes personnalisées sont-elles migrées ?

L'exécution de livres de recettes personnalisés n'est pas prise en charge lors d'un événement d'installation. Le script migre les recettes de configuration personnalisées des livres de recettes et crée un runbook Systems Manager Automation pour vous. Cependant, vous devez exécuter les recettes manuellement.

Procédez comme suit pour exécuter vos recettes de configuration.

1. Ouvrez la console Systems Manager à l'adresse https://console.aws.amazon.com/systems-manager/.

2. Dans le volet de navigation, choisissez Application Manager.

3. Dans la section Applications, sélectionnez Applications personnalisées.

4. Choisissez votre application. Le nom de l'application commence parapp-stack-name.

5. Choisissez Resources, puis choisissez le runbook de configuration.

6. Choisissez Execute Automation.

7. Choisissez les ID d'instance pour lesquels vous souhaitez exécuter les recettes de configuration, puis choisissez Execute.

Puis-je exécuter des recettes de déploiement et de dédéploiement sur mes instances nouvellement créées ?

Le script peut créer trois runbooks d'automatisation possibles en fonction de la configuration de votre couche.

• Configuration

• Configuration

• Terminer

Le script peut également créer les paramètres Systems Manager suivants qui contiennent des valeurs d'entrée pour le AWS-ApplyChefRecipes Run Command document.

• Configuration

• Déploiement

• Configuration

• Annulation du déploiement

• Terminer

Lorsqu'un événement de scale-out se produit, le runbook de configuration Automation s'exécute automatiquement. Cela inclut la configuration et le déploiement de recettes de livres de recettes personnalisées à partir de votre OpsWorks couche d'origine. Lorsqu'un événement de scale-in se produit, le runbook Terminate Automation s'exécute automatiquement. Le runbook Terminate Automation contient les recettes d'arrêt de votre OpsWorks couche d'origine.

Si vous souhaitez exécuter des recettes d'annulation ou de configuration manuellement, procédez comme suit.

1. Ouvrez la console Systems Manager à l'adresse https://console.aws.amazon.com/systems-manager/.

2. Dans le volet de navigation, choisissez Application Manager.

3. Dans la section Applications, sélectionnez Applications personnalisées.

4. Choisissez votre application. Le nom de l'application commence parapp-stack-name-first-six-characters-stack-id. Le gestionnaire d'applications ouvre l'onglet Vue d'ensemble.

5. Choisissez Resources, puis choisissez le runbook de configuration de l'automatisation.

6. Choisissez Execute Automation.

7. Pour le paramètre d'entrée applyChefRecipesPropertiesParameter Automation Runbook, référencez le paramètre Systems Manager correct. Le nom du paramètre Systems Manager suit le format/ApplyChefRecipes-Preset/OpsWorks-stack-name-OpsWorks-layer-name-first-six-characters-stack-id/event, dans lequel se trouve la valeur de l'événement ConfigureDeploy, ou Undeploy en fonction des recettes que vous souhaitez exécuter.

8. Choisissez les ID d'instance sur lesquels vous souhaitez exécuter les recettes, puis choisissez Execute.

Puis-je modifier les sous-réseaux couverts par mon groupe Auto Scaling ?

Par défaut, le groupe Auto Scaling couvre tous les sous-réseaux de votre stack OpsWorks VPC. Pour mettre à jour les sous-réseaux à couvrir, procédez comme suit.

1. Choisissez Link to the template affiché dans la sortie du script. Si vous avez fermé votre terminal, procédez comme suit pour accéder au modèle.

   1. Ouvrez la console Systems Manager à l'adresse https://console.aws.amazon.com/systems-manager/.

   2. Dans le volet de navigation, choisissez Application Manager.

   3. Choisissez des CloudFormation piles, puis choisissez Bibliothèque de modèles.

   4. Choisissez Owned by me et localisez votre modèle.

2. Dans Actions, sélectionnez Provision stack.

3. Confirmez que vous souhaitez utiliser le modèle par défaut. Choisissez Sélectionner une pile existante, puis choisissez la CloudFormation pile à mettre à jour.

   Note

   Si vous avez exécuté le script avec le --provision-application paramètre défini surFALSE, vous devez créer une nouvelle CloudFormation pile.

4. Pour le SubnetIDs paramètre, fournissez une liste séparée par des virgules des identifiants de sous-réseau que vous souhaitez étendre à votre groupe Auto Scaling.

5. Choisissez Next jusqu'à ce que la page Révision et approvisionnement apparaisse.

6. Sur la page Révision et mise à disposition, choisissez Je reconnais que des ressources IAM AWS CloudFormation peuvent être créées avec des noms personnalisés. Je comprends que les modifications apportées au modèle sélectionné peuvent entraîner la mise AWS CloudFormation à jour ou la suppression de AWS ressources existantes.

7. Sélectionnez Approvisionner une pile.