Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # CodeDeploy AppSpec referencia de archivo Esta sección se incluye solo como referencia. Para obtener una visión general conceptual del AppSpec archivo, consulte[CodeDeploy archivos de especificación de la aplicación (AppSpec)](application-specification-files.md). El archivo de especificaciones de la aplicación (AppSpec archivo) es un archivo con formato [YAML](http://www.yaml.org) o con formato JSON que se utiliza para administrar una implementación. CodeDeploy **nota** El AppSpec archivo de una implementación de EC2/local debe tener un nombre`appspec.yml`, a menos que vaya a realizar una implementación local. Para obtener más información, consulte [Creación de una implementación local](deployments-local.md#deployments-local-deploy). **Topics** + [AppSpec archivos en una plataforma informática Amazon ECS](#appspec-reference-ecs) + [AppSpec archivos en una plataforma AWS Lambda informática](#appspec-reference-lambda) + [AppSpec archivos en una plataforma informática local EC2/](#appspec-reference-server) + [AppSpec Estructura de archivos](reference-appspec-file-structure.md) + [AppSpec Ejemplo de archivo](reference-appspec-file-example.md) + [AppSpec Espaciado de archivos](#reference-appspec-file-spacing) + [Valide su AppSpec archivo y su ubicación](reference-appspec-file-validate.md) ## AppSpec archivos en una plataforma informática Amazon ECS En el caso de las aplicaciones de la plataforma informática Amazon ECS, el AppSpec archivo lo utiliza CodeDeploy para determinar: + El archivo de definición de la tarea de Amazon ECS. Esto se especifica con su ARN en la `TaskDefinition` instrucción del archivo. AppSpec + El contenedor y el puerto en el conjunto de tareas de sustitución donde el Equilibrador de carga de aplicación o el Equilibrador de carga de red redirige tráfico durante una implementación. Esto se especifica con la `LoadBalancerInfo` instrucción del AppSpec archivo. + Información opcional acerca del servicio del servicio de Amazon ECS como, por ejemplo, la versión de la plataforma en la que se ejecuta, sus subredes y sus grupos de seguridad. + Funciones de Lambda opcionales que ejecutar durante enlaces que se corresponden con eventos de ciclo de vida durante una implementación de Amazon ECS. Para obtener más información, consulte [AppSpec sección «ganchos» para una implementación de Amazon ECS](reference-appspec-file-structure-hooks.md#appspec-hooks-ecs). ## AppSpec archivos en una plataforma AWS Lambda informática En el AWS caso de las aplicaciones de la plataforma de cómputo Lambda, el AppSpec archivo se utiliza CodeDeploy para determinar: + Qué versión de función de Lambda se debe implementar. + Qué funciones de Lambda se van a usar como pruebas de validación. Un AppSpec archivo puede tener formato YAML o JSON. También puede introducir el contenido de un AppSpec archivo directamente en la CodeDeploy consola al crear una implementación. ## AppSpec archivos en una plataforma informática local EC2/ Si la aplicación utiliza la plataforma informática local de EC2, el AppSpec archivo debe tener un nombre de archivo con formato YAML `appspec.yml` y debe colocarse en la raíz de la estructura de directorios del código fuente de la aplicación. De lo contrario, las implementaciones producirán un error. Lo utiliza para determinar: CodeDeploy + Qué debe instalar en sus instancias desde la revisión de su aplicación en Amazon S3 o GitHub. + Los enlaces de eventos del ciclo de vida que se deben ejecutar en respuesta a los eventos del ciclo de vida de la implementación. Una vez completado el AppSpec archivo, lo agrupa, junto con el contenido que se va a implementar, en un archivo de almacenamiento (zip, tar o tar comprimido). Para obtener más información, consulte [Trabajar con revisiones de aplicaciones para CodeDeploy](application-revisions.md). **nota** Los formatos de archivo tar y tar comprimido (.tar y .tar.gz) no son compatibles con las instancias de Windows Server. Cuando tengas un archivo empaquetado (conocido CodeDeploy como *revisión*), lo subes a un bucket de Amazon S3 o a un repositorio de Git. A continuación, se utiliza CodeDeploy para implementar la revisión. Para obtener instrucciones, consulte [Cree una implementación con CodeDeploy](deployments-create.md). El archivo appspec.yml para la implementación en una plataforma de informática de EC2/en las instalaciones se guarda en el directorio raíz de la revisión. Para obtener más información, consulte [Agregue un AppSpec archivo para una implementación local de EC2/](application-revisions-appspec-file.md#add-appspec-file-server) y [Planificación de una revisión de CodeDeploy](application-revisions-plan.md). # AppSpec Estructura de archivos La siguiente es la estructura de alto nivel de un AppSpec archivo que se utiliza para las implementaciones en plataformas informáticas AWS Lambda y EC2/on-premise. Los valores de un AppSpec archivo con formato YAML que sean cadenas no deben estar entre comillas («») a menos que se especifique lo contrario. ## AppSpec estructura de archivos para las implementaciones de Amazon ECS **nota** Este AppSpec archivo está escrito en YAML, pero puede usar la misma estructura para escribir uno en JSON. Las cadenas de un AppSpec archivo con formato JSON siempre aparecen entre comillas («»). ``` version: 0.0 resources: ecs-service-specifications hooks: deployment-lifecycle-event-mappings ``` En esta estructura: ** **versión** ** En esta sección se especifica la versión del archivo. AppSpec No cambie este valor. Es obligatorio. El único valor permitido actualmente es **0.0**. Está reservado CodeDeploy para uso futuro. Especifique **version** con una cadena. ** **resources** ** En esta sección se especifica información sobre la aplicación de Amazon ECS que se va a implementar. Para obtener más información, consulte [AppSpec sección de «recursos» para las implementaciones de Amazon ECS](reference-appspec-file-structure-resources.md#reference-appspec-file-structure-resources-ecs). ** **enlaces** ** Esta sección especifica las funciones de Lambda que se van a ejecutar en enlaces de eventos específicos del ciclo de vida de la implementación para validar la implementación. Para obtener más información, consulte [Lista de enlaces de eventos de ciclo de vida para una implementación de Amazon ECS](reference-appspec-file-structure-hooks.md#reference-appspec-file-structure-hooks-list-ecs). ## AppSpec estructura de archivos para despliegues de AWS Lambda **nota** Este AppSpec archivo está escrito en YAML, pero puede usar la misma estructura para escribir un AppSpec archivo para una implementación de Lambda en JSON. Las cadenas de un AppSpec archivo con formato JSON siempre aparecen entre comillas («»). ``` version: 0.0 resources: lambda-function-specifications hooks: deployment-lifecycle-event-mappings ``` En esta estructura: ** **versión** ** En esta sección se especifica la versión del archivo. AppSpec No cambie este valor. Es obligatorio. El único valor permitido actualmente es **0.0**. Está reservado CodeDeploy para uso futuro. Especifique **version** con una cadena. ** **resources** ** En esta sección se especifica información sobre la función de Lambda que se va a implementar. Para obtener más información, consulte [AppSpec sección de «recursos» (solo Amazon ECS y AWS Lambda despliegues)](reference-appspec-file-structure-resources.md). ** **enlaces** ** Esta sección especifica las funciones de Lambda que se van a ejecutar en eventos específicos del ciclo de vida de la implementación para validar la implementación. Para obtener más información, consulte [AppSpec sección de «ganchos»](reference-appspec-file-structure-hooks.md). ## AppSpec estructura de archivos para despliegues de EC2/locales ``` version: 0.0 os: operating-system-name files: source-destination-files-mappings permissions: permissions-specifications hooks: deployment-lifecycle-event-mappings ``` En esta estructura: ** **versión** ** En esta sección se especifica la versión del archivo. AppSpec No cambie este valor. Es obligatorio. El único valor permitido actualmente es **0.0**. Está reservado CodeDeploy para uso futuro. Especifique **version** con una cadena. ** **os** ** Esta sección especifica el valor del sistema operativo de la instancia en la que se va a realizar la implementación. Es obligatorio. Se pueden especificar los siguientes valores: + **linux**: la instancia es una instancia de Amazon Linux, Ubuntu Server o RHEL. + **windows**: la instancia es una instancia de Windows Server. Especifique **os** con una cadena. ** **files** ** Esta sección especifica los nombres de los archivos que deben copiarse en la instancia durante el evento **Install** de la implementación. Para obtener más información, consulte [AppSpec Sección de «archivos» (solo para despliegues de EC2/on-premise)](reference-appspec-file-structure-files.md). ** **permissions** ** Esta sección especifica cómo los permisos especiales, si hay alguno, deben aplicarse a los archivos de la sección `files` cuando se copien en la instancia. Esta sección se aplica únicamente a instancias de Amazon Linux, Ubuntu Server y Red Hat Enterprise Linux (RHEL). Para obtener más información, consulte, [AppSpec sección de «permisos» (solo para despliegues de EC2/on-premise)](reference-appspec-file-structure-permissions.md). ** **enlaces** ** Esta sección especifica los scripts que se van a ejecutar en eventos específicos del ciclo de vida de la implementación durante la implementación. Para obtener más información, consulte [AppSpec sección de «ganchos»](reference-appspec-file-structure-hooks.md). **Topics** + [AppSpec estructura de archivos para las implementaciones de Amazon ECS](#ecs-appspec-structure) + [AppSpec estructura de archivos para despliegues de AWS Lambda](#lambda-appspec-structure) + [AppSpec estructura de archivos para despliegues de EC2/locales](#server-appspec-structure) + [AppSpec Sección de «archivos» (solo para despliegues de EC2/on-premise)](reference-appspec-file-structure-files.md) + [AppSpec sección de «recursos» (solo Amazon ECS y AWS Lambda despliegues)](reference-appspec-file-structure-resources.md) + [AppSpec sección de «permisos» (solo para despliegues de EC2/on-premise)](reference-appspec-file-structure-permissions.md) + [AppSpec sección de «ganchos»](reference-appspec-file-structure-hooks.md) # AppSpec Sección de «archivos» (solo para despliegues de EC2/on-premise) Proporciona información CodeDeploy sobre los archivos de la revisión de la aplicación que se deben instalar en la instancia durante el evento de **instalación** de la implementación. Esta sección solo es necesaria si va a copiar archivos de la revisión en ubicaciones de la instancia durante la implementación. Esta sección tiene la siguiente estructura: ``` files: - source: source-file-location-1 destination: destination-file-location-1 file_exists_behavior: DISALLOW|OVERWRITE|RETAIN ``` Se pueden establecer varios pares `source` y `destination`. La instrucción `source` identifica el archivo o directorio de la revisión que se va a copiar en la instancia: + Si `source` hace referencia a un archivo, solo se copian los archivos especificados en la instancia. + Si `source` hace referencia a un directorio, se copian todos los archivos del directorio en la instancia. + Si `source` es una sola barra diagonal ("/" para instancias de Amazon Linux, RHEL y Ubuntu Server o " \$1" para instancias de Windows Server), se copian todos los archivos de la revisión en la instancia. Las rutas utilizadas en `source` son relativas al archivo `appspec.yml`, que debería estar en la raíz de la revisión. Para obtener más información sobre la estructura de archivos de una revisión, consulte [Planificación de una revisión de CodeDeploy](application-revisions-plan.md). La instrucción `destination` identifica el lugar de la instancia en el que deben copiarse los archivos. Debe ser una ruta totalmente cualificada, como `/root/destination/directory` (en Linux, RHEL y Ubuntu) o `c:\destination\folder` (en Windows). `source` y `destination` se especifican con una cadena. La `file_exists_behavior` instrucción es opcional y especifica cómo se gestionan los CodeDeploy archivos que ya existen en la ubicación de destino de la implementación, pero que no formaban parte de la anterior implementación exitosa. Puede adoptar cualquiera de los siguientes valores: + NO PERMITIR: se produce un error en la implementación. Esta es la opción predeterminada si no se especifica ninguna opción. + SOBRESCRIBIR: la versión del archivo de la revisión de la aplicación sustituye a la versión ya incluida en la instancia. + RETENER: la versión del archivo que ya está en la instancia se conserva y se usa como parte de la nueva implementación. Si usa la configuración `file_exists_behavior`, debe comprender que esta configuración: + Solo se puede especificar una vez y se aplica a todos los archivos y directorios enumerados en `files:`. + tiene prioridad sobre la `--file-exists-behavior` AWS CLI opción y la opción de `fileExistsBehavior` API (ambas opciones también son opcionales). Esta es una sección `files` de ejemplo para una instancia de Amazon Linux, Ubuntu Server o RHEL. ``` files: - source: Config/config.txt destination: /webapps/Config - source: source destination: /webapps/myApp ``` En este ejemplo, se realizan las dos operaciones siguientes durante el evento **Install**: 1. Copiar el archivo `Config/config.txt` en la revisión en la ruta de `/webapps/Config/config.txt` de la instancia. 1. Copiar recursivamente todos los archivos del directorio `source` de la revisión en el directorio `/webapps/myApp` de la instancia. ## Ejemplos de la sección "files" Los siguientes ejemplos muestran cómo especificar la sección `files`. Aunque estos ejemplos describen estructuras de archivos y directorios (carpetas) de Windows Server, se pueden adaptar fácilmente para instancias de Amazon Linux, Ubuntu Server y RHEL. **nota** Solo las implementaciones de EC2/en las instalaciones utilizan la sección `files`. No se aplica a las implementaciones de AWS Lambda. En los siguientes ejemplos, presuponemos que estos archivos están en el paquete en la raíz de `source`: + `appspec.yml` + `my-file.txt` + `my-file-2.txt` + `my-file-3.txt` ``` # 1) Copy only my-file.txt to the destination folder c:\temp. # files: - source: .\my-file.txt destination: c:\temp # # Result: # c:\temp\my-file.txt # # --------------------- # # 2) Copy only my-file-2.txt and my-file-3.txt to the destination folder c:\temp. # files: - source: my-file-2.txt destination: c:\temp - source: my-file-3.txt destination: c:\temp # # Result: # c:\temp\my-file-2.txt # c:\temp\my-file-3.txt # # --------------------- # # 3) Copy my-file.txt, my-file-2.txt, and my-file-3.txt (along with the appspec.yml file) to the destination folder c:\temp. # files: - source: \ destination: c:\temp # # Result: # c:\temp\appspec.yml # c:\temp\my-file.txt # c:\temp\my-file-2.txt # c:\temp\my-file-3.txt ``` En los siguientes ejemplos, presuponemos que `appspec.yml` está en el paquete en la raíz de `source` junto con una carpeta denominada `my-folder` que contiene tres archivos: + `appspec.yml` + `my-folder\my-file.txt` + `my-folder\my-file-2.txt` + `my-folder\my-file-3.txt` ``` # 4) Copy the 3 files in my-folder (but do not copy my-folder itself) to the destination folder c:\temp. # files: - source: .\my-folder destination: c:\temp # # Result: # c:\temp\my-file.txt # c:\temp\my-file-2.txt # c:\temp\my-file-3.txt # # --------------------- # # 5) Copy my-folder and its 3 files to my-folder within the destination folder c:\temp. # files: - source: .\my-folder destination: c:\temp\my-folder # # Result: # c:\temp\my-folder\my-file.txt # c:\temp\my-folder\my-file-2.txt # c:\temp\my-folder\my-file-3.txt # # --------------------- # # 6) Copy the 3 files in my-folder to other-folder within the destination folder c:\temp. # files: - source: .\my-folder destination: c:\temp\other-folder # # Result: # c:\temp\other-folder\my-file.txt # c:\temp\other-folder\my-file-2.txt # c:\temp\other-folder\my-file-3.txt # # --------------------- # # 7) Copy only my-file-2.txt and my-file-3.txt to my-folder within the destination folder c:\temp. # files: - source: .\my-folder\my-file-2.txt destination: c:\temp\my-folder - source: .\my-folder\my-file-3.txt destination: c:\temp\my-folder # # Result: # c:\temp\my-folder\my-file-2.txt # c:\temp\my-folder\my-file-3.txt # # --------------------- # # 8) Copy only my-file-2.txt and my-file-3.txt to other-folder within the destination folder c:\temp. # files: - source: .\my-folder\my-file-2.txt destination: c:\temp\other-folder - source: .\my-folder\my-file-3.txt destination: c:\temp\other-folder # # Result: # c:\temp\other-folder\my-file-2.txt # c:\temp\other-folder\my-file-3.txt # # --------------------- # # 9) Copy my-folder and its 3 files (along with the appspec.yml file) to the destination folder c:\temp. If any of the files already exist on the instance, overwrite them. # files: - source: \ destination: c:\temp file_exists_behavior: OVERWRITE # # Result: # c:\temp\appspec.yml # c:\temp\my-folder\my-file.txt # c:\temp\my-folder\my-file-2.txt # c:\temp\my-folder\my-file-3.txt ``` # AppSpec sección de «recursos» (solo Amazon ECS y AWS Lambda despliegues) El contenido de la `'resources'` sección del AppSpec archivo varía en función de la plataforma informática de la implementación. La sección `'resources'` de una implementación de Amazon ECS contiene la definición de tareas de Amazon ECS, contenedor y puerto para dirigir el tráfico a su conjunto de tareas de Amazon ECS actualizado y otra información opcional. La `'resources'` sección de una AWS Lambda implementación contiene el nombre, el alias, la versión actual y la versión de destino de una función Lambda. **Topics** + [AppSpec sección de «recursos» para despliegues de AWS Lambda](#reference-appspec-file-structure-resources-lambda) + [AppSpec sección de «recursos» para las implementaciones de Amazon ECS](#reference-appspec-file-structure-resources-ecs) ## AppSpec sección de «recursos» para despliegues de AWS Lambda La sección `'resources'` especifica la función de Lambda que se va a implementar y tiene la siguiente estructura: YAML: ``` resources: - name-of-function-to-deploy: type: "AWS::Lambda::Function" properties: name: name-of-lambda-function-to-deploy alias: alias-of-lambda-function-to-deploy currentversion: version-of-the-lambda-function-traffic-currently-points-to targetversion: version-of-the-lambda-function-to-shift-traffic-to ``` JSON: ``` "resources": [ { "name-of-function-to-deploy" { "type": "AWS::Lambda::Function", "properties": { "name": "name-of-lambda-function-to-deploy", "alias": "alias-of-lambda-function-to-deploy", "currentversion": "version-of-the-lambda-function-traffic-currently-points-to", "targetversion": "version-of-the-lambda-function-to-shift-traffic-to" } } } ] ``` Cada propiedad se especifica con una cadena. + `name`: obligatorio. Es el nombre de la función de Lambda que se va a implementar. + `alias`: obligatorio. Es el nombre del alias de la función de Lambda. + `currentversion`: obligatorio. Es la versión de la función de Lambda a la que apunta actualmente el tráfico. Este valor debe ser un entero positivo válido. + `targetversion`: obligatorio. Es la versión de la función de Lambda a la que se va a desviar el tráfico. Este valor debe ser un entero positivo válido. ## AppSpec sección de «recursos» para las implementaciones de Amazon ECS La sección `'resources'` especifica el servicio de Amazon ECS que se va a implementar y tiene la siguiente estructura: YAML: ``` Resources: - TargetService: Type: AWS::ECS::Service Properties: TaskDefinition: "task-definition-arn" LoadBalancerInfo: ContainerName: "ecs-container-name" ContainerPort: "ecs-application-port" # Optional properties PlatformVersion: "ecs-service-platform-version" NetworkConfiguration: AwsvpcConfiguration: Subnets: ["ecs-subnet-1","ecs-subnet-n"] SecurityGroups: ["ecs-security-group-1","ecs-security-group-n"] AssignPublicIp: "ENABLED | DISABLED" CapacityProviderStrategy: - Base: integer CapacityProvider: "capacityProviderA" Weight: integer - Base: integer CapacityProvider: "capacityProviderB" Weight: integer ``` JSON: ``` "Resources": [ { "TargetService": { "Type": "AWS::ECS::Service", "Properties": { "TaskDefinition": "task-definition-arn", "LoadBalancerInfo": { "ContainerName": "ecs-container-name", "ContainerPort": "ecs-application-port" }, "PlatformVersion": "ecs-service-platform-version", "NetworkConfiguration": { "AwsvpcConfiguration": { "Subnets": [ "ecs-subnet-1", "ecs-subnet-n" ], "SecurityGroups": [ "ecs-security-group-1", "ecs-security-group-n" ], "AssignPublicIp": "ENABLED | DISABLED" } }, "CapacityProviderStrategy": [ { "Base": integer, "CapacityProvider": "capacityProviderA", "Weight": integer }, { "Base": integer, "CapacityProvider": "capacityProviderB", "Weight": integer } ] } } } ] ``` Cada propiedad se especifica con una cadena excepto `ContainerPort`, que es un número. + `TaskDefinition`: obligatorio. Esta es la definición de tarea para el servicio de Amazon ECS que se va a implementar. Se especifica con el ARN de la definición de tarea. El formato del ARN es `arn:aws:ecs:aws-region:account-id:task-definition/task-definition-family:task-definition-revision`. Para obtener más información, consulte [Nombres de recursos de Amazon (ARNs) y espacios de nombres AWS de servicios](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html). **nota** La parte `:task-definition-revision` del ARN es opcional. Si se omite, Amazon ECS utiliza la última revisión ACTIVA de la definición de la tarea. + `ContainerName`: obligatorio. Este es el nombre del contenedor de Amazon ECS que contiene la aplicación de Amazon ECS. Debe ser un contenedor especificado en la definición de tarea de Amazon ECS. + `ContainerPort`: obligatorio. Este es el puerto del contenedor al que se enrutará el tráfico. + `PlatformVersion`: opcional. La versión de la plataforma de las tareas Fargate en el servicio de Amazon ECS implementado. Para obtener más información, consulte [Versiones de la plataforma de AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/platform_versions.html). Si no se especifica, se utilizará `LATEST` de forma predeterminada. + `NetworkConfiguration`: opcional. En `AwsvpcConfiguration`, puede especificar lo siguiente. Para obtener más información, consulte la *referencia [AwsVpcConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AwsVpcConfiguration.html)de la API de Amazon ECS Container Service*. + `Subnets`: opcional. Una lista separada por comas de una o varias subredes en su servicio de Amazon ECS. + `SecurityGroups`: opcional. Una lista separada por comas de uno o varios grupos de seguridad en su Amazon Elastic Container Service. + `AssignPublicIp`: opcional. Una cadena que especifica si su interfaz de red elástica del servicio de Amazon ECS recibe una dirección IP pública. Los valores válidos son `ENABLED` y `DISABLED`. **nota** Deben especificarse todos o ninguno de los ajustes de `NetworkConfiguration`. Por ejemplo, si desea especificar `Subnets`, también debe especificar `SecurityGroups` y `AssignPublicIp`. Si no se especifica ninguno, CodeDeploy utiliza la configuración actual de Amazon ECS de la red. + `CapacityProviderStrategy`: opcional. Una lista de los proveedores de capacidad de Amazon ECS que desea utilizar para su implementación. Para obtener más información, consulte [Proveedores de capacidad de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-capacity-providers.html) en la *Guía para desarrolladores de Amazon Elastic Container Service*. Puede especificar la siguiente configuración para cada proveedor de capacidad. Para obtener más información sobre estos ajustes, consulte [AWS::ECS::ServiceCapacityProviderStrategyItem](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-capacityproviderstrategyitem.html)la *Guía AWS CloudFormation del usuario* + `Base`: opcional. El valor de base designa cuántas tareas, como mínimo, se ejecutarán en el proveedor de capacidad especificado. Solo un proveedor de capacidad en una estrategia de proveedor de capacidad puede tener una base definida. Si no se especifica ningún valor, se utiliza el valor predeterminado 0. + `CapacityProvider`: opcional. Nombre abreviado del proveedor de capacidad. Ejemplo: *capacityProviderA* + `Weight`: opcional. El valor *peso* designa el porcentaje relativo del número total de tareas lanzadas que debe utilizar el proveedor de capacidad especificado. El valor `weight` se tomará en cuenta luego de que el valor `base` se cumpla, en el caso de haber sido definido. Si no se especifica ningún valor `weight`, se utiliza el valor predeterminado `0`. Cuando se especifican varios proveedores de capacidad dentro de una estrategia de provisión de capacidad, al menos uno de los proveedores de capacidad deberá tener un valor de peso superior a cero y los proveedores de capacidad con un peso de `0` no se utilizarán para asignar tareas. Si especifican varios proveedores de capacidad en una estrategia en la que todos tienen un peso de `0`, se producirá un error en cualquiera de las acciones `RunTask` o `CreateService` que utilicen la estrategia de provisión de capacidad. Por ejemplo, si define una estrategia que contiene dos proveedores de capacidad y ambos tienen un peso de `1`, cuando `base` se cumpla las tareas se dividirán uniformemente entre los dos proveedores de capacidad. Siguiendo esta misma lógica, si especifica una ponderación de `1` para *capacityProviderA* y una ponderación de `4` para *capacityProviderB*, entonces por cada tarea que se ejecute usando *capacityProviderA*, habrá cuatro tareas que usen *capacityProviderB*. # AppSpec sección de «permisos» (solo para despliegues de EC2/on-premise) `'permissions'`En esta sección se especifica cómo se deben aplicar los permisos especiales, si los hay, a los archivos y directories/folders en la `'files'` sección después de copiarlos en la instancia. Puede especificar varias instrucciones `object`. Esta sección es opcional. Se aplica únicamente a las instancias de Amazon Linux, Ubuntu Server y RHEL. **nota** La sección `'permissions'` solo se utiliza para las implementaciones de EC2/en las instalaciones. No se utiliza para las implementaciones de AWS Lambda o Amazon ECS. Esta sección tiene la siguiente estructura: ``` permissions: - object: object-specification pattern: pattern-specification except: exception-specification owner: owner-account-name group: group-name mode: mode-specification acls: - acls-specification context: user: user-specification type: type-specification range: range-specification type: - object-type ``` Las instrucciones son las siguientes: + `object`: obligatorio. Este es un conjunto de objetos del sistema de archivos (archivos o directorios/carpetas) a los que se aplican los permisos especificados una vez que se copian en la instancia. Especifique `object` con una cadena. + `pattern`: opcional. Especifica un patrón para aplicar permisos. Si no se especifica o se especifica con los caracteres especiales **"\$1\$1"**, los permisos se aplican a todos los archivos o directorios coincidentes, en función del valor de `type`. Especifique `pattern` con una cadena con comillas (""). + `except`: opcional. Especifica los archivos o directorios que son excepciones a `pattern`. Especifique `except` con una lista separada por comas de cadenas entre corchetes. + `owner`: opcional. El nombre del propietario de `object`. Si no se especifica, todos los propietarios existentes aplicados a la estructura original de archivos o directorios/carpetas permanecen sin cambios después de la operación de copia. Especifique `owner` con una cadena. + `group`: opcional. El nombre del grupo de `object`. Si no se especifica, todos los grupos existentes aplicados a la estructura original de archivos o directorios/carpetas permanecen sin cambios después de la operación de copia. Especifique `group` con una cadena. + `mode`: opcional. Un valor numérico que especifica los permisos que se van a aplicar a `object`. La configuración del modo sigue la sintaxis del comando chmod de Linux. **importante** Si el valor incluye un cero a la izquierda, debe ponerlo entre comillas dobles o eliminar el cero inicial para que solo queden tres dígitos. **nota** El ajuste **u\$1x** no admite una notación simbólica como `mode`. Ejemplos: + `mode: "0644"` otorga permisos de lectura y escritura al propietario del objeto (6), permisos de solo lectura al grupo (4) y permisos de solo lectura a todos los demás usuarios (4). + `mode: 644` concede los mismos permisos que `mode: "0644"`. + `mode: 4755` establece el atributo setuid (4), otorga permisos de control total al propietario (7), otorga permisos de lectura y ejecución al grupo (5) y otorga permisos de lectura y ejecución a todos los demás usuarios (5). Para ver más ejemplos, consulte la documentación del comando chmod de Linux. Si no se especifica mode, todos los modos existentes aplicados a la estructura original de archivos o carpetas permanecen sin cambios después de la operación de copia. + `acls`: opcional. Una lista de cadenas de caracteres que representan una o varias entradas de la lista de control de acceso (ACL) aplicadas a `object`. Por ejemplo, **u:bob:rw** representa permisos de lectura y escritura para el usuario **bob**. (Para ver más ejemplos, consulte los ejemplos de formato de entradas de ACL en la documentación del comando `setfacl` de Linux). Puede especificar varias entradas de ACL. Si no `acls` se especifica, cualquier elemento existente ACLs aplicado al archivo o directory/folder estructura original permanecerá inalterado tras la operación de copia. Estas sustituyen a las existentes ACLs. Especifique una `acls` con un guion (-), seguido de un espacio y, a continuación, una cadena (por ejemplo, `- u:jane:rw`). Si tiene varias ACL, cada una de ellas se especifica en una línea independiente. **nota** Si se configuran usuarios sin nombre, grupos sin nombre u otras entradas de ACL similares, se produce un error en el AppSpec archivo. Utilice `mode` para especificar estos tipos de permisos en su lugar. + `context`: opcional. En el caso de las instancias habilitadas para Linux (SELinux) con seguridad mejorada, una lista de etiquetas de contexto relevantes para la seguridad que se deben aplicar a los objetos copiados. Las etiquetas se especifican como claves que contienen `user`, `type` y `range`. (Para obtener más información, consulte la documentación). SELinux Cada clave se escribe con una cadena. Si no se especifica, cualquier etiqueta existente aplicada al archivo o directory/folder estructura original permanecerá inalterada tras la operación de copia. + `user`: opcional. El SELinux usuario. + `type`: opcional. El nombre del SELinux tipo. + `range`: opcional. El especificador SELinux de rango. No tiene ningún efecto a no ser que Multi-Level Security (MLS) y Multi-Category Security (MCS) estén habilitados en la máquina. Si no está habilitada, el valor predeterminado de `range` es **s0**. Especifique `context` con una cadena (por ejemplo, `user: unconfined_u`). Cada `context` se especifica en una línea separada. + `type`: opcional. Los tipos de objetos a los que se van a aplicar los permisos especificados. `type` es una cadena que se puede establecer en **file** o en **directory**. Si se especifica **file**, los permisos se aplican únicamente a los archivos que estén incluidos en `object` después de la operación de copia (y no al propio `object`). Si **directory** se especifica, los permisos se aplican de forma recursiva a todos los directories/folders que se encuentren en cualquier punto `object` después de la operación de copia (pero no a `object` sí mismos). Especifique `type` con un guion (-), seguido de un espacio y, a continuación, una cadena (por ejemplo, `- file`). ## Ejemplo de la sección "permissions" En el siguiente ejemplo se muestra cómo especificar la sección `'permissions'` con las instrucciones `object`, `pattern`, `except`, `owner`, `mode` y `type`. Este ejemplo se aplica únicamente a las instancias de Amazon Linux, Ubuntu Server y RHEL. En este ejemplo, se presupone que se copian los siguientes archivos y carpetas en la instancia en esta jerarquía: ``` /tmp `-- my-app |-- my-file-1.txt |-- my-file-2.txt |-- my-file-3.txt |-- my-folder-1 | |-- my-file-4.txt | |-- my-file-5.txt | `-- my-file-6.txt `-- my-folder-2 |-- my-file-7.txt |-- my-file-8.txt |-- my-file-9.txt `-- my-folder-3 ``` El siguiente AppSpec archivo muestra cómo establecer los permisos en estos archivos y carpetas después de copiarlos: ``` version: 0.0 os: linux # Copy over all of the folders and files with the permissions they # were originally assigned. files: - source: ./my-file-1.txt destination: /tmp/my-app - source: ./my-file-2.txt destination: /tmp/my-app - source: ./my-file-3.txt destination: /tmp/my-app - source: ./my-folder-1 destination: /tmp/my-app/my-folder-1 - source: ./my-folder-2 destination: /tmp/my-app/my-folder-2 # 1) For all of the files in the /tmp/my-app folder ending in -3.txt # (for example, just my-file-3.txt), owner = adm, group = wheel, and # mode = 464 (-r--rw-r--). permissions: - object: /tmp/my-app pattern: "*-3.txt" owner: adm group: wheel mode: 464 type: - file # 2) For all of the files ending in .txt in the /tmp/my-app # folder, but not for the file my-file-3.txt (for example, # just my-file-1.txt and my-file-2.txt), # owner = ec2-user and mode = 444 (-r--r--r--). - object: /tmp/my-app pattern: "*.txt" except: [my-file-3.txt] owner: ec2-user mode: 444 type: - file # 3) For all the files in the /tmp/my-app/my-folder-1 folder except # for my-file-4.txt and my-file-5.txt, (for example, # just my-file-6.txt), owner = operator and mode = 646 (-rw-r--rw-). - object: /tmp/my-app/my-folder-1 pattern: "**" except: [my-file-4.txt, my-file-5.txt] owner: operator mode: 646 type: - file # 4) For all of the files that are immediately under # the /tmp/my-app/my-folder-2 folder except for my-file-8.txt, # (for example, just my-file-7.txt and # my-file-9.txt), owner = ec2-user and mode = 777 (-rwxrwxrwx). - object: /tmp/my-app/my-folder-2 pattern: "**" except: [my-file-8.txt] owner: ec2-user mode: 777 type: - file # 5) For all folders at any level under /tmp/my-app that contain # the name my-folder but not # /tmp/my-app/my-folder-2/my-folder-3 (for example, just # /tmp/my-app/my-folder-1 and /tmp/my-app/my-folder-2), # owner = ec2-user and mode = 555 (dr-xr-xr-x). - object: /tmp/my-app pattern: "*my-folder*" except: [tmp/my-app/my-folder-2/my-folder-3] owner: ec2-user mode: 555 type: - directory # 6) For the folder /tmp/my-app/my-folder-2/my-folder-3, # group = wheel and mode = 564 (dr-xrw-r--). - object: /tmp/my-app/my-folder-2/my-folder-3 group: wheel mode: 564 type: - directory ``` Los permisos resultantes son los siguientes: ``` -r--r--r-- ec2-user root my-file-1.txt -r--r--r-- ec2-user root my-file-2.txt -r--rw-r-- adm wheel my-file-3.txt dr-xr-xr-x ec2-user root my-folder-1 -rw-r--r-- root root my-file-4.txt -rw-r--r-- root root my-file-5.txt -rw-r--rw- operator root my-file-6.txt dr-xr-xr-x ec2-user root my-folder-2 -rwxrwxrwx ec2-user root my-file-7.txt -rw-r--r-- root root my-file-8.txt -rwxrwxrwx ec2-user root my-file-9.txt dr-xrw-r-- root wheel my-folder-3 ``` En el siguiente ejemplo se muestra cómo especificar la sección `'permissions'` con la adición de las instrucciones `acls` y `context`. Este ejemplo se aplica únicamente a las instancias de Amazon Linux, Ubuntu Server y RHEL. ``` permissions: - object: /var/www/html/WordPress pattern: "**" except: [/var/www/html/WordPress/ReadMe.txt] owner: bob group: writers mode: 644 acls: - u:mary:rw - u:sam:rw - m::rw context: user: unconfined_u type: httpd_sys_content_t range: s0 type: - file ``` # AppSpec sección de «ganchos» El contenido de la `'hooks'` sección del AppSpec archivo varía en función de la plataforma informática de la implementación. La sección `'hooks'` de una implementación de EC2/en las instalaciones contiene los mapeos que vinculan los enlaces de eventos del ciclo de vida de la implementación a uno o varios scripts. La sección `'hooks'` de una implementación de Lambda o de Amazon ECS especifica las funciones de validación de Lambda que se ejecutan durante un evento del ciclo de vida de la implementación. Si un enlace de evento no está presente, no se ejecuta ninguna operación para ese evento. Esta sección solo es necesaria si ejecuta scripts o funciones de validación de Lambda como parte de la implementación. **Topics** + [AppSpec sección «ganchos» para una implementación de Amazon ECS](#appspec-hooks-ecs) + [AppSpec sección de «ganchos» para una implementación de AWS Lambda](#appspec-hooks-lambda) + [AppSpec Sección de «enganches» para una implementación local de EC2/](#appspec-hooks-server) ## AppSpec sección «ganchos» para una implementación de Amazon ECS **Topics** + [Lista de enlaces de eventos de ciclo de vida para una implementación de Amazon ECS](#reference-appspec-file-structure-hooks-list-ecs) + [Orden de ejecución de los enlaces en una implementación de Amazon ECS.](#reference-appspec-file-structure-hooks-run-order-ecs) + [Estructura de la sección "hooks"](#reference-appspec-file-structure-hooks-section-structure-ecs) + [Ejemplo de función de “hooks” de Lambda](#reference-appspec-file-structure-hooks-section-structure-ecs-sample-function) ### Lista de enlaces de eventos de ciclo de vida para una implementación de Amazon ECS Un enlace de AWS Lambda es una función de Lambda especificada con una cadena en una línea nueva después del nombre del evento del ciclo de vida. Cada enlace se ejecuta una vez por implementación. A continuación, se muestran las descripciones de los eventos del ciclo de vida donde puede ejecutar un enlace durante una implementación de Amazon ECS. + `BeforeInstall`: se utiliza para ejecutar tareas antes de crear el conjunto de tareas de sustitución. Un grupo de destino se asocia al conjunto de tareas original. Si se especifica un agente de escucha de prueba opcional, se asociada al conjunto de tareas original. En este momento no es posible una restauración. + `AfterInstall`: se utiliza para ejecutar tareas una vez que el conjunto de tareas se ha creado y uno de los grupos de destino se ha asociado con él. Si se especifica un agente de escucha de prueba opcional, se asociada al conjunto de tareas original. El resultado de la función de enlace en este evento de ciclo de vida puede activar una restauración. + `AfterAllowTestTraffic`: se utiliza para ejecutar tareas después de que el oyente de prueba envía tráfico al conjunto de tareas de sustitución. El resultado de la función de enlace en este punto puede activar una restauración. + `BeforeAllowTraffic`: se utiliza para ejecutar tareas una vez que el segundo grupo de destino se ha asociado con el conjunto de tareas de sustitución, pero antes de que se envíe tráfico al conjunto de tareas de sustitución. El resultado de la función de enlace en este evento de ciclo de vida puede activar una restauración. + `AfterAllowTraffic`: se utiliza para ejecutar tareas después de que el segundo grupo de destino envíe tráfico al conjunto de tareas de sustitución. El resultado de la función de enlace en este evento de ciclo de vida puede activar una restauración. Para obtener más información, consulte [¿Qué sucede durante una implementación de Amazon ECS?](deployment-steps-ecs.md#deployment-steps-what-happens) y [Tutorial: Implementación de un servicio de Amazon ECS con una prueba de validación](tutorial-ecs-deployment-with-hooks.md). ### Orden de ejecución de los enlaces en una implementación de Amazon ECS. En una implementación de Amazon ECS, los enlaces de eventos se ejecutan en el siguiente orden: ![\[El orden de los enlaces de eventos en una implementación de Amazon ECS.\]](http://docs.aws.amazon.com/es_es/codedeploy/latest/userguide/images/lifecycle-event-order-ecs.png) **nota** Los eventos de **inicio **TestTraffic**AllowTraffic******, **instalación** y **finalización** de la implementación no se pueden programar, por lo que aparecen en gris en este diagrama. ### Estructura de la sección "hooks" Los siguientes ejemplos muestran la estructura de la sección `'hooks'`. Mediante YAML: ``` Hooks: - BeforeInstall: "BeforeInstallHookFunctionName" - AfterInstall: "AfterInstallHookFunctionName" - AfterAllowTestTraffic: "AfterAllowTestTrafficHookFunctionName" - BeforeAllowTraffic: "BeforeAllowTrafficHookFunctionName" - AfterAllowTraffic: "AfterAllowTrafficHookFunctionName" ``` Mediante JSON: ``` "Hooks": [ { "BeforeInstall": "BeforeInstallHookFunctionName" }, { "AfterInstall": "AfterInstallHookFunctionName" }, { "AfterAllowTestTraffic": "AfterAllowTestTrafficHookFunctionName" }, { "BeforeAllowTraffic": "BeforeAllowTrafficHookFunctionName" }, { "AfterAllowTraffic": "AfterAllowTrafficHookFunctionName" } ] } ``` ### Ejemplo de función de “hooks” de Lambda Utilice la `'hooks'` sección para especificar una función de Lambda a la que CodeDeploy se pueda llamar para validar una implementación de Amazon ECS. Puede utilizar la misma función o una distinta para los eventos de ciclo de vida de implementación `BeforeInstall`, `AfterInstall`, `AfterAllowTestTraffic`, `BeforeAllowTraffic` y `AfterAllowTraffic`. Tras completar las pruebas de validación, la `AfterAllowTraffic` función Lambda vuelve a llamar CodeDeploy y entrega un resultado de `Succeeded` o. `Failed` **importante** Se considera que el despliegue ha fallado si CodeDeploy la función de validación de Lambda no lo notifica en el plazo de una hora. Antes de invocar una función de enlace de Lambda, el servidor debe recibir una notificación con el ID de implementación y el ID de ejecución del enlace de evento del ciclo de vida con el comando `putLifecycleEventHookExecutionStatus`. A continuación, se muestra una función de enlace de Lambda de ejemplo escrita en Node.js. ``` 'use strict'; const aws = require('aws-sdk'); const codedeploy = new aws.CodeDeploy({apiVersion: '2014-10-06'}); exports.handler = (event, context, callback) => { //Read the DeploymentId from the event payload. var deploymentId = event.DeploymentId; //Read the LifecycleEventHookExecutionId from the event payload var lifecycleEventHookExecutionId = event.LifecycleEventHookExecutionId; /* Enter validation tests here. */ // Prepare the validation test results with the deploymentId and // the lifecycleEventHookExecutionId for CodeDeploy. var params = { deploymentId: deploymentId, lifecycleEventHookExecutionId: lifecycleEventHookExecutionId, status: 'Succeeded' // status can be 'Succeeded' or 'Failed' }; // Pass CodeDeploy the prepared validation test results. codedeploy.putLifecycleEventHookExecutionStatus(params, function(err, data) { if (err) { // Validation failed. callback('Validation test failed'); } else { // Validation succeeded. callback(null, 'Validation test succeeded'); } }); }; ``` ## AppSpec sección de «ganchos» para una implementación de AWS Lambda **Topics** + [Lista de enlaces de eventos del ciclo de vida para una implementación de AWS Lambda](#reference-appspec-file-structure-hooks-list-lambda) + [Orden de ejecución de los enlaces en una implementación de versiones de funciones de Lambda](#reference-appspec-file-structure-hooks-run-order-lambda) + [Estructura de la sección "hooks"](#reference-appspec-file-structure-hooks-section-structure-lambda) + [Ejemplo de función de “hooks” de Lambda](#reference-appspec-file-structure-hooks-section-structure-lambda-sample-function) ### Lista de enlaces de eventos del ciclo de vida para una implementación de AWS Lambda Un enlace de AWS Lambda es una función de Lambda especificada con una cadena en una línea nueva después del nombre del evento del ciclo de vida. Cada enlace se ejecuta una vez por implementación. Estas son las descripciones de los ganchos disponibles para su AppSpec uso en el archivo. + **BeforeAllowTraffic**— Se utiliza para ejecutar tareas antes de que el tráfico se traslade a la versión de la función Lambda implementada. + **AfterAllowTraffic**— Se utiliza para ejecutar tareas después de que todo el tráfico se haya desplazado a la versión de la función Lambda implementada. ### Orden de ejecución de los enlaces en una implementación de versiones de funciones de Lambda En una implementación de versiones de funciones de Lambda sin servidor, los enlaces de eventos se ejecutan en el siguiente orden: ![\[El orden de los enlaces de eventos en una implementación de Lambda.\]](http://docs.aws.amazon.com/es_es/codedeploy/latest/userguide/images/lifecycle-event-order-lambda.png) **nota** Los eventos de **inicio** y **finalización** de la implementación no se pueden programar, por lo que aparecen en gris en este diagrama. **AllowTraffic** ### Estructura de la sección "hooks" Los siguientes ejemplos muestran la estructura de la sección "hooks". Mediante YAML: ``` hooks: - BeforeAllowTraffic: BeforeAllowTrafficHookFunctionName - AfterAllowTraffic: AfterAllowTrafficHookFunctionName ``` Mediante JSON: ``` "hooks": [{ "BeforeAllowTraffic": "BeforeAllowTrafficHookFunctionName" }, { "AfterAllowTraffic": "AfterAllowTrafficHookFunctionName" }] ``` ### Ejemplo de función de “hooks” de Lambda Utilice la sección «hooks» para especificar una función de Lambda a la que CodeDeploy se pueda llamar para validar una implementación de Lambda. Puede utilizar la misma función o una diferente para los eventos de ciclo de vida de implementación `BeforeAllowTraffic` y `AfterAllowTraffic`. Tras completar las pruebas de validación, la función de validación de Lambda vuelve a llamar CodeDeploy y entrega un resultado de `Succeeded` o. `Failed` **importante** Se considera que el despliegue ha fallado si CodeDeploy la función de validación de Lambda no lo notifica en el plazo de una hora. Antes de invocar una función de enlace de Lambda, el servidor debe recibir una notificación con el ID de implementación y el ID de ejecución del enlace de evento del ciclo de vida con el comando `putLifecycleEventHookExecutionStatus`. A continuación, se muestra una función de enlace de Lambda de ejemplo escrita en Node.js. ``` 'use strict'; const aws = require('aws-sdk'); const codedeploy = new aws.CodeDeploy({apiVersion: '2014-10-06'}); exports.handler = (event, context, callback) => { //Read the DeploymentId from the event payload. var deploymentId = event.DeploymentId; //Read the LifecycleEventHookExecutionId from the event payload var lifecycleEventHookExecutionId = event.LifecycleEventHookExecutionId; /* Enter validation tests here. */ // Prepare the validation test results with the deploymentId and // the lifecycleEventHookExecutionId for CodeDeploy. var params = { deploymentId: deploymentId, lifecycleEventHookExecutionId: lifecycleEventHookExecutionId, status: 'Succeeded' // status can be 'Succeeded' or 'Failed' }; // Pass CodeDeploy the prepared validation test results. codedeploy.putLifecycleEventHookExecutionStatus(params, function(err, data) { if (err) { // Validation failed. callback('Validation test failed'); } else { // Validation succeeded. callback(null, 'Validation test succeeded'); } }); }; ``` ## AppSpec Sección de «enganches» para una implementación local de EC2/ **Topics** + [Lista de enlaces de eventos del ciclo de vida](#reference-appspec-file-structure-hooks-list) + [Disponibilidad de los enlaces de eventos del ciclo de vida](#reference-appspec-file-structure-hooks-availability) + [Orden de ejecución de los enlaces en una implementación](#reference-appspec-file-structure-hooks-run-order) + [Estructura de la sección "hooks"](#reference-appspec-file-structure-hooks-section-structure) + [Hacer referencia a los archivos en los scripts de enlaces](#codedeploy-agent-working-directory) + [Disponibilidad de las variables de entorno para los enlaces](#reference-appspec-file-structure-environment-variable-availability) + [Ejemplo de enlaces](#reference-appspec-file-structure-hooks-example) ### Lista de enlaces de eventos del ciclo de vida Un enlace de implementación de EC2/en las instalaciones se ejecuta una vez por cada implementación en una instancia. Puede especificar uno o varios scripts para ejecutar en un enlace. Cada enlace de un evento del ciclo de vida se especifica con una cadena en una línea independiente. Estas son las descripciones de los ganchos disponibles para su uso en el archivo. AppSpec Para obtener información sobre los enlaces de eventos del ciclo de vida válidos para cada tipo de implementación y restauración, consulte [Disponibilidad de los enlaces de eventos del ciclo de vida](#reference-appspec-file-structure-hooks-availability). + `ApplicationStop`: este evento de ciclo de vida de la implementación se produce incluso antes de que se descargue la revisión de la aplicación. Puede especificar scripts para este evento para detener con fluidez la aplicación o para eliminar los paquetes instalados actualmente en la preparación de una implementación. El AppSpec archivo y los scripts utilizados para este evento del ciclo de vida de la implementación provienen de la revisión anterior de la aplicación que se implementó correctamente. **nota** No existe ningún AppSpec archivo en una instancia antes de realizar la implementación en ella. Por este motivo, el enlace `ApplicationStop` no se ejecuta la primera vez que se realiza la implementación en la instancia. Puede utilizar el enlace `ApplicationStop` la segunda vez que realice la implementación en una instancia. Para determinar la ubicación de la última revisión de la aplicación implementada correctamente, el CodeDeploy agente busca la ubicación que aparece en el `deployment-group-id_last_successful_install` archivo. Este archivo se encuentra en: Carpeta `/opt/codedeploy-agent/deployment-root/deployment-instructions` en las instancias de Amazon EC2 en Amazon Linux, Ubuntu Server y RHEL. Carpeta `C:\ProgramData\Amazon\CodeDeploy\deployment-instructions` en las instancias de Amazon EC2 en Windows Server. Para solucionar un error de una implementación durante el evento del ciclo de vida de la implementación `ApplicationStop`, consulte [Solución de problemas relacionados con un error o un evento del ciclo de vida de ApplicationStop la BeforeBlockTraffic implementación AfterBlockTraffic](troubleshooting-deployments.md#troubleshooting-deployments-lifecycle-event-failures). + `DownloadBundle`— Durante este evento del ciclo de vida de la implementación, el CodeDeploy agente copia los archivos de revisión de la aplicación en una ubicación temporal: Carpeta `/opt/codedeploy-agent/deployment-root/deployment-group-id/deployment-id/deployment-archive` en las instancias de Amazon EC2 en Amazon Linux, Ubuntu Server y RHEL. Carpeta `C:\ProgramData\Amazon\CodeDeploy\deployment-group-id\deployment-id\deployment-archive` en las instancias de Amazon EC2 en Windows Server. Este evento está reservado para el CodeDeploy agente y no se puede utilizar para ejecutar scripts. Para solucionar un error de una implementación durante el evento del ciclo de vida de la implementación `DownloadBundle`, consulte [Solución de problemas de un evento fallido en el ciclo de vida de una DownloadBundle implementación con UnknownError: no abierto para lectura](troubleshooting-deployments.md#troubleshooting-deployments-downloadbundle). + `BeforeInstall`: puede usar este evento de ciclo de vida de la implementación para tareas de preinstalación, como descifrar archivos y crear un backup de la versión actual. + `Install`— Durante este evento del ciclo de vida de la implementación, el CodeDeploy agente copia los archivos de revisión de la ubicación temporal a la carpeta de destino final. Este evento está reservado para el CodeDeploy agente y no se puede utilizar para ejecutar scripts. + `AfterInstall`: puede usar este evento de ciclo de vida de la implementación para configurar la aplicación o para cambiar los permisos de los archivos. + `ApplicationStart`: este evento de ciclo de vida de la implementación se utiliza normalmente para reiniciar los servicios que se detuvieron durante `ApplicationStop`. + `ValidateService`: este es el último evento de ciclo de vida de la implementación. Se utiliza para verificar que la implementación se ha completado correctamente. + `BeforeBlockTraffic`: puede utilizar este evento de ciclo de vida de la implementación para ejecutar tareas en las instancias antes de que se cancele su registro de un equilibrador de carga. Para solucionar un error de una implementación durante el evento del ciclo de vida de la implementación `BeforeBlockTraffic`, consulte [Solución de problemas relacionados con un error o un evento del ciclo de vida de ApplicationStop la BeforeBlockTraffic implementación AfterBlockTraffic](troubleshooting-deployments.md#troubleshooting-deployments-lifecycle-event-failures). + `BlockTraffic`: durante este evento de ciclo de vida de la implementación, se bloquea el tráfico de Internet a las instancias que están actualmente sirviendo tráfico. Este evento está reservado para el CodeDeploy agente y no se puede usar para ejecutar scripts. + `AfterBlockTraffic`: puede utilizar este evento de ciclo de vida de la implementación para ejecutar tareas en las instancias después de que se cancele su equilibrador de carga. Para solucionar un error de una implementación durante el evento del ciclo de vida de la implementación `AfterBlockTraffic`, consulte [Solución de problemas relacionados con un error o un evento del ciclo de vida de ApplicationStop la BeforeBlockTraffic implementación AfterBlockTraffic](troubleshooting-deployments.md#troubleshooting-deployments-lifecycle-event-failures). + `BeforeAllowTraffic`: puede utilizar este evento de ciclo de vida de la implementación para ejecutar tareas en las instancias antes de que se registren con un equilibrador de carga. + `AllowTraffic`: durante este evento de ciclo de vida de la implementación, se permite el acceso del tráfico de Internet a las instancias después de una implementación. Este evento está reservado para el CodeDeploy agente y no se puede usar para ejecutar scripts. + `AfterAllowTraffic`: puede utilizar este evento de ciclo de vida de la implementación para ejecutar tareas en las instancias después de que se registren con un equilibrador de carga. ### Disponibilidad de los enlaces de eventos del ciclo de vida En la siguiente tabla se indican los enlaces de eventos del ciclo de vida disponibles para cada escenario de implementación y restauración. | Nombre de evento del ciclo de vida | Implementación de lanzamiento de Auto Scaling¹ | Implementación de terminación de Auto Scaling¹ | Implementación local¹ | Implementación blue/green: instancias originales | Implementación blue/green: instancias de sustitución | Restauración de implementación blue/green: instancias originales | Restauración de implementación blue/green: instancias de sustitución | | --- | --- | --- | --- | --- | --- | --- | --- | | ApplicationStop | ✓ | ✓ | ✓ | | ✓ | | | | DownloadBundle³ | ✓ | | ✓ | | ✓ | | | | BeforeInstall | ✓ | | ✓ | | ✓ | | | | Install² | ✓ | | ✓ | | ✓ | | | | AfterInstall | ✓ | | ✓ | | ✓ | | | | ApplicationStart | ✓ | | ✓ | | ✓ | | | | ValidateService | ✓ | | ✓ | | ✓ | | | | BeforeBlockTraffic | | ✓ | ✓ | ✓ | | | ✓ | | BlockTraffic³ | | ✓ | ✓ | ✓ | | | ✓ | | AfterBlockTraffic | | ✓ | ✓ | ✓ | | | ✓ | | BeforeAllowTraffic | ✓ | | ✓ | | ✓ | ✓ | | | AllowTraffic³ | ✓ | | ✓ | | ✓ | ✓ | | | AfterAllowTraffic | ✓ | | ✓ | | ✓ | ✓ | | | ¹ Para obtener más información sobre implementaciones de Amazon EC2 Auto Scaling, consulte [Cómo funciona Amazon EC2 Auto Scaling con CodeDeploy](integrations-aws-auto-scaling.md#integrations-aws-auto-scaling-behaviors). ² Se aplica también a la reversión de una implementación local. ³ Reservado para CodeDeploy operaciones. No se puede utilizar para ejecutar scripts. | ### Orden de ejecución de los enlaces en una implementación **Implementaciones de lanzamiento de Auto Scaling** Durante una implementación de lanzamiento de Auto Scaling, CodeDeploy ejecuta los enlaces de eventos en el siguiente orden. Para obtener más información sobre implementaciones de lanzamiento Auto Scaling, consulte [Cómo funciona Amazon EC2 Auto Scaling con CodeDeploy](integrations-aws-auto-scaling.md#integrations-aws-auto-scaling-behaviors). ![\[El orden de los enlaces de eventos durante una implementación de lanzamiento de Auto Scaling.\]](http://docs.aws.amazon.com/es_es/codedeploy/latest/userguide/images/lifecycle-event-order-scale-out.png) **nota** Los eventos de **inicio **DownloadBundle**AllowTraffic******, **instalación** y **finalización** de la implementación no se pueden programar, por lo que aparecen en gris en este diagrama. Sin embargo, puede editar la `'files'` sección del AppSpec archivo para especificar qué se instalará durante el evento de **instalación**. **Implementaciones de terminación de Auto Scaling** Durante un despliegue de terminación de Auto Scaling, CodeDeploy ejecuta los enlaces de eventos en el siguiente orden. Para obtener más información sobre implementaciones de terminación de Auto Scaling, consulte [Habilitación de implementaciones de terminación durante los eventos de reducción horizontal de Auto Scaling](integrations-aws-auto-scaling.md#integrations-aws-auto-scaling-behaviors-hook-enable). ![\[El orden de los enlaces de eventos durante una implementación de terminación de Auto Scaling.\]](http://docs.aws.amazon.com/es_es/codedeploy/latest/userguide/images/lifecycle-event-order-scale-in.png) **nota** Los eventos de **inicio** y **finalización** de la implementación no se pueden programar, por lo que aparecen en gris en este diagrama. **BlockTraffic** **Implementaciones in situ** En una implementación in situ, incluida la restauración de una implementación in situ, los enlaces de eventos se ejecutan en el orden siguiente: **nota** En el caso de las implementaciones locales, los seis enlaces relacionados con el bloqueo y el permiso del tráfico solo se aplican si se ha especificado un equilibrador de carga clásico, un equilibrador de carga de aplicación o un equilibrador de carga de red de Elastic Load Balancing en el grupo de implementación. ![\[El orden de los enlaces de eventos durante la restauración de una implementación local.\]](http://docs.aws.amazon.com/es_es/codedeploy/latest/userguide/images/lifecycle-event-order-in-place.png) **nota** Los eventos de **inicio **DownloadBundle****, **instalación** y **finalización** de la implementación no se pueden programar, por lo que aparecen en gris en este diagrama. Sin embargo, puede editar la `'files'` sección del AppSpec archivo para especificar qué se instalará durante el evento de **instalación**. **Implementaciones blue/green** En una blue/green implementación, los enlaces de eventos se ejecutan en el siguiente orden: ![\[El orden de los ganchos de eventos en una blue/green implementación.\]](http://docs.aws.amazon.com/es_es/codedeploy/latest/userguide/images/lifecycle-event-order-blue-green.png) **nota** Los eventos de **inicio **DownloadBundle**BlockTraffic**AllowTraffic********, **instalación** y **finalización** de la implementación no se pueden programar, por lo que aparecen en gris en este diagrama. Sin embargo, puede editar la sección de «archivos» del AppSpec archivo para especificar qué se instalará durante el evento de **instalación**. ### Estructura de la sección "hooks" La sección `'hooks'` tiene la siguiente estructura: ``` hooks: deployment-lifecycle-event-name: - location: script-location timeout: timeout-in-seconds runas: user-name ``` Puede incluir los siguientes elementos en una entrada **hook** detrás del nombre de evento del ciclo de vida de la implementación: ** ubicación ** Obligatorio. La ubicación en el paquete del archivo de script de la revisión. La ubicación de los scripts que especifica en la sección `hooks` es relativa a la raíz del paquete de revisión de la aplicación. Para obtener más información, consulte [Planificación de una revisión de CodeDeploy](application-revisions-plan.md). ** timeout ** Opcional. El número de segundos que se puede ejecutar el script antes de que se considere que se ha producido un error. El valor predeterminado es 3 600 segundos (1 hora). 3 600 segundos (1 hora) es la cantidad máxima de tiempo de ejecución permitido para el script para cada evento del ciclo de vida de la implementación. Si el script supera este límite, la implementación se detiene y la implementación en la instancia da un error. Asegúrese de que el número total de segundos especificados en **timeout** para todos los scripts en cada evento del ciclo de vida de la implementación no supere este límite. ** runas ** Opcional. El usuario que se va a suplantar al ejecutar el script. De forma predeterminada, este es el CodeDeploy agente que se ejecuta en la instancia. CodeDeploy no almacena contraseñas, por lo que no se puede suplantar la identidad del usuario si el usuario **runas** necesita una contraseña. Este ejemplo se aplica únicamente a las instancias de Amazon Linux y Ubuntu Server. ### Hacer referencia a los archivos en los scripts de enlaces Si va a conectar un script a un evento CodeDeploy del ciclo de vida, tal y como se describe en[AppSpec sección de «ganchos»](#reference-appspec-file-structure-hooks), y desea hacer referencia a un archivo (por ejemplo`helper.sh`) del script, tendrá que especificarlo mediante: `helper.sh` + (Recomendado) Una ruta absoluta. Consulte [Uso de rutas absolutas](#codedeploy-agent-working-dir-absolute). + Una ruta relativa. Consulte [Uso de rutas relativas](#codedeploy-agent-working-dir-relative). #### Uso de rutas absolutas Para hacer referencia a un archivo mediante su ruta *absoluta*, puede hacer lo siguiente: + Especifique la ruta absoluta en la `files` sección del AppSpec archivo, en la `destination` propiedad. A continuación, especifique la misma ruta absoluta en el script de enlace. Para obtener más información, consulte [AppSpec Sección de «archivos» (solo para despliegues de EC2/on-premise)](reference-appspec-file-structure-files.md). + Especifique una ruta absoluta dinámica en el script de enlace. Para obtener más información, consulte [Ubicación del archivo de implementación](#codedeploy-agent-working-dir-archive). **Ubicación del archivo de implementación** Durante el evento [DownloadBundle](#reference-appspec-file-structure-hooks-list)del ciclo de vida, el CodeDeploy agente extrae la [revisión](application-revisions.md) para el despliegue en un directorio que tiene el siguiente formato: `root-directory/deployment-group-id/deployment-id/deployment-archive` La *root-directory* parte de la ruta siempre se establece en el valor predeterminado que se muestra en la siguiente tabla o se controla mediante el ajuste de `:root_dir` configuración. Para obtener más información acerca de los ajustes de configuración, consulte [Referencia de configuración del agente de CodeDeploy](reference-agent-configuration.md). | Plataforma de agentes | Directorio raíz predeterminado | | --- | --- | | Linux: todas las distribuciones rpm | /opt/codedeploy-agent/deployment-root | | Ubuntu Server: todas las distribuciones deb | /opt/codedeploy-agent/deployment-root | | Windows Server | %ProgramData%\$1Amazon\$1CodeDeploy | Desde sus scripts de enlace, puede acceder al archivo de implementación actual utilizando la ruta del directorio raíz y las variables de entorno `DEPLOYMENT_ID` y `DEPLOYMENT_GROUP_ID`. Para obtener más información acerca de las que puede usar, consulte [Disponibilidad de las variables de entorno para los enlaces](#reference-appspec-file-structure-environment-variable-availability). Por ejemplo, así es como puede acceder a un archivo `data.json` que se encuentra en la raíz de su revisión en Linux: ``` #!/bin/bash rootDirectory="/opt/codedeploy-agent/deployment-root" # note: this will be different if you # customize the :root_dir configuration dataFile="$rootDirectory/$DEPLOYMENT_GROUP_ID/$DEPLOYMENT_ID/deployment-archive/data.json" data=$(cat dataFile) ``` Otro ejemplo: así es como puede acceder a un archivo `data.json` que se encuentra en la raíz de la revisión con Powershell en Windows: ``` $rootDirectory="$env:ProgramData\Amazon\CodeDeploy" # note: this will be different if you # customize the :root_dir configuration $dataFile="$rootDirectory\$env:DEPLOYMENT_GROUP_ID\$env:DEPLOYMENT_ID\deployment-archive\data.json" $data=(Get-Content $dataFile) ``` #### Uso de rutas relativas Para hacer referencia a un archivo mediante su ruta *relativa*, necesitará conocer el directorio de trabajo del CodeDeploy agente. Las rutas de los archivos son relativas a este directorio. La siguiente tabla muestra el directorio de trabajo de cada plataforma compatible del CodeDeploy agente. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/codedeploy/latest/userguide/reference-appspec-file-structure-hooks.html) ### Disponibilidad de las variables de entorno para los enlaces Durante cada evento del ciclo de vida de la implementación, los scripts de enlace pueden tener acceso a las siguientes variables de entorno: ** APPLICATION\$1NAME ** El nombre de la aplicación CodeDeploy que forma parte de la implementación actual (por ejemplo,`WordPress_App`). ** DEPLOYMENT\$1ID ** El ID se CodeDeploy ha asignado a la implementación actual (por ejemplo,`d-AB1CDEF23`). ** DEPLOYMENT\$1GROUP\$1NAME ** El nombre del grupo de despliegues CodeDeploy que forma parte del despliegue actual (por ejemplo,`WordPress_DepGroup`). ** DEPLOYMENT\$1GROUP\$1ID ** El ID del grupo de despliegues CodeDeploy que forma parte de la implementación actual (por ejemplo,`b1a2189b-dd90-4ef5-8f40-4c1c5EXAMPLE`). ** LIFECYCLE\$1EVENT ** El nombre del evento del ciclo de vida de la implementación actual (por ejemplo, `AfterInstall`). Estas variables de entorno son locales con respecto a cada evento del ciclo de vida de la implementación. Hay variables de entorno adicionales disponibles para conectar scripts de enlace en función del origen del paquete de implementación: **Paquete de Amazon S3** + **BUNDLE\$1BUCKET** El nombre del bucket de Amazon S3 desde el que se descargó el paquete de implementación (por ejemplo, `my-s3-bucket`). + **BUNDLE\$1KEY** La clave de objeto del paquete descargado dentro del bucket de Amazon S3 (por ejemplo, `WordPress_App.zip`). + **BUNDLE\$1VERSION** La versión del objeto del paquete (por ejemplo, `3sL4kqtJlcpXroDTDmJ+rmSpXd3dIbrHY+MTRCxf3vjVBH40Nr8X8gdRQBpUMLUo`). Esta variable solo se establece si el bucket de Amazon S3 tiene activado el [control de versiones de objetos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html). + **BUNDLE\$1ETAG** La ETag del objeto del paquete (por ejemplo, `b10a8db164e0754105b7a99be72e3fe5-4`). **Paquete de GitHub** + **BUNDLE\$1COMMIT** El hash de SHA256 confirmación del paquete generado por Git (por ejemplo,`d2a84f4b8b650937ec8f73cd8be2c74add5a911ba64df27458ed8229da804a26`). El script siguiente cambia el puerto de escucha de un servidor HTTP Apache a 9090 en lugar de a 80 si el valor de **DEPLOYMENT\$1GROUP\$1NAME** es igual a `Staging`. Este script debe invocarse durante el evento del ciclo de vida de implementación `BeforeInstall`: ``` if [ "$DEPLOYMENT_GROUP_NAME" == "Staging" ] then sed -i -e 's/Listen 80/Listen 9090/g' /etc/httpd/conf/httpd.conf fi ``` El script de ejemplo siguiente cambia el nivel de detalle de los mensajes registrados en su log de errores de advertencia a depurar si el valor de la variable de entorno **DEPLOYMENT\$1GROUP\$1NAME** es igual a `Staging`. Este script debe invocarse durante el evento del ciclo de vida de implementación `BeforeInstall`: ``` if [ "$DEPLOYMENT_GROUP_NAME" == "Staging" ] then sed -i -e 's/LogLevel warn/LogLevel debug/g' /etc/httpd/conf/httpd.conf fi ``` El script de ejemplo siguiente sustituye el texto de la página web especificada por el texto que muestra el valor de estas variables de entorno. Este script debe invocarse durante el evento del ciclo de vida de implementación `AfterInstall`: ``` #!/usr/bin/python import os strToSearch="

This application was deployed using CodeDeploy.

" strToReplace="

This page for "+os.environ['APPLICATION_NAME']+" application and "+os.environ['DEPLOYMENT_GROUP_NAME']+" deployment group with "+os.environ['DEPLOYMENT_GROUP_ID']+" deployment group ID was generated by a "+os.environ['LIFECYCLE_EVENT']+" script during "+os.environ['DEPLOYMENT_ID']+" deployment.

" fp=open("/var/www/html/index.html","r") buffer=fp.read() fp.close() fp=open("/var/www/html/index.html","w") fp.write(buffer.replace(strToSearch,strToReplace)) fp.close() ``` ### Ejemplo de enlaces A continuación se muestra un ejemplo de una entrada **hooks** (enlaces) que especifica dos enlaces para el evento de ciclo de vida `AfterInstall`. ``` hooks: AfterInstall: - location: Scripts/RunResourceTests.sh timeout: 180 - location: Scripts/PostDeploy.sh timeout: 180 ``` El script `Scripts/RunResourceTests.sh` se ejecuta durante la fase `AfterInstall` del proceso de implementación. La implementación no tendrá éxito si el script tarda más de 180 segundos (3 minutos) en ejecutarse. La ubicación de los scripts que especifica en la sección "hooks" es relativa a la raíz del paquete de revisión de la aplicación. En el ejemplo anterior, un archivo denominado `RunResourceTests.sh` está en un directorio denominado `Scripts`. El directorio `Scripts` está en la raíz del paquete. Para obtener más información, consulte [Planificación de una revisión de CodeDeploy](application-revisions-plan.md). # AppSpec Ejemplo de archivo En este tema se proporcionan AppSpec archivos de ejemplo para una implementación AWS Lambda y una implementación local de EC2. **Topics** + [AppSpec Ejemplo de archivo para una implementación de Amazon ECS](#appspec-file-example-ecs) + [AppSpec Ejemplo de archivo para una implementación de AWS Lambda](#appspec-file-example-lambda) + [AppSpec Ejemplo de archivo para una implementación local de EC2/](#appspec-file-example-server) ## AppSpec Ejemplo de archivo para una implementación de Amazon ECS A continuación, se muestra un ejemplo de un AppSpec archivo escrito en YAML para implementar un servicio de Amazon ECS. ``` version: 0.0 Resources: - TargetService: Type: AWS::ECS::Service Properties: TaskDefinition: "arn:aws:ecs:us-east-1:111222333444:task-definition/my-task-definition-family-name:1" LoadBalancerInfo: ContainerName: "SampleApplicationName" ContainerPort: 80 # Optional properties PlatformVersion: "LATEST" NetworkConfiguration: AwsvpcConfiguration: Subnets: ["subnet-1234abcd","subnet-5678abcd"] SecurityGroups: ["sg-12345678"] AssignPublicIp: "ENABLED" CapacityProviderStrategy: - Base: 1 CapacityProvider: "FARGATE_SPOT" Weight: 2 - Base: 0 CapacityProvider: "FARGATE" Weight: 1 Hooks: - BeforeInstall: "LambdaFunctionToValidateBeforeInstall" - AfterInstall: "LambdaFunctionToValidateAfterInstall" - AfterAllowTestTraffic: "LambdaFunctionToValidateAfterTestTrafficStarts" - BeforeAllowTraffic: "LambdaFunctionToValidateBeforeAllowingProductionTraffic" - AfterAllowTraffic: "LambdaFunctionToValidateAfterAllowingProductionTraffic" ``` Esta es una versión del ejemplo anterior escrita en JSON. ``` { "version": 0.0, "Resources": [ { "TargetService": { "Type": "AWS::ECS::Service", "Properties": { "TaskDefinition": "arn:aws:ecs:us-east-1:111222333444:task-definition/my-task-definition-family-name:1", "LoadBalancerInfo": { "ContainerName": "SampleApplicationName", "ContainerPort": 80 }, "PlatformVersion": "LATEST", "NetworkConfiguration": { "AwsvpcConfiguration": { "Subnets": [ "subnet-1234abcd", "subnet-5678abcd" ], "SecurityGroups": [ "sg-12345678" ], "AssignPublicIp": "ENABLED" } }, "CapacityProviderStrategy": [ { "Base" : 1, "CapacityProvider" : "FARGATE_SPOT", "Weight" : 2 }, { "Base" : 0, "CapacityProvider" : "FARGATE", "Weight" : 1 } ] } } } ], "Hooks": [ { "BeforeInstall": "LambdaFunctionToValidateBeforeInstall" }, { "AfterInstall": "LambdaFunctionToValidateAfterInstall" }, { "AfterAllowTestTraffic": "LambdaFunctionToValidateAfterTestTrafficStarts" }, { "BeforeAllowTraffic": "LambdaFunctionToValidateBeforeAllowingProductionTraffic" }, { "AfterAllowTraffic": "LambdaFunctionToValidateAfterAllowingProductionTraffic" } ] } ``` A continuación se muestra la secuencia de eventos durante la implementación: 1. Antes de instalar la aplicación de Amazon ECS actualizada en el conjunto de tareas de sustitución, se ejecuta la función de Lambda denominada `LambdaFunctionToValidateBeforeInstall`. 1. Una vez instalada la aplicación de Amazon ECS actualizada en el conjunto de tareas de sustitución, pero antes de recibir tráfico, se ejecuta la función de Lambda denominada `LambdaFunctionToValidateAfterInstall`. 1. Después de que la aplicación de Amazon ECS en el conjunto de tareas de sustitución empieza a recibir tráfico del oyente de prueba, se ejecuta la función de Lambda denominada `LambdaFunctionToValidateAfterTestTrafficStarts`. Esta función probablemente ejecuta pruebas de validación para determinar si la implementación continúa. Si no especifica un agente de escucha de prueba en el grupo de implementaciones, esta se omite. 1. Después de completar las pruebas de validación en el enlace `AfterAllowTestTraffic` y antes de enviar tráfico de producción a la aplicación de Amazon ECS actualizada, se ejecuta la función de Lambda denominada `LambdaFunctionToValidateBeforeAllowingProductionTraffic`. 1. Después de enviar tráfico de producción a la aplicación de Amazon ECS actualizada en el conjunto de tareas de sustitución, se ejecuta la función de Lambda denominada `LambdaFunctionToValidateAfterAllowingProductionTraffic`. Las funciones de Lambda que se ejecutan durante cualquier enlace pueden llevar a cabo pruebas de validación o recopilar métricas de tráfico. ## AppSpec Ejemplo de archivo para una implementación de AWS Lambda Este es un ejemplo de un AppSpec archivo escrito en YAML para implementar una versión de la función Lambda. ``` version: 0.0 Resources: - myLambdaFunction: Type: AWS::Lambda::Function Properties: Name: "myLambdaFunction" Alias: "myLambdaFunctionAlias" CurrentVersion: "1" TargetVersion: "2" Hooks: - BeforeAllowTraffic: "LambdaFunctionToValidateBeforeTrafficShift" - AfterAllowTraffic: "LambdaFunctionToValidateAfterTrafficShift" ``` Esta es una versión del ejemplo anterior escrita en JSON. ``` { "version": 0.0, "Resources": [{ "myLambdaFunction": { "Type": "AWS::Lambda::Function", "Properties": { "Name": "myLambdaFunction", "Alias": "myLambdaFunctionAlias", "CurrentVersion": "1", "TargetVersion": "2" } } }], "Hooks": [{ "BeforeAllowTraffic": "LambdaFunctionToValidateBeforeTrafficShift" }, { "AfterAllowTraffic": "LambdaFunctionToValidateAfterTrafficShift" } ] } ``` A continuación se muestra la secuencia de eventos durante la implementación: 1. Antes de desviar el tráfico de la versión 1 de la función de Lambda llamada `myLambdaFunction` a la versión 2, ejecute una función de Lambda llamada `LambdaFunctionToValidateBeforeTrafficShift` que valide que la implementación está lista para empezar a desviar el tráfico. 1. Si `LambdaFunctionToValidateBeforeTrafficShift` devuelve un código de salida de 0 (éxito), se empieza a desviar el tráfico a la versión 2 de `myLambdaFunction`. La configuración de esta implementación determina la velocidad a la que se desvía el tráfico. 1. Una vez completado el desvío de tráfico de la versión 1 de la función de Lambda llamada `myLambdaFunction` a la versión 2, ejecute una función de Lambda llamada `LambdaFunctionToValidateAfterTrafficShift` que valide que la implementación se ha realizado correctamente. ## AppSpec Ejemplo de archivo para una implementación local de EC2/ Este es un ejemplo de un AppSpec archivo para una implementación local en una instancia de Amazon Linux, Ubuntu Server o RHEL. **nota** Las implementaciones en instancias de Windows Server no admiten el elemento `runas`. Si va a realizar una implementación en instancias de Windows Server, no lo incluya en el archivo AppSpec . ``` version: 0.0 os: linux files: - source: Config/config.txt destination: /webapps/Config - source: source destination: /webapps/myApp hooks: BeforeInstall: - location: Scripts/UnzipResourceBundle.sh - location: Scripts/UnzipDataBundle.sh AfterInstall: - location: Scripts/RunResourceTests.sh timeout: 180 ApplicationStart: - location: Scripts/RunFunctionalTests.sh timeout: 3600 ValidateService: - location: Scripts/MonitorService.sh timeout: 3600 runas: codedeployuser ``` Para una instancia de Windows Server, cambie `os: linux` por `os: windows`. Además, las rutas de `destination` deben ser completas (por ejemplo, `c:\temp\webapps\Config` y `c:\temp\webapps\myApp`). No incluya el elemento `runas`. A continuación se muestra la secuencia de eventos durante la implementación: 1. Ejecutar el script que se encuentra en `Scripts/UnzipResourceBundle.sh`. 1. Si el script anterior devuelve un código de salida de 0 (éxito), ejecutar el script ubicado en `Scripts/UnzipDataBundle.sh`. 1. Copiar el archivo desde la ruta de `Config/config.txt` a la ruta `/webapps/Config/config.txt`. 1. Copiar recursivamente todos los archivos del directorio `source` en el directorio `/webapps/myApp`. 1. Ejecutar el script ubicado en `Scripts/RunResourceTests.sh` con un tiempo de espera de 180 segundos (3 minutos). 1. Ejecutar el script ubicado en `Scripts/RunFunctionalTests.sh` con un tiempo de espera de 3 600 segundos (1 hora). 1. Ejecutar el script ubicado en `Scripts/MonitorService.sh` como el usuario `codedeploy` con un tiempo de espera de 3 600 segundos (1 hora). ## AppSpec Espaciado de archivos El siguiente es el formato correcto para el espaciado de los AppSpec archivos. Los números entre corchetes indican el número de espacios que debe aparecer entre los elementos. Por ejemplo, `[4]` significa insertar cuatro espacios entre los elementos. CodeDeploy genera un error que puede ser difícil de depurar si las ubicaciones y el número de espacios de un AppSpec archivo no son correctos. ``` version:[1]version-number os:[1]operating-system-name files: [2]-[1]source:[1]source-files-location [4]destination:[1]destination-files-location permissions: [2]-[1]object:[1]object-specification [4]pattern:[1]pattern-specification [4]except:[1]exception-specification [4]owner:[1]owner-account-name [4]group:[1]group-name [4]mode:[1]mode-specification [4]acls: [6]-[1]acls-specification [4]context: [6]user:[1]user-specification [6]type:[1]type-specification [6]range:[1]range-specification [4]type: [6]-[1]object-type hooks: [2]deployment-lifecycle-event-name: [4]-[1]location:[1]script-location [6]timeout:[1]timeout-in-seconds [6]runas:[1]user-name ``` A continuación, se muestra un ejemplo de un archivo correctamente espaciado AppSpec : ``` version: 0.0 os: linux files: - source: / destination: /var/www/html/WordPress hooks: BeforeInstall: - location: scripts/install_dependencies.sh timeout: 300 runas: root AfterInstall: - location: scripts/change_permissions.sh timeout: 300 runas: root ApplicationStart: - location: scripts/start_server.sh - location: scripts/create_test_db.sh timeout: 300 runas: root ApplicationStop: - location: scripts/stop_server.sh timeout: 300 runas: root ``` Para obtener más información acerca del espaciado, consulte la especificación de [YAML](http://www.yaml.org). # Valide su AppSpec archivo y su ubicación **Sintaxis de archivos** Puede utilizar el script AppSpec Assistant AWS proporcionado para validar el contenido de un AppSpec archivo. Puede encontrar el script junto con las plantillas de AppSpec archivo en [GitHub](https://github.com/aws-samples/aws-codedeploy-appspec-assistant). También puede utilizar en su lugar una herramienta basada en navegador, como [YAML lint](http://www.yamllint.com/) u [Online YAML parser](http://yaml-online-parser.appspot.com/) para ayudarle a comprobar la sintaxis YAML. **Ubicación del archivo** Para comprobar que ha colocado el AppSpec archivo en el directorio raíz de la estructura de directorios del contenido fuente de la aplicación, ejecute uno de los siguientes comandos: En instancias locales de Linux, macOS o Unix: ``` ls path/to/root/directory/appspec.yml ``` Si el AppSpec archivo no se encuentra allí, aparecerá el error «No existe ese archivo o directorio». En instancias de Windows locales: ``` dir path\to\root\directory\appspec.yml ``` Si el AppSpec archivo no se encuentra allí, aparecerá el error «No se ha encontrado el archivo».