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, consultezBootstrap Windows Stacks AWS CloudFormation.

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 jeu de configuration lorsque vous appelez cfn-init dans votre modèle. Si vous ne spécifiez aucun jeu de configuration, cfn-init recherche une clé de configuration unique nommée config.

"Resources": {
  "MyInstance": {
    "Type": "AWS::EC2::Instance",
    "Metadata" : {
      "AWS::CloudFormation::Init" : {
        "config" : {
          "packages" : {
            :
          },
          "groups" : {
            :
          },
          "users" : {
            :
          },
          "sources" : {
            :
          },
          "files" : {
            :
          },
          "commands" : {
            :
          },
          "services" : {
            :
          }
        }
      }
    },
    "Properties": {
      :
    }
  }
}

Resources: 
  MyInstance: 
    Type: AWS::EC2::Instance
    Metadata: 
      AWS::CloudFormation::Init: 
        config: 
          packages: 
            :
          groups: 
            :
          users: 
            :
          sources: 
            :
          files: 
            :
          commands: 
            :
          services: 
            :
    Properties: 
      :

Jeux de configuration

Si vous souhaitez créer plusieurs clés de configuration traitées dans un ordre spécifique par cfn-init, créez un jeu de configuration qui contient ces clés 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.

"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" : "~"
            }
        }
    }
}     

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 connexes

Les exemples suivants d'appels à cfn-init utilisent les jeux de configuration précédents comme référence. Les exemples d'appels sont abrégés pour plus de clarté. Pour voir la syntaxe complète, consultez cfn-init.

Plusieurs jeux de configuration

Vous pouvez créer plusieurs jeux de configuration et les appeler en série à l'aide du 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.

"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" : "~"
            }
        }
    }
}

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 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é. Pour voir la syntaxe complète, consultez cfn-init.

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.

Exemple

L'extrait de l'exemple suivant appelle la commande echo si le fichier ~/test.txt n'existe pas.

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

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.

Exemples

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

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

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.

"files" : {
  "/tmp/myfile2.txt" : {
    "content" : "/tmp/myfile1.txt",
    "mode" : "120644"
  }
}

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 suivant génère la sortie « Content for test9 » dans /tmp/test9.txt.

"files" : {
    "/tmp/test9.txt" : {
        "content" : "Content for {{name}}",
        "context" : { "name" : "test9" }
    }
} 

files:
  /tmp/test9.txt:
    content: "Content for {{name}}"
    context:
      name: "test9"

Lorsque vous travaillez avec des modèles mustache, notez les éléments suivants :

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.

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.

"groups" : {
    "groupOne" : {},
    "groupTwo" : { "gid" : "45" }
}

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 script cfn-init prend actuellement en charge les formats de packages 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 tente 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 si une version du package est déjà installée, le script cfn-init n'installe 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 version URL pour rpm, demande les dernières versions à yum et Zypper, et la version 0.10.2 de chef à rubygems :

"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" : []
}

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 :

"msi" : {
  "awscli" : "https://s3.amazonaws.com/aws-cli/AWSCLI64.msi"
}

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é services vous permet également de spécifier les dépendances des sources, des packages et des fichiers. De cette façon, si un redémarrage est nécessaire en raison de l'installation de fichiers, cfn-init s'occupe du redémarrage du service. 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.

Exemples

Linux

L'extrait Linux suivant configure les services comme suit :

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

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"

[Unit]
Description=cfn-hup daemon
[Service]
ExecStart=/usr/bin/cfn-hup -v
PIDFile=/var/run/cfn-hup.pid
[Install]
WantedBy=multi-user.target

# 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 :

"services" : {
  "windows" : {
    "cfn-hup" : {
      "enabled" : "true",
      "ensureRunning" : "true",
      "files" : ["c:\\cfn\\cfn-hup.conf", "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"

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 :

Exemples

GitHub

Si vous l'utilisez GitHub comme système de contrôle de source, vous pouvez utiliser cfn-init et 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.

"sources" : {
  "/etc/puppet" : "https://github.com/user1/cfn-demo/tarball/main"
  }

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 :

"sources" : {
  "/etc/myapp" : "https://s3.amazonaws.com/mybucket/myapp.tar.gz"
  }

sources:
  /etc/myapp: "https://s3.amazonaws.com/mybucket/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.

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

"users" : {
    "myUser" : {
        "groups" : ["groupOne", "groupTwo"],
        "uid" : "50",
        "homeDir" : "/tmp"
    }
}

users:
  myUser:
    groups:
      - "groupOne"
      - "groupTwo"
    uid: "50"
    homeDir: "/tmp"