Bootstrap Windows Stacks AWS CloudFormation - AWS CloudFormation
Exemple d'amorçage d'une pile WindowsComment gérer les services WindowsComment résoudre les problèmes de création de la pile

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.

Bootstrap Windows Stacks 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 comptez créer votre propre image Windows à utiliser avec CloudFormation, consultez les informations de la section Configuration d'une instance Windows à l'aide d'EC2 ConfigService dans le guide Amazon EC2 Microsoft Windows pour obtenir des instructions. Vous devez configurer une instance Windows avec EC2 ConfigService pour qu'elle fonctionne avec les outils de AWS CloudFormation démarrage.

Exemple d'amorçage d'une pile Windows

À des fins d'illustration, nous allons examiner un modèle de SharePoint serveur AWS CloudFormation à instance unique.

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

Cet exemple montre comment :

  • Créez un IAM utilisateur 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 du serveur.

  • Utilisez a WaitCondition pour vous assurer que les ressources sont prêtes.

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

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

La AWS::CloudFormation::Init section s'appelle SharePointFoundation « » et commence par 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 l'installation SharePoint sur l'instance du serveur.

Important

Dans la mesure où les chemins sous Windows utilisent une barre oblique inverse (« \ »), vous devez toujours vous rappeler d'éviter correctement toutes les barres obliques inverses en ajoutant une autre barre oblique inverse chaque fois que vous faites référence à un chemin 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. Ainsi, nous pouvons nous assurer que le package d'installation est d'abord extrait, que tous les prérequis sont ensuite installés et que l'installation de SharePoint est enfin démarré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 aveccfn-signal. Les WaitConditionHandleet associés WaitConditionsont déclarés ensuite dans le modèle :

"SharePointFoundationWaitHandle" : {
   "Type" : "AWS::CloudFormation::WaitConditionHandle"
},

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

Comme l'exécution de toutes les étapes et l'installation SharePoint peuvent prendre un certain temps, mais pas une heure entière, le délai d' WaitCondition attente est d'une heure (3 600 secondes) avant d'expirer.

Si tout se passe bien, une adresse IP élastique est utilisée pour donner accès à l' SharePointinstance :

"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 la création de la pile terminée, l'adresse IP fournie par EIP sera affichée dans l'onglet Sorties de la AWS CloudFormation console. 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, choisissez Afficher les options avancées lors de la création de votre stack avec la AWS CloudFormation console, puis sélectionnez le sélecteur Non à côté de Rollback 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 :