

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

# Personalizar software em servidores Linux
<a name="customize-containers-ec2"></a>

Esta seção descreve o tipo de informação que você pode incluir em um arquivo de configuração para personalizar o software em suas EC2 instâncias que executam Linux. Para obter informações gerais sobre como personalizar e configurar ambientes, consulte [Configurar ambientes do Elastic Beanstalk](customize-containers.md). Para obter informações sobre a personalização do software em suas EC2 instâncias que executam o Windows, consulte[Personalizar software em Windows Servers](customize-containers-windows-ec2.md).

Você pode personalizar e configurar o software do qual seu aplicativo depende. É possível adicionar comandos a serem executados durante o provisionamento da instância, definir usuários e grupos do Linux e baixar ou criar arquivos diretamente nas instâncias do ambiente. Esses arquivos podem ser dependências exigidas pela aplicação, por exemplo, pacotes adicionais do repositório yum, ou podem ser arquivos de configuração, por exemplo, um arquivo de configuração de proxy para substituir configurações específicas usadas como padrão pelo Elastic Beanstalk.

**Observações**  
Em plataformas do Amazon Linux 2, em vez de fornecer arquivos e comandos em arquivos de configuração .ebextensions, é altamente recomendável usar *Buildfile*. *Procfile*, e *hooks de plataforma* sempre que possível para configurar e executar um código personalizado nas instâncias do ambiente durante o provisionamento da instância. Para obter detalhes sobre esses mecanismos, consulte [Estender as plataformas Linux do Elastic Beanstalk](platforms-linux-extend.md).
YAML depende de um recuo consistente. Compare o nível de recuo ao substituir o conteúdo em um arquivo de configuração de exemplo e se confira se o editor de texto usa espaços, e não caracteres de tabulação, como recuo.

Os arquivos de configuração oferecem suporte às seguintes chaves que afetam o servidor Linux no qual seu aplicativo é executado.

**Topics**
+ [Pacotes](#linux-packages)
+ [Groups (Grupos)](#linux-groups)
+ [Usuários](#linux-users)
+ [Fontes](#linux-sources)
+ [Arquivos](#linux-files)
+ [Comandos](#linux-commands)
+ [Services](#linux-services)
+ [Comandos de contêiner](#linux-container-commands)
+ [Exemplo: uso de CloudWatch métricas personalizadas da Amazon](customize-containers-cw.md)

As chaves são processadas na ordem em que aparecem listadas aqui.

Assista a seus [eventos](using-features.events.md) de ambiente enquanto desenvolve e testa os arquivos de configuração. O Elastic Beanstalk ignora um arquivo de configuração que contém erros de validação, como uma chave inválida, e não processa nenhuma das outras chaves no mesmo arquivo. Quando isso acontece, o Elastic Beanstalk adiciona um evento de aviso ao log de eventos.

## Pacotes
<a name="linux-packages"></a>

Use a chave `packages` para fazer download e instalar aplicativos e componentes predefinidos.

### Sintaxe
<a name="linux-packages-syntax"></a>

```
packages: 
  {{name of package manager}}:
    {{package name}}: {{version}}
    ...
  {{name of package manager}}:
    {{package name}}: {{version}}
    ...
  ...
```

Você pode especificar vários pacotes sob cada chave do gerenciador de pacotes.

### Formatos de pacote com suporte
<a name="linux-packages-support"></a>

Atualmente, o Elastic Beanstalk é compatível com os seguintes gerenciadores de pacote: yum, rubygems, python e rpm. Os pacotes são processados na seguinte ordem: rpm, yum e, em seguida, rubygems e python. Não há ordem entre rubygems e python. Dentro de cada gerenciador de pacotes, a ordem de instalação do pacote não é garantida. Use um gerenciador de pacotes compatível com o seu sistema operacional.

**nota**  
O Elastic Beanstalk é compatível com dois gerenciadores de pacotes subjacentes para Python, pip e easy\_install. No entanto, na sintaxe do arquivo de configuração, especifique o nome do gerenciador de pacotes como `python`. Quando você usa um arquivo de configuração para especificar um gerenciador de pacotes Python, o Elastic Beanstalk usa o Python 2.7. Se seu aplicativo conta com uma versão diferente do Python, especifique os pacotes a serem instalados em um arquivo `requirements.txt`. Para obter mais informações, consulte [Especificação de dependências usando um arquivo de requisitos no Elastic Beanstalk](python-configuration-requirements.md).

### Como especificar versões
<a name="linux-packages-versions"></a>

Dentro de cada gerenciador de pacotes, cada pacote é especificado como um nome de pacote e uma lista de versões. A versão pode ser uma sequência, uma lista de versões ou uma sequência ou lista vazia. Uma sequência ou lista vazia indica que você deseja a versão mais recente. Para o gerenciador de rpm, a versão é especificada como um caminho para um arquivo no disco ou um URL. Não há suporte para caminhos relativos.

Se você especificar uma versão de um pacote, o Elastic Beanstalk tentará instalar essa versão, mesmo que uma versão mais recente do pacote já esteja instalada na instância. Se uma versão mais recente já estiver instalada, a implantação não terá êxito. Alguns gerenciadores de pacotes oferecem suporte a várias versões, mas outros não. Verifique a documentação do seu gerenciador de pacotes para obter mais informações. Se você não especificar uma versão e uma versão do pacote já estiver instalada, o Elastic Beanstalk não instalará uma nova versão, pois vai considerar que você deseja manter e usar a versão existente.

### Trecho de exemplo
<a name="linux-packages-snippet"></a>

O trecho a seguir especifica um URL da versão para rpm, solicita a versão mais recente do yum e a versão 0.10.2 de chef do rubygems.

```
packages: 
  yum:
    libmemcached: [] 
    ruby-devel: []
    gcc: []
  rpm:
    epel: http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm
  rubygems: 
    chef: '0.10.2'
```

## Groups (Grupos)
<a name="linux-groups"></a>

Você pode usar a `groups` chave para criar Linux/UNIX grupos e atribuir grupos IDs. Para criar um grupo, adicione um novo par de chave/valor que mapeie um novo nome de grupo para um ID de grupo opcional. A chave de grupos pode conter um ou mais nomes de grupos. A tabela a seguir lista as chaves disponíveis.

### Sintaxe
<a name="linux-groups-syntax"></a>

```
groups:
  {{name of group}}: {}
  {{name of group}}:
    gid: "{{group id}}"
```

### Opções
<a name="linux-groups-options"></a>

`gid`  
Um número de ID de grupo.  
Se um ID de grupo for especificado e o grupo já existir por nome, a criação do grupo não terá êxito. Se outro grupo tiver o ID de grupo especificado, o sistema operacional poderá rejeitar a respectiva criação.

### Trecho de exemplo
<a name="linux-groups-snippet"></a>

O trecho a seguir especifica um grupo chamado groupOne, sem atribuir um ID de grupo, e um grupo chamado groupTwo que especificou um valor de ID de grupo 45.

```
groups:
  groupOne: {}
  groupTwo:
    gid: "{{45}}"
```

## Usuários
<a name="linux-users"></a>

Você pode usar a `users` chave para criar Linux/UNIX usuários na EC2 instância.

### Sintaxe
<a name="linux-users-syntax"></a>

```
users:
  {{name of user}}:
    groups:
      - {{name of group}}
    uid: "{{id of the user}}"
    homeDir: "{{user's home directory}}"
```

### Opções
<a name="linux-users-options"></a>

`uid`  
Um ID de usuário. Haverá falha no processo de criação se o nome do usuário existir com outro ID de usuário. Se o ID de usuário já estiver atribuído a um usuário existente, o sistema operacional poderá rejeitar a solicitação de criação.

`groups`  
Uma lista de nomes de grupos. O usuário é adicionado a cada grupo da lista.

`homeDir`  
O diretório base de usuário.

Os usuários são criados como usuários de sistema não interativos com um shell de `/sbin/nologin`. Este é o design e não pode ser modificado.

### Trecho de exemplo
<a name="linux-users-snippet"></a>

```
users:
  myuser:
    groups:
      - {{group1}}
      - {{group2}}
    uid: "{{50}}"
    homeDir: "{{/tmp}}"
```

## Fontes
<a name="linux-sources"></a>

Você pode usar a `sources` chave para baixar um arquivo de um URL público e descompactá-lo em um diretório de destino na EC2 instância.

### Sintaxe
<a name="linux-sources-syntax"></a>

```
sources:
  {{target directory}}: {{location of archive file}}
```

### Formatos com suporte
<a name="linux-sources-support"></a>

Os formatos com suporte são tar, tar\+gzip, tar\+bz2 e zip. Você pode fazer referência a locais externos, como o Amazon Simple Storage Service (Amazon S3) (por exemplo, `https://amzn-s3-demo-bucket.s3.amazonaws.com/myobject`), desde que o URL seja publicamente acessível.

### Trecho de exemplo
<a name="linux-sources-example"></a>

O exemplo a seguir faz download de um arquivo .zip público de um bucket do Amazon S3 e o descompacta em `/etc/myapp`:

```
sources:  
  /etc/myapp: https://amzn-s3-demo-bucket.s3.amazonaws.com/myobject
```

**nota**  
Não reutilize o mesmo caminho de destino para várias extrações. A extração de outra origem para o mesmo caminho de destino substituirá em vez de anexar aos conteúdos. 

## Arquivos
<a name="linux-files"></a>

Você pode usar a `files` chave para criar arquivos na EC2 instância. O conteúdo pode estar embutido no arquivo de configuração ou o conteúdo pode ser obtido de um URL. Os arquivos são gravados em disco em ordem lexicográfica.

É possível usar a chave `files` para fazer download de arquivos privados do Amazon S3 ao fornecer o perfil da instância para autorização.

Se o caminho do arquivo especificado já existir na instância, o arquivo existente será mantido com a extensão `.bak` anexada ao nome.

### Sintaxe
<a name="linux-files-syntax"></a>

```
files:  
  "{{target file location on disk}}": 
     mode: "{{six-digit octal value}}"
     owner: {{name of owning user for file}}
     group: {{name of owning group for file}}
     source: {{URL}}
     authentication: {{authentication name}}:

  "{{target file location on disk}}": 
     mode: "{{six-digit octal value}}"
     owner: {{name of owning user for file}}
     group: {{name of owning group for file}}
     content: |
      {{# this is my}}
      {{# file content}}
     encoding: {{encoding format}}
     authentication: {{authentication name}}:
```

### Opções
<a name="linux-files-options"></a>

`content`  
Conteúdo de sequência para adicionar ao arquivo. Especifique `content` ou `source`, mas não ambos.

`source`  
URL de um arquivo para fazer download: Especifique `content` ou `source`, mas não ambos.

`encoding`  
O formato de codificação da sequência especificada com a opção `content`.  
Valores válidos: `plain` \| `base64`

`group`  
Grupo do Linux que possui o arquivo.

`owner`  
Usuário do Linux que possui o arquivo.

`mode`  
Um valor octal de seis dígitos que representa o modo para este arquivo. Sem suporte para sistemas Windows. Use os primeiros três dígitos para symlinks e os três últimos dígitos para configurar permissões. Para criar um symlink, especifique `120{{xxx}}`, em que `xxx` define as permissões do arquivo de destino. Para especificar permissões para um arquivo, use os últimos três dígitos, como `000644`.

`authentication`  
O nome de um [método de autenticação do CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-authentication.html) para usar. É possível adicionar métodos de autenticação aos metadados do grupo de Auto Scaling com a chave Resources. Veja um exemplo a seguir.

### Trecho de exemplo
<a name="linux-files-snippet"></a>

```
files:
  "/home/ec2-user/myfile" :
    mode: "000755"
    owner: root
    group: root
    source: http://foo.bar/myfile
 
  "/home/ec2-user/myfile2" :
    mode: "000755"
    owner: root
    group: root
    content: |
      this is my
      file content
```

Exemplo usando um symlink. Isso cria um link `/tmp/myfile2.txt` que aponta para o arquivo existente `/tmp/myfile1.txt`.

```
files:
  "/tmp/myfile2.txt" :
    mode: "120400"
    content: "/tmp/myfile1.txt"
```

O exemplo a seguir usa a chave Resources para adicionar um método de autenticação chamado S3Auth e o usa para fazer download de um arquivo privado de um bucket do Amazon S3:

```
Resources:
  AWSEBAutoScalingGroup:
    Metadata:
      AWS::CloudFormation::Authentication:
        {{S3Auth}}:
          type: "s3"
          buckets: ["{{amzn-s3-demo-bucket2}}"]
          roleName:
            "Fn::GetOptionSetting":
              Namespace: "aws:autoscaling:launchconfiguration"
              OptionName: "IamInstanceProfile"
              DefaultValue: "aws-elasticbeanstalk-ec2-role"

files:
  "{{/tmp/data.json}}" :
    mode: "000755"
    owner: root
    group: root
    authentication: "{{S3Auth}}"
    source: {{https://elasticbeanstalk-us-west-2-123456789012.s3-us-west-2.amazonaws.com/data.json}}
```

## Comandos
<a name="linux-commands"></a>

Você pode usar a `commands` chave para executar comandos na EC2 instância. Os comandos executados antes da configuração do aplicativo e do servidor web e da extração do arquivo de versão do aplicativo.

Os comandos especificados são executadas como o usuário raiz e processados em ordem alfabética por nome. Por padrão, os comandos são executados no diretório raiz. Para executar comandos de outro diretório, use a opção `cwd`.

Para solucionar problemas com seus comandos, você pode encontrar a saída deles nos [logs da instância](using-features.logging.md).

### Sintaxe
<a name="linux-commands-syntax"></a>

```
commands:
  {{command name}}: 
    command: {{command to run}}
    cwd: {{working directory}}
    env: 
      {{variable name}}: {{variable value}}
    test: {{conditions for command}} 
    ignoreErrors: true
```

### Opções
<a name="linux-commands-options"></a>

`command`  
Uma matriz ([coleção de sequência em bloco](http://yaml.org/spec/1.2/spec.html#id2759963) em sintaxe de YAML) ou uma cadeia que especifica o comando a ser executado. Algumas observações importantes:  
+ Se você usar uma cadeia, você não precisa colocar a cadeia inteira entre aspas. Se você usar aspas, pule as ocorrências literais do mesmo tipo de citação.
+ Se você usar uma matriz, não precisará de caracteres de espaço de escape ou de aspas para parâmetros de comandos. Cada elemento de matriz é um único argumento de comando. Não use uma matriz para especificar vários comandos.
Os exemplos a seguir são todos equivalentes:  

```
commands:
  command1:
    command: git commit -m "This is a comment."
  command2:
    command: "git commit -m \"This is a comment.\""
  command3:
    command: 'git commit -m "This is a comment."'
  command4:
    command:
      - git
      - commit
      - -m
      - This is a comment.
```
Para especificar múltiplos comandos, use um [escalar de bloco literal](http://yaml.org/spec/1.2/spec.html#id2760844), como exibido no exemplo a seguir.  

```
commands:
  command block:
    command: |
      git commit -m "This is a comment."
      git push
```

`env`  
(Opcional) Define variáveis de ambiente para o comando. Essa propriedade substitui, em vez de anexar, o ambiente existente.

`cwd`  
(Opcional) O diretório de trabalho. Se não for especificado, os comandos serão executados a partir do diretório raiz (/).

`test`  
(Opcional) Um comando que deve retornar o valor `true` (código de saída 0) para que o Elastic Beanstalk processe o comando, por exemplo, um script de shell, contido na chave `command`.

`ignoreErrors`  
(Opcional) Um valor booliano que determina se outros comandos deverão ser executados se houver falha no comando incluído na chave `command` (retorna um valor diferente de zero). Defina esse valor como `true` para continuar executando os comandos mesmo se houver falha no comando. Defina-o como `false` para interromper a execução dos comandos em caso de falha no comando. O valor padrão é `false`.

### Trecho de exemplo
<a name="linux-commands-snippet"></a>

O exemplo a seguir executa um trecho de script do Python.

```
commands:
  python_install:
    command: myscript.py
    cwd: /home/ec2-user
    env:
      myvarname: myvarvalue
    test: "[ -x /usr/bin/python ]"
```

## Services
<a name="linux-services"></a>

É possível usar a chave `services` para definir quais serviços deverão ser iniciados ou interrompidos quando a instância for executada. A chave `services` também permite especificar dependências de origens, pacotes e arquivos para que, se for necessária uma reinicialização devido à instalação de arquivos, o Elastic Beanstalk reinicie o serviço.

### Sintaxe
<a name="linux-services-syntax"></a>

```
services:
  sysvinit:
    {{name of service}}:
      enabled: "true"
      ensureRunning: "true"
      files: 
        - "{{file name}}"
      sources: 
        - "{{directory}}"	
      packages: 
        {{name of package manager}}:
          "{{package name}}[: {{version}}]"
      commands: 
        - "{{name of command}}"
```

### Opções
<a name="linux-services-options"></a>

`ensureRunning`  
Defina `true` para garantir que o serviço esteja em execução depois que o Elastic Beanstalk for concluído.  
Defina `false` para garantir que o serviço não esteja em execução depois que o Elastic Beanstalk for concluído.  
Omita essa chave para não fazer nenhuma alteração no estado do serviço.

`enabled`  
Defina como `true` para garantir que o serviço seja iniciado automaticamente na inicialização.  
Defina como `false` para garantir que o serviço não seja iniciado automaticamente na inicialização.  
Omita essa chave para não fazer nenhuma alteração nessa propriedade.

`files`  
Uma lista de arquivos. Se o Elastic Beanstalk alterar um diretamente por meio do bloco de arquivos, o serviço será reiniciado.

`sources`  
Uma lista de diretórios. Se o Elastic Beanstalk expandir um arquivo em um desses diretórios, o serviço será reiniciado.

`packages`  
Um mapa do gerenciador de pacotes para uma lista de nomes de pacotes. Se o Elastic Beanstalk instalar ou atualizar um desses pacotes, o serviço será reiniciado.

`commands`  
Uma lista de nomes de comandos. Se o Elastic Beanstalk executar o comando especificado, o serviço será reiniciado.

### Trecho de exemplo
<a name="linux-services-snippet"></a>

Veja, a seguir, um trecho de exemplo:

```
services: 
  sysvinit:
    myservice:
      enabled: true
      ensureRunning: true
```

## Comandos de contêiner
<a name="linux-container-commands"></a>

É possível usar a chave `container_commands` para executar comandos que afetam o código-fonte do seu aplicativo. Os comandos de contêiner são executados depois que o aplicativo e o servidor Web são configurados e o arquivo de versão do aplicativo é extraído, mas antes da implantação da versão do aplicativo. Os comandos que não são de contêiner e outras operações de personalização são executados antes da extração do código-fonte do aplicativo.

Os comandos especificados são executadas como o usuário raiz e processados em ordem alfabética por nome. Os comandos de contêiner são executados no diretório de preparação, onde seu código-fonte é extraído antes de ser implantado no servidor de aplicativo. Quaisquer alterações que você fizer em seu código-fonte no diretório de preparação com um comando de contêiner serão incluídas quando a fonte for implantada em seu local final.

**nota**  
A saída dos comandos de contêiner é registrada no log da instância `cfn-init-cmd.log`. Para obter mais informações sobre como recuperar e visualizar registros de instâncias, consulte [Visualização de registros de EC2 instâncias da Amazon](using-features.logging.md).

É possível usar `leader_only` para somente executar o comando em uma única instância ou configurar um `test` para somente executar o comando quando um comando de teste for avaliado como `true`. Os comandos de contêiner somente líderes são executados apenas durante a criação do ambiente e as implantações, enquanto outros comandos e operações de personalização de servidor são executados sempre que uma instância é provisionada ou atualizada. Os comandos de contêiner somente líderes não são executados devido a alterações na configuração de execução, como uma alteração no ID do AMI ou no tipo de instância.

### Sintaxe
<a name="linux-container-commands-syntax"></a>

```
container_commands:
  {{name of container_command}}:
    command: "{{command to run}}"
    leader_only: true
  {{name of container_command}}:
    command: "{{command to run}}"
```

### Opções
<a name="linux-container-commands-options"></a>

`command`  
Uma string ou matriz de strings para execução.

`env`  
(Opcional) Defina variáveis de ambiente antes de executar o comando, substituindo qualquer valor existente.

`cwd`  
(Opcional) O diretório de trabalho. Por padrão, este é o diretório de preparação do aplicativo descompactado.

`leader_only`  
(Opcional) Somente execute o comando em uma única instância escolhida pelo Elastic Beanstalk. Os comandos de contêiner somente líderes são executados antes dos outros comandos de contêiner. Um comando pode ser somente líder ou ter um `test`, mas não as duas coisas (`leader_only` tem precedência).

`test`  
(Opcional) Execute um comando de teste que deve retornar `true` para executar o comando de contêiner. Um comando pode ser somente líder ou ter um `test`, mas não as duas coisas (`leader_only` tem precedência).

`ignoreErrors`  
(Opcional) Não falhar implantações se o comando de contêiner retornar um valor diferente de 0 (êxito). Defina como `true` para habilitar.

### Trecho de exemplo
<a name="linux-container-commands-snippet"></a>

Veja, a seguir, um trecho de exemplo.

```
container_commands:
  collectstatic:
    command: "django-admin.py collectstatic --noinput"
  01syncdb:
    command: "django-admin.py syncdb --noinput"
    leader_only: true
  02migrate:
    command: "django-admin.py migrate"
    leader_only: true
  99customize:
    command: "scripts/customize.sh"
```