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à. # CodeDeploy AppSpec riferimento al file Questa sezione è solo per riferimento. Per una panoramica concettuale del AppSpec file, vedere[CodeDeploy file delle specifiche dell'applicazione (AppSpec)](application-specification-files.md). Il file delle specifiche dell'applicazione (AppSpec file) è un file in formato [YAML](http://www.yaml.org) o JSON utilizzato da per gestire una distribuzione. CodeDeploy **Nota** Il AppSpec file per una distribuzione EC2/on-premise deve avere un nome, a meno che non si stia eseguendo una distribuzione locale. `appspec.yml` Per ulteriori informazioni, consulta [Crea una distribuzione locale](deployments-local.md#deployments-local-deploy). **Topics** + [ ## AppSpec file su una piattaforma di elaborazione Amazon ECS ](#appspec-reference-ecs) + [ ## AppSpec file su una piattaforma di elaborazione AWS Lambda ](#appspec-reference-lambda) + [ ## AppSpec file su una piattaforma di elaborazione EC2/on-premise ](#appspec-reference-server) + [ # AppSpec Struttura dei file ](reference-appspec-file-structure.md) + [ # AppSpec Esempio di file ](reference-appspec-file-example.md) + [ ## AppSpec Spaziatura tra i file ](#reference-appspec-file-spacing) + [ # Convalida il AppSpec file e la posizione del file ](reference-appspec-file-validate.md) ## AppSpec file su una piattaforma di elaborazione Amazon ECS Per le applicazioni della piattaforma di calcolo Amazon ECS, il AppSpec file viene utilizzato CodeDeploy per determinare: + Il tuo file di definizione delle attività di Amazon ECS. Questo è specificato con il relativo ARN nelle `TaskDefinition` istruzioni del file. AppSpec + Il contenitore e la porta del set di attività sostitutivo in cui l'Application Load Balancer o il Network Load Balancer reindirizzano il traffico durante una distribuzione. Questo viene specificato con le istruzioni contenute nel file. `LoadBalancerInfo` AppSpec + Informazioni opzionali sul tuo servizio Amazon ECS, come la versione della piattaforma su cui viene eseguito, le sue sottoreti e i suoi gruppi di sicurezza. + Funzioni Lambda opzionali da eseguire durante gli hook che corrispondono agli eventi del ciclo di vita durante una distribuzione Amazon ECS. Per ulteriori informazioni, consulta [AppSpec sezione 'hook' per una distribuzione Amazon ECS](reference-appspec-file-structure-hooks.md#appspec-hooks-ecs). ## AppSpec file su una piattaforma di elaborazione AWS Lambda Per le applicazioni della piattaforma di calcolo AWS Lambda, il AppSpec file viene utilizzato per CodeDeploy determinare: + Quale versione della funzione Lambda distribuire. + Quali funzioni Lambda utilizzare come test di convalida. Un AppSpec file può essere in formato YAML o in formato JSON. Puoi anche inserire il contenuto di un AppSpec file direttamente nella console quando crei una distribuzione. CodeDeploy ## AppSpec file su una piattaforma di elaborazione EC2/on-premise Se l'applicazione utilizza la piattaforma di calcolo EC2/on-premise, il AppSpec file deve essere un file in formato YAML denominato `appspec.yml` e deve essere inserito nella radice della struttura di directory del codice sorgente di un'applicazione. In alternativa, le distribuzioni non riescono. CodeDeploy Viene utilizzato per determinare: + Cosa deve installare sulle istanze dalla revisione dell'applicazione in Amazon S3 o. GitHub + Quali hook di eventi del ciclo di vita eseguire in risposta agli eventi del ciclo di vita della distribuzione. Una volta completato, AppSpec il file viene raggruppato, insieme al contenuto da distribuire, in un file di archivio (zip, tar o tar compresso). Per ulteriori informazioni, consulta [Utilizzo delle revisioni delle applicazioni per CodeDeploy](application-revisions.md). **Nota** I formati di file di archivio tar e tar compressi (.tar e .tar.gz) non sono supportati per le istanze di Windows Server. Dopo aver creato un file di archivio in bundle (noto CodeDeploy come *revisione*), lo carichi in un bucket Amazon S3 o in un repository Git. Quindi lo usi per distribuire la revisione CodeDeploy . Per istruzioni, consulta [Crea una distribuzione con CodeDeploy](deployments-create.md). L'appspec.yml per una distribuzione della piattaforma di calcolo EC2/on-premise viene salvato nella directory principale della revisione. Per ulteriori informazioni, consultare [Aggiungi un AppSpec file per una distribuzione EC2/on-premise](application-revisions-appspec-file.md#add-appspec-file-server) e [Pianifica una revisione per CodeDeploy](application-revisions-plan.md). # AppSpec Struttura dei file Di seguito è riportata la struttura di alto livello di un AppSpec file utilizzato per le distribuzioni su piattaforme di calcolo AWS Lambda ed EC2/on-premise. Un valore in un AppSpec file in formato YAML che è una stringa non deve essere racchiuso tra virgolette («») se non diversamente specificato. ## AppSpec struttura dei file per le distribuzioni di Amazon ECS **Nota** Questo AppSpec file è scritto in YAML, ma puoi usare la stessa struttura per scriverne uno in JSON. Una stringa in un AppSpec file in formato JSON è sempre racchiusa tra virgolette («»). ``` version: 0.0 resources: ecs-service-specifications hooks: deployment-lifecycle-event-mappings ``` In questa struttura: ** **versione** ** Questa sezione specifica la versione del file. AppSpec Non modificare questo valore. È obbligatorio. Attualmente, l'unico valore consentito è **0.0**. È riservato CodeDeploy per usi futuri. Specifica **version** con una stringa. ** **resources** ** Questa sezione specifica le informazioni sull'applicazione Amazon ECS da distribuire. Per ulteriori informazioni, consulta [AppSpec sezione «risorse» per le distribuzioni di Amazon ECS](reference-appspec-file-structure-resources.md#reference-appspec-file-structure-resources-ecs). ** **hooks** ** Questa sezione specifica le funzioni Lambda da eseguire in specifici hook di eventi del ciclo di vita della distribuzione per convalidare la distribuzione. Per ulteriori informazioni, consulta [Elenco di eventi del ciclo di vita per una distribuzione Amazon ECS](reference-appspec-file-structure-hooks.md#reference-appspec-file-structure-hooks-list-ecs). ## AppSpec struttura dei file per le implementazioni AWS Lambda **Nota** Questo AppSpec file è scritto in YAML, ma puoi usare la stessa struttura per scrivere un AppSpec file per una distribuzione Lambda in JSON. Una stringa in un AppSpec file in formato JSON è sempre racchiusa tra virgolette («»). ``` version: 0.0 resources: lambda-function-specifications hooks: deployment-lifecycle-event-mappings ``` In questa struttura: ** **versione** ** Questa sezione specifica la versione del file. AppSpec Non modificare questo valore. È obbligatorio. Attualmente, l'unico valore consentito è **0.0**. È riservato CodeDeploy per usi futuri. Specifica **version** con una stringa. ** **resources** ** Questa sezione specifica le informazioni sulla funzione Lambda da distribuire. Per ulteriori informazioni, consulta [AppSpec sezione «risorse» (solo Amazon ECS e AWS Lambda distribuzioni)](reference-appspec-file-structure-resources.md). ** **hooks** ** Questa sezione specifica le funzioni Lambda da eseguire in occasione di eventi specifici del ciclo di vita della distribuzione per convalidare la distribuzione. Per ulteriori informazioni, consulta [AppSpec sezione 'hooks'](reference-appspec-file-structure-hooks.md). ## AppSpec struttura dei file per le distribuzioni EC2/on-premise ``` version: 0.0 os: operating-system-name files: source-destination-files-mappings permissions: permissions-specifications hooks: deployment-lifecycle-event-mappings ``` In questa struttura: ** **versione** ** Questa sezione specifica la versione del file. AppSpec Non modificare questo valore. È obbligatorio. Attualmente, l'unico valore consentito è **0.0**. È riservato CodeDeploy per usi futuri. Specifica **version** con una stringa. ** **os** ** In questa sezione viene specificato il valore del sistema operativo dell'istanza in cui effettui la distribuzione. È obbligatorio. È possibile specificare i seguenti valori: + **linux**: l'istanza è un'istanza Amazon Linux, Ubuntu Server o RHEL. + **windows**: l'istanza è un'istanza di Windows Server. Specifica **os** con una stringa. ** **files** ** In questa sezione vengono specificati i nomi dei file che devono essere copiati nell'istanza durante l'evento **Install** della distribuzione. Per ulteriori informazioni, consulta [AppSpec sezione 'file' (solo distribuzioni EC2/on-premise)](reference-appspec-file-structure-files.md). ** **permissions** ** In questa sezione viene specificato come le autorizzazioni speciali, se presenti, devono essere applicate alla sezione `files` quando vengono copiate nell'istanza. Questa sezione si applica solo alle istanze Amazon Linux, Ubuntu Server e Red Hat Enterprise Linux (RHEL). Per ulteriori informazioni, consultare [AppSpec sezione 'permessi' (solo distribuzioni EC2/locali)](reference-appspec-file-structure-permissions.md). ** **hooks** ** In questa sezione vengono specificati gli script da eseguire per specifici eventi del ciclo di vita durante la distribuzione. Per ulteriori informazioni, consulta [AppSpec sezione 'hooks'](reference-appspec-file-structure-hooks.md). **Topics** + [ ## AppSpec struttura dei file per le distribuzioni di Amazon ECS ](#ecs-appspec-structure) + [ ## AppSpec struttura dei file per le implementazioni AWS Lambda ](#lambda-appspec-structure) + [ ## AppSpec struttura dei file per le distribuzioni EC2/on-premise ](#server-appspec-structure) + [ # AppSpec sezione 'file' (solo distribuzioni EC2/on-premise) ](reference-appspec-file-structure-files.md) + [ # AppSpec sezione «risorse» (solo Amazon ECS e AWS Lambda distribuzioni) ](reference-appspec-file-structure-resources.md) + [ # AppSpec sezione 'permessi' (solo distribuzioni EC2/locali) ](reference-appspec-file-structure-permissions.md) + [ # AppSpec sezione 'hooks' ](reference-appspec-file-structure-hooks.md) # AppSpec sezione 'file' (solo distribuzioni EC2/on-premise) Fornisce informazioni CodeDeploy sui file della revisione dell'applicazione da installare sull'istanza durante l'evento di **installazione** della distribuzione. Questa sezione è obbligatoria solo se stai copiando i file dalla tua revisione nelle posizioni sull'istanza durante la distribuzione. Questa sezione ha la seguente struttura: ``` files: - source: source-file-location-1 destination: destination-file-location-1 file_exists_behavior: DISALLOW|OVERWRITE|RETAIN ``` È possibile impostare più coppie `source` e `destination`. L'istruzione `source` identifica un file o una directory della revisione da copiare nell'istanza: + Se `source` fa riferimento a un file, solo i file specificati vengono copiati nell'istanza. + Se `source` fa riferimento a una directory, tutti i file della directory vengono copiati nell'istanza. + Se `source` è una barra singola («/» per le istanze di Amazon Linux, RHEL e Ubuntu Server o «\$1» per le istanze di Windows Server), tutti i file della revisione vengono copiati nell'istanza. I percorsi utilizzati in `source` sono relativi al `appspec.yml` file, che dovrebbe essere alla radice della revisione. Per i dettagli sulla struttura dei file di una revisione, vedere. [Pianifica una revisione per CodeDeploy](application-revisions-plan.md) L'istruzione `destination` identifica il percorso dell'istanza in cui i file devono essere copiati. Deve trattarsi di un percorso completo, ad esempio `/root/destination/directory` (su Linux, RHEL e Ubuntu) o `c:\destination\folder` (su Windows). `source` e `destination` sono specificati ciascuno con una stringa. L'`file_exists_behavior`istruzione è facoltativa e specifica in che modo CodeDeploy gestisce i file già esistenti in una posizione di destinazione di distribuzione ma che non facevano parte della precedente distribuzione riuscita. Questa impostazione può assumere uno qualsiasi dei seguenti valori: + DISALLOW: la distribuzione non riesce. Questo è anche il comportamento predefinito se non viene specificata alcuna opzione. + SOVRASCRITTURA: la versione del file contenuta nella revisione dell'applicazione attualmente distribuita sostituisce la versione già presente sull'istanza. + RETAIN: la versione del file già presente nell'istanza viene conservata e utilizzata come parte della nuova distribuzione. Quando usi l'`file_exists_behavior`impostazione, tieni presente che questa impostazione: + può essere specificata una sola volta e si applica a tutti i file e le directory elencati sotto`files:`. + ha la precedenza sull'`--file-exists-behavior` AWS CLI opzione e sull'opzione `fileExistsBehavior` API (entrambe anch'esse opzionali). Ecco una `files` sezione di esempio per un'istanza Amazon Linux, Ubuntu Server o RHEL. ``` files: - source: Config/config.txt destination: /webapps/Config - source: source destination: /webapps/myApp ``` In questo esempio, le seguenti due operazioni vengono eseguite durante l'evento **Install**: 1. Copia il file `Config/config.txt` della revisione nel percorso `/webapps/Config/config.txt` dell'istanza. 1. Copia in modo ricorsivo tutti i file della directory `source` della revisione nella directory `/webapps/myApp` dell'istanza. ## Esempi della sezione 'File' I seguenti esempi mostrano come specificare la sezione `files`. Sebbene questi esempi descrivano le strutture di file e directory (cartelle) di Windows Server, possono essere facilmente adattati per Amazon Linux, Ubuntu Server e istanze RHEL. **Nota** Solo le distribuzioni EC2/on-premise utilizzano questa sezione. `files` Non si applica alle distribuzioni AWS Lambda. Per i seguenti esempi presupponiamo che questi file siano nel bundle della directory radice di `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 ``` Per i seguenti esempi presupponiamo che il file `appspec.yml` sia nel bundle della radice di `source` insieme a una cartella denominata `my-folder` che contiene tre file: + `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 sezione «risorse» (solo Amazon ECS e AWS Lambda distribuzioni) Il contenuto nella `'resources'` sezione del AppSpec file varia a seconda della piattaforma di elaborazione della distribuzione. La `'resources'` sezione relativa a una distribuzione di Amazon ECS contiene la definizione delle attività di Amazon ECS, il contenitore e la porta per instradare il traffico verso il set di attività Amazon ECS aggiornato e altre informazioni opzionali. La `'resources'` sezione relativa a una AWS Lambda distribuzione contiene il nome, l'alias, la versione corrente e la versione di destinazione di una funzione Lambda. **Topics** + [ ## AppSpec sezione «risorse» per le implementazioni AWS Lambda ](#reference-appspec-file-structure-resources-lambda) + [ ## AppSpec sezione «risorse» per le distribuzioni di Amazon ECS ](#reference-appspec-file-structure-resources-ecs) ## AppSpec sezione «risorse» per le implementazioni AWS Lambda La `'resources'` sezione specifica la funzione Lambda da distribuire e ha la seguente struttura: 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" } } } ] ``` Ogni proprietà viene specificata con una stringa. + `name`: obbligatorio Questo è il nome della funzione Lambda da distribuire. + `alias`: obbligatorio Questo è il nome dell'alias della funzione Lambda. + `currentversion`: obbligatorio Questa è la versione della funzione Lambda a cui punta attualmente il traffico. Questo valore deve essere un numero intero positivo valido. + `targetversion`: obbligatorio Questa è la versione della funzione Lambda a cui viene spostato il traffico. Questo valore deve essere un numero intero positivo valido. ## AppSpec sezione «risorse» per le distribuzioni di Amazon ECS La `'resources'` sezione specifica il servizio Amazon ECS da distribuire e ha la seguente struttura: 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 } ] } } } ] ``` Ogni proprietà è specificata con una stringa ad eccezione di`ContainerPort`, che è un numero. + `TaskDefinition`: obbligatorio Questa è la definizione dell'attività da distribuire per il servizio Amazon ECS. Viene specificata con l'ARN della definizione dell'attività. Il formato dell'ARN è `arn:aws:ecs:aws-region:account-id:task-definition/task-definition-family:task-definition-revision`. Per ulteriori informazioni, consulta [Amazon Resource Names (ARNs) e AWS service namespace](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html). **Nota** La `:task-definition-revision` parte dell'ARN è facoltativa. Se viene omesso, Amazon ECS utilizza l'ultima revisione ACTIVE della definizione dell'attività. + `ContainerName`: obbligatorio Questo è il nome del contenitore Amazon ECS che contiene la tua applicazione Amazon ECS. Deve essere un contenitore specificato nella definizione dell'attività di Amazon ECS. + `ContainerPort`: obbligatorio Questa è la porta del container verso cui verrà indirizzato il traffico. + `PlatformVersion`: facoltativo. La versione della piattaforma delle attività Fargate nel servizio Amazon ECS distribuito. Per ulteriori informazioni, consulta [Versioni della piattaforma AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/platform_versions.html). Se non specificato, `LATEST` viene utilizzato per impostazione predefinita. + `NetworkConfiguration`: facoltativo. In `AwsvpcConfiguration`, è possibile specificare le forme seguenti: Per ulteriori informazioni, consulta [AwsVpcConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AwsVpcConfiguration.html)*Amazon ECS Container Service API Reference.* + `Subnets`: facoltativo. Un elenco separato da virgole di una o più sottoreti nel tuo servizio Amazon ECS. + `SecurityGroups`: facoltativo. Un elenco separato da virgole di uno o più gruppi di sicurezza nel tuo Amazon Elastic Container Service. + `AssignPublicIp`: facoltativo. Una stringa che specifica se l'interfaccia di rete elastica del servizio Amazon ECS riceve un indirizzo IP pubblico. I valori validi sono `ENABLED` e `DISABLED`. **Nota** È necessario specificare tutte o nessuna delle impostazioni in `NetworkConfiguration`. Ad esempio, se si desidera specificare `Subnets`, è necessario specificare anche `SecurityGroups` e `AssignPublicIp`. Se non ne viene specificata nessuna, CodeDeploy utilizza le impostazioni di rete correnti di Amazon ECS. + `CapacityProviderStrategy`: facoltativo. Un elenco di provider di capacità Amazon ECS che desideri utilizzare per la distribuzione. Per ulteriori informazioni, consulta i [provider di capacità di Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-capacity-providers.html) nella *Amazon Elastic Container Service Developer Guide*. Per ogni provider di capacità, puoi specificare le seguenti impostazioni. Per i dettagli su queste impostazioni, [AWS::ECS::ServiceCapacityProviderStrategyItem](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-capacityproviderstrategyitem.html)consulta la *Guida AWS CloudFormation per l'utente* + `Base`: facoltativo. Il valore di base indica il numero minimo di attività da eseguire nel provider di capacità specificato. Solo un provider di capacità in una strategia di provider di capacità può avere una base definita. Se non viene specificato alcun valore, sarà utilizzato il valore predefinito 0. + `CapacityProvider`: facoltativo. Nome breve o completo del provider di capacità. Esempio: *CapacityProvidera* + `Weight`: facoltativo. Il valore *peso* indica la percentuale relativa del numero totale di attività avviate che devono utilizzare il provider di capacità specificato. Il valore `weight` viene preso in considerazione dopo che è stato soddisfatto il valore `base`, se definito. Se non viene specificato alcun valore `weight`, sarà utilizzato il valore predefinito `0`. Quando più provider di capacità sono specificati nell'ambito di una strategia di provider di capacità, almeno uno dei provider deve avere un valore di peso superiore a zero e qualsiasi provider di capacità con un peso pari a `0` non sarà utilizzato per svolgere attività. Se specifichi più provider di capacità in una strategia tutti con un peso di `0`, qualsiasi operazione `RunTask` o `CreateService` che utilizza la strategia del provider di capacità avrà esito negativo. Uno scenario di esempio di utilizzo dei pesi è la definizione di una strategia contenente due provider di capacità, ognuno con un peso pari a `1`, quindi una volta soddisfatto il `base`, le attività saranno suddivise in maniera equa tra i due provider. Utilizzando la stessa logica, se si specifica un peso di `1` per *capacityProviderA* e un peso di `4` per *capacityProviderB*, per ogni attività che viene eseguita utilizzando *capacityProviderA*, quattro attività utilizzano *capacityProviderB*. # AppSpec sezione 'permessi' (solo distribuzioni EC2/locali) La `'permissions'` sezione specifica in che modo le eventuali autorizzazioni speciali devono essere applicate ai file e directories/folders nella sezione dopo che sono state copiate nell'`'files'`istanza. Puoi specificare più istruzioni `object`. Questa sezione è facoltativa. Si applica solo alle istanze Amazon Linux, Ubuntu Server e RHEL. **Nota** La `'permissions'` sezione viene utilizzata solo per le distribuzioni EC2/on-premise. Non viene utilizzato per le implementazioni AWS Lambda o Amazon ECS. Questa sezione ha la seguente struttura: ``` 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 ``` Sono disponibili le seguenti istruzioni: + `object`: obbligatorio È un set di oggetti del file system (file o directory/cartelle) a cui vengono applicate le autorizzazioni specificate dopo che gli oggetti del file system sono stati copiati nell'istanza. Specificare `object` con una stringa. + `pattern` : Opzionale. Specifica un modello per applicare le autorizzazioni. Se non è specificato o è specificato con i caratteri speciali **"\$1\$1"**, le autorizzazioni vengono applicate a tutti i file o le directory corrispondenti, a seconda del `type`. Specifica `pattern` con una stringa tra virgolette (""). + `except` : Opzionale. Specifica i file o le directory che sono eccezioni di `pattern`. Specifica `except` con un elenco di stringhe separate da virgola tra parentesi quadre. + `owner` : Opzionale. Il nome del proprietario di `object`. Se non specificato, tutti i proprietari esistenti applicati alla struttura di directory/cartelle o file originale rimangono invariati dopo l'operazione di copia. Specificare `owner` con una stringa. + `group` : Opzionale. Il nome del gruppo per `object`. Se non specificato, tutti i gruppi esistenti applicati alla struttura di directory/cartelle o file originale rimangono invariati dopo l'operazione di copia. Specificare `group` con una stringa. + `mode` : Opzionale. Un valore numerico che specifica le autorizzazioni a cui applicare. `object` L'impostazione della modalità segue la sintassi del comando Linux chmod. **Importante** Se il valore include uno zero iniziale, è necessario racchiuderlo tra virgolette doppie o rimuovere lo zero iniziale in modo che rimangano solo tre cifre. **Nota** La notazione simbolica, ad esempio, non **u\$1x** è supportata per l'impostazione. `mode` Esempi: + `mode: "0644"`fornisce autorizzazioni di lettura e scrittura al proprietario dell'oggetto (6), autorizzazioni di sola lettura al gruppo (4) e autorizzazioni di sola lettura a tutti gli altri utenti (4). + `mode: 644`concede le stesse autorizzazioni di. `mode: "0644"` + `mode: 4755`imposta l'attributo setuid (4), fornisce i permessi di controllo completo al proprietario (7), fornisce i permessi di lettura ed esecuzione al gruppo (5) e fornisce i permessi di lettura ed esecuzione a tutti gli altri utenti (5). Per altri esempi, consultate la documentazione del comando Linux chmod. Se la modalità non è specificata, tutte le modalità esistenti applicate alla struttura originale del file o della cartella rimangono invariate dopo l'operazione di copia. + `acls` : Opzionale. Elenco di stringhe di caratteri che rappresenta una o più voci della lista di controllo accessi (ACL) applicate a `object`. Ad esempio, **u:bob:rw** rappresenta le autorizzazioni di lettura e scrittura per l'utente **bob**. Per ulteriori informazioni, consulta gli esempi del formato per le voci ACL nella documentazione del comando `setfacl` di Linux. Puoi specificare più voci ACL. Se non `acls` è specificata, le eventuali strutture esistenti ACLs applicate al file o alla directory/folder struttura originale rimangono invariate dopo l'operazione di copia. Questi sostituiscono quelli esistenti ACLs. Specifica `acls` con un trattino (-) seguito da uno spazio e quindi da una stringa, ad esempio, `- u:jane:rw`. Se hai più liste ACL, ogni lista viene specificata su una riga separata. **Nota** L'impostazione di utenti senza nome, gruppi senza nome o altre voci ACL simili causa un errore nel AppSpec file. Utilizza `mode` per specificare i tipi di autorizzazione. + `context` : Opzionale. Per le istanze che supportano Security-Enhanced Linux (SELinux), un elenco di etichette di contesto rilevanti per la sicurezza da applicare agli oggetti copiati. Le etichette vengono specificate come chiavi contenenti `user`, `type` e `range`. (Per ulteriori informazioni, consultate la documentazione.) SELinux Ogni chiave viene specificata con una stringa. Se non specificato, le etichette esistenti applicate al file o alla directory/folder struttura originale rimangono invariate dopo l'operazione di copia. + `user` : Opzionale. L' SELinux utente. + `type` : Opzionale. Il nome del SELinux tipo. + `range` : Opzionale. L'identificatore dell' SELinux intervallo. Questo ha effetto solo se Multi-Level Security (MLS) e Multi-Category Security (MCS) sono abilitati sul computer. Se non è abilitata, l’impostazione di `range` è predefinita su **s0**. Specificare `context` con una stringa (ad esempio, `user: unconfined_u`). Ogni `context` viene specificato su una riga separata. + `type` : Opzionale. I tipi di oggetti a cui si applicano le autorizzazioni specificate. `type` è una stringa che può essere impostata su **file** o **directory**. Se **file** è specificato, le autorizzazioni vengono applicate solo ai file contenuti direttamente in `object` dopo l'operazione di copia (e non a `object` stesso). Se **directory** specificato, i permessi vengono applicati in modo ricorsivo a tutto ciò directories/folders che si trova in un punto qualsiasi `object` dopo l'operazione di copia (ma non a se stesso). `object` Specifica `type` con un trattino (-) seguito da uno spazio e quindi da una stringa, ad esempio, `- file`. ## Esempio di sezione 'Autorizzazioni' L'esempio seguente mostra come specificare la sezione `'permissions'` con le istruzioni `object`, `pattern`, `except`, `owner`, `mode` e `type`. Questo esempio si applica solo alle istanze Amazon Linux, Ubuntu Server e RHEL. In questo esempio presupponiamo che i file e le cartelle seguenti siano copiati nell'istanza in questa gerarchia: ``` /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 ``` Il AppSpec file seguente mostra come impostare le autorizzazioni per questi file e cartelle dopo che sono stati copiati: ``` 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 ``` Le autorizzazioni risultanti sono le seguenti: ``` -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 ``` L'esempio seguente mostra come specificare la sezione `'permissions'` con l'aggiunta delle istruzioni `context` e `acls`. Questo esempio si applica solo alle istanze Amazon Linux, Ubuntu Server e 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 sezione 'hooks' Il contenuto nella `'hooks'` sezione del AppSpec file varia a seconda della piattaforma di elaborazione utilizzata per la distribuzione. La `'hooks'` sezione relativa alla distribuzione EC2/on-premise contiene mappature che collegano gli hook degli eventi del ciclo di vita della distribuzione a uno o più script. La `'hooks'` sezione relativa a una distribuzione Lambda o Amazon ECS specifica le funzioni di convalida Lambda da eseguire durante un evento del ciclo di vita della distribuzione. Se l'hook di un evento non è presente, non viene eseguita alcuna operazione per quell'evento. Questa sezione è obbligatoria solo se esegui script o funzioni di convalida Lambda come parte della distribuzione. **Topics** + [ ## AppSpec sezione 'hook' per una distribuzione Amazon ECS ](#appspec-hooks-ecs) + [ ## AppSpec sezione 'hooks' per una distribuzione AWS Lambda ](#appspec-hooks-lambda) + [ ## AppSpec sezione 'hooks' per una distribuzione EC2/on-premise ](#appspec-hooks-server) ## AppSpec sezione 'hook' per una distribuzione Amazon ECS **Topics** + [ ### Elenco di eventi del ciclo di vita per una distribuzione Amazon ECS ](#reference-appspec-file-structure-hooks-list-ecs) + [ ### Esegui l'ordine degli hook in una distribuzione Amazon ECS. ](#reference-appspec-file-structure-hooks-run-order-ecs) + [ ### Struttura della sezione «ganci» ](#reference-appspec-file-structure-hooks-section-structure-ecs) + [ ### Esempio di funzione «ganci» Lambda ](#reference-appspec-file-structure-hooks-section-structure-ecs-sample-function) ### Elenco di eventi del ciclo di vita per una distribuzione Amazon ECS Un hook AWS Lambda è una funzione Lambda specificata con una stringa su una nuova riga dopo il nome dell'evento del ciclo di vita. Ogni hook viene eseguito una volta per distribuzione. Di seguito sono riportate le descrizioni degli eventi del ciclo di vita in cui è possibile eseguire un hook durante una distribuzione Amazon ECS. + `BeforeInstall`— Da utilizzare per eseguire attività prima della creazione del set di attività sostitutivo. Un gruppo target è associato al set di attività originale. Se un listener di test facoltativo è specificato, esso viene associato al set di attività originale. Un rollback non è possibile in questa fase. + `AfterInstall`— Da utilizzare per eseguire attività dopo la creazione del set di attività sostitutivo e l'associazione di uno dei gruppi target. Se un listener di test facoltativo è specificato, esso viene associato al set di attività originale. I risultati di una funzione di hook per questo evento del ciclo di vita possono attivare un rollback. + `AfterAllowTestTraffic`— Da utilizzare per eseguire attività dopo che il listener di test ha inviato il traffico al set di attività sostitutivo. I risultati di una funzione di hook a questo punto possono attivare un rollback. + `BeforeAllowTraffic`— Da utilizzare per eseguire attività dopo che il secondo gruppo target è stato associato al set di attività sostitutivo, ma prima che il traffico venga spostato verso il set di attività sostitutivo. I risultati di una funzione di hook per questo evento del ciclo di vita possono attivare un rollback. + `AfterAllowTraffic`— Da utilizzare per eseguire attività dopo che il secondo gruppo target ha inviato traffico al set di attività sostitutivo. I risultati di una funzione di hook per questo evento del ciclo di vita possono attivare un rollback. Per ulteriori informazioni, consultare [Cosa succede durante una distribuzione di Amazon ECS](deployment-steps-ecs.md#deployment-steps-what-happens) e [Tutorial: distribuisci un servizio Amazon ECS con un test di convalida](tutorial-ecs-deployment-with-hooks.md). ### Esegui l'ordine degli hook in una distribuzione Amazon ECS. In una distribuzione Amazon ECS, gli event hook vengono eseguiti nel seguente ordine: ![\[L'ordine degli eventi in una distribuzione Amazon ECS.\]](http://docs.aws.amazon.com/it_it/codedeploy/latest/userguide/images/lifecycle-event-order-ecs.png) **Nota** Gli eventi di **avvio **TestTraffic**AllowTraffic******, **installazione** e **fine** della distribuzione non possono essere gestiti tramite script, motivo per cui appaiono in grigio in questo diagramma. ### Struttura della sezione «ganci» Di seguito sono riportati alcuni esempi della struttura della sezione `'hooks'`. Utilizzando YAML: ``` Hooks: - BeforeInstall: "BeforeInstallHookFunctionName" - AfterInstall: "AfterInstallHookFunctionName" - AfterAllowTestTraffic: "AfterAllowTestTrafficHookFunctionName" - BeforeAllowTraffic: "BeforeAllowTrafficHookFunctionName" - AfterAllowTraffic: "AfterAllowTrafficHookFunctionName" ``` Utilizzando JSON: ``` "Hooks": [ { "BeforeInstall": "BeforeInstallHookFunctionName" }, { "AfterInstall": "AfterInstallHookFunctionName" }, { "AfterAllowTestTraffic": "AfterAllowTestTrafficHookFunctionName" }, { "BeforeAllowTraffic": "BeforeAllowTrafficHookFunctionName" }, { "AfterAllowTraffic": "AfterAllowTrafficHookFunctionName" } ] } ``` ### Esempio di funzione «ganci» Lambda Utilizza la `'hooks'` sezione per specificare una funzione Lambda che CodeDeploy può chiamare per convalidare una distribuzione Amazon ECS. Puoi utilizzare la stessa funzione o una diversa per gli eventi del ciclo di vita della `AfterAllowTraffic` distribuzione `BeforeInstall` `AfterInstall``AfterAllowTestTraffic`,`BeforeAllowTraffic`, e. Dopo il completamento dei test di convalida, la funzione `AfterAllowTraffic` Lambda CodeDeploy richiama e fornisce il risultato `Succeeded` di o. `Failed` **Importante** L'implementazione è considerata fallita se non CodeDeploy viene notificata dalla funzione di convalida Lambda entro un'ora. Prima di richiamare una funzione Lambda hook, il server deve ricevere una notifica dell'ID di distribuzione e dell'ID di esecuzione dell'hook dell'evento lifecycle utilizzando il comando. `putLifecycleEventHookExecutionStatus` Di seguito è riportato un esempio di funzione hook Lambda scritta in 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 sezione 'hooks' per una distribuzione AWS Lambda **Topics** + [ ### Elenco degli hook relativi agli eventi del ciclo di vita per un'implementazione Lambda AWS ](#reference-appspec-file-structure-hooks-list-lambda) + [ ### Esegui l'ordine degli hook in una distribuzione della versione della funzione Lambda ](#reference-appspec-file-structure-hooks-run-order-lambda) + [ ### Struttura della sezione «ganci» ](#reference-appspec-file-structure-hooks-section-structure-lambda) + [ ### Esempio di funzione «ganci» Lambda ](#reference-appspec-file-structure-hooks-section-structure-lambda-sample-function) ### Elenco degli hook relativi agli eventi del ciclo di vita per un'implementazione Lambda AWS Un hook AWS Lambda è una funzione Lambda specificata con una stringa su una nuova riga dopo il nome dell'evento del ciclo di vita. Ogni hook viene eseguito una volta per distribuzione. Di seguito sono riportate le descrizioni degli hook disponibili per l'uso nel file. AppSpec + **BeforeAllowTraffic**— Da utilizzare per eseguire attività prima che il traffico venga spostato alla versione della funzione Lambda implementata. + **AfterAllowTraffic**— Da utilizzare per eseguire attività dopo che tutto il traffico è stato spostato sulla versione della funzione Lambda implementata. ### Esegui l'ordine degli hook in una distribuzione della versione della funzione Lambda In una versione di una funzione Lambda senza server, gli event hook vengono eseguiti nel seguente ordine: ![\[L'ordine degli event hook in una distribuzione Lambda.\]](http://docs.aws.amazon.com/it_it/codedeploy/latest/userguide/images/lifecycle-event-order-lambda.png) **Nota** Gli eventi di **inizio** e **fine** della distribuzione non possono essere gestiti tramite script, motivo per cui appaiono in grigio in questo diagramma. **AllowTraffic** ### Struttura della sezione «ganci» Di seguito sono riportati alcuni esempi della struttura della sezione "hooks". Utilizzando YAML: ``` hooks: - BeforeAllowTraffic: BeforeAllowTrafficHookFunctionName - AfterAllowTraffic: AfterAllowTrafficHookFunctionName ``` Utilizzando JSON: ``` "hooks": [{ "BeforeAllowTraffic": "BeforeAllowTrafficHookFunctionName" }, { "AfterAllowTraffic": "AfterAllowTrafficHookFunctionName" }] ``` ### Esempio di funzione «ganci» Lambda Usa la sezione 'hooks' per specificare una funzione Lambda CodeDeploy che può chiamare per convalidare una distribuzione Lambda. È possibile utilizzare la stessa funzione o una diversa per gli eventi del ciclo di vita della distribuzione`BeforeAllowTraffic`. `AfterAllowTraffic` Dopo il completamento dei test di convalida, la funzione di convalida Lambda CodeDeploy richiama e fornisce il risultato di o. `Succeeded` `Failed` **Importante** L'implementazione è considerata fallita se non CodeDeploy viene notificata dalla funzione di convalida Lambda entro un'ora. Prima di richiamare una funzione Lambda hook, il server deve ricevere una notifica dell'ID di distribuzione e dell'ID di esecuzione dell'hook dell'evento lifecycle utilizzando il comando. `putLifecycleEventHookExecutionStatus` Di seguito è riportato un esempio di funzione hook Lambda scritta in 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 sezione 'hooks' per una distribuzione EC2/on-premise **Topics** + [ ### Elenco degli hook relativi agli eventi del ciclo di vita ](#reference-appspec-file-structure-hooks-list) + [ ### Disponibilità di Lifecycle Event Hook ](#reference-appspec-file-structure-hooks-availability) + [ ### Esegui l'ordine degli hook in una distribuzione ](#reference-appspec-file-structure-hooks-run-order) + [ ### Struttura della sezione «ganci» ](#reference-appspec-file-structure-hooks-section-structure) + [ ### Riferimento ai file negli script hook ](#codedeploy-agent-working-directory) + [ ### Disponibilità delle variabili di ambiente per gli hook ](#reference-appspec-file-structure-environment-variable-availability) + [ ### Esempio di hook ](#reference-appspec-file-structure-hooks-example) ### Elenco degli hook relativi agli eventi del ciclo di vita Un hook di distribuzione EC2/on-premise viene eseguito una volta per implementazione su un'istanza. Puoi specificare uno o più script da eseguire in un hook. Ogni hook per un evento del ciclo di vita viene specificato con una stringa su una riga separata. Di seguito sono riportate le descrizioni degli hook disponibili per l'uso nel file. AppSpec Per informazioni sugli hook degli eventi del ciclo di vita validi per i vari tipi di rollback e di distribuzione, consulta [Disponibilità di Lifecycle Event Hook](#reference-appspec-file-structure-hooks-availability). + `ApplicationStop`— Questo evento del ciclo di vita della distribuzione si verifica anche prima del download della revisione dell'applicazione. Puoi specificare gli script per questo evento per arrestare correttamente l'applicazione o rimuovere i pacchetti attualmente installati in preparazione di una distribuzione. Il AppSpec file e gli script utilizzati per questo evento del ciclo di vita della distribuzione provengono dalla precedente revisione dell'applicazione distribuita correttamente. **Nota** Un AppSpec file non esiste su un'istanza prima della distribuzione su di essa. Per questo motivo, l'hook `ApplicationStop` non viene eseguito la prima volta che lo distribuisci all'istanza. Puoi utilizzare l'hook `ApplicationStop` la seconda volta che distribuisci a un'istanza. Per determinare la posizione dell'ultima revisione dell'applicazione distribuita correttamente, l' CodeDeploy agente cerca la posizione elencata nel file. `deployment-group-id_last_successful_install` Questo file si trova nella: `/opt/codedeploy-agent/deployment-root/deployment-instructions`cartella su istanze Amazon Linux, Ubuntu Server e RHEL Amazon EC2. `C:\ProgramData\Amazon\CodeDeploy\deployment-instructions`cartella su istanze Amazon EC2 di Windows Server. Per risolvere i problemi di una distribuzione che non riesce durante l'evento del ciclo di vita della distribuzione `ApplicationStop`, consulta [Risoluzione dei problemi relativi a un evento non riuscito o ApplicationStop AfterBlockTraffic relativo al BeforeBlockTraffic ciclo di vita dell'implementazione](troubleshooting-deployments.md#troubleshooting-deployments-lifecycle-event-failures). + `DownloadBundle`— Durante questo evento del ciclo di vita della distribuzione, l' CodeDeploy agente copia i file di revisione dell'applicazione in una posizione temporanea: `/opt/codedeploy-agent/deployment-root/deployment-group-id/deployment-id/deployment-archive`cartella su istanze Amazon Linux, Ubuntu Server e RHEL Amazon EC2. `C:\ProgramData\Amazon\CodeDeploy\deployment-group-id\deployment-id\deployment-archive`cartella su istanze Amazon EC2 di Windows Server. Questo evento è riservato all' CodeDeploy agente e non può essere utilizzato per eseguire script. Per risolvere i problemi di una distribuzione che non riesce durante l'evento del ciclo di vita della distribuzione `DownloadBundle`, consulta [Risoluzione dei problemi relativi a un evento del ciclo di vita di DownloadBundle distribuzione non riuscito con UnknownError: not open-for reading](troubleshooting-deployments.md#troubleshooting-deployments-downloadbundle). + `BeforeInstall`— È possibile utilizzare questo evento del ciclo di vita della distribuzione per attività di preinstallazione, come la decrittografia dei file e la creazione di un backup della versione corrente. + `Install`— Durante questo evento del ciclo di vita della distribuzione, l' CodeDeployagente copia i file di revisione dalla posizione temporanea alla cartella di destinazione finale. Questo evento è riservato all' CodeDeploy agente e non può essere utilizzato per eseguire script. + `AfterInstall`— È possibile utilizzare questo evento del ciclo di vita della distribuzione per attività come la configurazione dell'applicazione o la modifica delle autorizzazioni dei file. + `ApplicationStart`— In genere si utilizza questo evento del ciclo di vita della distribuzione per riavviare i servizi che sono stati interrotti durante. `ApplicationStop` + `ValidateService`— Questo è l'ultimo evento del ciclo di vita della distribuzione. È utilizzato per verificare se la distribuzione è stata completata. + `BeforeBlockTraffic`— È possibile utilizzare questo evento del ciclo di vita della distribuzione per eseguire attività sulle istanze prima che vengano cancellate da un sistema di bilanciamento del carico. Per risolvere i problemi di una distribuzione che non riesce durante l'evento del ciclo di vita della distribuzione `BeforeBlockTraffic`, consulta [Risoluzione dei problemi relativi a un evento non riuscito o ApplicationStop AfterBlockTraffic relativo al BeforeBlockTraffic ciclo di vita dell'implementazione](troubleshooting-deployments.md#troubleshooting-deployments-lifecycle-event-failures). + `BlockTraffic`— Durante questo evento del ciclo di vita della distribuzione, al traffico Internet viene impedito l'accesso alle istanze che attualmente servono traffico. Questo evento è riservato all' CodeDeploy agente e non può essere utilizzato per eseguire script. + `AfterBlockTraffic`— È possibile utilizzare questo evento del ciclo di vita della distribuzione per eseguire attività sulle istanze dopo che queste sono state cancellate dal rispettivo sistema di bilanciamento del carico. Per risolvere i problemi di una distribuzione che non riesce durante l'evento del ciclo di vita della distribuzione `AfterBlockTraffic`, consulta [Risoluzione dei problemi relativi a un evento non riuscito o ApplicationStop AfterBlockTraffic relativo al BeforeBlockTraffic ciclo di vita dell'implementazione](troubleshooting-deployments.md#troubleshooting-deployments-lifecycle-event-failures). + `BeforeAllowTraffic`— È possibile utilizzare questo evento del ciclo di vita della distribuzione per eseguire attività sulle istanze prima che vengano registrate con un sistema di bilanciamento del carico. + `AllowTraffic`— Durante questo evento del ciclo di vita della distribuzione, il traffico Internet può accedere alle istanze dopo una distribuzione. Questo evento è riservato all' CodeDeploy agente e non può essere utilizzato per eseguire script. + `AfterAllowTraffic`— È possibile utilizzare questo evento del ciclo di vita della distribuzione per eseguire attività sulle istanze dopo che sono state registrate con un sistema di bilanciamento del carico. ### Disponibilità di Lifecycle Event Hook La tabella seguente elenca gli hook degli eventi del ciclo di vita disponibili per ogni scenario di distribuzione e rollback. | Nome dell'evento del ciclo di vita | Implementazione del lancio di Auto Scaling¹ | Implementazione della terminazione con Auto Scaling¹ | Implementazione sul posto² | Distribuzione blue/verde: istanze originali | Distribuzione blue/verde: istanze di sostituzione | Rollback blue/verde: istanze originali | Rollback blue/verde: istanze di sostituzione | | --- | --- | --- | --- | --- | --- | --- | --- | | ApplicationStop | ✓ | ✓ | ✓ | | ✓ | | | | DownloadBundle³ | ✓ | | ✓ | | ✓ | | | | BeforeInstall | ✓ | | ✓ | | ✓ | | | | Installa ³ | ✓ | | ✓ | | ✓ | | | | AfterInstall | ✓ | | ✓ | | ✓ | | | | ApplicationStart | ✓ | | ✓ | | ✓ | | | | ValidateService | ✓ | | ✓ | | ✓ | | | | BeforeBlockTraffic | | ✓ | ✓ | ✓ | | | ✓ | | BlockTraffic³ | | ✓ | ✓ | ✓ | | | ✓ | | AfterBlockTraffic | | ✓ | ✓ | ✓ | | | ✓ | | BeforeAllowTraffic | ✓ | | ✓ | | ✓ | ✓ | | | AllowTraffic³ | ✓ | | ✓ | | ✓ | ✓ | | | AfterAllowTraffic | ✓ | | ✓ | | ✓ | ✓ | | | ¹ Per informazioni sulle implementazioni di Amazon EC2 Auto Scaling, consulta. [Come funziona Amazon EC2 Auto Scaling con CodeDeploy](integrations-aws-auto-scaling.md#integrations-aws-auto-scaling-behaviors) ² Si applica anche al rollback di una distribuzione sul posto. ³ Riservato alle operazioni CodeDeploy . Non può essere utilizzato per l'esecuzione di script. | ### Esegui l'ordine degli hook in una distribuzione **Implementazioni di lancio di Auto Scaling** Durante una distribuzione con avvio di Auto Scaling, CodeDeploy esegue gli event hook nell'ordine seguente. Per ulteriori informazioni sulle implementazioni di avvio di Auto Scaling, vedere. [Come funziona Amazon EC2 Auto Scaling con CodeDeploy](integrations-aws-auto-scaling.md#integrations-aws-auto-scaling-behaviors) ![\[L'ordine degli eventi si agganciano durante l'implementazione del lancio di Auto Scaling.\]](http://docs.aws.amazon.com/it_it/codedeploy/latest/userguide/images/lifecycle-event-order-scale-out.png) **Nota** Gli eventi di **avvio **DownloadBundle**AllowTraffic******, **installazione** e **fine** della distribuzione non possono essere gestiti tramite script, motivo per cui appaiono in grigio in questo diagramma. Tuttavia, è possibile modificare la `'files'` sezione del AppSpec file per specificare cosa viene installato durante l'evento di **installazione**. **Implementazioni di terminazione con Auto Scaling** Durante una distribuzione con terminazione di Auto Scaling, CodeDeploy esegue gli event hook nell'ordine seguente. Per ulteriori informazioni sulle implementazioni di terminazione con Auto Scaling, vedere. [Abilitazione delle implementazioni di terminazione durante gli eventi scale-in di Auto Scaling](integrations-aws-auto-scaling.md#integrations-aws-auto-scaling-behaviors-hook-enable) ![\[L'ordine degli event hook durante una distribuzione con terminazione dell'Auto Scaling.\]](http://docs.aws.amazon.com/it_it/codedeploy/latest/userguide/images/lifecycle-event-order-scale-in.png) **Nota** Gli eventi di **inizio** e **fine** della distribuzione non possono essere gestiti tramite script, motivo per cui appaiono in grigio in questo diagramma. **BlockTraffic** **Distribuzioni locali** In una distribuzione in loco, incluso il rollback di una distribuzione in loco, gli hook degli eventi vengono eseguiti nel seguente ordine: **Nota** Per le distribuzioni sul posto, i sei hook relativi al blocco e all'autorizzazione del traffico si applicano solo se si specifica un Classic Load Balancer, Application Load Balancer o Network Load Balancer di Elastic Load Balancing nel gruppo di distribuzione. ![\[L'ordine degli hook degli eventi durante il rollback di una distribuzione sul posto.\]](http://docs.aws.amazon.com/it_it/codedeploy/latest/userguide/images/lifecycle-event-order-in-place.png) **Nota** Gli eventi di **avvio **DownloadBundle****, **installazione** e **fine** della distribuzione non possono essere gestiti tramite script, motivo per cui appaiono in grigio in questo diagramma. Tuttavia, è possibile modificare la `'files'` sezione del AppSpec file per specificare cosa viene installato durante l'evento di **installazione**. **Implementazioni blu/verdi** In una blue/green distribuzione, gli event hook vengono eseguiti nell'ordine seguente: ![\[L'ordine degli event hook in una blue/green distribuzione.\]](http://docs.aws.amazon.com/it_it/codedeploy/latest/userguide/images/lifecycle-event-order-blue-green.png) **Nota** Gli eventi di **avvio **DownloadBundle**BlockTraffic**AllowTraffic********, **installazione** e **fine** della distribuzione non possono essere gestiti tramite script, motivo per cui vengono visualizzati in grigio in questo diagramma. Tuttavia, è possibile modificare la sezione 'files' del AppSpec file per specificare cosa viene installato durante l'evento di **installazione**. ### Struttura della sezione «ganci» La sezione `'hooks'` ha la seguente struttura: ``` hooks: deployment-lifecycle-event-name: - location: script-location timeout: timeout-in-seconds runas: user-name ``` Puoi includere i seguenti elementi in una voce **hook** dopo il nome dell'evento del ciclo di vita della distribuzione: ** location ** Obbligatorio. La posizione nel bundle del file di script per la revisione. La posizione degli script specificati nella `hooks` sezione è relativa alla radice del pacchetto di revisione dell'applicazione. Per ulteriori informazioni, consulta [Pianifica una revisione per CodeDeploy](application-revisions-plan.md). ** timeout ** Opzionale. Il numero di secondi dedicati all'esecuzione dello script prima che venga considerato non riuscito. Il valore predefinito è 3600 secondi (1 ora). 3600 secondi (1 ora) è il periodo di tempo massimo consentito per l'esecuzione di uno script per ogni evento del ciclo di vita della distribuzione. Se gli script superano questo limite, la distribuzione viene interrotta e la distribuzione nell'istanza non riesce. Assicurati che il numero totale di secondi specificato per **timeout** per tutti gli script in ogni evento del ciclo di vita della distribuzione non superi questo limite. ** runas ** Opzionale. L'utente da rappresentare quando viene eseguito lo script. Per impostazione predefinita, questo è l' CodeDeploy agente in esecuzione sull'istanza. CodeDeploy non memorizza le password, quindi l'utente non può essere impersonato se l'utente **runas** necessita di una password. Questo elemento si applica solo alle istanze di Amazon Linux e Ubuntu Server. ### Riferimento ai file negli script hook Se stai collegando uno script a un evento CodeDeploy del ciclo di vita come descritto in [AppSpec sezione 'hooks'](#reference-appspec-file-structure-hooks) e desideri fare riferimento a un file (ad esempio,`helper.sh`) nello script, dovrai specificare utilizzando: `helper.sh` + (Consigliato) Un percorso assoluto. Per informazioni, consulta [Utilizzo di percorsi assoluti](#codedeploy-agent-working-dir-absolute). + Un percorso relativo. Per informazioni, consulta [Utilizzo di percorsi relativi](#codedeploy-agent-working-dir-relative). #### Utilizzo di percorsi assoluti Per fare riferimento a un file usando il suo percorso *assoluto*, puoi: + Specificate il percorso assoluto `files` nella sezione del AppSpec file, nella `destination` proprietà. Quindi, specifica lo stesso percorso assoluto nel tuo script hook. Per ulteriori informazioni, consulta [AppSpec sezione 'file' (solo distribuzioni EC2/on-premise)](reference-appspec-file-structure-files.md). + Specificate un percorso assoluto dinamico nello script hook. Per ulteriori informazioni, consulta [Deployment archive location](#codedeploy-agent-working-dir-archive). **Posizione dell'archivio di distribuzione** Durante l'evento del [DownloadBundle](#reference-appspec-file-structure-hooks-list)ciclo di vita, l' CodeDeploy agente estrae la [revisione](application-revisions.md) per la distribuzione in una directory con il seguente formato: `root-directory/deployment-group-id/deployment-id/deployment-archive` La *root-directory* parte del percorso è sempre impostata sul valore predefinito mostrato nella tabella seguente o è controllata dall'impostazione di configurazione. `:root_dir` Per ulteriori informazioni sulle impostazioni di configurazione, vedere[CodeDeploy riferimento alla configurazione dell'agente](reference-agent-configuration.md). | Piattaforma Agent | Directory principale predefinita | | --- | --- | | Linux: tutte le distribuzioni rpm | /opt/codedeploy-agent/deployment-root | | Ubuntu Server: tutte le distribuzioni deb | /opt/codedeploy-agent/deployment-root | | Windows Server | %ProgramData%\$1Amazon\$1CodeDeploy | Dai tuoi script hook, puoi accedere all'archivio di distribuzione corrente utilizzando il percorso della directory principale e le variabili di ambiente `DEPLOYMENT_ID` and`DEPLOYMENT_GROUP_ID`. Per ulteriori informazioni sulle variabili che è possibile utilizzare, vedere[Disponibilità delle variabili di ambiente per gli hook](#reference-appspec-file-structure-environment-variable-availability). Ad esempio, ecco come è possibile accedere a un `data.json` file che si trova nella radice della revisione su 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) ``` Come altro esempio, ecco come è possibile accedere a un `data.json` file che si trova alla radice della revisione utilizzando Powershell su 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) ``` #### Utilizzo di percorsi relativi Per fare riferimento a un file utilizzando il *relativo* percorso, è necessario conoscere la directory di lavoro dell' CodeDeploy agente. I percorsi dei file sono relativi a questa directory. La tabella seguente mostra la directory di lavoro per ogni piattaforma supportata dall' CodeDeploy agente. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/codedeploy/latest/userguide/reference-appspec-file-structure-hooks.html) ### Disponibilità delle variabili di ambiente per gli hook Durante ogni evento del ciclo di vita della distribuzione, gli script di hook possono accedere alle seguenti variabili di ambiente: ** APPLICATION\$1NAME ** Il nome dell'applicazione CodeDeploy che fa parte della distribuzione corrente (ad esempio,`WordPress_App`). ** DEPLOYMENT\$1ID ** L'ID CodeDeploy è stato assegnato alla distribuzione corrente (ad esempio,`d-AB1CDEF23`). ** DEPLOYMENT\$1GROUP\$1NAME ** Il nome del gruppo di distribuzione CodeDeploy che fa parte della distribuzione corrente (ad esempio,`WordPress_DepGroup`). ** DEPLOYMENT\$1GROUP\$1ID ** L'ID del gruppo di distribuzione CodeDeploy che fa parte della distribuzione corrente (ad esempio,`b1a2189b-dd90-4ef5-8f40-4c1c5EXAMPLE`). ** LIFECYCLE\$1EVENT ** Il nome dell'evento del ciclo di vita della distribuzione corrente (ad esempio `AfterInstall`). Queste variabili di ambiente sono locali per ciascun evento del ciclo di vita della distribuzione. Sono disponibili variabili di ambiente aggiuntive per agganciare gli script a seconda dell'origine del pacchetto di distribuzione: **Pacchetto da Amazon S3** + **BUNDLE\$1BUCKET** Il nome del bucket Amazon S3 da cui è stato scaricato il pacchetto di distribuzione (ad esempio,). `my-s3-bucket` + **BUNDLE\$1KEY** La chiave oggetto per il pacchetto scaricato all'interno del bucket Amazon S3 (ad esempio,). `WordPress_App.zip` + **BUNDLE\$1VERSION** La versione dell'oggetto per il pacchetto (ad esempio,). `3sL4kqtJlcpXroDTDmJ+rmSpXd3dIbrHY+MTRCxf3vjVBH40Nr8X8gdRQBpUMLUo` Questa variabile viene impostata solo se il bucket Amazon S3 ha abilitato il controllo delle versioni [degli oggetti](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html). + **BUNDLE\$1ETAG** L'oggetto etag per il pacchetto (ad esempio,). `b10a8db164e0754105b7a99be72e3fe5-4` **Bundle da GitHub** + **BUNDLE\$1COMMIT** L'hash di SHA256 commit del pacchetto generato da Git (ad esempio,`d2a84f4b8b650937ec8f73cd8be2c74add5a911ba64df27458ed8229da804a26`). Il seguente script modifica la porta di ascolto di un server HTTP Apache su 9090 anziché 80 se il valore di **DEPLOYMENT\$1GROUP\$1NAME** è uguale a `Staging`. Questo script devono essere richiamato durante l'evento del ciclo di vita della distribuzione `BeforeInstall`: ``` if [ "$DEPLOYMENT_GROUP_NAME" == "Staging" ] then sed -i -e 's/Listen 80/Listen 9090/g' /etc/httpd/conf/httpd.conf fi ``` Il seguente esempio di script modifica il livello di verbosità dei messaggi registrati nel log degli errori da avviso a debug se il valore della variabile di ambiente **DEPLOYMENT\$1GROUP\$1NAME** è uguale a `Staging`. Questo script devono essere richiamato durante l'evento del ciclo di vita della distribuzione `BeforeInstall`: ``` if [ "$DEPLOYMENT_GROUP_NAME" == "Staging" ] then sed -i -e 's/LogLevel warn/LogLevel debug/g' /etc/httpd/conf/httpd.conf fi ``` Il seguente esempio di script sostituisce il testo nella pagina Web specificata con il testo che visualizza il valore di queste variabili di ambiente. Questo script devono essere richiamato durante l'evento del ciclo di vita della distribuzione `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() ``` ### Esempio di hook Ecco un esempio della voce **hooks** che specifica due hook per l'evento del ciclo di vita `AfterInstall`: ``` hooks: AfterInstall: - location: Scripts/RunResourceTests.sh timeout: 180 - location: Scripts/PostDeploy.sh timeout: 180 ``` Lo script `Scripts/RunResourceTests.sh` viene eseguito durante la fase `AfterInstall` del processo di distribuzione. La distribuzione non ha esito positivo se lo script impiega più di 180 secondi (3 minuti) per l'esecuzione. La posizione degli script specificati nella sezione "hooks" è relativa alla radice del bundle di revisione dell'applicazione. Nel precedente esempio, un file denominato `RunResourceTests.sh` si trova in una directory denominata `Scripts`. La directory `Scripts` si trova al livello di radice del bundle. Per ulteriori informazioni, consulta [Pianifica una revisione per CodeDeploy](application-revisions-plan.md). # AppSpec Esempio di file Questo argomento fornisce AppSpec file di esempio per una distribuzione AWS Lambda e EC2/locale. **Topics** + [ ## AppSpec Esempio di file per una distribuzione Amazon ECS ](#appspec-file-example-ecs) + [ ## AppSpec Esempio di file per una distribuzione AWS Lambda ](#appspec-file-example-lambda) + [ ## AppSpec Esempio di file per una distribuzione EC2/on-premise ](#appspec-file-example-server) ## AppSpec Esempio di file per una distribuzione Amazon ECS Ecco un esempio di AppSpec file scritto in YAML per la distribuzione di un servizio 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" ``` Questa è una versione dell'esempio precedente scritto in formato 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'applicazione Amazon ECS aggiornata venga installata nel set di attività sostitutivo, viene eseguita la funzione `LambdaFunctionToValidateBeforeInstall` Lambda chiamata. 1. Dopo aver installato l'applicazione Amazon ECS aggiornata nel set di attività sostitutivo, ma prima che riceva traffico, viene eseguita la funzione `LambdaFunctionToValidateAfterInstall` Lambda chiamata. 1. Dopo che l'applicazione Amazon ECS sul set di attività sostitutivo inizia a ricevere traffico dal listener di test, viene eseguita la funzione Lambda chiamata. `LambdaFunctionToValidateAfterTestTrafficStarts` È 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. 1. Una volta completati tutti i test di convalida nell'`AfterAllowTestTraffic`hook e prima che il traffico di produzione venga inviato all'applicazione Amazon ECS aggiornata, viene eseguita la funzione Lambda chiamata. `LambdaFunctionToValidateBeforeAllowingProductionTraffic` 1. Dopo che il traffico di produzione è stato inviato all'applicazione Amazon ECS aggiornata sul set di attività sostitutivo, viene eseguita la funzione `LambdaFunctionToValidateAfterAllowingProductionTraffic` Lambda chiamata. 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 in 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" ``` Questa è una versione dell'esempio precedente scritto in formato 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. 1. 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. 1. 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 EC2/on-premise Ecco un esempio di AppSpec file per una distribuzione locale su un'istanza Amazon Linux, Ubuntu Server o RHEL. **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`. 1. Se lo script precedente ha restituito il codice di uscita 0 (operazione completata), esegui lo script presente in `Scripts/UnzipDataBundle.sh`. 1. Copia il file dal percorso `Config/config.txt` nel percorso `/webapps/Config/config.txt`. 1. Copia in modo ricorsivo tutti i file nella directory `source` nella directory `/webapps/myApp`. 1. Esegui lo script che si trova in `Scripts/RunResourceTests.sh` con un timeout di 180 secondi (3 minuti). 1. Esegui lo script che si trova in `Scripts/RunFunctionalTests.sh` con un timeout di 3600 secondi (1 ora). 1. Esegui lo script che si trova in `Scripts/MonitorService.sh` come utente `codedeploy` con un timeout di 3600 secondi (1 ora). ## AppSpec Spaziatura tra i file Di seguito è riportato il formato corretto per la spaziatura tra i AppSpec file. I numeri tra parentesi quadre indicano il numero di spazi che devono essere presenti tra gli elementi. Ad esempio, `[4]` significa inserire quattro spazi tra gli elementi. CodeDeploy genera un errore di cui potrebbe essere difficile eseguire il debug se le posizioni e il numero di spazi in un AppSpec file non sono corretti. ``` 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 ``` Ecco un esempio di file con AppSpec spaziatura corretta: ``` 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 ``` Per ulteriori informazioni sulla spaziatura, consulta la specifica [YAML](http://www.yaml.org). # Convalida il AppSpec file e la posizione del file **Sintassi del file** Puoi utilizzare lo script AppSpec Assistant AWS fornito per convalidare il contenuto di un file. AppSpec È possibile trovare lo script insieme ai modelli di AppSpec file su. [GitHub](https://github.com/aws-samples/aws-codedeploy-appspec-assistant) Puoi anche utilizzare uno strumento basato su browser come [YAML lint o il parser YAML](http://www.yamllint.com/) [online per aiutarti a controllare la sintassi YAML](http://yaml-online-parser.appspot.com/). **Posizione del file** Per verificare di aver inserito il AppSpec file nella directory principale della struttura di directory del contenuto di origine dell'applicazione, esegui uno dei seguenti comandi: Nelle istanze locali di Linux, macOS o Unix: ``` ls path/to/root/directory/appspec.yml ``` Se il AppSpec file non si trova lì, viene visualizzato l'errore «Nessun file o directory di questo tipo». Sulle istanze Windows locali: ``` dir path\to\root\directory\appspec.yml ``` Se il AppSpec file non si trova lì, viene visualizzato l'errore «File non trovato».