AppSpec Ejemplo de archivo - AWS CodeDeploy

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.

AppSpec Ejemplo de archivo

En este tema se proporcionan AppSpec archivos de ejemplo para una implementación de AWS Lambda y una implementación de EC2 /On-Premises.

AppSpec Ejemplo de archivo para una ECS implementación de Amazon

Este es un ejemplo de un AppSpec archivo escrito YAML para implementar un ECS servicio de Amazon.

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

{ "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 ECS aplicación Amazon actualizada en el conjunto de tareas de reemplazo, se ejecuta la función Lambda denominadaLambdaFunctionToValidateBeforeInstall.

  2. Una vez instalada la ECS aplicación Amazon actualizada en el conjunto de tareas de reemplazo, pero antes de que reciba tráfico, se ejecuta la función Lambda denominadaLambdaFunctionToValidateAfterInstall.

  3. Cuando la ECS aplicación de Amazon del conjunto de tareas de reemplazo comience a recibir tráfico del detector de pruebas, se ejecutará la función LambdaFunctionToValidateAfterTestTrafficStarts Lambda denominada. 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.

  4. Una vez completadas las pruebas de validación AfterAllowTestTraffic del enlace y antes de que el tráfico de producción se envíe a la ECS aplicación de Amazon actualizada, se ejecuta la función Lambda denominadaLambdaFunctionToValidateBeforeAllowingProductionTraffic.

  5. Una vez que el tráfico de producción se envía a la ECS aplicación Amazon actualizada en el conjunto de tareas de reemplazo, se ejecuta la función Lambda denominadaLambdaFunctionToValidateAfterAllowingProductionTraffic.

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 YAML para implementar una versión de 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 enJSON.

{ "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.

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

  3. 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 de EC2 /On-Premises

A continuación, se muestra un ejemplo de un AppSpec archivo para una implementación local en Amazon Linux, Ubuntu Server o RHEL instancia.

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 AppSpec archivo.

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.

  2. Si el script anterior devuelve un código de salida de 0 (éxito), ejecutar el script ubicado en Scripts/UnzipDataBundle.sh.

  3. Copiar el archivo desde la ruta de Config/config.txt a la ruta /webapps/Config/config.txt.

  4. Copiar recursivamente todos los archivos del directorio source en el directorio /webapps/myApp.

  5. Ejecutar el script ubicado en Scripts/RunResourceTests.sh con un tiempo de espera de 180 segundos (3 minutos).

  6. Ejecutar el script ubicado en Scripts/RunFunctionalTests.sh con un tiempo de espera de 3 600 segundos (1 hora).

  7. Ejecutar el script ubicado en Scripts/MonitorService.sh como el usuario codedeploy con un tiempo de espera de 3 600 segundos (1 hora).