

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

# Buildfile e Procfile
<a name="platforms-linux-extend.build-proc"></a>

Algumas plataformas permitem que você personalize a maneira como cria ou prepara seu aplicativo e especifique os processos que executam seu aplicativo. Cada tópico individual da plataforma menciona especificamente o *Buildfile and/or *Procfile** se a plataforma os suportar. Procure sua plataforma específica em [Plataformas do Elastic Beanstalk](concepts-all-platforms.md).

Para todas as plataformas compatíveis, a sintaxe e a semântica são idênticas e descritas nesta página. Tópicos individuais da plataforma mencionam o uso específico desses arquivos para criar e executar aplicativos em suas respectivas linguagens.

## Buildfile
<a name="platforms-linux-extend.build"></a>

Para especificar um comando personalizado de compilação e configuração para o aplicativo, coloque um arquivo chamado `Buildfile` no diretório raiz da origem do aplicativo. O nome do arquivo diferencia maiúsculas de minúsculas. Use a seguinte sintaxe para o `Buildfile`.

```
{{<process_name>}}: {{<command>}}
```

O comando no `Buildfile` deve corresponder à expressão regular: `^[A-Za-z0-9_-]+:\s*[^\s].*$`.

O Elastic Beanstalk não monitora a aplicação executada com um `Buildfile`. Use um `Buildfile` para comandos que são executados por breves períodos e são encerrados após a conclusão das tarefas. Para processos de aplicativo de longa execução que não devem ser encerrados, use o [Procfile](#platforms-linux-extend.proc).

Todos os caminhos no `Buildfile` são relativos à raiz do pacote de origem. No seguinte exemplo de um `Buildfile`, o `build.sh` é um script de shell localizado na raiz do pacote de origem.

**Example Buildfile**  

```
make: ./build.sh
```

Se você quiser fornecer etapas de compilação personalizadas, recomendamos que você use os hooks de plataforma `predeploy` para qualquer coisa, exceto os comandos mais simples, em vez de um `Buildfile`. Os hooks de plataforma permitem scripts mais avançados e melhor tratamento de erros. Os hooks de plataforma são descritos na próxima seção.

## Procfile
<a name="platforms-linux-extend.proc"></a>

Para especificar comandos personalizados para iniciar e executar o aplicativo, coloque um arquivo chamado `Procfile` no diretório raiz da origem do aplicativo. O nome do arquivo diferencia maiúsculas de minúsculas. Use a seguinte sintaxe para o `Procfile`. Você pode especificar um ou mais comandos.

```
{{<process_name1>}}: {{<command1>}}
{{<process_name2>}}: {{<command2>}}
...
```

Cada linha no `Procfile` deve corresponder à expressão regular: `^[A-Za-z0-9_-]+:\s*[^\s].*$`.

Use um `Procfile` para processos de aplicações de longa execução que não devem ser fechadas. O Elastic Beanstalk espera que os processos sejam executados a partir do `Procfile` para serem executados continuamente. O Elastic Beanstalk monitora esses processos e reinicia qualquer processo que seja encerrado. Para processos de curta execução, use um [Buildfile](#platforms-linux-extend.build).

Todos os caminhos no `Procfile` são relativos à raiz do pacote de origem. O exemplo do `Procfile` a seguir define três processos. O primeiro, chamado `web` no exemplo, é o *principal aplicativo web*.

**Example Procfile**  

```
web: {{bin/myserver}}
cache: {{bin/mycache}}
foo: {{bin/fooapp}}
```

O Elastic Beanstalk configura o servidor de proxy para encaminhar solicitações à sua aplicação Web principal na porta 5000, e esse número de porta pode ser configurado. Um uso comum para um `Procfile` é passar esse número de porta para sua aplicação como um argumento de comando. Para obter detalhes sobre a configuração do proxy, consulte [Configuração de proxy reverso](platforms-linux-extend.proxy.md).

O Elastic Beanstalk captura streams de saída padrão e erros dos processos `Procfile` em arquivos de log. O Elastic Beanstalk fornece nomes aos arquivos de log após o processo e os armazena no `/var/log`. Por exemplo, o processo `web` do exemplo anterior gera logs chamados `web-1.log` e `web-1.error.log` para `stdout` e `stderr`, respectivamente.