AWS::CloudFormation::Init
Utilice el tipo AWS::CloudFormation::Init
para incluir metadatos en una instancia de Amazon EC2 para el script de ayuda cfn-init. Si la plantilla llama al script cfn-init, el script buscará los metadatos de los recursos enraizados en la clave de metadatos de AWS::CloudFormation::Init
. Para obtener más información acerca de cfn-init, consulte cfn-init.
cfn-init admite todos los tipos de metadatos para sistemas Linux. Admite los tipos de metadatos para Windows con las condiciones que se describen en las secciones que aparecen a continuación.
Para obtener un ejemplo de uso de AWS::CloudFormation::Init
y el script de ayuda cfn-init para crear una pila de Linux, consulte Implementación de aplicaciones en Amazon EC2. Para ver un ejemplo de pila de Windows, consulte Arranque de pilas de Windows de AWS CloudFormation.
Sintaxis
La configuración se divide en secciones. El siguiente fragmento de código de plantilla muestra cómo se pueden adjuntar metadatos de cfn-init a un recurso de instancia de EC2 dentro de la plantilla.
Los metadatos se organizan en claves de configuración, que puede agrupar en configsets. Puede especificar un configset cuando llama a cfn-init
en la plantilla. Si no especifica un configset, cfn-init
buscará una clave de configuración única denominada config.
nota
El script auxiliar cfn-init
procesa estas secciones de configuración en el siguiente orden: paquetes, grupos, usuarios, fuentes, archivos, comandos y, a continuación, servicios. Si necesita un orden diferente, separe las secciones en diferentes claves de configuración y, a continuación, utilice un configset que especifica el orden en el que deben procesarse las claves de configuración.
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: :
nota
En las siguientes secciones se incluyen ejemplos de scripts escritos en lenguajes de script de intérprete de comandos tipo Unix, como Bash. Para crear scripts para PowerShell en su lugar, asegúrese de estar familiarizado con el lenguaje PowerShell. La sintaxis de PowerShell es diferente a la de los intérpretes de comandos tipo Unix, por lo que tendrá que estar familiarizado con la forma de hacer las cosas de PowerShell.
Configsets
Si desea crear más de una clave de configuración y que cfn-init
las procese en un orden específico, cree un configset que contenga las claves de configuración en el orden deseado.
Configset individual
El siguiente fragmento de código de plantilla crea configsets denominados ascending
y descending
que contienen cada uno dos claves de configuración.
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: "~"
Llamadas a cfn-init
relacionadas
Las siguientes llamadas a cfn-init
de ejemplo refieren a los configsets de ejemplo anteriores. Las llamadas de ejemplo se abrevian para facilitar la lectura. Para ver la sintaxis completa, consulte cfn-init.
-
Si una llamada a
cfn-init
especifica el configsetascending
:cfn-init -c ascending
El script procesa
config1
y, a continuación, procesaconfig2
y el archivotest.txt
contendrá el textoI come from config2
. -
Si una llamada a
cfn-init
especifica el configsetdescending
:cfn-init -c descending
El script procesa
config2
y, a continuación, procesaconfig1
y el archivotest.txt
contendrá el textoI come from config1
.
Varios configsets
Puede crear varios configsets y llamar a una serie de ellos con su script cfn-init
. Cada configset puede contener una lista de claves de configuración o referencias a otros configsets. Por ejemplo, el siguiente fragmento de código de plantilla crea tres configsets. El primer configset, test1
, contiene una clave de configuración denominada 1
. El segundo configset, test2
, contiene una referencia al configset test1
y una clave de configuración denominada 2
. El tercer configset, de forma predeterminada, contiene una referencia al configset 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"
Llamadas a cfn-init
relacionadas
Las siguientes llamadas a cfn-init
refieren a los configSets declarados en el anterior fragmento de código de plantilla. Las llamadas de ejemplo se abrevian para facilitar la lectura. Para ver la sintaxis completa, consulte cfn-init.
-
Si especifica
test1
solamente:cfn-init -c test1
cfn-init
procesa la clave de configuración1
solamente. -
Si especifica
test2
solamente:cfn-init -c test2
cfn-init
procesa la clave de configuración1
y, a continuación, procesa la clave de configuración2
. -
Si especifica el configset
default
(o ningún configset en absoluto):cfn-init -c default
Obtendrá el mismo comportamiento que si especifica el configset
test2
.
Comandos
Puede utilizar la clave de comandos para ejecutar comandos en la instancia de EC2. Los comandos se procesan en orden alfabético por nombre.
Clave | Obligatoria | Descripción |
---|---|---|
comando |
Obligatoria |
Una matriz o bien una cadena que especifica el comando que se va a ejecutar. Si utiliza una matriz, no es preciso que utilizar el carácter de escape para los caracteres de espacio ni incluir los parámetros de comandos entre comillas. No utilice la matriz para especificar varios comandos. |
env |
Opcional |
Establece las variables de entorno para el comando. Esta propiedad sobrescribe, en lugar de anexar, el entorno existente. |
cwd |
Opcional |
El directorio de trabajo. |
prueba |
Opcional |
Un comando de prueba que determina si En el caso de Linux, el comando de prueba debe devolver un código de salida de |
ignoreErrors |
Opcional |
Un valor booleano que determina si |
waitAfterCompletion |
Opcional |
Para sistemas Windows solamente. Especifica el tiempo durante el que esperar (en segundos) después de que un comando ha terminado en caso de que el comando provoque un reinicio. El valor predeterminado es de 60 segundos y un valor de “forever” indica a |
Ejemplo
El siguiente fragmento de código de ejemplo llama al comando echo si el archivo ~/test.txt
no existe.
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"
Archivos
Puede utilizar la clave files
para crear archivos en la instancia de EC2. El contenido puede ser en línea en la plantilla o el contenido puede extraerse de una URL. Los archivos se escriben en el disco en orden lexicográfico. En la tabla siguiente se muestran las claves admitidas.
Clave | Descripción |
---|---|
content |
Una cadena o un objeto JSON con formato correcto. Si utiliza un objeto JSON como su contenido, el objeto JSON se escribirá en un archivo en el disco. Cualquier función intrínseca como notaSi crea un symlink, el script auxiliar modifica los permisos del archivo de destino. Actualmente, no puede crear un symlink sin modificar los permisos del archivo de destino. |
source |
Una URL desde la que cargar el archivo. Esta opción no se puede especificar con la clave de contenido. |
encoding |
El formato de la codificación. Solo se utiliza si el contenido es una cadena. La codificación no se aplica si utiliza una fuente. Valores válidos: |
grupo |
El nombre del grupo propietario de este archivo. No es compatible con sistemas Windows. |
owner |
El nombre del usuario propietario de este archivo. No es compatible con sistemas Windows. |
mode |
Un valor octal de seis dígitos que representa el modo para este archivo. No es compatible con sistemas Windows. Utilice los tres primeros dígitos para symlinks y los últimos tres dígitos para la configuración de permisos. Para crear un symlink, especifique |
autenticación |
El nombre de un método de autenticación que se debe utilizar. Esto anula cualquier autenticación predeterminada. Puede utilizar esta propiedad para seleccionar un método de autenticación definido con el recurso AWS::CloudFormation::Authentication. |
context |
Especifica un contexto para los archivos que se procesan como plantillas Mustache |
Ejemplos
El siguiente fragmento de código de ejemplo crea un archivo denominado setup.mysql
como parte de una instalación de mayor tamaño.
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"
La plantilla completa está disponible en: https://s3.amazonaws.com/cloudformation-templates-us-east-1/Drupal_Single_Instance.template
El siguiente fragmento de código de ejemplo crea un symlink /tmp/myfile2.txt
que apunta a un archivo /tmp/myfile1.txt
existente. Los permisos del archivo de destino /tmp/myfile1.txt
se definen por el valor de modo 644
.
JSON
"files" : { "/tmp/myfile2.txt" : { "content" : "/tmp/myfile1.txt", "mode" : "120644" } }
YAML
files: /tmp/myfile2.txt: content: "/tmp/myfile1.txt" mode: "120644"
Las plantillas Mustache se utilizan principalmente para crear archivos de configuración. Por ejemplo, puede almacenar un archivo de configuración en un bucket de S3 e interpolar Refs y GetAtts de la plantilla, en lugar de usar Fn::Join. El siguiente fragmento de código de ejemplo muestra Content for test9
para /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"
Cuando trabaje con plantillas Mustache, tenga en cuenta lo siguiente:
-
Para que se procesen los archivos, la clave del contexto tiene que estar presente.
-
La clave del contexto debe ser un mapa clave-valor, pero se puede anidar.
-
Puede procesar archivos con contenido en línea mediante la clave de contenido y archivos remoto mediante la clave de origen.
-
La compatibilidad de Mustache depende de la versión de pystache. La versión 0.5.2 es compatible con la especificación Mustache 1.1.2
.
Grupos
Puede utilizar la clave de grupos para crear grupos de Linux/UNIX y asignar ID de grupo. La clave de grupos no es compatible con sistemas Windows.
Para crear un grupo, añada un nuevo par clave-valor que asigne un nuevo nombre de grupo a un ID de grupo opcional. La clave “groups” puede contener uno o varios nombres de grupo. En la tabla siguiente, se muestran las claves disponibles.
Clave | Descripción |
---|---|
|
Número de ID de grupo. Si se especifica un ID de grupo y el nombre del grupo ya existe, se producirá un error al crear el grupo. Si otro grupo tiene el ID de grupo especificado, el sistema operativo podría rechazar la creación del grupo. Ejemplo: |
Fragmento de código de ejemplo
El siguiente fragmento de código especifica un grupo denominado groupOne
sin asignar un ID de grupo y un grupo denominado groupTwo
que especifica un valor de ID de grupo de 45
.
JSON
"groups" : { "groupOne" : {}, "groupTwo" : { "gid" : "45" } }
YAML
groups: groupOne: {} groupTwo: gid: "45"
Paquetes
Puede utilizar la clave de paquetes para descargar e instalar aplicaciones y componentes previamente empaquetados. En los sistemas Windows, la clave de paquetes solo admite el instalador MSI.
Formatos de paquetes admitidos
Actualmente, el script cfn-init
es compatible con los siguientes formatos de paquete: apt, msi, python, rpm, rubygems, yum y Zypper. Los paquetes se procesan en el orden siguiente: rpm, yum/apt/zypper y, a continuación, rubygems y python. No existe ningún orden establecido entre rubygems y python, y los paquetes dentro de cada administrador de paquetes no tienen garantizada la instalación en ningún orden.
Especificación de versiones
Dentro de cada administrador de paquetes, cada paquete se especifica con un nombre de paquete y una lista de versiones. La versión puede ser una cadena, una lista de versiones o una cadena o lista vacía. Una cadena o lista vacía indica que se debe usar la versión más reciente. Para el administrador de rpm, la versión se especifica como una ruta a un archivo en el disco o una URL.
Si especifica una versión de un paquete, cfn-init
intentará instalar esa versión, incluso si ya hay una versión más reciente del paquete instalada en la instancia. Algunos administradores de paquetes admiten varias versiones, pero puede haber otros que no. Verifique la documentación del administrador de paquetes para obtener más información. Si no especifica una versión y ya hay una versión del paquete instalada, el script cfn-init
no instalará una nueva versión, sino que presupondrá que desea mantener y utilizar la versión existente.
Fragmentos de código de ejemplo
RPM, yum, Rubygems y Zypper
El siguiente fragmento de código especifica una URL de versión para rpm, solicita las últimas versiones de yum y Zypper, y la versión 0.10.2 de chef de 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: []
Paquete MSI
El siguiente fragmento de código especifica una URL para un paquete MSI:
JSON
"msi" : { "awscli" : "https://s3.amazonaws.com/aws-cli/AWSCLI64.msi" }
YAML
msi: awscli: "https://s3.amazonaws.com/aws-cli/AWSCLI64.msi"
Servicios
Puede utilizar la clave de servicios para definir qué servicios deben habilitarse o deshabilitarse cuando se lanza la instancia. En sistemas Linux, esta clave es compatible con sysvinit o systemd. En sistemas Windows, es compatible con el administrador de servicio de Windows.
La clave de servicios también le permite especificar dependencias en orígenes, paquetes y archivos. De esta manera, si es necesario realizar un reinicio debido a los archivos que se están instalado, cfn-init
se encargará de reiniciar el servicio. Por ejemplo, si descarga el paquete del servidor HTTP Apache, la instalación del paquete comenzará automáticamente el servidor HTTP Apache durante el proceso de creación de la pila. Sin embargo, si la configuración del servidor HTTP Apache se actualiza más adelante en el proceso de creación de la pila, la actualización no surtirá efecto hasta que se reinicie el servidor Apache. Puede utilizar la clave de servicios para asegurarse de que se reinicia el servicio HTTP Apache.
En la tabla siguiente se muestran las claves admitidas.
Clave | Descripción |
---|---|
ensureRunning |
Establézcalo en verdadero para garantizar que el servicio se ejecuta una vez que finaliza Establézcalo en falso para garantizar que el servicio no se ejecuta una vez que finaliza Omita esta clave para no realizar ningún cambio en el estado del servicio. |
enabled |
Establezca en true para garantizar que el servicio comenzará automáticamente al arrancar. Establezca en false para garantizar que el servicio no comenzará automáticamente al arrancar. Omita esta clave para no realizar ningún cambio a esta propiedad. |
files |
Una lista de archivos. Si |
sources |
Una lista de directorios. Si |
packages |
Una asignación del administrador de paquetes con la lista de nombres de paquetes. Si |
comandos |
Una lista de nombres de comandos. Si |
Ejemplos
Linux
El siguiente fragmento de código de Linux configura los servicios de la siguiente manera:
-
El servicio nginx se reiniciará si
/etc/nginx/nginx.conf
o/var/www/html
es modificado porcfn-init
. -
El servicio php-fastcgi se reiniciará si
cfn-init
instala o actualiza php o spawn-fcgi mediante yum. -
El servicio sendmail se interrumpirá y deshabilitará mediante 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"
Para usar systemd con un servicio, este debe tener configurado un archivo de unidad systemd. El siguiente archivo de unidad permite que systemd inicie y detenga el daemon cfn-hup en el destino del servicio multiusuario:
[Unit] Description=cfn-hup daemon [Service] ExecStart=/usr/bin/cfn-hup -v PIDFile=/var/run/cfn-hup.pid [Install] WantedBy=multi-user.target
Esta configuración supone que cfn-hup está instalado en el directorio /usr/bin. Sin embargo, la ubicación real donde se instala cfn-hup puede variar en diferentes plataformas. Puede anular esta configuración al crear un archivo de anulación en /etc/systemd/system/cfn-hup.service.d/override.conf de la siguiente manera:
# In this example, cfn-hup executable is available under /usr/local/bin [Service] ExecStart= ExecStart=/usr/local/bin/cfn-hup -v
Windows
El siguiente fragmento de código de Windows inicia el servicio cfn-hup, lo establece en automático y reinicia el servicio si cfn-init
modifica los archivos de configuración especificados:
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"
Orígenes
Puede utilizar la clave de origen para descargar un archivo de almacenamiento y extraerlo en un directorio de destino en la instancia de EC2. Esta clave es totalmente compatible con los sistemas Linux y Windows.
Formatos admitidos
Los formatos admitidos son:
-
tar
-
tar+gzip
-
tar+bz2
-
zip
Ejemplos
GitHub
Si usa GitHub como un sistema de control de origen, puede usar cfn-init
y el mecanismo del paquete de origen para extraer una versión específica de su aplicación. GitHub le permite crear un zip o un tar a partir de una versión específica a través de una URL de la siguiente manera:
https://github.com/<your directory>/(zipball|tarball)/<version>
Por ejemplo, el siguiente fragmento de código extrae la versión principal como un archivo .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"
Bucket de S3
En el siguiente ejemplo, se descarga un tarball de un bucket de S3 y se desempaqueta en /etc/myapp
:
nota
Puede utilizar las credenciales de autenticación para un origen. Sin embargo, no puede incluir una clave de autenticación en el bloque de fuentes. En su lugar, incluya una clave de cubos en su bloque de S3AccessCreds
. Para obtener más información sobre las credenciales de autenticación de Amazon S3, consulte AWS::CloudFormation::Authentication.
Para ver un ejemplo, consulte https://s3.amazonaws.com/cloudformation-templates-us-east-1/S3Bucket_SourceAuth.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"
Usuarios
Puede utilizar la clave de usuarios para crear usuarios de Linux/UNIX en la instancia de EC2. La clave de usuarios no es compatible con sistemas Windows.
En la tabla siguiente se muestran las claves admitidas.
Clave | Descripción |
---|---|
uid |
ID de usuario. El proceso de creación falla si existe un nombre de usuario con otro ID. Si el ID de usuario ya se ha asignado a un usuario existente, el sistema operativo podría rechazar la solicitud de creación. |
groups |
Lista de nombres de grupos. Se añadirá al usuario a cada grupo en la lista. |
homeDir |
Directorio de inicio del usuario. |
Ejemplo
Los usuarios se crean como usuarios de un sistema no interactivo con un shell de /sbin/nologin
. Esto es así por diseño y no se puede modificar.
JSON
"users" : { "myUser" : { "groups" : ["groupOne", "groupTwo"], "uid" : "50", "homeDir" : "/tmp" } }
YAML
users: myUser: groups: - "groupOne" - "groupTwo" uid: "50" homeDir: "/tmp"