Plataformas personalizadas do Elastic Beanstalk (retiradas) - 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 (retiradas)

nota

Em 18 de julho de 2022, o Elastic Beanstalk definiu o status de todas as filiais da plataforma baseadas no Amazon Linux () como descontinuadas. AMI AL1 Isso inclui plataformas personalizadas. O Elastic Beanstalk não é compatível com plataformas personalizadas. Para obter mais informações sobre a aposentadoria do Amazon Linux AMI pela 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 suportavam a criação AMI e a partir do AMI Amazon RHEL Linux, RHEL 7, 6 ou Ubuntu 16.04. AMIs 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 com imagens personalizadas, nas quais você modifica uma Amazon Machine Image (AMI) para uso com uma plataforma existente do Elastic Beanstalk, e o Elastic Beanstalk ainda fornece os scripts da plataforma e controla a pilha de software da plataforma. 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, você cria uma a AMI partir de um dos sistemas operacionais compatíveis — Ubuntu ou Amazon Linux (consulte a flavor entrada Formato do arquivo platform.yaml para ver os números exatos da versão) — e adiciona outras personalizações. RHEL Você cria sua própria plataforma Elastic Beanstalk usando o Packer, que é uma ferramenta de código aberto para criar imagens de máquina para várias plataformas, AMIs inclusive para uso com o Amazon Elastic Compute Cloud (Amazon). EC2 Uma plataforma do Elastic Beanstalk AMI compreende um conjunto configurado para executar um conjunto de software que dá suporte a um aplicativo e metadados que podem incluir opções de configuração personalizadas e configurações 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.

Você cria uma plataforma fornecendo ao Elastic Beanstalk um modelo do Packer e os scripts e arquivos que o modelo invoca para criar um. AMI Esses componentes são empacotados com um arquivo de definição de plataforma, que especifica o modelo e os metadados, em um ZIP arquivo, 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 da sua conta podem usar suas plataformas personalizadas especificando uma plataforma ARN durante a criação do ambiente. Eles ARNs são retornados pelo eb platform create comando 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 a ARNMyCustomPlatformARN, que poderia ser a versão 3.0, sua linha de CLI comando do EB ficaria assim:

eb create -p MyCustomPlatformARN

Para implantar a versão 2.1, sua linha de CLI comando do EB ficaria 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 nas amostras antes de usá-los são uma fonte AMI 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 na RHELversão 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 informa ao Packer como criar o AMIs para a plataforma, usando um Ubuntu AMI como base para a imagem da plataforma para tipos de HVM instância. 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 no Packer: AMIs

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 AMI e de 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 seus ambientes do Elastic Beanstalk 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 o EB CLI para criar sua primeira plataforma personalizada com o arquivo de definição de plataforma de amostra.

Para criar uma plataforma personalizada
  1. Instale o EB CLI.

  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 createpara iniciar um ambiente Packer e obter ARN a 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.

    O EB CLI mostra a saída do evento do ambiente do Packer até que a construção seja concluída. 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. Corraeb create -p CUSTOM-PLATFORM-ARN, onde CUSTOM-PLATFORM-ARN é o ARN retornado por um eb platform create comando para iniciar um ambiente executando 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 ZIP arquivo 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 sua plataforma.

nota

Quando você usa o EB CLI para criar uma plataforma personalizada, o EB CLI cria um arquivo de definição de plataforma a partir dos arquivos e pastas no repositório da plataforma, para que você não precise criar o arquivamento manualmente.

O arquivo de definição da plataforma é um arquivo YAML formatado que deve ser nomeado platform.yaml e estar na raiz do arquivo de definição da 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 em seu arquivo de definição de plataforma são scripts e arquivos usados pelo modelo para personalizar uma instância antes de criar umaAMI.

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 AMI plataformas Amazon Linux (anteriores ao Amazon Linux 2), elas ainda podem funcionar de maneiras úteis em alguns casos; use-as com cuidado.

Ganchos de plataforma personalizados são um recurso antigo que existe nas AMI plataformas 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 só podem ser visualizadas e encerradas usando o serviço da Amazon. EC2

Para limpar manualmente essas instâncias
  1. Abra o EC2console da Amazon.

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

  3. Em Recursos, escolha N Instâncias em execução, onde 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 YAML definição. 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 JSON arquivo que contém as configurações para provisioner-type.

provisioner-flavor

Opcional. O sistema operacional básico usado para AMI o. 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

RHEL7

rhel6

RHEL6

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 do 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_name

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_value

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_name

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ê usa o EB CLI para criar sua versão personalizada da plataforma, use a --tags opção com eb platform create para adicionar tags.

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

Com o AWS CLI ou com outros clientes API baseados, 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=amzn-s3-demo-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ê usa o EB CLI para atualizar sua versão personalizada da plataforma, 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 API baseados, 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 dos EB CLI e AWS CLI comandos com uma versão de plataforma personalizada do Elastic Beanstalk, você precisa da versão personalizada da plataforma. ARN 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.