Il s’agit du nouveau *Guide de référence des modèles CloudFormation *. Veuillez mettre à jour vos favoris et vos liens. Pour obtenir de l'aide pour démarrer CloudFormation, consultez le [guide de AWS CloudFormation l'utilisateur](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html). 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. # `AWS::CloudFormation::Init` Utilisez le `AWS::CloudFormation::Init` type pour inclure des métadonnées sur une EC2 instance Amazon pour le script d'`cfn-init`assistance. Si votre modèle appelle le script `cfn-init`, ce dernier recherche les métadonnées de ressource issues de la clé de métadonnées `AWS::CloudFormation::Init`. Pour de plus amples informations, veuillez consulter [cfn-init](cfn-init.md). `cfn-init` prend en charge tous les types de métadonnées pour les systèmes Linux. Il prend en charge les types de métadonnées pour Windows avec les conditions décrites dans les sections suivantes. ## Syntaxe La configuration est divisée en sections. L'extrait de modèle suivant montre comment vous pouvez associer des métadonnées `cfn-init` à une ressource d' EC2 instance dans le modèle. Les métadonnées sont organisées en clés de configuration, que vous pouvez regrouper en jeux de configuration. Vous pouvez spécifier un configset lorsque vous appelez `cfn-init` dans votre modèle. Si vous ne spécifiez pas de configset, `cfn-init` recherche une clé de configuration unique nommée `config`. **Note** Le script d’assistance `cfn-init` traite les sections de configuration dans l’ordre suivant : packages, groupes, utilisateurs, sources, fichiers, commandes, puis services. Si vous avez besoin d'un ordre différent, séparez vos sections en clés de configuration distinctes, puis utilisez un jeu de configuration qui spécifie l'ordre dans lequel ces clés doivent être traitées. ### JSON ``` "Resources": { "MyInstance": { "Type": "AWS::EC2::Instance", "Metadata" : { "AWS::CloudFormation::Init" : { "config" : { "packages" : { : }, "groups" : { : }, "users" : { : }, "sources" : { : }, "files" : { : }, "commands" : { : }, "services" : { : } } } }, "Properties": { : } } } ``` ### YAML ``` Resources: MyInstance: Type: AWS::EC2::Instance Metadata: AWS::CloudFormation::Init: config: packages: : groups: : users: : sources: : files: : commands: : services: : Properties: : ``` **Note** Les sections suivantes contiennent des exemples de scripts écrits dans des langages de script shell de type Unix, comme Bash. Pour créer des scripts pour la PowerShell place, assurez-vous de bien connaître le PowerShell langage. PowerShell la syntaxe est différente de celle des shells de type Unix, vous devez donc vous familiariser avec la PowerShell façon de faire les choses. ## Jeux de configuration Si vous souhaitez créer plusieurs clés de configuration et faire en sorte que `cfn-init` les traite dans un ordre précis, créez un configset contenant les clés de configuration dans l’ordre souhaité. ### Jeu de configuration unique L'extrait d'exemple de modèle suivant crée les jeux de configuration `ascending` et `descending`, qui incluent chacun deux clés de configuration. #### JSON ``` "AWS::CloudFormation::Init" : { "configSets" : { "ascending" : [ "config1" , "config2" ], "descending" : [ "config2" , "config1" ] }, "config1" : { "commands" : { "test" : { "command" : "echo \"$CFNTEST\" > test.txt", "env" : { "CFNTEST" : "I come from config1." }, "cwd" : "~" } } }, "config2" : { "commands" : { "test" : { "command" : "echo \"$CFNTEST\" > test.txt", "env" : { "CFNTEST" : "I come from config2" }, "cwd" : "~" } } } } ``` #### YAML ``` AWS::CloudFormation::Init: configSets: ascending: - "config1" - "config2" descending: - "config2" - "config1" config1: commands: test: command: "echo \"$CFNTEST\" > test.txt" env: CFNTEST: "I come from config1." cwd: "~" config2: commands: test: command: "echo \"$CFNTEST\" > test.txt" env: CFNTEST: "I come from config2" cwd: "~" ``` #### Appels à `cfn-init` associés Les exemples suivants d’appels à `cfn-init` se réfèrent aux configsets présentés précédemment. Les exemples d’appels sont abrégés pour plus de clarté. Consultez [cfn-init](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/cfn-init.html) pour la syntaxe complète. + Si un appel à `cfn-init` spécifie le configset `ascending` : ``` cfn-init -c ascending ``` Le script traite `config1`, puis traite `config2`, et le fichier `test.txt` contient alors le texte `I come from config2`. + Si un appel à `cfn-init` spécifie le configset `descending` : ``` cfn-init -c descending ``` Le script traite `config2`, puis traite `config1`, et le fichier `test.txt` contient alors le texte `I come from config1`. ### Plusieurs jeux de configuration Vous pouvez créer plusieurs configsets et appeler une série d’entre eux à l’aide de votre script `cfn-init`. Chaque jeu de configuration peut contenir une liste de clés de configuration ou des références à d'autres jeux de configuration. Par exemple, l'extrait de modèle suivant crée trois jeux de configuration. Le premier, `test1`, contient une seule clé de configuration nommée `1`. Le second, `test2`, contient une référence au jeu de configuration `test1` et une clé de configuration nommée `2`. Le troisième, default, contient une référence au jeu de configuration `test2`. #### JSON ``` "AWS::CloudFormation::Init" : { "configSets" : { "test1" : [ "1" ], "test2" : [ { "ConfigSet" : "test1" }, "2" ], "default" : [ { "ConfigSet" : "test2" } ] }, "1" : { "commands" : { "test" : { "command" : "echo \"$MAGIC\" > test.txt", "env" : { "MAGIC" : "I come from the environment!" }, "cwd" : "~" } } }, "2" : { "commands" : { "test" : { "command" : "echo \"$MAGIC\" >> test.txt", "env" : { "MAGIC" : "I am test 2!" }, "cwd" : "~" } } } } ``` #### YAML ``` AWS::CloudFormation::Init: 1: commands: test: command: "echo \"$MAGIC\" > test.txt" env: MAGIC: "I come from the environment!" cwd: "~" 2: commands: test: command: "echo \"$MAGIC\" >> test.txt" env: MAGIC: "I am test 2!" cwd: "~" configSets: test1: - "1" test2: - ConfigSet: "test1" - "2" default: - ConfigSet: "test2" ``` #### Appels à `cfn-init` associés Les appels à `cfn-init` suivants se réfèrent aux `configSets` déclarés dans l’extrait de modèle précédent. Les exemples d’appels sont abrégés pour plus de clarté. Consultez [cfn-init](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/cfn-init.html) pour la syntaxe complète. + Si vous spécifiez `test1` uniquement : ``` cfn-init -c test1 ``` `cfn-init` traite uniquement la clé de configuration `1`. + Si vous spécifiez `test2` uniquement : ``` cfn-init -c test2 ``` `cfn-init` traite la clé de configuration `1`, puis la clé de configuration `2`. + Si vous spécifiez le jeu de configuration `default` (ou aucun jeu de configuration) : ``` cfn-init -c default ``` vous obtenez le même comportement que si vous spécifiez le jeu de configuration `test2`. ## Commandes Vous pouvez utiliser la touche commandes pour exécuter des commandes sur l' EC2 instance. Les commandes sont traitées par ordre alphabétique en fonction de leur nom. | Clé | Obligatoire | Description | | --- | --- | --- | | `command` | Obligatoire | Soit un tableau, soit une chaîne spécifiant la commande à exécuter. Si vous utilisez un tableau, vous n'avez pas besoin de caractères d'espacement ou d'inclure des paramètres de commande entre guillemets. N'utilisez pas le tableau pour spécifier plusieurs commandes. | | `env` | Facultatif | Définit des variables d'environnement pour la commande. Cette propriété remplace, plutôt que d'ajouter, l'environnement existant. | | `cwd` | Facultatif | Répertoire de travail. | | `test` | Facultatif | Commande de test permettant de déterminer si `cfn-init` exécute les commandes spécifiées dans la clé de commande. Si le test réussit, `cfn-init` exécute les commandes. Le script `cfn-init` exécute le test dans un interpréteur de commandes, tel que Bash ou `cmd.exe`. La réussite du test dépend du code de sortie que l'interpréteur renvoie.
Pour Linux, la commande de test doit retourner le code de sortie `0` pour que le test réussisse. Pour Windows, la commande de test doit renvoyer la valeur %ERRORLEVEL% `0`. | | `ignoreErrors` | Facultatif | Valeur booléenne déterminant si `cfn-init` continue de s’exécuter lorsque la commande contenue dans la clé de commande échoue (renvoie une valeur non nulle). Définissez sur `true` si vous souhaitez que `cfn-init` continue de s’exécuter même en cas d’échec de la commande. Définissez sur `false` si vous souhaitez que `cfn-init` arrête son exécution en cas d’échec de la commande. La valeur par défaut est `false`. | | `waitAfterCompletion` | Facultatif | Pour les systèmes Windows uniquement. Spécifie la durée (en secondes) à attendre après la fin d'une commande si cette dernière entraîne un redémarrage. La valeur par défaut est 60 secondes. Une valeur « forever » indique à `cfn-init` de quitter, puis de reprendre uniquement lorsque le redémarrage est terminé. Définissez cette valeur sur `0` si vous ne souhaitez pas attendre chaque commande. | ### Exemple L'extrait de l'exemple suivant appelle la commande echo si le fichier `~/test.txt` n'existe pas. #### JSON ``` "commands" : { "test" : { "command" : "echo \"$MAGIC\" > test.txt", "env" : { "MAGIC" : "I come from the environment!" }, "cwd" : "~", "test" : "test ! -e ~/test.txt", "ignoreErrors" : "false" }, "test2" : { "command" : "echo \"$MAGIC2\" > test2.txt", "env" : { "MAGIC2" : "I come from the environment!" }, "cwd" : "~", "test" : "test ! -e ~/test2.txt", "ignoreErrors" : "false" } } ``` #### YAML ``` commands: test: command: "echo \"$MAGIC\" > test.txt" env: MAGIC: "I come from the environment!" cwd: "~" test: "test ! -e ~/test.txt" ignoreErrors: "false" test2: command: "echo \"$MAGIC2\" > test2.txt" env: MAGIC2: "I come from the environment!" cwd: "~" test: "test ! -e ~/test2.txt" ignoreErrors: "false" ``` ## Fichiers Vous pouvez utiliser la `files` clé pour créer des fichiers sur l' EC2 instance. Le contenu peut être intégré dans le modèle ou extrait à partir d'une URL. Les fichiers sont écrits sur disque par ordre lexicographique. Le tableau suivant répertorie les clés prises en charge. | Clé | Description | | --- | --- | | `content` | Chaîne ou objet JSON avec le bon format. Si vous utilisez un objet JSON pour votre contenu, le format JSON sera écrit dans un fichier sur le disque. Toute fonction intrinsèque, telle que `Fn::GetAtt` ou `Ref`, est évaluée avant l'écriture de l'objet JSON sur le disque. Lorsque vous créez un lien symbolique, spécifiez la cible du lien en tant que contenu. Si vous avez créé un lien symbolique, le script d'assistant modifie les autorisations du fichier cible. Actuellement, vous ne pouvez pas créer un lien symbolique sans modifier les autorisations du fichier cible. | | `source` | Une URL à partir de laquelle charger le fichier. Cette option ne peut pas être spécifiée avec la clé de contenu. | | `encoding` | Le format d'encodage. Utilisé uniquement si le contenu est une chaîne. L'encodage n'est pas appliqué si vous utilisez une source.
Valeurs valides : `plain` \| `base64` | | `group` | Nom du groupe auquel appartient ce fichier. Non pris en charge pour les systèmes Windows. | | `owner` | Nom de l'utilisateur auquel appartient ce fichier. Non pris en charge pour les systèmes Windows. | | `mode` | Valeur octale à six chiffres qui représente le mode de ce fichier. Non pris en charge pour les systèmes Windows. Utilisez les trois premiers chiffres pour les liens symboliques et les trois derniers chiffres pour définir les autorisations. Pour créer un lien symbolique, spécifiez **120{{xxx}}**, où `xxx` définit les autorisations du fichier cible. Pour définir des autorisations pour un fichier, utilisez les trois derniers chiffres, tels que **000644**. | | `authentication` | Nom d'une méthode d'authentification à utiliser. Celle-ci remplace toute authentification par défaut. Vous pouvez utiliser cette propriété pour sélectionner une méthode d'authentification que vous définissez avec la ressource [`AWS::CloudFormation::Authentication`](aws-resource-authentication.md). | | `context` | Spécifie un contexte pour les fichiers à traiter comme [modèles Mustache](https://mustache.github.io/mustache.5.html). Pour utiliser cette clé, vous devez avoir installé `aws-cfn-bootstrap` en version 1.3–11 ou ultérieure, ainsi que [https://github.com/defunkt/pystache](https://github.com/defunkt/pystache). | ### Exemples L’exemple d’extrait suivant crée un fichier nommé `setup.mysql` dans le cadre d’une installation plus large. #### JSON ``` "files" : { "/tmp/setup.mysql" : { "content" : { "Fn::Join" : ["", [ "CREATE DATABASE ", { "Ref" : "DBName" }, ";\n", "CREATE USER '", { "Ref" : "DBUsername" }, "'@'localhost' IDENTIFIED BY '", { "Ref" : "DBPassword" }, "';\n", "GRANT ALL ON ", { "Ref" : "DBName" }, ".* TO '", { "Ref" : "DBUsername" }, "'@'localhost';\n", "FLUSH PRIVILEGES;\n" ]]}, "mode" : "000644", "owner" : "root", "group" : "root" } } ``` #### YAML ``` files: /tmp/setup.mysql: content: !Sub | CREATE DATABASE ${DBName}; CREATE USER '${DBUsername}'@'localhost' IDENTIFIED BY '${DBPassword}'; GRANT ALL ON ${DBName}.* TO '${DBUsername}'@'localhost'; FLUSH PRIVILEGES; mode: "000644" owner: "root" group: "root" ``` Le modèle complet est disponible à l'adresse : [https://s3.amazonaws.com/cloudformation-templates-us-east-1/Drupal\_Single\_Instance.template](https://s3.amazonaws.com/cloudformation-templates-us-east-1/Drupal_Single_Instance.template). L'exemple d'extrait suivant crée un lien symbolique `/tmp/myfile2.txt` qui renvoie vers le fichier `/tmp/myfile1.txt`. Les autorisations du fichier cible `/tmp/myfile1.txt` sont définies par la valeur de mode `644`. #### JSON ``` "files" : { "/tmp/myfile2.txt" : { "content" : "/tmp/myfile1.txt", "mode" : "120644" } } ``` #### YAML ``` files: /tmp/myfile2.txt: content: "/tmp/myfile1.txt" mode: "120644" ``` Les modèles mustache sont utilisés principalement pour créer des fichiers de configuration. Par exemple, vous pouvez stocker un fichier de configuration dans un compartiment S3 et interpoler les références GetAtts à partir du modèle, au lieu de l'utiliser. `Fn::Join` L’extrait d’exemple suivant génère `Content for test9` vers `/tmp/test9.txt`. #### JSON ``` "files" : { "/tmp/test9.txt" : { "content" : "Content for {{name}}", "context" : { "name" : "test9" } } } ``` #### YAML ``` files: /tmp/test9.txt: content: "Content for {{name}}" context: name: "test9" ``` Lorsque vous travaillez avec des modèles mustache, notez les éléments suivants : + La clé de contexte doit être présente pour les fichiers à traiter. + La clé de contexte doit être un mappage clé-valeur, mais elle peut être imbriquée. + Vous pouvez traiter les fichiers avec du contenu intégré avec la clé content et les fichiers à distance avec la clé source. + La prise en charge de Mustache dépend de la version pystache. La version 0.5.2 prend en charge la [spécification Mustache 1.1.2](https://github.com/mustache/spec/tree/v1.1.2). ## Groupes Vous pouvez utiliser la touche de groupe pour créer des Linux/UNIX groupes et pour attribuer des groupes IDs. La clé groups n'est pas prise en charge par les systèmes Windows. Pour créer un groupe, ajoutez une nouvelle paire clé-valeur qui mappe un nouveau nom de groupe à un ID de groupe facultatif. La clé des groupes peut contenir un ou plusieurs noms de groupe. Le tableau suivant répertorie les clés disponibles. | Clé | Description | | --- | --- | | `gid` | Numéro d'identification d'un groupe.
Si un ID de groupe est spécifié et que le nom du groupe existe déjà, la création du groupe échoue. Si un autre groupe contient l'ID de groupe spécifié, le système d'exploitation peut refuser la création du groupe.
Exemple : `{ "gid" : "23" }` | ### Exemple d'extrait L'extrait suivant spécifie un groupe nommé `groupOne` sans attribuer d'ID de groupe, et un groupe nommé `groupTwo` qui a spécifié `45` comme valeur d'ID de groupe. #### JSON ``` "groups" : { "groupOne" : {}, "groupTwo" : { "gid" : "45" } } ``` #### YAML ``` groups: groupOne: {} groupTwo: gid: "45" ``` ## Forfaits Vous pouvez utiliser la clé packages pour télécharger et installer des applications et des composants prépackagés. Sur les systèmes Windows, la clé packages prend uniquement en charge le programme d'installation MSI. ### Formats de packages pris en charge Le script `cfn-init` prend actuellement en charge les formats de packages suivants : apt, msi, python, rpm, rubygems, yum, Zypper. Les packages sont traités dans l'ordre suivant : rpmyum/apt/zypper, puis rubygems et python. Il n'existe pas d'ordre établi entre les packages rubygems et python, et les packages inclus dans chaque gestionnaire de package n'ont aucune garantie d'être installés selon un certain ordre. ### Spécification des versions Au sein de chaque gestionnaire de package, chaque package est spécifié sous la forme d'un nom de package et d'une liste de versions. La version peut être une chaîne, une liste de versions, ou une chaîne ou une liste vide. Une chaîne ou une liste vide indique que vous souhaitez la dernière version. Pour le gestionnaire rpm, la version est spécifiée sous la forme d'un chemin d'accès à un fichier sur disque ou d'une URL. Si vous spécifiez une version d’un package, `cfn-init` tentera d’installer cette version même si une version plus récente est déjà présente sur l’instance. Certains gestionnaires de package prennent en charge plusieurs versions, mais pas tous. Vérifiez la documentation de votre gestionnaire de package pour plus d'informations. Si vous ne spécifiez pas de version et qu’une version du package est déjà installée, le script `cfn-init` n’installera pas de nouvelle version ; il suppose que vous souhaitez conserver et utiliser la version existante. ### Exemples d'extraits #### RPM, yum, Rubygems et Zypper L'extrait suivant spécifie une URL de version pour rpm, demande les dernières versions à yum et Zypper et la version 0.10.2 de chef à rubygems : ##### JSON ``` "rpm" : { "epel" : "http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm" }, "yum" : { "httpd" : [], "php" : [], "wordpress" : [] }, "rubygems" : { "chef" : [ "0.10.2" ] }, "zypper" : { "git" : [] } ``` ##### YAML ``` rpm: epel: "http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm" yum: httpd: [] php: [] wordpress: [] rubygems: chef: - "0.10.2" zypper: git: [] ``` #### Package MSI L'extrait suivant spécifie une URL pour un package MSI : ##### JSON ``` "msi" : { "awscli" : "https://s3.amazonaws.com/aws-cli/AWSCLI64.msi" } ``` ##### YAML ``` msi: awscli: "https://s3.amazonaws.com/aws-cli/AWSCLI64.msi" ``` ## Services Vous pouvez utiliser la clé services pour définir les services qui doivent être activés ou désactivés lors du lancement de l'instance. Les systèmes Amazon Linux 2 et versions ultérieures exécutant `aws-cfn-bootstrap` en version 2.0-29\+ prennent en charge cette clé via systemd. Les autres systèmes Linux prennent en charge cette clé via sysvinit (par défaut) ou systemd (en ajoutant les configurations nécessaires ci-dessous). Les systèmes Windows prennent en charge cette clé via le gestionnaire de services Windows. La clé services permet également de définir des dépendances sur les sources, les packages et les fichiers. Ainsi, si un redémarrage est nécessaire en raison de l’installation de fichiers, `cfn-init` se charge d’effectuer le redémarrage du service. Par exemple, si vous téléchargez le package Apache HTTP Server, son installation lance automatiquement Apache HTTP Server pendant le processus de création de la pile. Toutefois, si la configuration Apache HTTP Server est mise à jour ultérieurement lors de la création de la pile, la mise à jour ne prendra effet, sauf si le serveur Apache est redémarré. Vous pouvez utiliser la clé services pour vous assurer que le service Apache HTTP est redémarré. Le tableau suivant répertorie les clés prises en charge. | Clé | Description | | --- | --- | | `ensureRunning` | Définissez la valeur sur true pour garantir que le service est en cours d’exécution après la fin de `cfn-init`.
Définissez la valeur sur false pour garantir que le service n’est pas en cours d’exécution après la fin de `cfn-init`.
Ignorez cette clé pour n'apporter aucune modification à l'état du service. | | `enabled` | Définissez la valeur true pour garantir le démarrage automatique du service en cas de redémarrage.
Définissez la valeur false pour garantir le non-démarrage automatique du service en cas de redémarrage.
Ignorez cette clé pour n'apporter aucune modification à cette propriété. | | `files` | Liste de fichiers. Si `cfn-init` modifie un fichier directement via le bloc de fichiers, ce service sera redémarré. | | sources | Liste de répertoires. Si `cfn-init` développe une archive dans l’un de ces répertoires, ce service sera redémarré. | | packages | Mappage du gestionnaire de package avec la liste des noms de package. Si `cfn-init` installe ou met à jour l’un de ces packages, ce service sera redémarré. | | commands | Liste de noms de commandes. Si `cfn-init` exécute la commande spécifiée, ce service sera redémarré. | ### Exemples #### Linux L'extrait Linux suivant configure les services comme suit : + Le service nginx sera redémarré si `/etc/nginx/nginx.conf` ou `/var/www/html` sont modifiés par `cfn-init`. + Le service php-fastcgi sera redémarré si `cfn-init` installe ou met à jour php ou spawn-fcgi à l’aide de yum. + Le service sendmail sera arrêté et désactivé à l'aide de systemd. ##### JSON ``` "services" : { "sysvinit" : { "nginx" : { "enabled" : "true", "ensureRunning" : "true", "files" : ["/etc/nginx/nginx.conf"], "sources" : ["/var/www/html"] }, "php-fastcgi" : { "enabled" : "true", "ensureRunning" : "true", "packages" : { "yum" : ["php", "spawn-fcgi"] } } }, "systemd": { "sendmail" : { "enabled" : "false", "ensureRunning" : "false" } } } ``` ##### YAML ``` services: sysvinit: nginx: enabled: "true" ensureRunning: "true" files: - "/etc/nginx/nginx.conf" sources: - "/var/www/html" php-fastcgi: enabled: "true" ensureRunning: "true" packages: yum: - "php" - "spawn-fcgi" systemd: sendmail: enabled: "false" ensureRunning: "false" ``` Pour utiliser systemd avec un service, le service doit disposer d'un fichier d'unité systemd configuré. Le fichier d'unité suivant permet à systemd de démarrer et d'arrêter le démon `cfn-hup` dans la cible de service multiutilisateurs : ``` [Unit] Description=cfn-hup daemon [Service] ExecStart=/usr/bin/cfn-hup -v PIDFile=/var/run/cfn-hup.pid [Install] WantedBy=multi-user.target ``` Cette configuration suppose que `cfn-hup` est installé dans le répertoire `/usr/bin`. Cependant, l’emplacement réel de `cfn-hup` peut varier selon les plateformes. Vous pouvez remplacer cette configuration en créant un fichier de surcharge dans `/etc/systemd/system/cfn-hup.service.d/override.conf` comme suit : ``` # In this example, cfn-hup executable is available under /usr/local/bin [Service] ExecStart= ExecStart=/usr/local/bin/cfn-hup -v ``` #### Windows L'extrait Windows suivant démarre le service `cfn-hup`, le définit comme automatique et le redémarre si `cfn-init` modifie les fichiers de configuration spécifiés : ##### JSON ``` "services" : { "windows" : { "cfn-hup" : { "enabled" : "true", "ensureRunning" : "true", "files" : ["c:\\cfn\\cfn-hup.conf", "c:\\cfn\\hooks.d\\cfn-auto-reloader.conf"] } } } ``` ##### YAML ``` services: windows: cfn-hup: enabled: "true" ensureRunning: "true" files: - "c:\\cfn\\cfn-hup.conf" - "c:\\cfn\\hooks.d\\cfn-auto-reloader.conf" ``` ## Sources Vous pouvez utiliser la clé sources pour télécharger un fichier d'archive et le décompresser dans un répertoire cible de l' EC2 instance. Cette clé est entièrement prise en charge par les systèmes Linux et Windows. **Formats pris en charge** Formats pris en charge : + `tar` + `tar+gzip` + `tar+bz2` + `zip` ### Exemples #### GitHub Si vous l'utilisez GitHub comme système de contrôle de source, vous pouvez utiliser `cfn-init` le mécanisme de paquetage des sources pour extraire une version spécifique de votre application. GitHub vous permet de créer un fichier .zip ou .tar à partir d'une version spécifique via une URL comme suit : ``` https://github.com//(zipball|tarball)/ ``` Par exemple, l’extrait suivant récupère la version `main` sous forme de fichier `.tar`. ##### JSON ``` "sources" : { "/etc/puppet" : "https://github.com/user1/cfn-demo/tarball/main" } ``` ##### YAML ``` sources: /etc/puppet: "https://github.com/user1/cfn-demo/tarball/main" ``` #### S3 Bucket L'exemple suivant télécharge une archive à partir d'un compartiment S3 et la décompresse dans `/etc/myapp` : **Note** Vous pouvez utiliser les informations d'authentification pour une source. Cependant, vous ne pouvez pas intégrer une clé authentication dans le bloc sources. Au lieu de cela, vous devez inclure une clé buckets dans le bloc `S3AccessCreds`. Pour plus d'informations sur les informations d'identification Amazon S3, consultez [`AWS::CloudFormation::Authentication`](aws-resource-authentication.md). Pour un exemple, consultez le fichier [https://s3.amazonaws.com/cloudformation-templates-us-east-1/SourceAuthS3Bucket\_](https://s3.amazonaws.com/cloudformation-templates-us-east-1/S3Bucket_SourceAuth.template) .template. ##### JSON ``` "sources" : { "/etc/myapp" : "https://s3.amazonaws.com/{{amzn-s3-demo-bucket}}/myapp.tar.gz" } ``` ##### YAML ``` sources: /etc/myapp: "https://s3.amazonaws.com/{{amzn-s3-demo-bucket}}/myapp.tar.gz" ``` ## Utilisateurs Vous pouvez utiliser la clé users pour créer des Linux/UNIX utilisateurs sur l' EC2 instance. La clé `users` n’est pas prise en charge sur les systèmes Windows. Le tableau suivant répertorie les clés prises en charge. | Clé | Description | | --- | --- | | `uid` | ID d'un utilisateur. Le processus de création échoue si le nom d'utilisateur existe avec un autre ID d'utilisateur. Si l'ID d'utilisateur est déjà attribué à un utilisateur existant, le système d'exploitation peut refuser la requête de création. | | `groups` | Liste de noms de groupes. L'utilisateur sera ajouté à chaque groupe de la liste. | | `homeDir` | Répertoire de base de l'utilisateur. | ### Exemple Les utilisateurs sont créés en tant qu'utilisateurs du système non interactif avec le shell `/sbin/nologin`. Ce paramètre est intégré à la conception et ne peut pas être modifié. #### JSON ``` "users" : { "myUser" : { "groups" : ["groupOne", "groupTwo"], "uid" : "50", "homeDir" : "/tmp" } } ``` #### YAML ``` users: myUser: groups: - "groupOne" - "groupTwo" uid: "50" homeDir: "/tmp" ```