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 (retirado) **nota** [Em 18 de julho de 2022,](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2022-07-18-linux-al1-retire.html) **o Elastic Beanstalk definiu o status de todas as ramificações da 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](using-features.migration-al.FAQ.md). 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 de uma AMI a partir da base Amazon Linux AMI, RHEL 7, RHEL 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. ## Plataformas personalizadas Uma plataforma personalizada é uma personalização mais avançada do que uma [imagem personalizada](using-features.customenv.md) 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](#platform-yaml-format) para ver os números de versão exatos), e inclua outras personalizações. Você cria sua própria [plataforma](https://www.packer.io/) 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 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](#custom-platform-creating), que especifica o modelo e os metadados, em um arquivo ZIP, conhecido como [arquivo de definição de plataforma](#custom-platforms-pda). 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](#custom-platforms-packercleanup). Os usuários em sua conta podem utilizar suas Plataformas personalizadas especificando um [Nome de região da Amazon (ARN) da Plataforma](AWSHowTo.iam.policies.arn.md) 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 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](#custom-platforms-tagging). ### 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](#platform-yaml-format). Você pode criar sua Plataforma personalizada do zero ou usar uma das [Plataformas personalizadas de exemplo](#custom-platforms-sample) 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\$1Ubuntu.zip](https://github.com/awslabs/eb-custom-platforms-samples/releases/download/v1.0.4/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\$1RHEL.zip](https://github.com/awslabs/eb-custom-platforms-samples/releases/download/v1.0.4/NodePlatform_RHEL.zip) Essa Plataforma personalizada é baseada no **RHEL 7.2** e é compatível com o **Node.js 4.4.4**. [NodePlatform\$1 AmazonLinux .zip](https://github.com/awslabs/eb-custom-platforms-samples/releases/download/v1.0.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\$1Ubuntu.zip](https://github.com/awslabs/eb-custom-platforms-samples/releases/download/v1.0.4/TomcatPlatform_Ubuntu.zip) Essa Plataforma personalizada é baseada no **Ubuntu 16.04** e é compatível com o **Tomcat 7/Java 8**. [CustomPlatform\$1 NodeSampleApp .zip](https://github.com/awslabs/eb-custom-platforms-samples/releases/download/v1.0.4/CustomPlatform_NodeSampleApp.zip) Um exemplo de Node.js que usa **express** e **ejs** para exibir uma página da web estática. [CustomPlatform\$1 TomcatSampleApp .zip](https://github.com/awslabs/eb-custom-platforms-samples/releases/download/v1.0.4/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. **Example NodePlatform\$1Ubuntu.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 explica ao Packer como criar o AMIs para a plataforma, usando uma [AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) do Ubuntu como base para a imagem da plataforma para tipos de instância 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 no Packer: AMIs AWS\$1EB\$1PLATAFORMA\$1ARN O ARN da plataforma personalizada. AWS\$1EB\$1NOME\$1DA\$1PLATAFORMA O nome da plataforma personalizada. AWS\$1EB\$1VERSÃO\$1PLATAFORMA 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](https://github.com/aws-samples/eb-custom-platforms-samples#updating-packer-template) no *eb-custom-platforms-samples* GitHub repositório. **Example custom\$1platform.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](using-features.logging.md) 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 ambientes Elastic Beanstalk](custom-platforms-scripts.md) 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](health-enhanced.md#health-enhanced-agent) 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](eb-cli3.md#eb-cli3-install). 1. Crie um diretório no qual você extrairá a plataforma personalizada de exemplo. ``` ~$ mkdir ~/custom-platform ``` 1. 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 ``` 1. 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](https://github.com/aws-samples/eb-custom-platforms-samples#updating-packer-template). 1. Execute [**eb platform init**](eb3-platform.md#eb3-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. 1. Execute [**eb platform create**](eb3-platform.md#eb3-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**](eb3-platform.md#eb3-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\$1C**. 1. Você pode consultar os logs para ver se há erros usando o comando [**eb platform logs**](eb3-platform.md#eb3-platform-logs). ``` ~/custom-platform$ eb platform logs ... ``` 1. Você pode verificar o processo mais tarde com [**eb platform events**](eb3-platform.md#eb3-platform-events). ``` ~/custom-platform$ eb platform events ... ``` 1. Verifique o status da sua Plataforma com [**eb platform status**](eb3-platform.md#eb3-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](environments-create-wizard.md). **Para iniciar um ambiente em sua plataforma personalizada** 1. Crie um diretório para seu aplicativo. ``` ~$ mkdir custom-platform-app ~$ cd ~/custom-platform-app ``` 1. Inicialize um repositório do aplicativo. ``` ~/custom-platform-app$ eb init ... ``` 1. Baixe o aplicativo de amostra [NodeSampleApp.zip.](samples/NodeSampleApp.zip) 1. Extraia o aplicativo de exemplo. ``` ~/custom-platform-app$ unzip ~/NodeSampleApp.zip ``` 1. Execute**eb create -p *CUSTOM-PLATFORM-ARN***, onde o ARN *CUSTOM-PLATFORM-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](applications-sourcebundle.md). 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](#custom-platform-creating) 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](https://www.packer.io/docs/templates/introduction.html) 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](platforms-linux-extend.md). 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](using-features.logging.md), 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 [ EC2 console da Amazon](https://console.aws.amazon.com/ec2/). 1. Verifique se você está na mesma AWS região em que criou a instância com o Packer. 1. Em **Recursos**, escolha *N * **Running Instances**, onde *N* indica o número de instâncias em execução. 1. Clique na caixa de texto de consulta. 1. Selecione a tag **Name (Nome)**. 1. Digite **packer**. A consulta deve ter a seguinte aparência: **tag:Name: packer (tag:Nome: packer)** 1. Selecione quaisquer instâncias correspondentes à consulta. 1. 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 contendo 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\$1system\$1name* Opcional. Nome do sistema operacional da plataforma (50 caracteres). Esse valor está disponível ao filtrar a saída da [ListPlatformVersions](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_ListPlatformVersions.html)API. *metadata-operating\$1system\$1version* Opcional. Versão do sistema operacional da plataforma (20 caracteres). *metadata-programming\$1language\$1name* Opcional. Linguagem de programação compatível com a plataforma (50 caracteres) *metadata-programming\$1language\$1version* Opcional. Versão da linguagem da plataforma (20 caracteres). *metadata-framework\$1name* Opcional. Nome do framework da Web usado pela plataforma (50 caracteres). *metadata-framework\$1version* 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\$1name* 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\$1value* Opcional. O valor padrão usado quando o usuário não especificar um. O exemplo a seguir cria a opção **NPM\$1START**. ``` 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\$1name* Opcional. Nome da opção. Você pode especificar até 50 [opções fornecidas pelo Elastic Beanstalk](command-options-general.md). *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](applications-tagging-resources.md). 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](eb3-platform.md#eb3-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](https://docs.aws.amazon.com/cli/latest/reference/elasticbeanstalk/create-platform-version.html)** 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ê usar a CLI do EB para atualizar a versão da plataforma personalizada, use **[eb tags](eb3-tags.md)** 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](https://docs.aws.amazon.com/cli/latest/reference/elasticbeanstalk/list-tags-for-resource.html)** 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](https://docs.aws.amazon.com/cli/latest/reference/elasticbeanstalk/update-tags-for-resource.html)** 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.