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

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. Para obter informações sobre a personalização do software em suas EC2 instâncias que executam o Windows, consultePersonalizar software em Windows Servers.

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.

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

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

Assista a seus eventos 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

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

Sintaxe

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

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.

Como especificar versões

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 rpm, a versão é especificada como um caminho para um arquivo no disco ou URL a. 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

O trecho a seguir especifica uma versão URL para rpm, solicita a versão mais recente do yum e a versão 0.10.2 do 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'

Grupos

Você pode usar a groups chave para criar grupos Linux/e atribuir UNIX 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

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

Opções

Trecho de exemplo

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

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

Usuários

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

Sintaxe

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

Opções

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

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

Origens

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

Sintaxe

sources:
  target directory: location of archive file

Formatos com compatibilidade

Os formatos com suporte são tar, tar+gzip, tar+bz2 e zip. Você pode referenciar locais externos, como o Amazon Simple Storage Service (Amazon S3) (por exemplohttps://amzn-s3-demo-bucket.s3.amazonaws.com/myobject,), desde que estejam acessíveis publicamenteURL.

Trecho de exemplo

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

Arquivos

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 pode ser extraído de umURL. 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

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

Trecho de exemplo

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

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.

Sintaxe

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

Opções

Trecho de exemplo

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 ]"

Serviços

É 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

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

Trecho de exemplo

Veja, a seguir, um trecho de exemplo:

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

Comandos de contêiner

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

É 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 exclusivos do Leader não são executados devido a alterações na configuração do lançamento, como uma alteração no AMI ID ou no tipo de instância.

Sintaxe

container_commands:
  name of container_command:
    command: "command to run"
    leader_only: true
  name of container_command:
    command: "command to run"

Opções

Trecho de exemplo

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"