As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # CodeDeploy AppSpec referência de arquivo Esta seção é apenas uma referência. Para obter uma visão geral conceitual do AppSpec arquivo, consulte[CodeDeploy arquivos de especificação do aplicativo (AppSpec)](application-specification-files.md). O arquivo de especificação do aplicativo (AppSpec arquivo) é um arquivo formatado em [YAML](http://www.yaml.org) ou em formato JSON usado por para gerenciar uma implantação. CodeDeploy **nota** O AppSpec arquivo para uma implantação EC2/local deve ser nomeado`appspec.yml`, a menos que você esteja executando uma implantação local. Para obter mais informações, consulte [Criar uma implantação local](deployments-local.md#deployments-local-deploy). **Topics** + [AppSpec arquivos em uma plataforma computacional Amazon ECS](#appspec-reference-ecs) + [AppSpec arquivos em uma plataforma de AWS Lambda computação](#appspec-reference-lambda) + [AppSpec arquivos em uma plataforma de computação EC2/local](#appspec-reference-server) + [AppSpec Estrutura do arquivo](reference-appspec-file-structure.md) + [AppSpec Exemplo de arquivo](reference-appspec-file-example.md) + [AppSpec Espaçamento de arquivos](#reference-appspec-file-spacing) + [Valide seu AppSpec arquivo e a localização do arquivo](reference-appspec-file-validate.md) ## AppSpec arquivos em uma plataforma computacional Amazon ECS Para aplicativos da plataforma de computação Amazon ECS, o AppSpec arquivo é usado CodeDeploy para determinar: + Seu arquivo de definição de tarefa do Amazon ECS. Isso é especificado com seu ARN na `TaskDefinition` instrução no AppSpec arquivo. + O contêiner e a porta de seu conjunto de tarefas de substituição em que o Application Load Balancer ou o Network Load Balancer redireciona o tráfego durante uma implantação. Isso é especificado com a `LoadBalancerInfo` instrução no AppSpec arquivo. + Informações opcionais sobre o serviço do Amazon ECS, como a versão da plataforma em que ele é executado, suas sub-redes e seus grupos de segurança. + Funções do Lambda opcionais que serão executadas durante hooks que correspondam aos eventos de ciclo de vida durante uma implantação do Amazon ECS. Para obter mais informações, consulte [AppSpec seção 'hooks' para uma implantação do Amazon ECS](reference-appspec-file-structure-hooks.md#appspec-hooks-ecs). ## AppSpec arquivos em uma plataforma de AWS Lambda computação Para aplicativos AWS da plataforma de computação Lambda, o AppSpec arquivo é usado por para determinar: CodeDeploy + Qual versão da função do Lambda a ser implantada. + As funções do Lambda a serem usadas como testes de validação. Um AppSpec arquivo pode ser formatado em YAML ou em formato JSON. Você também pode inserir o conteúdo de um AppSpec arquivo diretamente no CodeDeploy console ao criar uma implantação. ## AppSpec arquivos em uma plataforma de computação EC2/local Se seu aplicativo usa a plataforma de computação EC2/local, o AppSpec arquivo deve ser um arquivo no formato YAML chamado `appspec.yml` e deve ser colocado na raiz da estrutura de diretórios do código-fonte de um aplicativo. Caso contrário, haverá falha nas implantações. É usado por CodeDeploy para determinar: + O que ele deve instalar em suas instâncias a partir da revisão do aplicativo no Amazon S3 ou. GitHub + quais ganchos de evento de ciclo de vida devem ser executados em resposta a eventos de ciclo de vida de implantação. Depois de concluir um AppSpec arquivo, você o agrupa, junto com o conteúdo a ser implantado, em um arquivo compactado (zip, tar ou tar compactado). Para obter mais informações, consulte [Trabalhando com revisões de aplicativos para CodeDeploy](application-revisions.md). **nota** Os formatos de arquivo tar e tar compactado (.tar e .tar.gz) não são compatíveis com instâncias do Windows Server. Depois de ter um arquivo compactado (conhecido CodeDeploy como *revisão*), você o carrega em um bucket do Amazon S3 ou repositório Git. Em seguida, você usa CodeDeploy para implantar a revisão. Para instruções, consulte [Crie uma implantação com CodeDeploy](deployments-create.md). O appspec.yml para uma implantação de plataforma de computação EC2/On-Premises é salvo no diretório raiz da sua revisão. Para obter mais informações, consulte [Adicionar um AppSpec arquivo para uma implantação EC2/local](application-revisions-appspec-file.md#add-appspec-file-server) e [Planejar uma revisão para o CodeDeploy](application-revisions-plan.md). # AppSpec Estrutura do arquivo A seguir está a estrutura de alto nível de um AppSpec arquivo usado para implantações em plataformas de computação AWS Lambda e EC2/locais. Um valor em um AppSpec arquivo formatado em YAML que seja uma string não deve ser colocado entre aspas (“”), a menos que especificado de outra forma. ## AppSpec estrutura de arquivos para implantações do Amazon ECS **nota** Esse AppSpec arquivo é escrito em YAML, mas você pode usar a mesma estrutura para escrever um em JSON. Uma string em um AppSpec arquivo formatado em JSON está sempre entre aspas (“”). ``` version: 0.0 resources: ecs-service-specifications hooks: deployment-lifecycle-event-mappings ``` Nessa estrutura: ** **version** ** Esta seção especifica a versão do AppSpec arquivo. Não mude esse valor. Ele é necessário. Atualmente, o único valor permitido é **0.0**. É reservado CodeDeploy para uso futuro. Especifique a **versão** com uma string. ** **recursos** ** Esta seção especifica informações sobre o aplicativo do Amazon ECS que será implantado. Para obter mais informações, consulte [AppSpec seção 'recursos' para implantações do Amazon ECS](reference-appspec-file-structure-resources.md#reference-appspec-file-structure-resources-ecs). ** **hooks** ** Esta seção especifica as funções do Lambda que serão executadas em hooks de eventos específicos de ciclo de vida de implantação para validar a implantação. Para obter mais informações, consulte [Lista de hooks do evento do ciclo de vida para uma implantação Amazon ECS](reference-appspec-file-structure-hooks.md#reference-appspec-file-structure-hooks-list-ecs). ## AppSpec estrutura de arquivos para implantações do AWS Lambda **nota** Esse AppSpec arquivo é escrito em YAML, mas você pode usar a mesma estrutura para gravar um AppSpec arquivo para uma implantação do Lambda em JSON. Uma string em um AppSpec arquivo formatado em JSON está sempre entre aspas (“”). ``` version: 0.0 resources: lambda-function-specifications hooks: deployment-lifecycle-event-mappings ``` Nessa estrutura: ** **version** ** Esta seção especifica a versão do AppSpec arquivo. Não mude esse valor. Ele é necessário. Atualmente, o único valor permitido é **0.0**. É reservado CodeDeploy para uso futuro. Especifique a **versão** com uma string. ** **recursos** ** Esta seção especifica informações sobre a função do Lambda a ser implantada. Para obter mais informações, consulte [AppSpec seção 'recursos' (somente Amazon ECS e AWS Lambda implantações)](reference-appspec-file-structure-resources.md). ** **hooks** ** Esta seção especifica as funções do Lambda a serem executadas em eventos específicos de ciclo de vida de implantação para validar a implantação. Para obter mais informações, consulte [AppSpec seção 'ganchos'](reference-appspec-file-structure-hooks.md). ## AppSpec estrutura de arquivos para implantações EC2/locais ``` version: 0.0 os: operating-system-name files: source-destination-files-mappings permissions: permissions-specifications hooks: deployment-lifecycle-event-mappings ``` Nessa estrutura: ** **version** ** Esta seção especifica a versão do AppSpec arquivo. Não mude esse valor. Ele é necessário. Atualmente, o único valor permitido é **0.0**. É reservado CodeDeploy para uso futuro. Especifique a **versão** com uma string. ** **os** ** Esta seção especifica o valor do sistema operacional da instância na qual você fará a implantação. Ele é necessário. Os seguintes valores podem ser especificados: + **linux**: a instância é uma instância Amazon Linux, Ubuntu Server ou RHEL. + **windows**: A instância é uma instância do Windows Server. Especifique o **SO** com uma string. ** **files** ** Esta seção especifica o nome dos arquivos que devem ser copiados para a instância durante o evento **Install** da implantação. Para obter mais informações, consulte [AppSpec seção 'arquivos' (somente implantações EC2/locais)](reference-appspec-file-structure-files.md). ** **permissions** ** Esta seção especifica como permissões especiais, se houver, devem ser aplicadas aos arquivos na seção `files` à medida que estes são copiados para a instância. Essa seção se aplica somente às instâncias Amazon Linux, Ubuntu Server e Red Hat Enterprise Linux (RHEL). Para obter mais informações, consulte, [AppSpec seção 'permissões' (somente implantações EC2/locais)](reference-appspec-file-structure-permissions.md). ** **hooks** ** Esta seção especifica scripts a serem executados em eventos específicos de ciclo de vida de implantação durante a implantação. Para obter mais informações, consulte [AppSpec seção 'ganchos'](reference-appspec-file-structure-hooks.md). **Topics** + [AppSpec estrutura de arquivos para implantações do Amazon ECS](#ecs-appspec-structure) + [AppSpec estrutura de arquivos para implantações do AWS Lambda](#lambda-appspec-structure) + [AppSpec estrutura de arquivos para implantações EC2/locais](#server-appspec-structure) + [AppSpec seção 'arquivos' (somente implantações EC2/locais)](reference-appspec-file-structure-files.md) + [AppSpec seção 'recursos' (somente Amazon ECS e AWS Lambda implantações)](reference-appspec-file-structure-resources.md) + [AppSpec seção 'permissões' (somente implantações EC2/locais)](reference-appspec-file-structure-permissions.md) + [AppSpec seção 'ganchos'](reference-appspec-file-structure-hooks.md) # AppSpec seção 'arquivos' (somente implantações EC2/locais) Fornece informações CodeDeploy sobre quais arquivos da revisão do seu aplicativo devem ser instalados na instância durante o evento de **instalação** da implantação. Esta seção é necessária apenas quando você copia arquivos da sua revisão em locais na instância durante a implantação. Esta seção tem a seguinte estrutura: ``` files: - source: source-file-location-1 destination: destination-file-location-1 file_exists_behavior: DISALLOW|OVERWRITE|RETAIN ``` Vários pares `destination` e `source` podem ser definidos. A instrução `source` identifica um arquivo ou diretório de sua revisão para copiar na instância: + Se a `source` se referir a um arquivo, somente os arquivos especificados serão copiados na instância. + Se a `source` se referir a um diretório, todos os arquivos no diretório serão copiados na instância. + Se `source` for uma única barra ("/" para as instâncias do Amazon Linux, RHEL e Ubuntu Server, ou "\$1" para instâncias do Windows Server), todos os arquivos da sua revisão serão copiados na instância. Os caminhos usados no `source` são relativos ao arquivo `appspec.yml`, que deve estar na raiz da sua revisão. Para obter detalhes sobre a estrutura de arquivos de uma revisão, consulte [Planejar uma revisão para o CodeDeploy](application-revisions-plan.md). A instrução `destination` identifica a localização na instância em que os arquivos devem ser copiados. Esse deve ser um caminho totalmente qualificado, como `/root/destination/directory` (no Linux, RHEL e Ubuntu) ou `c:\destination\folder` (no Windows). `source` e `destination` são especificados com uma string. A `file_exists_behavior` instrução é opcional e especifica como CodeDeploy manipula arquivos que já existem em um local de destino de implantação, mas não faziam parte da implantação anterior bem-sucedida. Essa configuração ser um dos valores a seguir: + DISALLOW: a implantação falha. Esse também é o comportamento padrão se nenhuma opção for especificada. + OVERWRITE: a versão do arquivo da revisão de aplicativo substitui a versão sendo implantada no momento que já está na instância. + RETAIN: A versão do arquivo que já está na instância é mantida e usada como parte da nova implantação. Ao usar a configuração `file_exists_behavior`, entenda que essa configuração: + só pode ser especificada uma vez e se aplica a todos os arquivos e diretórios listados sob `files:`. + tem precedência sobre a `--file-exists-behavior` AWS CLI opção e a opção `fileExistsBehavior` API (ambas também são opcionais). Aqui está uma seção `files` de exemplo para uma instância Amazon Linux, Ubuntu Server ou RHEL. ``` files: - source: Config/config.txt destination: /webapps/Config - source: source destination: /webapps/myApp ``` Neste exemplo, as duas operações a seguir são realizadas durante o evento **Install**: 1. Copie o arquivo `Config/config.txt` em sua revisão no caminho `/webapps/Config/config.txt` na instância. 1. Copie recursivamente todos os arquivos no diretório `source` da revisão para o diretório `/webapps/myApp` na instância. ## Exemplos da seção “files” Os exemplos a seguir mostram como especificar a seção `files`. Embora esses exemplos descrevam estruturas de arquivos e diretórios (pasta) do Windows Server, eles podem ser facilmente adaptados para instâncias do Amazon Linux, Ubuntu Server e RHEL. **nota** Somente implantações EC2/On-Premises usam a seção `files`. Ela não se aplica às implantações do AWS Lambda. Para os exemplos a seguir, supomos que esses arquivos apareçam no pacote na raiz de `source`: + `appspec.yml` + `my-file.txt` + `my-file-2.txt` + `my-file-3.txt` ``` # 1) Copy only my-file.txt to the destination folder c:\temp. # files: - source: .\my-file.txt destination: c:\temp # # Result: # c:\temp\my-file.txt # # --------------------- # # 2) Copy only my-file-2.txt and my-file-3.txt to the destination folder c:\temp. # files: - source: my-file-2.txt destination: c:\temp - source: my-file-3.txt destination: c:\temp # # Result: # c:\temp\my-file-2.txt # c:\temp\my-file-3.txt # # --------------------- # # 3) Copy my-file.txt, my-file-2.txt, and my-file-3.txt (along with the appspec.yml file) to the destination folder c:\temp. # files: - source: \ destination: c:\temp # # Result: # c:\temp\appspec.yml # c:\temp\my-file.txt # c:\temp\my-file-2.txt # c:\temp\my-file-3.txt ``` Para os seguintes exemplos, supomos que `appspec.yml` apareça no pacote na raiz de `source`, juntamente com uma pasta chamada `my-folder` que contém três arquivos: + `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 seção 'recursos' (somente Amazon ECS e AWS Lambda implantações) O conteúdo na `'resources'` seção do AppSpec arquivo varia, dependendo da plataforma computacional da sua implantação. A seção `'resources'` para uma implantação do Amazon ECS contém a definição de tarefa do Amazon ECS, o contêiner e a porta para rotear o tráfego para o seu conjunto de tarefas do Amazon ECS atualizado e outras informações opcionais. A `'resources'` seção de uma AWS Lambda implantação contém o nome, o alias, a versão atual e a versão de destino de uma função Lambda. **Topics** + [AppSpec seção 'recursos' para implantações do AWS Lambda](#reference-appspec-file-structure-resources-lambda) + [AppSpec seção 'recursos' para implantações do Amazon ECS](#reference-appspec-file-structure-resources-ecs) ## AppSpec seção 'recursos' para implantações do AWS Lambda A seção `'resources'` especifica a função do Lambda que será implantada e tem a seguinte estrutura: YAML: ``` resources: - name-of-function-to-deploy: type: "AWS::Lambda::Function" properties: name: name-of-lambda-function-to-deploy alias: alias-of-lambda-function-to-deploy currentversion: version-of-the-lambda-function-traffic-currently-points-to targetversion: version-of-the-lambda-function-to-shift-traffic-to ``` JSON: ``` "resources": [ { "name-of-function-to-deploy" { "type": "AWS::Lambda::Function", "properties": { "name": "name-of-lambda-function-to-deploy", "alias": "alias-of-lambda-function-to-deploy", "currentversion": "version-of-the-lambda-function-traffic-currently-points-to", "targetversion": "version-of-the-lambda-function-to-shift-traffic-to" } } } ] ``` Cada propriedade é especificada com uma string. + `name` – obrigatório. Esse é o nome da função do Lambda a ser implantada. + `alias` – obrigatório. Esse é o nome do alias da função do Lambda. + `currentversion` – obrigatório. Essa é a versão para a qual o tráfego da função do Lambda aponta. Este valor deve ser um inteiro positivo válido. + `targetversion` – obrigatório. Essa é a versão para a qual o tráfego da função do Lambda é deslocado. Este valor deve ser um inteiro positivo válido. ## AppSpec seção 'recursos' para implantações do Amazon ECS A seção `'resources'` especifica o serviço do Amazon ECS que será implantado e tem a seguinte estrutura: YAML: ``` Resources: - TargetService: Type: AWS::ECS::Service Properties: TaskDefinition: "task-definition-arn" LoadBalancerInfo: ContainerName: "ecs-container-name" ContainerPort: "ecs-application-port" # Optional properties PlatformVersion: "ecs-service-platform-version" NetworkConfiguration: AwsvpcConfiguration: Subnets: ["ecs-subnet-1","ecs-subnet-n"] SecurityGroups: ["ecs-security-group-1","ecs-security-group-n"] AssignPublicIp: "ENABLED | DISABLED" CapacityProviderStrategy: - Base: integer CapacityProvider: "capacityProviderA" Weight: integer - Base: integer CapacityProvider: "capacityProviderB" Weight: integer ``` JSON: ``` "Resources": [ { "TargetService": { "Type": "AWS::ECS::Service", "Properties": { "TaskDefinition": "task-definition-arn", "LoadBalancerInfo": { "ContainerName": "ecs-container-name", "ContainerPort": "ecs-application-port" }, "PlatformVersion": "ecs-service-platform-version", "NetworkConfiguration": { "AwsvpcConfiguration": { "Subnets": [ "ecs-subnet-1", "ecs-subnet-n" ], "SecurityGroups": [ "ecs-security-group-1", "ecs-security-group-n" ], "AssignPublicIp": "ENABLED | DISABLED" } }, "CapacityProviderStrategy": [ { "Base": integer, "CapacityProvider": "capacityProviderA", "Weight": integer }, { "Base": integer, "CapacityProvider": "capacityProviderB", "Weight": integer } ] } } } ] ``` Cada propriedade é especificada com uma string, exceto `ContainerPort`, que é um número. + `TaskDefinition` – obrigatório. Esta é a definição de tarefa para o serviço do Amazon ECS que será implantado. Ela é especificada com o ARN da definição de tarefa. O formato do ARN é `arn:aws:ecs:aws-region:account-id:task-definition/task-definition-family:task-definition-revision`. Para obter mais informações, consulte [Amazon Resource Names (ARNs) e namespaces AWS de serviços](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html). **nota** A porção `:task-definition-revision` do ARN é opcional. Se for omitido, o Amazon ECS usa a última revisão ATIVA da definição da tarefa. + `ContainerName` – obrigatório. Esse é o nome do contêiner do Amazon ECS que contém seu aplicativo do Amazon ECS. Ele deve ser um contêiner especificado em sua definição de tarefa do Amazon ECS. + `ContainerPort` – obrigatório. Essa é a porta do contêiner para a qual o tráfego será roteado. + `PlatformVersion`: opcional. A versão da plataforma das tarefas do Fargate no serviço do Amazon ECS implantado. Para obter mais informações, consulte [Versões da plataforma do AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/platform_versions.html). Se não for especificado, `LATEST` é usado como padrão. + `NetworkConfiguration`: opcional. Em `AwsvpcConfiguration`, especifique o seguinte: Para obter mais informações, consulte [AwsVpcConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AwsVpcConfiguration.html)a *Referência da API do Amazon ECS Container Service*. + `Subnets`: opcional. Uma lista separada por vírgulas de uma ou mais sub-redes em seu serviço do Amazon ECS. + `SecurityGroups`: opcional. Uma lista separada por vírgulas de um ou mais grupos de segurança em seu serviço do Amazon Elastic Container Service. + `AssignPublicIp`: opcional. Uma string que especifica se a interface de rede elástica do serviço do Amazon ECS recebe um endereço IP público. Os valores válidos são `ENABLED` e `DISABLED`. **nota** Todas ou nenhuma das configurações em `NetworkConfiguration` devem ser especificadas. Por exemplo, se você deseja especificar `Subnets`, também deverá especificar `SecurityGroups` e `AssignPublicIp`. Se nenhuma for especificada, CodeDeploy usa as configurações atuais da rede Amazon ECS. + `CapacityProviderStrategy`: opcional. Uma lista dos provedores de capacidade do Amazon ECS que você deseja usar para sua implantação. Para obter mais informações, consulte [Provedores de capacidade do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-capacity-providers.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*. Para cada provedor de capacidade, é possível especificar as configurações a seguir. Para obter detalhes sobre essas configurações, consulte [AWS::ECS::ServiceCapacityProviderStrategyItem](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-capacityproviderstrategyitem.html)o *Guia AWS CloudFormation do Usuário* + `Base`: opcional. O valor da base designa o número mínimo de tarefas que serão executadas no provedor de capacidade especificado. Somente um provedor de capacidade em uma estratégia de provedor de capacidade pode ter uma base definida. Se nenhum valor for especificado, será usado o valor padrão 0. + `CapacityProvider`: opcional. O nome curto do provedor de capacidade. Exemplo: *capacityProviderA* + `Weight`: opcional. O valor do *peso* designa a porcentagem relativa do número total de tarefas executadas que devem usar o provedor de capacidade especificado. O valor `weight` é levado em consideração depois que o valor `base`, se definido, for satisfeito. Se nenhum valor de `weight` for especificado, será usado o valor padrão de `0`. Quando vários fornecedores de capacidade são especificados dentro de uma estratégia de provedor de capacidade, pelo menos um dos provedores de capacidade deve ter um valor ponderal superior a zero e quaisquer prestadores de capacidade com um peso de não `0` serão utilizados para realizar tarefas. Se você especificar vários provedores de capacidade em uma estratégia em que todos tenham um peso de `0`, quaisquer ações `CreateService` ou `RunTask` que usarem a estratégia de provedor de capacidade apresentarão falha. Um exemplo de situação para o uso de pesos é definir uma estratégia que contenha dois provedores de capacidade e ambos tiverem um peso de `1`. Quando o `base` for atendido, as tarefas serão divididas uniformemente entre os dois provedores de capacidade. Usando essa mesma lógica, se você especificar um peso de `1` para *CapacityProviderA* e um peso de `4` para *CapacityProviderB*, então, para cada tarefa executada que usar o *CapacityProviderA*, quatro tarefas usariam o *CapacityProviderB*. # AppSpec seção 'permissões' (somente implantações EC2/locais) A `'permissions'` seção especifica como as permissões especiais, se houver, devem ser aplicadas aos arquivos e directories/folders na `'files'` seção após serem copiadas para a instância. É possível especificar várias instruções `object`. Esta seção é opcional. Ela se aplica somente às instâncias Amazon Linux, Ubuntu Server e RHEL. **nota** A seção `'permissions'` é usada somente para implantações EC2/On-Premises. Ele não é usado para implantações do AWS Lambda ou do Amazon ECS. Esta seção tem a seguinte estrutura: ``` 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 ``` As instruções são as seguintes: + `object` – obrigatório. Este é um conjunto de objetos do sistema de arquivos (arquivos ou diretórios/pastas) ao qual as permissões especificadas serão aplicadas depois que esses objetos forem copiados para a instância. Especifique `object` com uma string. + `pattern`: opcional. Especifica um padrão para aplicar permissões. Se não forem especificadas ou se forem especificadas com os caracteres especiais **"\$1\$1"**, as permissões serão aplicadas em todos os arquivos ou diretórios correspondentes, de acordo com o `type`. Especifique `pattern` com uma string entre aspas (""). + `except`: opcional. Especifica os arquivos ou diretórios que são exceções ao `pattern`. Especifique `except` com uma lista de strings separada por vírgulas entre colchetes. + `owner`: opcional. O nome do proprietário do `object`. Se não for especificado, todos os proprietários existentes aplicados à estrutura original de arquivos ou diretórios/pastas permanecerão inalterados após a operação de cópia. Especifique `owner` com uma string. + `group`: opcional. O nome do grupo para `object`. Se não for especificado, todos os grupos existentes aplicados à estrutura original de arquivos ou diretórios/pastas permanecerão inalterados após a operação de cópia. Especifique `group` com uma string. + `mode`: opcional. Um valor numérico que especifica as permissões a serem aplicadas ao `object`. A configuração do modo segue a sintaxe do comando chmod do Linux. **Importante** Se o valor incluir um zero inicial, você deverá colocá-lo entre aspas duplas ou remover o zero inicial para que restem apenas três dígitos. **nota** Notação simbólica, como **u\$1x**, não é suportada para a configuração `mode`. Exemplos: + `mode: "0644"` concede permissões de leitura e gravação ao proprietário do objeto (6), permissões somente leitura ao grupo (4) e permissões somente leitura a todos os outros usuários (4). + `mode: 644` concede as mesmas permissões que `mode: "0644"`. + `mode: 4755` define o atributo setuid (4), concede permissões de controle total ao proprietário (7), concede permissões de leitura e execução ao grupo (5) e concede permissões de leitura e execução a todos os outros usuários (5). Para obter mais exemplos, consulte a documentação do comando chmod do Linux. Se o modo não for especificado, todos os modos existentes aplicados à estrutura original de arquivos ou pastas permanecerão inalterados após a operação de cópia. + `acls`: opcional. Uma lista de strings de caracteres que representam uma ou mais entradas da lista de controle de acesso (ACL) aplicadas ao `object`. Por exemplo, **u:bob:rw** representa permissões de leitura e gravação para o usuário **bob**. (Para obter mais exemplos, consulte exemplos de formatos de entradas de ACL na documentação do comando `setfacl` do Linux). É possível especificar várias entradas de ACL. Se não `acls` for especificado, qualquer existente ACLs aplicado ao arquivo ou directory/folder estrutura original permanecerá inalterado após a operação de cópia. Eles substituem os existentes ACLs. Especifique uma `acls` com um traço (-), seguido por um espaço e uma string (por exemplo, `- u:jane:rw`). Se você tiver mais de uma ACL, cada uma será especificada em uma linha separada. **nota** A configuração de usuários sem nome, grupos sem nome ou outras entradas de ACL semelhantes faz com que o AppSpec arquivo falhe. Use `mode` para especificar esses tipos de permissões em vez disso. + `context`: opcional. Para instâncias habilitadas para Security-Enhanced Linux (SELinux), uma lista de rótulos de contexto relevantes à segurança a serem aplicados aos objetos copiados. Os rótulos são especificados como chaves contendo `user`, `type`, e `range`. (Para obter mais informações, consulte a SELinux documentação.) Cada chave é inserida com uma string. Se não for especificado, todos os rótulos existentes aplicados ao arquivo ou directory/folder estrutura original permanecerão inalterados após a operação de cópia. + `user`: opcional. O SELinux usuário. + `type`: opcional. O nome do SELinux tipo. + `range`: opcional. O especificador SELinux de intervalo. Isso apenas terá efeito se os recursos MLS (Multi-Level Security) e MCS (Multi-Category Security) estiverem habilitados na máquina. Se não estiver habilitado, `range` assumirá **s0** como padrão. Especifique `context` com uma string (por exemplo, `user: unconfined_u`). Cada `context` é especificado em uma linha separada. + `type`: opcional. Os tipos de objetos aos quais aplicar as permissões especificadas. `type` é uma string que pode ser definida como **file** ou **directory**. Se **file** for especificado, as permissões serão aplicadas somente nos arquivos que estiverem imediatamente contidos no `object` após a operação de cópia (e não no `object` em si). Se **directory** for especificado, as permissões serão aplicadas recursivamente a tudo o directories/folders que estiver em qualquer lugar `object` após a operação de cópia (mas não a `object` si mesma). Especifique o `type` com um traço (-), seguido por um espaço e uma string (por exemplo, `- file`). ## Exemplo da seção 'permissions' O exemplo a seguir mostra como especificar a seção `'permissions'` com as instruções `object`, `pattern`, `except`, `owner`, `mode` e `type`. Esse exemplo se aplica somente às instâncias Amazon Linux, Ubuntu Server e RHEL. Neste exemplo, suponha que os seguintes arquivos e pastas sejam copiados para a instância nesta hierarquia: ``` /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 ``` O AppSpec arquivo a seguir mostra como definir permissões nesses arquivos e pastas após serem copiados: ``` 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 ``` As permissões resultantes são as seguintes: ``` -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 ``` O exemplo a seguir mostra como especificar a seção `'permissions'` com a adição das instruções `acls` e `context`. Esse exemplo se aplica somente às instâncias 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 seção 'ganchos' O conteúdo na `'hooks'` seção do AppSpec arquivo varia, dependendo da plataforma de computação para sua implantação. A seção `'hooks'` para uma implantação EC2/On-Premises contém mapeamentos que vinculam os hooks de evento do ciclo de vida de implantação a um ou mais scripts. A seção `'hooks'` para uma implantação do Lambda ou Amazon ECS especifica as funções de validação Lambda que serão executadas durante um evento de ciclo de vida de implantação. Se um gancho de evento não estiver presente, nenhuma operação será executada para esse evento. Esta seção é necessária somente se você está executando scripts ou funções de validação do Lambda como parte da implantação. **Topics** + [AppSpec seção 'hooks' para uma implantação do Amazon ECS](#appspec-hooks-ecs) + [AppSpec seção 'hooks' para uma implantação do AWS Lambda](#appspec-hooks-lambda) + [AppSpec seção 'ganchos' para uma implantação EC2/local](#appspec-hooks-server) ## AppSpec seção 'hooks' para uma implantação do Amazon ECS **Topics** + [Lista de hooks do evento do ciclo de vida para uma implantação Amazon ECS](#reference-appspec-file-structure-hooks-list-ecs) + [Ordem de execução de hooks em uma implantação do Amazon ECS.](#reference-appspec-file-structure-hooks-run-order-ecs) + [Estrutura da seção 'hooks'](#reference-appspec-file-structure-hooks-section-structure-ecs) + [Exemplo da função do Lambda 'hooks'](#reference-appspec-file-structure-hooks-section-structure-ecs-sample-function) ### Lista de hooks do evento do ciclo de vida para uma implantação Amazon ECS Um gancho AWS Lambda é uma função Lambda especificada com uma string em uma nova linha após o nome do evento do ciclo de vida. Cada gancho é executado uma vez por implantação. Veja a seguir as descrições dos eventos de ciclo de vida em que você pode executar um hook durante uma implantação do Amazon ECS. + `BeforeInstall`: use para executar tarefas antes que o conjunto de tarefas de substituição seja criado. Um grupo de destino é associado ao conjunto de tarefas original. Se um listener de teste opcional for especificado, ele será associado ao conjunto de tarefas original. Não é possível fazer uma reversão nesse momento. + `AfterInstall`: use para executar tarefas depois que o conjunto de tarefas de substituição for criado e um dos grupos de destino for associado a ele. Se um listener de teste opcional for especificado, ele será associado ao conjunto de tarefas original. Os resultados de uma função de gancho nesse evento de ciclo de vida podem acionar uma reversão. + `AfterAllowTestTraffic`: use para executar tarefas depois que o receptor de teste distribuir o tráfego para o conjunto de tarefas de substituição. Os resultados de uma função de gancho, nesse momento, podem acionar uma reversão. + `BeforeAllowTraffic`: use para executar tarefas depois que o segundo grupo de destino for associado ao conjunto de tarefas de substituição, mas antes que o tráfego seja deslocado para o conjunto de tarefas de substituição. Os resultados de uma função de gancho nesse evento de ciclo de vida podem acionar uma reversão. + `AfterAllowTraffic`: use para executar tarefas depois que o segundo grupo de destino distribuir o tráfego para o conjunto de tarefas de substituição. Os resultados de uma função de gancho nesse evento de ciclo de vida podem acionar uma reversão. Para obter mais informações, consulte [O que acontece durante uma implantação do](deployment-steps-ecs.md#deployment-steps-what-happens) e [Tutorial: Implantar um serviço do Amazon ECS com um teste de validação](tutorial-ecs-deployment-with-hooks.md). ### Ordem de execução de hooks em uma implantação do Amazon ECS. Em uma implantação do Amazon ECS, hooks de eventos são executados na seguinte ordem: ![\[A ordem de hooks de eventos em uma implantação do Amazon ECS.\]](http://docs.aws.amazon.com/pt_br/codedeploy/latest/userguide/images/lifecycle-event-order-ecs.png) **nota** Os eventos **Start**, **Install **TestTraffic****, **AllowTraffic**, e **End** na implantação não podem ser programados por script, e é por isso que eles aparecem em cinza neste diagrama. ### Estrutura da seção 'hooks' Os seguintes são exemplos da estrutura da seção `'hooks'`. Uso de YAML: ``` Hooks: - BeforeInstall: "BeforeInstallHookFunctionName" - AfterInstall: "AfterInstallHookFunctionName" - AfterAllowTestTraffic: "AfterAllowTestTrafficHookFunctionName" - BeforeAllowTraffic: "BeforeAllowTrafficHookFunctionName" - AfterAllowTraffic: "AfterAllowTrafficHookFunctionName" ``` Uso de JSON: ``` "Hooks": [ { "BeforeInstall": "BeforeInstallHookFunctionName" }, { "AfterInstall": "AfterInstallHookFunctionName" }, { "AfterAllowTestTraffic": "AfterAllowTestTrafficHookFunctionName" }, { "BeforeAllowTraffic": "BeforeAllowTrafficHookFunctionName" }, { "AfterAllowTraffic": "AfterAllowTrafficHookFunctionName" } ] } ``` ### Exemplo da função do Lambda 'hooks' Use a `'hooks'` seção para especificar uma função Lambda que CodeDeploy pode ser chamada para validar uma implantação do Amazon ECS. É possível usar a mesma função ou uma diferente para os eventos de ciclo de vida de implantação `BeforeInstall`, `AfterInstall`, `AfterAllowTestTraffic`, `BeforeAllowTraffic` e `AfterAllowTraffic`. Após a conclusão dos testes de validação, a `AfterAllowTraffic` função Lambda retorna CodeDeploy e fornece um resultado de `Succeeded` ou. `Failed` **Importante** A implantação é considerada falhada se não CodeDeploy for notificada pela função de validação do Lambda em uma hora. Antes de invocar uma função de hook do Lambda, o servidor deve ser notificado sobre o ID de implantação e o ID de execução do hook de evento de ciclo de vida usando o comando `putLifecycleEventHookExecutionStatus`. A seguir está um exemplo de uma função de hook do Lambda escrita em 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 seção 'hooks' para uma implantação do AWS Lambda **Topics** + [Lista de ganchos de eventos de ciclo de vida para uma implantação do Lambda AWS](#reference-appspec-file-structure-hooks-list-lambda) + [Ordem de execução de hooks em uma implantação da versão da função do Lambda](#reference-appspec-file-structure-hooks-run-order-lambda) + [Estrutura da seção 'hooks'](#reference-appspec-file-structure-hooks-section-structure-lambda) + [Exemplo da função do Lambda 'hooks'](#reference-appspec-file-structure-hooks-section-structure-lambda-sample-function) ### Lista de ganchos de eventos de ciclo de vida para uma implantação do Lambda AWS Um gancho AWS Lambda é uma função Lambda especificada com uma string em uma nova linha após o nome do evento do ciclo de vida. Cada gancho é executado uma vez por implantação. Aqui estão as descrições dos ganchos disponíveis para uso em seu AppSpec arquivo. + **BeforeAllowTraffic**— Use para executar tarefas antes que o tráfego seja transferido para a versão implantada da função Lambda. + **AfterAllowTraffic**— Use para executar tarefas depois que todo o tráfego for transferido para a versão implantada da função Lambda. ### Ordem de execução de hooks em uma implantação da versão da função do Lambda Em uma implantação da versão da função do Lambda com tecnologia sem servidor, os hooks de eventos são executados na seguinte ordem: ![\[Ordem de hooks de eventos em uma implantação do Lambda.\]](http://docs.aws.amazon.com/pt_br/codedeploy/latest/userguide/images/lifecycle-event-order-lambda.png) **nota** Os eventos **Start** e **End** na implantação não podem ser programados por script, e é por isso que eles aparecem em cinza neste diagrama. **AllowTraffic** ### Estrutura da seção 'hooks' Os seguintes são exemplos da estrutura da seção 'hooks'. Uso de YAML: ``` hooks: - BeforeAllowTraffic: BeforeAllowTrafficHookFunctionName - AfterAllowTraffic: AfterAllowTrafficHookFunctionName ``` Uso de JSON: ``` "hooks": [{ "BeforeAllowTraffic": "BeforeAllowTrafficHookFunctionName" }, { "AfterAllowTraffic": "AfterAllowTrafficHookFunctionName" }] ``` ### Exemplo da função do Lambda 'hooks' Use a seção 'hooks' para especificar uma função Lambda CodeDeploy que pode ser chamada para validar uma implantação do Lambda. É possível usar a mesma função ou uma diferente para os eventos de ciclo de vida de implantação `BeforeAllowTraffic` e `AfterAllowTraffic`. Após a conclusão dos testes de validação, a função de validação do Lambda retorna CodeDeploy e fornece um resultado de `Succeeded` ou. `Failed` **Importante** A implantação é considerada falhada se não CodeDeploy for notificada pela função de validação do Lambda em uma hora. Antes de invocar uma função de hook do Lambda, o servidor deve ser notificado sobre o ID de implantação e o ID de execução do hook de evento de ciclo de vida usando o comando `putLifecycleEventHookExecutionStatus`. A seguir está um exemplo de uma função de hook do Lambda escrita em 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 seção 'ganchos' para uma implantação EC2/local **Topics** + [Lista de hooks de eventos de ciclo de vida](#reference-appspec-file-structure-hooks-list) + [Disponibilidade de hooks de eventos de ciclo de vida](#reference-appspec-file-structure-hooks-availability) + [Ordem de execução de hooks em uma implantação](#reference-appspec-file-structure-hooks-run-order) + [Estrutura da seção 'hooks'](#reference-appspec-file-structure-hooks-section-structure) + [Referenciar arquivos em scripts de hook](#codedeploy-agent-working-directory) + [Disponibilidade variáveis de ambientes para hooks](#reference-appspec-file-structure-environment-variable-availability) + [Exemplo de hooks](#reference-appspec-file-structure-hooks-example) ### Lista de hooks de eventos de ciclo de vida Um hook de implantação EC2/On-Premises é executado uma vez por implantação a uma instância. Você pode especificar um ou mais scripts a serem executados em um gancho. Cada gancho para um evento de ciclo de vida é especificado com uma string em uma linha separada. Aqui estão as descrições dos ganchos disponíveis para uso em seu AppSpec arquivo. Para obter informações sobre quais ganchos de eventos de ciclo de vida são válidos para quais tipos de implantação e reversão, consulte [Disponibilidade de hooks de eventos de ciclo de vida](#reference-appspec-file-structure-hooks-availability). + `ApplicationStop`: esse evento de ciclo de vida de implantação ocorre mesmo antes do download da revisão de aplicativo. É possível especificar scripts para esse evento de forma a interromper normalmente o aplicativo ou remover pacotes atualmente instalados na preparação para uma implantação. O AppSpec arquivo e os scripts usados para esse evento do ciclo de vida da implantação são da revisão anterior do aplicativo implantado com sucesso. **nota** Um AppSpec arquivo não existe em uma instância antes de você implantá-la. Por esse motivo, o gancho `ApplicationStop` não é executado da primeira vez em que você implanta na instância. Você poderá usar o gancho `ApplicationStop` na segunda vez que implantar em uma instância. Para determinar o local da última revisão do aplicativo implantada com sucesso, o CodeDeploy agente consulta o local listado no `deployment-group-id_last_successful_install` arquivo. Esse arquivo está localizado em: Pasta `/opt/codedeploy-agent/deployment-root/deployment-instructions` em instâncias do Amazon Linux, do Ubuntu Server e do RHEL do Amazon EC2. Pasta `C:\ProgramData\Amazon\CodeDeploy\deployment-instructions` em instâncias do Windows Server Amazon EC2 Para solucionar um problema de falha na implantação durante o evento de ciclo de vida de implantação `ApplicationStop`, consulte [Solução de problemas de falha ApplicationStop ou BeforeBlockTraffic evento do ciclo AfterBlockTraffic de vida da implantação](troubleshooting-deployments.md#troubleshooting-deployments-lifecycle-event-failures). + `DownloadBundle`— Durante esse evento do ciclo de vida da implantação, o CodeDeploy agente copia os arquivos de revisão do aplicativo em um local temporário: Pasta `/opt/codedeploy-agent/deployment-root/deployment-group-id/deployment-id/deployment-archive` em instâncias do Amazon Linux, do Ubuntu Server e do RHEL do Amazon EC2. Pasta `C:\ProgramData\Amazon\CodeDeploy\deployment-group-id\deployment-id\deployment-archive` em instâncias do Windows Server Amazon EC2 Esse evento é reservado para o CodeDeploy agente e não pode ser usado para executar scripts. Para solucionar um problema de falha na implantação durante o evento de ciclo de vida de implantação `DownloadBundle`, consulte [Solução de problemas em um evento DownloadBundle de ciclo de vida de implantação com falha com UnknownError: não aberto para leitura](troubleshooting-deployments.md#troubleshooting-deployments-downloadbundle). + `BeforeInstall`: use esse evento de ciclo de vida de implantação para tarefas de pré-instalação, como descriptografar arquivos e criar um backup da versão atual. + `Install`— Durante esse evento do ciclo de vida da implantação, o CodeDeploy agente copia os arquivos de revisão do local temporário para a pasta de destino final. Esse evento é reservado para o CodeDeploy agente e não pode ser usado para executar scripts. + `AfterInstall`: use esse evento de ciclo de vida de implantação para tarefas como configurar seu aplicativo ou alterar as permissões dos arquivos. + `ApplicationStart`: normalmente, você usa esse evento de ciclo de vida de implantação para reiniciar os serviços que foram interrompidos durante o `ApplicationStop`. + `ValidateService`: este é o último evento de ciclo de vida de implantação. Ele é usado para verificar se a implantação foi concluída com êxito. + `BeforeBlockTraffic`: você pode usar esse evento de ciclo de vida de implantação para executar tarefas em instâncias antes que elas tenham seu registro cancelado em um balanceador de carga. Para solucionar um problema de falha na implantação durante o evento de ciclo de vida de implantação `BeforeBlockTraffic`, consulte [Solução de problemas de falha ApplicationStop ou BeforeBlockTraffic evento do ciclo AfterBlockTraffic de vida da implantação](troubleshooting-deployments.md#troubleshooting-deployments-lifecycle-event-failures). + `BlockTraffic`: durante esse evento de ciclo de vida de implantação, o tráfego da Internet é impedido de acessar as instâncias que atualmente estão distribuindo o tráfego. Esse evento é reservado para o CodeDeploy agente e não pode ser usado para executar scripts. + `AfterBlockTraffic`: você pode usar esse evento de ciclo de vida de implantação para executar tarefas em instâncias depois que elas tenham seu registro cancelado em seu respectivo balanceador de carga. Para solucionar um problema de falha na implantação durante o evento de ciclo de vida de implantação `AfterBlockTraffic`, consulte [Solução de problemas de falha ApplicationStop ou BeforeBlockTraffic evento do ciclo AfterBlockTraffic de vida da implantação](troubleshooting-deployments.md#troubleshooting-deployments-lifecycle-event-failures). + `BeforeAllowTraffic`: você pode usar esse evento de ciclo de vida de implantação para executar tarefas em instâncias antes que elas sejam registradas em um balanceador de carga. + `AllowTraffic`: durante esse evento de ciclo de vida de implantação, o tráfego da Internet pode acessar instâncias após uma implantação. Esse evento é reservado para o CodeDeploy agente e não pode ser usado para executar scripts. + `AfterAllowTraffic`: você pode usar esse evento de ciclo de vida de implantação para executar tarefas em instâncias depois que elas sejam registradas em um balanceador de carga. ### Disponibilidade de hooks de eventos de ciclo de vida A tabela a seguir lista os ganchos de eventos de ciclo de vida disponíveis para cada cenário de implantação e reversão. | Nome do evento de ciclo de vida | Implantação de inicialização do Auto Scaling¹ | Implantação de encerramento do Auto Scaling¹ | Implantação no local² | Implementação azul/verde: instâncias originais | Implementação azul/verde: instâncias de substituição | Reversão de implementação azul/verde: instâncias originais | Reversão de implantação azul/verde: instâncias de substituição | | --- | --- | --- | --- | --- | --- | --- | --- | | ApplicationStop | ✓ | ✓ | ✓ | | ✓ | | | | DownloadBundle³ | ✓ | | ✓ | | ✓ | | | | BeforeInstall | ✓ | | ✓ | | ✓ | | | | Instalar³ | ✓ | | ✓ | | ✓ | | | | AfterInstall | ✓ | | ✓ | | ✓ | | | | ApplicationStart | ✓ | | ✓ | | ✓ | | | | ValidateService | ✓ | | ✓ | | ✓ | | | | BeforeBlockTraffic | | ✓ | ✓ | ✓ | | | ✓ | | BlockTraffic³ | | ✓ | ✓ | ✓ | | | ✓ | | AfterBlockTraffic | | ✓ | ✓ | ✓ | | | ✓ | | BeforeAllowTraffic | ✓ | | ✓ | | ✓ | ✓ | | | AllowTraffic³ | ✓ | | ✓ | | ✓ | ✓ | | | AfterAllowTraffic | ✓ | | ✓ | | ✓ | ✓ | | | ¹ Para obter informações sobre as implantações do Amazon EC2 Auto Scaling, consulte [Como o Amazon EC2 Auto Scaling funciona com CodeDeploy](integrations-aws-auto-scaling.md#integrations-aws-auto-scaling-behaviors). ² Também se aplica à reversão de uma implantação no local. ³ Reservado para CodeDeploy operações. Não pode ser usado para executar scripts. | ### Ordem de execução de hooks em uma implantação **Implantações de inicialização do Auto Scaling** Durante uma implantação de lançamento do Auto Scaling, CodeDeploy executa ganchos de eventos na seguinte ordem. Para obter mais informações sobre as implantações de inicialização do Auto Scaling, consulte [Como o Amazon EC2 Auto Scaling funciona com CodeDeploy](integrations-aws-auto-scaling.md#integrations-aws-auto-scaling-behaviors). ![\[A ordem de hooks de eventos durante uma implantação de inicialização do Auto Scaling.\]](http://docs.aws.amazon.com/pt_br/codedeploy/latest/userguide/images/lifecycle-event-order-scale-out.png) **nota** Os eventos **Start **DownloadBundle**AllowTraffic******, **Install** e **End** na implantação não podem ser programados por script, e é por isso que eles aparecem em cinza neste diagrama. No entanto, você pode editar a `'files'` seção do AppSpec arquivo para especificar o que será instalado durante o evento de **instalação**. **Implantações de encerramento do Auto Scaling** Durante uma implantação de encerramento do Auto Scaling, CodeDeploy executa ganchos de eventos na seguinte ordem. Para obter mais informações sobre as implantações de encerramento do Auto Scaling, consulte [Ativar implantações de encerramento durante eventos de redução da escala horizontal do Auto Scaling](integrations-aws-auto-scaling.md#integrations-aws-auto-scaling-behaviors-hook-enable). ![\[A ordem de hooks de eventos durante uma implantação de encerramento do Auto Scaling.\]](http://docs.aws.amazon.com/pt_br/codedeploy/latest/userguide/images/lifecycle-event-order-scale-in.png) **nota** Os eventos **Start** e **End** na implantação não podem ser programados por script, e é por isso que eles aparecem em cinza neste diagrama. **BlockTraffic** **Implantações no local** Em uma implantação no local, incluindo a reversão de uma implantação no local, ganchos de eventos são executados na seguinte ordem: **nota** Para implantações no local, os seis hooks relacionados ao bloqueio e à permissão de tráfego apenas serão aplicáveis se você especificar um Classic Load Balancer, Application Load Balancer ou Network Load Balancer do Elastic Load Balancing no grupo de implantação. ![\[A ordem de hooks de eventos durante a reversão de uma implantação no local.\]](http://docs.aws.amazon.com/pt_br/codedeploy/latest/userguide/images/lifecycle-event-order-in-place.png) **nota** Os eventos **Start **DownloadBundle****, **Install** e **End** na implantação não podem ser programados por script, e é por isso que eles aparecem em cinza neste diagrama. No entanto, você pode editar a `'files'` seção do AppSpec arquivo para especificar o que será instalado durante o evento de **instalação**. **Implantações azuis/verdes** Em uma blue/green implantação, os ganchos de eventos são executados na seguinte ordem: ![\[A ordem dos ganchos de eventos em uma blue/green implantação.\]](http://docs.aws.amazon.com/pt_br/codedeploy/latest/userguide/images/lifecycle-event-order-blue-green.png) **nota** Os eventos **Start **DownloadBundle****, **Install **BlockTraffic****, **AllowTraffic**, e **End** na implantação não podem ser programados por script, e é por isso que eles aparecem em cinza neste diagrama. No entanto, você pode editar a seção “arquivos” do AppSpec arquivo para especificar o que será instalado durante o evento de **instalação**. ### Estrutura da seção 'hooks' A seção `'hooks'` tem a seguinte estrutura: ``` hooks: deployment-lifecycle-event-name: - location: script-location timeout: timeout-in-seconds runas: user-name ``` É possível incluir os seguintes elementos em uma entrada **hook** após o nome do evento de ciclo de vida de implantação: ** location ** Obrigatório. A localização no pacote do arquivo de script para a revisão. A localização dos scripts que você especifica na seção `hooks` é relativa à raiz do empacotamento de revisão de aplicativo. Para obter mais informações, consulte [Planejar uma revisão para o CodeDeploy](application-revisions-plan.md). ** timeout ** Opcional. O número de segundos para permitir que o script seja executado antes que ele seja considerado com falha. O padrão é 3600 segundos (1 hora). 3600 segundos (1 hora) é o tempo máximo permitido para a execução do script para cada evento de ciclo de vida de implantação. Se os scripts excederem esse limite, a implantação será interrompida, e a implantação na instância falhará. Certifique-se de que o número total de segundos especificado em **timeout** para todos os scripts em cada evento de ciclo de vida de implantação não exceda esse limite. ** runas ** Opcional. O usuário para representar ao executar o script. Por padrão, esse é o CodeDeploy agente em execução na instância. CodeDeploy não armazena senhas, portanto, o usuário não pode ser representado se o usuário **runas** precisar de uma senha. Esse elemento se aplica somente às instâncias Amazon Linux e Ubuntu Server. ### Referenciar arquivos em scripts de hook Se você estiver conectando um script a um evento de CodeDeploy ciclo de vida, conforme descrito em[AppSpec seção 'ganchos'](#reference-appspec-file-structure-hooks), e quiser referenciar um arquivo (por exemplo,`helper.sh`) em seu script, precisará especificar usando: `helper.sh` + (Recomendado) Um caminho absoluto. Consulte [Utilizar caminhos absolutos](#codedeploy-agent-working-dir-absolute). + Um caminho relativo. Consulte [Utilizar caminhos relativos](#codedeploy-agent-working-dir-relative). #### Utilizar caminhos absolutos Para referenciar um arquivo utilizando o caminho *absoluto*, você pode: + Especifique o caminho absoluto na `files` seção do AppSpec arquivo, na `destination` propriedade. Especificar o mesmo caminho absoluto no script de hook. Para obter mais informações, consulte [AppSpec seção 'arquivos' (somente implantações EC2/locais)](reference-appspec-file-structure-files.md). + Especificar um caminho absoluto dinâmico no script de hook. Para obter mais informações, consulte [Local de arquivamento da implantação](#codedeploy-agent-working-dir-archive). **Local de arquivamento da implantação** Durante o evento do [DownloadBundle](#reference-appspec-file-structure-hooks-list)ciclo de vida, o CodeDeploy agente extrai a [revisão](application-revisions.md) da implantação em um diretório com o seguinte formato: `root-directory/deployment-group-id/deployment-id/deployment-archive` A *root-directory* parte do caminho é sempre definida como o padrão mostrado na tabela a seguir ou é controlada pela definição de `:root_dir` configuração. Para obter mais informações sobre as definições das configurações, consulte [Referência de configuração do agente do CodeDeploy](reference-agent-configuration.md). | Plataforma de agentes | Diretório raiz padrão | | --- | --- | | Linux: todas as distribuições de rpm | /opt/codedeploy-agent/deployment-root | | Ubuntu Server: todas as distribuições de deb | /opt/codedeploy-agent/deployment-root | | Windows Server | %ProgramData%\$1Amazon\$1CodeDeploy | Nos scripts de hook, é possível acessar o arquivo de implantação atual utilizando o caminho do diretório raiz e as variáveis de ambiente `DEPLOYMENT_ID` e `DEPLOYMENT_GROUP_ID`. Para obter mais informações sobre as variáveis, consulte [Disponibilidade variáveis de ambientes para hooks](#reference-appspec-file-structure-environment-variable-availability). Por exemplo, veja como é possível acessar um arquivo `data.json` que reside na raiz da revisão no 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) ``` Como outro exemplo, veja como é possível acessar um arquivo `data.json` que reside na raiz da revisão utilizando o Powershell no 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) ``` #### Utilizar caminhos relativos Para referenciar um arquivo usando seu caminho *relativo*, você precisará conhecer o diretório de trabalho do CodeDeploy agente. Os caminhos dos arquivos são relativos a esse diretório. A tabela a seguir mostra o diretório de trabalho de cada plataforma compatível do CodeDeploy agente. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/codedeploy/latest/userguide/reference-appspec-file-structure-hooks.html) ### Disponibilidade variáveis de ambientes para hooks Durante cada evento de ciclo de vida de implantação, os scripts hook podem acessar as seguintes variáveis de ambiente: ** APPLICATION\$1NAME ** O nome do aplicativo CodeDeploy que faz parte da implantação atual (por exemplo,`WordPress_App`). ** DEPLOYMENT\$1ID ** O ID CodeDeploy foi atribuído à implantação atual (por exemplo,`d-AB1CDEF23`). ** DEPLOYMENT\$1GROUP\$1NAME ** O nome do grupo de implantação CodeDeploy que faz parte da implantação atual (por exemplo,`WordPress_DepGroup`). ** DEPLOYMENT\$1GROUP\$1ID ** O ID do grupo de implantação CodeDeploy que faz parte da implantação atual (por exemplo,`b1a2189b-dd90-4ef5-8f40-4c1c5EXAMPLE`). ** LIFECYCLE\$1EVENT ** O nome do evento de ciclo de vida de implantação atual (por exemplo, `AfterInstall`). Essas variáveis de ambiente são locais para cada evento de ciclo de vida de implantação. Há variáveis de ambiente adicionais disponíveis para scripts de hook, dependendo da origem do empacotamento de implantação: **Empacotamento do Amazon S3** + **BUNDLE\$1BUCKET** O nome do bucket do Amazon S3 do qual o empacotamento de implantação foi baixado por download (por exemplo, `my-s3-bucket`). + **BUNDLE\$1KEY** A chave do objeto para o empacotamento baixado dentro do bucket do Amazon S3 (por exemplo, `WordPress_App.zip`). + **BUNDLE\$1VERSION** A versão do objeto do empacotamento (por exemplo, `3sL4kqtJlcpXroDTDmJ+rmSpXd3dIbrHY+MTRCxf3vjVBH40Nr8X8gdRQBpUMLUo`). Essa variável só é definida se o bucket do Amazon S3 tiver o [versionamento de objetos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html) ativado. + **BUNDLE\$1ETAG** A etag do objeto do empacotamento (por exemplo, `b10a8db164e0754105b7a99be72e3fe5-4`). **Pacote de GitHub** + **BUNDLE\$1COMMIT** O hash de SHA256 confirmação do pacote gerado pelo Git (por exemplo,). `d2a84f4b8b650937ec8f73cd8be2c74add5a911ba64df27458ed8229da804a26` O script a seguir mudará a porta de escuta em um servidor Apache HTTP para 9090 em vez de 80 se o valor de **DEPLOYMENT\$1GROUP\$1NAME** for igual a `Staging`. Este script deve ser invocado durante o evento de ciclo de vida de implantação `BeforeInstall`: ``` if [ "$DEPLOYMENT_GROUP_NAME" == "Staging" ] then sed -i -e 's/Listen 80/Listen 9090/g' /etc/httpd/conf/httpd.conf fi ``` O exemplo de script a seguir alterará o nível de detalhamento das mensagens registradas em seu log de erros de aviso para depuração quando o valor da variável de ambiente **DEPLOYMENT\$1GROUP\$1NAME** for igual a `Staging`. Este script deve ser invocado durante o evento de ciclo de vida de implantação `BeforeInstall`: ``` if [ "$DEPLOYMENT_GROUP_NAME" == "Staging" ] then sed -i -e 's/LogLevel warn/LogLevel debug/g' /etc/httpd/conf/httpd.conf fi ``` O exemplo de script a seguir substitui o texto na página da Web especificada pelo texto que exibe o valor dessas variáveis de ambiente. Este script deve ser invocado durante o evento de ciclo de vida de implantação `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() ``` ### Exemplo de hooks Veja a seguir um exemplo de uma entrada de **ganchos** que especifica dois ganchos para o evento de ciclo de vida `AfterInstall`: ``` hooks: AfterInstall: - location: Scripts/RunResourceTests.sh timeout: 180 - location: Scripts/PostDeploy.sh timeout: 180 ``` O script `Scripts/RunResourceTests.sh` será executado durante o estágio `AfterInstall` do processo de implantação. A implantação não terá êxito se o script precisar de mais de 180 segundos (3 minutos) para ser executado. A localização dos scripts que você especifica na seção hooks é relativa à raiz do pacote de revisão de aplicativo. No exemplo anterior, um arquivo chamado `RunResourceTests.sh` está em um diretório chamado `Scripts`. O diretório `Scripts` está no nível raiz do pacote. Para obter mais informações, consulte [Planejar uma revisão para o CodeDeploy](application-revisions-plan.md). # AppSpec Exemplo de arquivo Este tópico fornece AppSpec arquivos de exemplo para uma implantação AWS Lambda e EC2/local. **Topics** + [AppSpec Exemplo de arquivo para uma implantação do Amazon ECS](#appspec-file-example-ecs) + [AppSpec Exemplo de arquivo para uma implantação do AWS Lambda](#appspec-file-example-lambda) + [AppSpec Exemplo de arquivo para uma implantação EC2/local](#appspec-file-example-server) ## AppSpec Exemplo de arquivo para uma implantação do Amazon ECS Aqui está um exemplo de um AppSpec arquivo escrito em YAML para implantar um serviço 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" ``` Aqui está uma versão do exemplo anterior escrito em 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" } ] } ``` Veja a seguir a sequência de eventos durante a implantação: 1. Antes que o aplicativo do Amazon ECS atualizado seja instalado no conjunto de tarefas de substituição, a função do Lambda chamada `LambdaFunctionToValidateBeforeInstall` é executada. 1. Depois que o aplicativo do Amazon ECS atualizado seja instalado no conjunto de tarefas de substituição, mas antes que ele receba tráfego, a função do Lambda chamada `LambdaFunctionToValidateAfterInstall` é executada. 1. Depois que o aplicativo do Amazon ECS no conjunto de tarefas de substituição começar a receber tráfego do receptor de teste, a função do Lambda chamada `LambdaFunctionToValidateAfterTestTrafficStarts` será executada. Essa função provavelmente executa testes de validação para determinar se a implantação continua. Se você não especificar um listener de teste no seu grupo de implantação, este gancho será ignorado. 1. Depois que todos os testes de validação no hook `AfterAllowTestTraffic` forem concluídos, e antes que o tráfego de produção seja fornecido para o aplicativo do Amazon ECS atualizado, a função do Lambda chamada `LambdaFunctionToValidateBeforeAllowingProductionTraffic` é executada. 1. Depois que o tráfego de produção for fornecido para o aplicativo do Amazon ECS atualizado no conjunto de tarefas de substituição, a função do Lambda chamada `LambdaFunctionToValidateAfterAllowingProductionTraffic` é executada. As funções do Lambda que são executadas durante qualquer hook podem executar testes de validação ou coletar métricas de tráfego. ## AppSpec Exemplo de arquivo para uma implantação do AWS Lambda Aqui está um exemplo de um AppSpec arquivo escrito em YAML para implantar uma versão da função Lambda. ``` version: 0.0 Resources: - myLambdaFunction: Type: AWS::Lambda::Function Properties: Name: "myLambdaFunction" Alias: "myLambdaFunctionAlias" CurrentVersion: "1" TargetVersion: "2" Hooks: - BeforeAllowTraffic: "LambdaFunctionToValidateBeforeTrafficShift" - AfterAllowTraffic: "LambdaFunctionToValidateAfterTrafficShift" ``` Aqui está uma versão do exemplo anterior escrito em JSON. ``` { "version": 0.0, "Resources": [{ "myLambdaFunction": { "Type": "AWS::Lambda::Function", "Properties": { "Name": "myLambdaFunction", "Alias": "myLambdaFunctionAlias", "CurrentVersion": "1", "TargetVersion": "2" } } }], "Hooks": [{ "BeforeAllowTraffic": "LambdaFunctionToValidateBeforeTrafficShift" }, { "AfterAllowTraffic": "LambdaFunctionToValidateAfterTrafficShift" } ] } ``` Veja a seguir a sequência de eventos durante a implantação: 1. Antes de deslocar o tráfego da versão 1 de uma função do Lambda chamada `myLambdaFunction` para a versão 2, execute uma função do Lambda chamada `LambdaFunctionToValidateBeforeTrafficShift` que comprova que a implantação está pronta para iniciar o deslocamento do tráfego. 1. Se `LambdaFunctionToValidateBeforeTrafficShift` retornou um código de saída de 0 (êxito), comece a deslocar tráfego para a versão 2 da `myLambdaFunction`. A configuração de implantação para esta implantação determina a taxa em que o tráfego é deslocado. 1. Após o deslocamento do tráfego da versão 1 de uma função do Lambda chamada `myLambdaFunction` para a versão 2 for concluído, execute uma função do Lambda chamada `LambdaFunctionToValidateAfterTrafficShift` que comprova que a implantação foi concluída com êxito. ## AppSpec Exemplo de arquivo para uma implantação EC2/local Aqui está um exemplo de um AppSpec arquivo para uma implantação local em uma instância Amazon Linux, Ubuntu Server ou RHEL. **nota** As implantações em instâncias do Windows Server não oferecem suporte ao elemento `runas`. Se você estiver implantando em instâncias do Windows Server, não o inclua em seu AppSpec arquivo. ``` 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 uma instância do Windows Server, mude `os: linux` para `os: windows`. Além disso, você deve qualificar completamente os caminhos de `destination` (por exemplo, `c:\temp\webapps\Config` e `c:\temp\webapps\myApp`). Não inclua o elemento `runas`. Veja a seguir a sequência de eventos durante a implantação: 1. Execute o script localizado em `Scripts/UnzipResourceBundle.sh`. 1. Se o script anterior retornou um código de saída de 0 (êxito), execute o script localizado em `Scripts/UnzipDataBundle.sh`. 1. Copie o arquivo do caminho `Config/config.txt` para o caminho `/webapps/Config/config.txt`. 1. Copie recursivamente todos os arquivos no diretório `source` para o diretório `/webapps/myApp`. 1. Execute o script localizado em `Scripts/RunResourceTests.sh` com um tempo limite de 180 segundos (3 minutos). 1. Execute o script localizado em `Scripts/RunFunctionalTests.sh` com um tempo limite de 3600 segundos (1 hora). 1. Execute o script localizado em `Scripts/MonitorService.sh` como o usuário `codedeploy` com um tempo limite de 3600 segundos (1 hora). ## AppSpec Espaçamento de arquivos A seguir está o formato correto para espaçamento de AppSpec arquivos. Os números entre colchetes indicam o número de espaços que deve haver entre os itens. Por exemplo, `[4]` significa inserir quatro espaços entre os itens. CodeDeploy gera um erro que pode ser difícil de depurar se os locais e o número de espaços em um AppSpec arquivo não estiverem corretos. ``` 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 ``` Aqui está um exemplo de um AppSpec arquivo corretamente espaçado: ``` version: 0.0 os: linux files: - source: / destination: /var/www/html/WordPress hooks: BeforeInstall: - location: scripts/install_dependencies.sh timeout: 300 runas: root AfterInstall: - location: scripts/change_permissions.sh timeout: 300 runas: root ApplicationStart: - location: scripts/start_server.sh - location: scripts/create_test_db.sh timeout: 300 runas: root ApplicationStop: - location: scripts/stop_server.sh timeout: 300 runas: root ``` Para obter mais informações sobre espaçamento, consulte a especificação [YAML](http://www.yaml.org). # Valide seu AppSpec arquivo e a localização do arquivo **Sintaxe de arquivos** Você pode usar o script do AppSpec Assistente AWS fornecido para validar o conteúdo de um AppSpec arquivo. Você pode encontrar o script junto com os modelos de AppSpec arquivo em [GitHub](https://github.com/aws-samples/aws-codedeploy-appspec-assistant). Também é possível usar uma ferramenta baseada em navegador, como [YAML Lint](http://www.yamllint.com/) ou [Online YAML Parser](http://yaml-online-parser.appspot.com/) para ajudar a verificar a sintaxe de YAML. **Local do arquivo** Para verificar se você colocou seu AppSpec arquivo no diretório raiz da estrutura de diretórios do conteúdo de origem do aplicativo, execute um dos seguintes comandos: Em instâncias locais do Linux, macOS ou Unix: ``` ls path/to/root/directory/appspec.yml ``` Se o AppSpec arquivo não estiver localizado lá, um erro “Não existe esse arquivo ou diretório” será exibido. Em instâncias locais do Windows: ``` dir path\to\root\directory\appspec.yml ``` Se o AppSpec arquivo não estiver localizado lá, um erro “Arquivo não encontrado” será exibido.