Syntaxe Jeux de configuration Commandes Dépôt de Groups Packages Services Sources Users

`AWS::CloudFormation::Init`

Utilisez le AWS::CloudFormation::Init type pour inclure des métadonnées sur une EC2 instance Amazon pour le script d'assistance cfn-init. Si votre modèle appelle le script cfn-init, ce dernier recherche les métadonnées de ressource issues de la clé AWS::CloudFormation::Init. Pour plus d'informations sur cfn-init, consultez cfn-init.

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.

Pour un exemple d'utilisation du script AWS::CloudFormation::Init d'assistance cfn-init pour créer une pile Linux, consultez. Déployez des applications sur Amazon EC2 Pour un exemple de stack Windows, consultezAction d’amorçage AWS CloudFormation Piles de fenêtres.

Syntaxe

La configuration est divisée en sections. L'extrait de modèle suivant montre comment vous pouvez associer des métadonnées pour cfn-init à une ressource d'EC2instance 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 ensemble de configurations lorsque vous appelez cfn-init votre modèle. Si vous ne spécifiez aucun ensemble de configurations, cfn-init recherche une seule clé de configuration nommée config.

Note

Le script cfn-init d'assistance traite ces 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, tels que 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 les cfn-init traiter dans un ordre spécifique, créez un ensemble de configurations 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: "~"

`cfn-init`Appels connexes

L'exemple suivant appelle pour faire cfn-init référence aux ensembles de configurations d'exemple précédents. Les exemples d'appels sont abrégés pour plus de clarté. Voir cfn-init pour la syntaxe complète.

Si un appel à cfn-init spécifie le ascending configset :
```
cfn-init -c ascending
```
Le script traite config1 puis traite config2 et le test.txt fichier contiendrait le texteI come from config2.
Si un appel à cfn-init spécifie le descending configset :
```
cfn-init -c descending
```
Le script traite config2 puis traite config1 et le test.txt fichier contiendrait le texteI come from config1.

Plusieurs jeux de configuration

Vous pouvez créer plusieurs ensembles de configurations et en appeler une série à l'aide de votre cfn-init script. 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"

`cfn-init`Appels connexes

Les appels suivants cfn-init font référence à ce qui est configSets déclaré dans l'extrait de modèle précédent. Les exemples d'appels sont abrégés pour plus de clarté. Voir cfn-init pour la syntaxe complète.

Si vous spécifiez test1 uniquement :
```
cfn-init -c test1
```
cfn-inittraite 1 uniquement la clé de configuration.
Si vous spécifiez test2 uniquement :
```
cfn-init -c test2
```
cfn-inittraite la clé de configuration 1 puis traite la clé de configuration2.
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'EC2instance. 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 qui détermine si `cfn-init` les commandes spécifiées dans la touche de commande sont exécutées. Si le test réussit, `cfn-init` exécute les commandes. Le `cfn-init` script 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 un % ERRORLEVEL % de`0`.
ignoreErrors	Facultatif	Valeur booléenne qui détermine si l'exécution `cfn-init` se poursuit en cas d'échec de la commande contenue dans la touche de commande (renvoie une valeur différente de zéro). Définissez cette `true` valeur si vous `cfn-init` souhaitez continuer à exécuter même si la commande échoue. Définissez cette valeur `false` si vous souhaitez `cfn-init` arrêter l'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 de 60 secondes et la valeur « pour toujours » indique `cfn-init` de quitter et de reprendre uniquement une fois le redémarrage 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"

Dépôt de

Vous pouvez utiliser la files clé pour créer des fichiers sur l'EC2instance. Le contenu peut être intégré dans le modèle ou extrait d'unURL. Les fichiers sont écrits sur disque par ordre lexicographique. Le tableau suivant répertorie les clés prises en charge.

Clé	Description
content	Il s'agit soit d'une chaîne, soit d'un JSON objet correctement formaté. Si vous utilisez un JSON objet comme contenu, celui-ci JSON sera écrit dans un fichier sur le disque. Toutes les fonctions intrinsèques telles que `Fn::GetAtt` ou `Ref` sont évaluées avant que l'JSONobjet ne soit écrit sur le disque. Lorsque vous créez un lien symbolique, spécifiez la cible du lien en tant que contenu. Note 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	A URL à partir duquel 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`
groupe	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 `120xxx`, 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`.
authentification	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.
context	Spécifie un contexte pour les fichiers qui doivent être traités en tant que modèles mustache. Pour utiliser cette clé, vous devez au préalable installer `aws-cfn-bootstrap` 1.3–11 ou version ultérieure en plus de pystache.

Exemples

L'exemple d'extrait suivant crée un fichier nommé dans le setup.mysql cadre d'une installation plus importante.

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.

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'exemple d'extrait de code suivant renvoie Content for test9 à. /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.

Groups

Vous pouvez utiliser la touche groups pour créer des groupes Linux/ et pour assigner un UNIX groupe. 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

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" }`

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"

Packages

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é du package ne prend en charge que le MSI programme d'installation.

Formats de packages pris en charge

Le cfn-init script prend actuellement en charge les formats de paquets suivants : apt, msi, python, rpm, rubygems, yum et Zypper. Les packages sont traités dans l'ordre suivant : rpm, yum/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 forme de chemin d'accès à un fichier sur le disque ou un fichierURL.

Si vous spécifiez une version d'un package, cfn-init tentera d'installer cette version même si une version plus récente du package est déjà installée 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 cfn-init script n'installera pas de nouvelle version. Il supposera que vous souhaitez conserver et utiliser la version existante.

Exemples d'extraits

RPM, yum, Rubygems et Zypper

L'extrait suivant spécifie une version URL 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: []

MSIpaquet

L'extrait de code suivant spécifie un URL pour un MSI package :

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. Sur les systèmes Linux, cette clé est prise en charge avec sysvinit ou systemd. Sur les systèmes Windows, elle est prise en charge en utilisant le gestionnaire de services Windows.

La clé de services vous permet également de spécifier les dépendances relatives aux sources, aux packages et aux fichiers afin que, si un redémarrage est nécessaire en raison de l'installation de fichiers, le redémarrage du service cfn-init soit pris en charge. Par exemple, si vous téléchargez le package du HTTP serveur Apache, l'installation du package démarrera automatiquement le HTTP serveur Apache pendant le processus de création de la pile. Toutefois, si la configuration HTTP du serveur Apache est mise à jour ultérieurement dans le processus de création de la pile, la mise à jour ne prendra effet que si le serveur Apache est redémarré. Vous pouvez utiliser la clé de services pour vous assurer que le HTTP service Apache est redémarré.

Le tableau suivant répertorie les clés prises en charge.

Clé	Description
ensureRunning	Définissez cette valeur sur true pour garantir que le service fonctionne une fois `cfn-init` terminé. Définissez cette valeur sur false pour garantir que le service ne s'exécute pas une fois `cfn-init` terminé. Ignorez cette clé pour n'apporter aucune modification à l'état du service.
activé	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 vous en `cfn-init` modifiez un directement par le biais du bloc de fichiers, ce service sera redémarré.
sources	Liste de répertoires. Si `cfn-init` une archive est étendue 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. En cas `cfn-init` d'installation ou de mise à jour de l'un de ces packages, ce service sera redémarré.
commands	Liste de noms de commandes. Si `cfn-init` la commande spécifiée est exécutée, ce service sera redémarré.

Exemples

Linux

L'extrait Linux suivant configure les services comme suit :

Le service nginx sera redémarré si l'un /etc/nginx/nginx.conf ou /var/www/html l'autre est modifié par. cfn-init
Le service php-fastcgi sera redémarré si vous cfn-init installez ou mettez à 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é sous le répertoire /usr/bin. Cependant, l'emplacement d'installation de cfn-hup peut varier selon les plateformes. Vous pouvez remplacer cette configuration en créant un fichier de remplacement dans /etc/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'EC2instance. 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 en procédant URL comme suit :


https://github.com/<your directory>/(zipball|tarball)/<version>

Par exemple, l'extrait suivant extrait 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.

Pour un exemple, consultez le fichier https://s3.amazonaws.com/cloudformation-templates-us-east-1/SourceAuthS3Bucket_ .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"

Users

Vous pouvez utiliser la clé users pour créer des UNIX utilisateurs Linux/ sur l'EC2instance. La clé users n'est pas prise en charge par 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"

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

AWS::CloudFormation::Authentication

AWS::CloudFormation::Interface

AWS::CloudFormation::Init

Syntaxe

Note

JSON

YAML

Note

Jeux de configuration

Jeu de configuration unique

JSON

YAML

cfn-initAppels connexes

Plusieurs jeux de configuration

JSON

YAML

cfn-initAppels connexes

Commandes

Exemple

JSON

YAML

Dépôt de

Note

Exemples

JSON

YAML

JSON

YAML

JSON

YAML

Groups

Exemple d'extrait

JSON

YAML

Packages

Formats de packages pris en charge

Spécification des versions

Exemples d'extraits

RPM, yum, Rubygems et Zypper

JSON

YAML

MSIpaquet

JSON

YAML

Services

Exemples

Linux

JSON

YAML

Windows

JSON

YAML

Sources

Formats pris en charge

Exemples

GitHub

JSON

YAML

S3 Bucket

Note

JSON

YAML

Users

Exemple

JSON

YAML

`AWS::CloudFormation::Init`

`cfn-init`Appels connexes

`cfn-init`Appels connexes