AppSpec Esempio di file - AWS CodeDeploy
AppSpec Esempio di file per una ECS distribuzione Amazon AppSpec Esempio di file per una distribuzione AWS Lambda AppSpec Esempio di file per una distribuzione /On-Premises EC2

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

AppSpec Esempio di file

Questo argomento fornisce AppSpec file di esempio per una distribuzione AWS Lambda e EC2 /On-Premises.

AppSpec Esempio di file per una ECS distribuzione Amazon

Ecco un esempio di AppSpec file scritto YAML per la distribuzione di un ECS servizio 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"

Ecco una versione dell'esempio precedente scritta in. 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"
        }
    ]
}

Ecco è la sequenza degli eventi durante la distribuzione:

  1. Prima che l'ECSapplicazione Amazon aggiornata venga installata nel set di attività sostitutivo, viene eseguita la funzione Lambda chiamataLambdaFunctionToValidateBeforeInstall.

  2. Dopo aver installato l'ECSapplicazione Amazon aggiornata nel set di attività sostitutivo, ma prima che riceva traffico, viene eseguita la funzione Lambda chiamataLambdaFunctionToValidateAfterInstall.

  3. Dopo che l'ECSapplicazione Amazon sul set di attività sostitutivo inizia a ricevere traffico dal listener di test, viene eseguita la funzione LambdaFunctionToValidateAfterTestTrafficStarts Lambda chiamata. È probabile che questa funzione esegua test di convalida per determinare se la distribuzione deve continuare. Se non specifichi un listener di test nel tuo gruppo di distribuzione, questo hook verrà ignorato.

  4. Una volta completati tutti i test di convalida nell'AfterAllowTestTraffichook e prima che il traffico di produzione venga inviato all'ECSapplicazione Amazon aggiornata, viene eseguita la funzione LambdaFunctionToValidateBeforeAllowingProductionTraffic Lambda chiamata.

  5. Dopo che il traffico di produzione è stato inviato all'ECSapplicazione Amazon aggiornata nel set di attività sostitutivo, viene eseguita la funzione Lambda chiamataLambdaFunctionToValidateAfterAllowingProductionTraffic.

Le funzioni Lambda eseguite durante qualsiasi hook possono eseguire test di convalida o raccogliere metriche sul traffico.

AppSpec Esempio di file per una distribuzione AWS Lambda

Ecco un esempio di AppSpec file scritto YAML per la distribuzione di una versione della funzione Lambda. 

version: 0.0
Resources:
  - myLambdaFunction:
      Type: AWS::Lambda::Function
      Properties:
        Name: "myLambdaFunction"
        Alias: "myLambdaFunctionAlias"
        CurrentVersion: "1"
        TargetVersion: "2"
Hooks:
  - BeforeAllowTraffic: "LambdaFunctionToValidateBeforeTrafficShift"
  - AfterAllowTraffic: "LambdaFunctionToValidateAfterTrafficShift"

Ecco una versione dell'esempio precedente scritta in. JSON 

{
 	"version": 0.0,
 	"Resources": [{
 		"myLambdaFunction": {
 			"Type": "AWS::Lambda::Function",
 			"Properties": {
 				"Name": "myLambdaFunction",
 				"Alias": "myLambdaFunctionAlias",
 				"CurrentVersion": "1",
 				"TargetVersion": "2"
 			}
 		}
 	}],
 	"Hooks": [{
 			"BeforeAllowTraffic": "LambdaFunctionToValidateBeforeTrafficShift"
      },
      {
 			"AfterAllowTraffic": "LambdaFunctionToValidateAfterTrafficShift"
 		}
 	]
 }

Ecco è la sequenza degli eventi durante la distribuzione:

  1. Prima di spostare il traffico dalla versione 1 di una funzione Lambda myLambdaFunction chiamata alla versione 2, esegui una funzione Lambda LambdaFunctionToValidateBeforeTrafficShift chiamata che convalida che la distribuzione sia pronta per avviare lo spostamento del traffico.

  2. Se LambdaFunctionToValidateBeforeTrafficShift ha restituito il codice di uscita 0 (operazione completata), inizia il trasferimento del traffico alla versione 2 di myLambdaFunction. La configurazione della distribuzione per questa distribuzione determina la velocità di trasferimento del traffico.

  3. Una volta completato lo spostamento del traffico dalla versione 1 di una funzione Lambda myLambdaFunction chiamata alla versione 2, esegui una funzione Lambda LambdaFunctionToValidateAfterTrafficShift chiamata che convalida il completamento della distribuzione.

AppSpec Esempio di file per una distribuzione /On-Premises EC2

Ecco un esempio di AppSpec file per una distribuzione locale su Amazon Linux, Ubuntu Server o un'RHEListanza.

Nota

Le distribuzioni su istanze di Windows Server non supportano l'elemento. runas Se si esegue la distribuzione su istanze di Windows Server, non includerlo nel file. 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

Per un'istanza di Windows Server, passa os: linux a. os: windows Inoltre, devi specificare i percorsi completi per destination (ad esempio, c:\temp\webapps\Config e c:\temp\webapps\myApp). Non includere l'elemento runas.

Ecco è la sequenza degli eventi durante la distribuzione:

  1. Esegui lo script presente in Scripts/UnzipResourceBundle.sh.

  2. Se lo script precedente ha restituito il codice di uscita 0 (operazione completata), esegui lo script presente in Scripts/UnzipDataBundle.sh.

  3. Copia il file dal percorso Config/config.txt nel percorso /webapps/Config/config.txt.

  4. Copia in modo ricorsivo tutti i file nella directory source nella directory /webapps/myApp.

  5. Esegui lo script che si trova in Scripts/RunResourceTests.sh con un timeout di 180 secondi (3 minuti).

  6. Esegui lo script che si trova in Scripts/RunFunctionalTests.sh con un timeout di 3600 secondi (1 ora).

  7. Esegui lo script che si trova in Scripts/MonitorService.sh come utente codedeploy con un timeout di 3600 secondi (1 ora).