Ejemplo de archivo AppSpec - AWS CodeDeploy
Archivo AppSpec de ejemplo para una implementación de Amazon ECS Archivo AppSpec de ejemplo para una implementación de AWS Lambda Archivo AppSpec de ejemplo para una implementación de EC2/en las instalaciones

Ejemplo de archivo AppSpec

Este tema proporciona también archivos AppSpec de ejemplo para una implementación de AWS Lambda y de EC2/en las instalaciones.

Archivo AppSpec de ejemplo para una implementación de Amazon ECS

A continuación, se muestra un ejemplo de un archivo AppSpec 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.

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

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

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

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

Archivo AppSpec de ejemplo para una implementación de AWS Lambda

A continuación, se muestra un ejemplo de un archivo AppSpec escrito en YAML para implementar una versión de una función de 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.

  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.

Archivo AppSpec de ejemplo para una implementación de EC2/en las instalaciones

A continuación se muestra un ejemplo de un archivo AppSpec 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 implementar 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.

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