Plataformas personalizadas do Elastic Beanstalk - AWS Elastic Beanstalk

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

Plataformas personalizadas do Elastic Beanstalk

nota

Em 18 de julho de 2022, o Elastic Beanstalk definiu o status de todas as ramificações de plataforma baseadas no Amazon Linux AMI (AL1) como descontinuadas. Isso inclui plataformas personalizadas. O Elastic Beanstalk não é compatível com plataformas personalizadas. Para obter mais informações sobre a descontinuação do Amazon Linux AMI no Elastic Beanstalk, consulte Perguntas frequentes sobre descontinuação de plataformas.

Este tópico foi mantido neste documento como referência para todos os clientes que usavam o recurso de plataforma personalizada do Elastic Beanstalk antes de ser descontinuado. No passado, as plataformas personalizadas do Elastic Beanstalk eram compatíveis com a criação de uma AMI a partir das AMIs de base do Amazon Linux AMI, do RHEL 7, do RHEL 6 ou do Ubuntu 16.04. O Elastic Beanstalk não é mais compatível com esses sistemas operacionais. Para ler mais sobre o recurso de plataformas personalizadas, que não é mais compatível, expanda o tópico a seguir.

Uma plataforma personalizada é uma personalização mais avançada do que uma imagem personalizada de várias maneiras. Uma plataforma personalizada permite que você desenvolva toda uma nova plataforma do zero, personalizando o sistema operacional, software adicional e scripts executados pelo Elastic Beanstalk em instâncias de plataforma. Essa flexibilidade permite que você crie uma plataforma para uma aplicação que usa uma linguagem ou outro software de infraestrutura para o qual o Elastic Beanstalk não oferece uma plataforma gerenciada. Compare isso a imagens personalizadas, em que você modifica uma imagem de máquina da Amazon (AMI) para uso com uma plataforma existente do Elastic Beanstalk, e o Elastic Beanstalk ainda oferece os scripts de plataforma e controla a pilha de software. Além disso, com plataformas personalizadas você usa uma maneira automatizada e com scripts de criar e manter a personalização, enquanto com imagens personalizadas você faz as alterações manualmente em uma instância em execução.

Para criar uma plataforma personalizada, crie uma AMI de um dos sistemas operacionais compatíveis: Ubuntu, RHEL ou Amazon Linux (consulte a entrada flavor em Formato do arquivo platform.yaml para ver os números de versão exatos), e inclua outras personalizações. Crie sua própria plataforma do Elastic Beanstalk usando o Packer, que é uma ferramenta de código aberto para criar imagens de máquina para muitas plataformas, incluindo AMIs para uso com o Amazon Elastic Compute Cloud (Amazon EC2). Uma plataforma do Elastic Beanstalk consiste em uma AMI configurada para executar um conjunto de software compatível com uma aplicação e metadados que podem incluir opções de configuração personalizadas e opções de configuração padrão.

O Elastic Beanstalk gerencia o Packer como uma plataforma integrada separada, e não é necessário se preocupar com a configuração e as versões do Packer.

Crie uma plataforma fornecendo ao Elastic Beanstalk um modelo do Packer, e os scripts e arquivos que o modelo invoca para criar uma AMI. Esses componentes são empacotados com um arquivo de definição de plataforma, que especifica o modelo e os metadados, em um arquivo ZIP, conhecido como arquivo de definição de plataforma.

Quando você cria uma plataforma personalizada, inicia um ambiente de uma única instância sem um IP elástico que executa o Packer. O Packer executa outra instância para criar uma imagem. Você pode reutilizar esse ambiente para várias plataformas e várias versões de cada plataforma.

nota

As plataformas personalizadas são específicas AWS da região. Se você usar o Elastic Beanstalk em várias regiões, deverá criar suas plataformas separadamente em cada região.

Em determinadas circunstâncias, as instâncias executadas pelo Packer não são limpas e precisam ser manualmente encerradas. Para saber como limpar manualmente essas instâncias, consulte Limpeza da instância do Packer.

Os usuários em sua conta podem utilizar suas Plataformas personalizadas especificando um Nome de região da Amazon (ARN) da Plataforma durante a criação do ambiente. Esses ARNs são retornados pelo comando eb platform create que você usou para criar a plataforma personalizada.

Cada vez que você cria sua plataforma personalizada, o Elastic Beanstalk cria uma nova versão dela. Os usuários podem especificar uma plataforma por nome para obter apenas a versão mais recente dela ou incluir um número de versão para obter uma versão específica.

Por exemplo, para implantar a versão mais recente da plataforma personalizada com o ARN MyCustomPlatformARN, que pode ser a versão 3.0, a linha de comando da CLI do EB seria assim:

eb create -p MyCustomPlatformARN

Para implantar a versão 2.1, a linha de comando da CLI do EB seria assim:

eb create -p MyCustomPlatformARN --version 2.1

Você pode aplicar tags a uma versão da plataforma personalizada ao criá-la e editar tags de versões existentes da plataforma personalizada. Para obter detalhes, consulte Atribuir tags em versões de plataforma personalizada.

Criar uma plataforma personalizada

Para criar uma plataforma personalizada, a raiz da sua aplicação deve incluir um arquivo de definição de plataforma platform.yaml, que define o tipo de criador usado para criar a plataforma personalizada. O formato desse arquivo está descrito no tópico Formato do arquivo platform.yaml. Você pode criar sua Plataforma personalizada do zero ou usar uma das Plataformas personalizadas de exemplo como ponto de partida.

Usar uma plataforma personalizada de exemplo

Uma alternativa para criar sua própria plataforma personalizada é usar um dos arquivos demonstrativos de definição de plataforma para inicializá-la. Os únicos itens que você precisa configurar nos exemplos para que você possa usá-las são uma AMI de origem e uma região.

nota

Não use uma plataforma personalizada de exemplo não modificada em produção. O objetivo dos exemplos é mostrar algumas das funcionalidades disponíveis em uma plataforma personalizada, mas eles não foram reforçados para uso em produção.

NodePlatform_Ubuntu.zip

Essa Plataforma personalizada é baseada no Ubuntu 16.04 e é compatível com o Node.js 4.4.4. Vamos usar essa plataforma personalizada para os exemplos nesta seção.

NodePlatform_RHEL.zip

Essa Plataforma personalizada é baseada no RHEL 7.2 e é compatível com o Node.js 4.4.4.

NodePlatform_ AmazonLinux .zip

Essa Plataforma personalizada é baseada no Amazon Linux 2016.09.1 e é compatível com o Node.js 4.4.4.

TomcatPlatform_Ubuntu.zip

Essa Plataforma personalizada é baseada no Ubuntu 16.04 e é compatível com o Tomcat 7/Java 8.

CustomPlatform_ NodeSampleApp .zip

Um exemplo de Node.js que usa express e ejs para exibir uma página da web estática.

CustomPlatform_ TomcatSampleApp .zip

Um exemplo de Tomcat que exibe uma página da web estática quando implantado.

Faça download do arquivo demonstrativo de definição da plataforma: NodePlatform_Ubuntu.zip. Esse arquivo contém um arquivo de definição de plataforma, um modelo do Packer, scripts executados pelo Packer durante a criação de imagens e scripts e arquivos de configuração copiados pelo Packer na instância do criador durante a criação da plataforma.

exemplo NodePlatform_Ubuntu.zip
|-- builder                 Contains files used by Packer to create the custom platform
|-- custom_platform.json    Packer template
|-- platform.yaml           Platform definition file
|-- ReadMe.txt              Briefly describes the sample

O arquivo de definição da plataforma platform.yaml, informa ao Elastic Beanstalk o nome do modelo do Packer custom_platform.json.

version: "1.0"

provisioner:
  type: packer
  template: custom_platform.json
  flavor: ubuntu1604

O modelo do Packer instrui o próprio Packer a criar as AMIs para a plataforma usando uma AMI do Ubuntu como base para a imagem da plataforma para tipos de instâncias HVM. A seção provisioners instrui o Packer a copiar todos os arquivos na pasta builder dentro do arquivo para a instância e a executar o script builder.sh na instância. Quando os scripts são concluídos, o Packer cria uma imagem da instância modificada.

O Elastic Beanstalk cria três variáveis de ambiente que podem ser usadas para marcar as AMIs no Packer:

AWS_EB_PLATFORM_ARN

O ARN da plataforma personalizada.

AWS_EB_PLATFORM_NAME

O nome da plataforma personalizada.

AWS_EB_PLATFORM_VERSION

A versão da plataforma personalizada.

O arquivo custom_platform.json de exemplo usa essas variáveis para definir os seguintes valores que ele utiliza nos scripts:

  • platform_name, que é definido por platform.yaml

  • platform_version, que é definido por platform.yaml

  • platform_arn, que é definido pelo script de construção principal, builder.sh, exibido no fim do arquivo custom_platform.json de exemplo.

O arquivo custom_platform.json contém duas propriedades para as quais você precisa fornecer valores: source_ami e region. Para obter detalhes sobre como escolher os valores corretos de AMI e região, consulte Atualização do modelo do Packer no eb-custom-platforms-samples GitHub repositório.

exemplo custom_platform.json
{
  "variables": {
    "platform_name": "{{env `AWS_EB_PLATFORM_NAME`}}",
    "platform_version": "{{env `AWS_EB_PLATFORM_VERSION`}}",
    "platform_arn": "{{env `AWS_EB_PLATFORM_ARN`}}"
  },
  "builders": [
    {
      ...
      "region": "",
      "source_ami": "",
      ...
    }
  ],
  "provisioners": [
    {...},
    {
      "type": "shell",
      "execute_command": "chmod +x {{ .Path }}; {{ .Vars }} sudo {{ .Path }}",
      "scripts": [
        "builder/builder.sh"
      ]
    }
  ]
}

Os scripts e outros arquivos incluídos no arquivo de definição de plataforma variam muito de acordo com as modificações que você deseja fazer na instância. A plataforma de exemplo inclui os seguintes scripts:

  • 00-sync-apt.sh: comentados: apt -y update. Nós comentamos fora do comando porque ele solicita a entrada ao usuário, que divide a atualização do pacote automatizado. Isso pode ser um problema no Ubuntu. No entanto, executar apt -y update ainda é a melhor prática recomendada. Por esse motivo, nós deixamos o comando no script de exemplo para referência.

  • 01-install-nginx.sh: instala o nginx.

  • 02-setup-platform.sh: instala wget, tree e git. Copia hooks e configurações de registro na instância e cria os seguintes diretórios:

    • /etc/SampleNodePlatform: onde é feito upload do arquivo de configuração do contêiner durante a implantação.

    • /opt/elasticbeanstalk/deploy/appsource/: onde o script 00-unzip.sh carrega o código-fonte da aplicação durante a implantação (consulte a seção Ferramentas de script de plataforma para obter informações sobre esse script).

    • /var/app/staging/: onde o código-fonte da aplicação é processado durante a implantação.

    • /var/app/current/: onde o código-fonte da aplicação é executado após o processamento.

    • /var/log/nginx/healthd/: onde o agente de integridade aprimorada grava os logs.

    • /var/nodejs: onde é feito upload dos arquivos Node.js durante a implantação.

Use a CLI do EB para criar sua primeira plataforma personalizada com o arquivo demonstrativo de definição de plataforma.

Para criar uma plataforma personalizada

  1. Instale a CLI do EB.

  2. Crie um diretório no qual você extrairá a plataforma personalizada de exemplo.

    ~$ mkdir ~/custom-platform

  3. Extraia NodePlatform_Ubuntu.zip no diretório e, em seguida, altere para o diretório extraído.

    ~$ cd ~/custom-platform
~/custom-platform$ unzip ~/NodePlatform_Ubuntu.zip
~/custom-platform$ cd NodePlatform_Ubuntu

  4. Edite o arquivo custom_platform.json e forneça valores para as propriedades source_ami e region. Para obter detalhes, consulte Atualizar o modelo do Packer.

  5. Execute eb platform init e siga os prompts para inicializar um repositório da Plataforma.

    Você pode abreviar eb platform como ebp.

    nota

    O Windows PowerShell usa ebp como um alias de comando. Se você estiver executando o EB CLI no Windows PowerShell, use a forma longa deste comando:. eb platform

    ~/custom-platform$ eb platform init

    Esse comando também cria o diretório .elasticbeanstalk no diretório atual e adiciona o arquivo de configuração config.yml ao diretório. Não altere nem exclua esse arquivo, porque o Elastic Beanstalk o utiliza para criar a plataforma personalizada.

    Por padrão, o eb platform init usa o nome da pasta atual como o nome da plataforma personalizada, que é custom-platform neste exemplo.

  6. Execute eb platform create para iniciar um ambiente Packer e obter o ARN da Plataforma personalizada. Você precisará desse valor no futuro quando criar um ambiente com base na plataforma personalizada.

    ~/custom-platform$ eb platform create
...

    Por padrão, o Elastic Beanstalk cria o perfil da instância aws-elasticbeanstalk-custom-platform-ec2-role para plataformas personalizadas. Em vez disso, se você deseja usar um perfil da instância existente, adicione a opção -ip INSTANCE_PROFILE ao comando eb platform create.

    nota

    O Packer não poderá criar uma plataforma personalizada se você usar o perfil da instância padrão do Elastic Beanstalk aws-elasticbeanstalk-ec2-role.

    A EB CLI mostra a saída do evento do ambiente Packer até a conclusão da criação. Você pode sair da visualização do evento pressionando Ctrl+C.

  7. Você pode consultar os logs para ver se há erros usando o comando eb platform logs.

    ~/custom-platform$ eb platform logs
...

  8. Você pode verificar o processo mais tarde com eb platform events.

    ~/custom-platform$ eb platform events
...

  9. Verifique o status da sua Plataforma com eb platform status.

    ~/custom-platform$ eb platform status
...

Quando a operação for concluída, você terá uma plataforma que poderá ser usada para executar um ambiente do Elastic Beanstalk.

Você pode usar a plataforma personalizada ao criar um ambiente do console. Consulte O assistente de criação de novo ambiente.

Para iniciar um ambiente em sua plataforma personalizada

  1. Crie um diretório para seu aplicativo.

    ~$ mkdir custom-platform-app
~$ cd ~/custom-platform-app

  2. Inicialize um repositório do aplicativo.

    ~/custom-platform-app$ eb init
...

  3. Baixe o aplicativo de amostra NodeSampleApp.zip.

  4. Extraia o aplicativo de exemplo.

    ~/custom-platform-app$ unzip ~/NodeSampleApp.zip

  5. Execute eb create -p CUSTOM-PLATFORM-ARN, em que CUSTOM-PLATFORM-ARN é o ARN retornado por um comando eb platform create para iniciar um ambiente que executa sua Plataforma personalizada.

    ~/custom-platform-app$ eb create -p CUSTOM-PLATFORM-ARN
...

Conteúdo do arquivamento de definição da plataforma

Um arquivo de definição de plataforma é a plataforma equivalente a um pacote de origem de aplicação. O arquivo de definição de plataforma é um arquivo ZIP que contém um arquivo de definição de plataforma, um modelo do Packer e os scripts e arquivos usados pelo modelo do Packer para criar a plataforma.

nota

Quando a CLI do EB é utilizada para criar uma plataforma personalizada, ela cria um arquivo de definição de plataforma com base nos arquivos e pastas no repositório de sua plataforma para que você não precise criar o arquivo manualmente.

O arquivo de definição de plataforma é um arquivo formatado em YAML que deve ser denominado platform.yaml e estar na raiz do arquivo de definição de plataforma. Consulte Criar uma plataforma personalizada para obter uma lista das chaves obrigatórias e opcionais compatíveis com um arquivo de definição de plataforma.

Você não precisa fornecer um nome específico ao modelo do Packer, mas o nome do arquivo deve corresponder ao modelo do provisionador especificado no arquivo de definição de plataforma. Consulte a documentação oficial do Packer para obter instruções sobre a criação de modelos.

Os outros arquivos no arquivo de definição de plataforma são scripts e arquivos usados pelo modelo para personalizar uma instância antes de criar uma AMI.

Hooks de plataforma personalizada

O Elastic Beanstalk usa uma estrutura de diretórios padronizada para hooks em plataformas personalizadas. Esses scripts são executados durante eventos de ciclo de vida e em resposta a operações de gerenciamento: quando as instâncias são executadas em seu ambiente ou quando um usuário inicia uma implantação ou usa o recurso de reinicialização do servidor de aplicativos.

Coloque os scripts que você deseja que os hooks acionem em uma das subpastas da pasta /opt/elasticbeanstalk/hooks/.

Atenção

O uso de hooks de plataforma personalizadas não é compatível com plataformas gerenciadas. Os hooks de plataforma personalizada são projetados para plataformas personalizadas. Em plataformas gerenciadas do Elastic Beanstalk, eles podem funcionar de forma diferente ou ter alguns problemas, e o comportamento pode ser diferente entre plataformas. Nas plataformas da AMI do Amazon Linux (anteriores ao Amazon Linux 2), eles ainda podem funcionar de maneiras úteis em alguns casos; use-os com cautela.

Os ganchos de plataforma personalizada são um recurso legado existente em plataformas da AMI do Amazon Linux. Nas plataformas do Amazon Linux 2, os ganchos de plataforma personalizados na pasta /opt/elasticbeanstalk/hooks/ foram totalmente descontinuados. O Elastic Beanstalk não os lê nem os executa. As plataformas do Amazon Linux 2 são compatíveis com um novo tipo de ganchos de plataforma, projetados especificamente para estender as plataformas gerenciadas do Elastic Beanstalk. É possível adicionar scripts e programas personalizados diretamente a um diretório de ganchos no pacote de origem da aplicação. O Elastic Beanstalk os executa durante vários estágios de provisionamento de instâncias. Para obter mais informações, expanda a seção Platform Hooks (Hooks de plataforma) em Estender as plataformas Linux do Elastic Beanstalk.

Os hooks são organizados nas seguintes pastas:

  • appdeploy – Scripts executados durante uma implantação de aplicativo. O Elastic Beanstalk executa uma implantação de aplicativo quando novas instâncias são executadas e quando um cliente inicia a implantação de uma nova versão.

  • configdeploy: scripts executados quando um cliente executa uma atualização de configuração que afeta a configuração do software na instância, por exemplo, definição das propriedades do ambiente ou habilitação da alternância de logs no Amazon S3.

  • restartappserver – Scripts executados quando um cliente executa uma operação de reinicialização do servidor de aplicativos.

  • preinit – Scripts executados durante o bootstrapping da instância.

  • postinit – Scripts executados após o bootstrapping da instância.

As pastas appdeploy, configdeploy e restartappserver contêm as subpastas pre, enact e post. Em cada fase de uma operação, todos os scripts na pasta pre são executados em ordem alfabética, em seguida os da pasta enact e depois os da pasta post.

Quando uma instância é iniciada, o Elastic Beanstalk executa preinit, appdeploy e postinit, nessa ordem. Nas implantações subsequentes às instâncias em execução, o Elastic Beanstalk executa hooks appdeploy. Os hooks configdeploy são executados quando um usuário atualiza as definições de configuração de software da instância. Os hooks restartappserver são executados somente quando o usuário inicia uma reinicialização do servidor de aplicativos.

Quando os scripts encontram erros, eles podem sair com um status diferente de zero e gravar no arquivo stderr para falhar a operação. A mensagem que você gravar no stderr é exibida no evento que é gerado quando a operação falha. O Elastic Beanstalk também captura essas informações no arquivo de log /var/log/eb-activity.log. Se você não deseja que a operação falhe, retorne 0. As mensagens que você gravar no stderr ou no stdout aparecerão nos logs de implantação, mas não aparecerão no stream de eventos, a menos que a operação falhe.

Limpeza da instância do Packer

Em determinadas circunstâncias, como interrupção do processo do construtor Packer antes de ser concluído, as instâncias executadas pelo Packer não serão limpas. Essas instâncias não fazem parte do ambiente do Elastic Beanstalk e podem ser visualizadas e encerradas somente usando o serviço Amazon EC2.

Para limpar manualmente essas instâncias

  1. Abra o console do Amazon EC2.

  2. Verifique se você está na mesma AWS região em que criou a instância com o Packer.

  3. Em Resources (Recursos), escolha N Running Instances (N instâncias em execução), em que N indica o número de instâncias em execução.

  4. Clique na caixa de texto de consulta.

  5. Selecione a tag Name (Nome).

  6. Digite packer.

    A consulta deve ter a seguinte aparência: tag:Name: packer (tag:Nome: packer)

  7. Selecione quaisquer instâncias correspondentes à consulta.

  8. Se Instance State (Estado da instância) for running (em execução), escolha Actions (Ações), Instance State (Estado da instância), Stop (Parar) e, em seguida, Actions (Ações), Instance State (Estado da instância) e Terminate (Encerrar).

Formato do arquivo platform.yaml

O arquivo platform.yaml tem o seguinte formato.

version: "version-number"

provisioner:
   type: provisioner-type
   template: provisioner-template
   flavor: provisioner-flavor
        
metadata:
   maintainer: metadata-maintainer
   description: metadata-description
   operating_system_name: metadata-operating_system_name
   operating_system_version: metadata-operating_system_version
   programming_language_name: metadata-programming_language_name
   programming_language_version: metadata-programming_language_version
   framework_name: metadata-framework_name
   framework_version: metadata-framework_version

option_definitions:
   - namespace: option-def-namespace
     option_name: option-def-option_name
     description: option-def-description
     default_value: option-def-default_value

option_settings:
   - namespace: "option-setting-namespace"
     option_name: "option-setting-option_name"
     value: "option-setting-value"

Substitua os espaços reservados por esses valores:

version-number

Obrigatório. A versão da definição de YAML. Deve ser 1.0.

provisioner-type

Obrigatório. O tipo de construtor usado para criar a plataforma personalizada. Deve ser packer.

provisioner-template

Obrigatório. O arquivo JSON com as configurações de provisioner-type.

provisioner-flavor

Opcional. O sistema operacional básico usado para a AMI. Um dos seguintes:

amazon (padrão)

Amazon Linux Se não for especificado, a versão mais recente do Amazon Linux quando a plataforma é criada.

O Amazon Linux 2 não é um tipo de sistema operacional compatível.

ubuntu1604

Ubuntu 16.04 LTS

rhel7

RHEL 7

rhel6

RHEL 6

metadata-maintainer

Opcional. As informações de contato da pessoa que possui a plataforma (100 caracteres).

metadata-description

Opcional. Descrição da plataforma (2.000 caracteres).

metadata-operating_system_name

Opcional. Nome do sistema operacional da plataforma (50 caracteres). Esse valor está disponível ao filtrar a saída da ListPlatformVersionsAPI.

metadata-operating_system_version

Opcional. Versão do sistema operacional da plataforma (20 caracteres).

metadata-programming_language_name

Opcional. Linguagem de programação compatível com a plataforma (50 caracteres)

metadata-programming_language_version

Opcional. Versão da linguagem da plataforma (20 caracteres).

metadata-framework_name

Opcional. Nome do framework da Web usado pela plataforma (50 caracteres).

metadata-framework_version

Opcional. Versão do framework da Web da plataforma (20 caracteres).

option-def-namespace

Opcional. Um namespace sob aws:elasticbeanstalk:container:custom (100 caracteres).

option-def-option_nome

Opcional. O nome da opção (100 caracteres). Você pode definir até 50 opções de configuração personalizadas que a plataforma fornece aos usuários.

option-def-description

Opcional. Descrição da opção (1.024 caracteres).

option-def-default_valor

Opcional. O valor padrão usado quando o usuário não especificar um.

O exemplo a seguir cria a opção NPM_START.

options_definitions:
 -  namespace: "aws:elasticbeanstalk:container:custom:application"
    option_name: "NPM_START"
    description: "Default application startup command"
    default_value: "node application.js"
option-setting-namespace

Opcional. Namespace da opção.

option-setting-option_nome

Opcional. Nome da opção. Você pode especificar até 50 opções fornecidas pelo Elastic Beanstalk.

option-setting-value

Opcional. Valor padrão usado quando o usuário não especifica um.

O exemplo a seguir cria a opção TEST.

option_settings:
 - namespace: "aws:elasticbeanstalk:application:environment"
   option_name: "TEST"
   value: "This is a test"

Atribuir tags em versões de plataforma personalizada

Você pode aplicar tags às versões AWS Elastic Beanstalk personalizadas da sua plataforma. As tags são pares de valores-chave associados AWS aos recursos. Para obter informações sobre a atribuição de tags do recurso do Elastic Beanstalk, casos de uso, restrições de chave e valor de tag, além de tipos de recursos compatíveis, consulte Marcar recursos da aplicação do Elastic Beanstalk.

Você pode especificar tags quando criar uma versão da plataforma personalizada. Em uma versão da plataforma personalizada existente, você pode adicionar ou remover tags e atualizar os valores de tags existentes. Você pode adicionar até 50 tags para cada versão da plataforma personalizada.

Adicionar tags durante a criação da versão da plataforma personalizada

Se você usar a CLI do EB para criar a versão da plataforma personalizada, use a opção --tags com eb platform create para adicionar tags.

~/workspace/my-app$ eb platform create --tags mytag1=value1,mytag2=value2

Com o AWS CLI ou outros clientes baseados em API, adicione tags usando o --tags parâmetro no create-platform-version comando.

$ aws elasticbeanstalk create-platform-version \
      --tags Key=mytag1,Value=value1 Key=mytag2,Value=value2 \
      --platform-name my-platform --platform-version 1.0.0 --platform-definition-bundle S3Bucket=DOC-EXAMPLE-BUCKET,S3Key=sample.zip

Gerenciar tags de uma versão da plataforma personalizada existente

É possível adicionar, atualizar e excluir tags em uma versão da plataforma personalizada existente do Elastic Beanstalk.

Se você usar a CLI do EB para atualizar a versão da plataforma personalizada, use eb tags para adicionar, atualizar, excluir ou listar tags.

Por exemplo, o comando a seguir lista as tags em uma versão da plataforma personalizada.

~/workspace/my-app$ eb tags --list --resource "arn:aws:elasticbeanstalk:us-east-2:my-account-id:platform/my-platform/1.0.0"

O comando a seguir atualiza a tag mytag1 e exclui a tag mytag2.

~/workspace/my-app$ eb tags --update mytag1=newvalue --delete mytag2 \
      --resource "arn:aws:elasticbeanstalk:us-east-2:my-account-id:platform/my-platform/1.0.0"

Para obter uma lista de opções e mais exemplos, consulte eb tags.

Com o AWS CLI ou outros clientes baseados em API, use o list-tags-for-resource comando para listar as tags de uma versão personalizada da plataforma.

$ aws elasticbeanstalk list-tags-for-resource --resource-arn "arn:aws:elasticbeanstalk:us-east-2:my-account-id:platform/my-platform/1.0.0"

Use o comando update-tags-for-resource para adicionar, atualizar ou excluir tags em uma versão da plataforma personalizada.

$ aws elasticbeanstalk update-tags-for-resource \
      --tags-to-add Key=mytag1,Value=newvalue --tags-to-remove mytag2 \
      --resource-arn "arn:aws:elasticbeanstalk:us-east-2:my-account-id:platform/my-platform/1.0.0"

Especifique as tags a serem adicionadas e atualizadas no parâmetro --tags-to-add do update-tags-for-resource. Uma tag não existente é adicionada, e o valor de uma tag existente é atualizado.

nota

Para usar alguns AWS CLI comandos e CLI do EB com uma versão de plataforma personalizada do Elastic Beanstalk, você precisa do ARN da versão da plataforma personalizada. Você pode recuperar o ARN usando o comando a seguir.

$ aws elasticbeanstalk list-platform-versions

Use a opção --filters para filtrar a saída até o nome da plataforma personalizada.