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 Utiliser le EC2Config service pour effectuer des tâches lors du lancement de l'EC2ancienne instance du système d'exploitation Windows dans le guide de l'EC2utilisateur Amazon pour obtenir des instructions. Vous devez configurer une instance Windows avec un EC2Config service 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 est nommée SharePointFoundation et commence par une déclaration standard :

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

Ensuite, la files section 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 commands section, qui sont cmd.exe les commandes.

"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.

Vient ensuite la Properties section :

"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 UserData propriété contient un cmd.exe script qui sera exécuté parcfn-init, entouré de <script> balises. Vous pouvez plutôt utiliser un script Windows Powershell ici en l'entourant de <powershell> balises. 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 WaitConditionHandle et associés WaitCondition sont 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'WaitConditionattente 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 Connect to your Windows instance RDP in the Amazon EC2 User Guide.

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 cfn-hup service, le définit sur Automatique et le redémarre en cas de cfn-init modification des fichiers c:\cfn\cfn-hup.conf ou de c:\cfn\hooks.d\cfn-auto-reloader.conf configuration.

"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. Cela vous permettra de vous connecter à votre instance et de consulter les fichiers journaux afin d'identifier les problèmes rencontrés lors de l'exécution de vos scripts de démarrage.

Voici les principaux journaux que vous devez examiner :

Consultez ces EC2 guides pour plus de journaux :