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 EC2ConfigService à l'aide du guide Amazon EC2 Microsoft Windows pour obtenir des instructions. Vous devez configurer une instance Windows EC2ConfigService 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 peut être consulté dans son intégralité à l'adresse suivante URL :

Cet exemple montre comment :

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 :

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.

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 le handle des conditions d'attente en base64. URL

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 la section Connexion à votre instance Windows RDP à l'aide du guide de EC2 l'utilisateur Amazon.

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 :

Consultez ces EC2 guides pour plus de journaux :