Amorçage de piles Windows AWS CloudFormation - AWS CloudFormation

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.

Amorçage de piles Windows AWS CloudFormation

Cette rubrique décrit comment amorcer une pile Windows et comment résoudre les problèmes de création de la pile. Si vous voulez créer votre propre image Windows à utiliser avec CloudFormation, consultez Configuration d'une instance Windows à l'aide du service EC2Config dans le Guide Amazon EC2 Microsoft Windows pour obtenir des instructions. Vous devez configurer une instance Windows avec EC2ConfigService pour qu'elle fonctionne avec les outils d'amorçage AWS CloudFormation.

Exemple d'amorçage d'une pile Windows

À titre d'illustration, nous étudierons un modèle de serveur SharePoint à une instance AWS CloudFormation.

Le modèle est consultable dans son intégralité à partir de l’URL suivante :

Cet exemple montre comment :

  • Créez un utilisateur IAM et un groupe de sécurité pour accéder à l'instance.

  • Configurez des fichiers d'initialisation : cfn-credentials, cfn-hup.conf et cfn-auto-reloader.conf.

  • Téléchargez et installez un package tel que Sharepoint Foundation 2010 sur l'instance de serveur.

  • Utilisez une condition d'attente pour s'assurer que les ressources sont prêtes.

  • Récupérer une adresse IP pour l'instance avec Amazon Elastic IP (EIP)

Le script d'assistant AWS CloudFormation cfn-init est utilisé pour effectuer chacune de ces actions, en fonction des informations de la ressource AWS::CloudFormation::Init dans le modèle Windows Single Server Sharepoint Foundation.

La section AWS::CloudFormation::Init est nommée « SharePointFoundation » et commence avec une déclaration standard :

"SharePointFoundation": { "Type" : "AWS::EC2::Instance", "Metadata" : { "AWS::CloudFormation::Init" : { "config" : {

Après cela, la section fichiers de AWS::CloudFormation::Init est déclarée :

"files" : { "c:\\cfn\\cfn-hup.conf" : { "content" : { "Fn::Join" : ["", [ "[main]\n", "stack=", { "Ref" : "AWS::StackName" }, "\n", "region=", { "Ref" : "AWS::Region" }, "\n" ]]} }, "c:\\cfn\\hooks.d\\cfn-auto-reloader.conf" : { "content": { "Fn::Join" : ["", [ "[cfn-auto-reloader-hook]\n", "triggers=post.update\n", "path=Resources.SharePointFoundation.Metadata.AWS::CloudFormation::Init\n", "action=cfn-init.exe -v -s ", { "Ref" : "AWS::StackName" }, " -r SharePointFoundation", " --region ", { "Ref" : "AWS::Region" }, "\n" ]]} }, "C:\\SharePoint\\SharePointFoundation2010.exe" : { "source" : "http://d3adzpja92utk0.cloudfront.net/SharePointFoundation.exe" } },

Trois fichiers sont créés ici et placés dans le répertoire C:\cfn au niveau de l'instance de serveur. Ils sont :

  • cfn-hup.conf, le fichier de configuration pour cfn-hup.

  • cfn-auto-reloader.conf, le fichier de configuration pour le hook utilisé par cfn-hup afin de lancer une mise à jour (appel cfn-init) lorsque les métadonnées d'AWS::CloudFormation::Init changent.

Il y a également un fichier qui est téléchargé vers le serveur : SharePointFoundation.exe. Ce fichier est utilisé pour installer SharePoint au niveau de l'instance de serveur.

Important

Dans la mesure où les chemins Windows utilisent une barre oblique inverse (« \ »), n'oubliez pas d'ajouter une autre barre oblique inverse chaque fois que vous faites référence à un chemin d'accès Windows dans le modèle AWS CloudFormation.

Vient ensuite la section commands, qui désigne des commandes cmd.exe.

"commands" : { "1-extract" : { "command" : "C:\\SharePoint\\SharePointFoundation2010.exe /extract:C:\\SharePoint\\SPF2010 /quiet /log:C:\\SharePoint\\SharePointFoundation2010-extract.log" }, "2-prereq" : { "command" : "C:\\SharePoint\\SPF2010\\PrerequisiteInstaller.exe /unattended" }, "3-install" : { "command" : "C:\\SharePoint\\SPF2010\\setup.exe /config C:\\SharePoint\\SPF2010\\Files\\SetupSilent\\config.xml" }

Étant donné que les commandes de l'instance sont traitées par ordre alphabétique en fonction de leur nom, un nombre indiquant l'ordre d'exécution souhaité est ajouté à chacune d'elles. Nous pouvons ainsi garantir que le package d'installation est extrait en premier, puis que toutes les conditions préalables sont installées et, enfin, que l'installation de SharePoint est lancée.

Apparaît ensuite la section Properties :

"Properties": { "InstanceType" : { "Ref" : "InstanceType" }, "ImageId" : { "Fn::FindInMap" : [ "AWSRegionArch2AMI", { "Ref" : "AWS::Region" }, { "Fn::FindInMap" : [ "AWSInstanceType2Arch", { "Ref" : "InstanceType" }, "Arch" ] } ] }, "SecurityGroups" : [ {"Ref" : "SharePointFoundationSecurityGroup"} ], "KeyName" : { "Ref" : "KeyPairName" }, "UserData" : { "Fn::Base64" : { "Fn::Join" : ["", [ "<script>\n", "cfn-init.exe -v -s ", { "Ref" : "AWS::StackName" }, " -r SharePointFoundation", " --region ", { "Ref" : "AWS::Region" }, "\n", "cfn-signal.exe -e %ERRORLEVEL% ", { "Fn::Base64" : { "Ref" : "SharePointFoundationWaitHandle" }}, "\n", "</script>" ]]}} }

Dans cette section, la propriété UserData contient un script cmd.exe qui sera exécuté par cfn-init, entouré de balises <script>. Au lieu de cela, vous pouvez ici utiliser un script Windows Powershell en entourant le script de balises <powershell>. Pour les piles Windows, vous devez encoder à nouveau l'URL du descripteur de condition d'attente au format base64.

SharePointFoundationWaitHandle est référencé ici et fonctionne avec cfn-signal. La valeur WaitConditionHandle et la condition WaitCondition associée sont ensuite déclarées dans le modèle :

"SharePointFoundationWaitHandle" : { "Type" : "AWS::CloudFormation::WaitConditionHandle" }, "SharePointFoundationWaitCondition" : { "Type" : "AWS::CloudFormation::WaitCondition", "DependsOn" : "SharePointFoundation", "Properties" : { "Handle" : {"Ref" : "SharePointFoundationWaitHandle"}, "Timeout" : "3600" } }

Dans la mesure où l'exécution de toutes les étapes et l'installation de SharePoint peuvent prendre un certain temps, mais moins d'une heure, la condition d'attente attend une heure (3600 secondes) avant d'expirer.

Si tout va bien, une adresse IP Elastic est utilisée pour fournir un accès à l'instance SharePoint :

"Outputs" : { "SharePointFoundationURL" : { "Value" : { "Fn::Join" : ["", ["http://", { "Ref" : "SharePointFoundationEIP" } ]] }, "Description" : "SharePoint Team Site URL. Please retrieve Administrator password of the instance and use it to access the URL" }

Une fois que la création de la pile est terminée, l'adresse IP fournie par EIP s'affiche dans l'onglet Sorties de la console AWS CloudFormation. Toutefois, avant de pouvoir accéder à l'instance, vous devez récupérer le mot de passe administrateur temporaire généré pour l'instance. Pour plus d'informations, consultez Connexion à votre instance Windows à l'aide de RDP dans le Amazon EC2 Guide de l'utilisateur pour les instances Windows.

Comment gérer les services Windows

Vous gérez les services Windows de la même manière que les services Linux, sauf que vous utilisez une clé windows au lieu de sysvinit. L'exemple suivant démarre le service cfn-hup, le définit sur Automatic et le redémarre si cfn-init modifie les fichiers de configuration c:\cfn\cfn-hup.conf ou c:\cfn\hooks.d\cfn-auto-reloader.conf.

"services" : { "windows" : { "cfn-hup" : { "enabled" : "true", "ensureRunning" : "true", "files" : ["c:\\cfn\\cfn-hup.conf", "c:\\cfn\\hooks.d\\cfn-auto-reloader.conf"] } } }

Vous pouvez gérer les autres services Windows de la même manière en utilisant le nom (et non pas le nom complet) pour référencer le service.

Comment résoudre les problèmes de création de la pile

Si votre pile échoue lors de la création, le comportement par défaut consiste à retourner en arrière. Bien que ce comportement par défaut soit généralement approprié, car il permet d'éviter des frais inutiles, il complique le débogage du problème qui est à l'origine de l'échec de création de la pile.

Pour désactiver ce comportement, sélectionnez Show Advanced Options (Afficher les options avancées) lors de la création de la pile avec la console AWS CloudFormation, puis cliquez sur le sélecteur No (Non) à côté de l'option Rollback on failure (Restauration en cas d'échec). Cette approche vous permet de vous connecter à l'instance et de consulter les fichiers journaux pour identifier les problèmes rencontrés lors de l'exécution des scripts de démarrage.

Voici les principaux journaux que vous devez examiner :

  • Le journal de configuration EC2 à l'adresse C:\Program Files\Amazon\Ec2ConfigService\Logs\Ec2ConfigLog.txt

  • Journal cfn-init de chemin : C:\cfn\log\cfn-init.log

Voir ces guides EC2 pour plus de journaux :