AWS App Runner não estará mais aberto a novos clientes a partir de 30 de abril de 2026. Se você quiser usar o App Runner, inscreva-se antes dessa data. Os clientes atuais podem continuar usando o serviço normalmente. Para obter mais informações, consulte [Mudança de disponibilidade do AWS App Runner](https://docs.aws.amazon.com/apprunner/latest/dg/apprunner-availability-change.html). 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á. # Serviço App Runner baseado no código-fonte Você pode usar AWS App Runner para criar e gerenciar serviços com base em dois tipos fundamentalmente diferentes de fonte de serviço: *código-fonte* *e imagem* de origem. Independentemente do tipo de fonte, o App Runner se encarrega de iniciar, executar, escalar e balancear a carga do seu serviço. Você pode usar o CI/CD recurso do App Runner para rastrear alterações em sua imagem ou código fonte. Quando o App Runner descobre uma alteração, ele cria automaticamente (para o código-fonte) e implanta a nova versão no seu serviço App Runner. Este capítulo discute serviços baseados no código-fonte. Para obter informações sobre serviços baseados em uma imagem de origem, consulte[Serviço App Runner baseado em uma imagem de origem](service-source-image.md). O código-fonte é o código do aplicativo que o App Runner cria e implanta para você. Você aponta o App Runner para um [diretório de origem](#service-source-code.source-directory) em um repositório de código e escolhe um tempo de *execução* adequado que corresponda a uma versão da plataforma de programação. O App Runner cria uma imagem baseada na imagem base do tempo de execução e no código do seu aplicativo. Em seguida, ele inicia um serviço que executa um contêiner com base nessa imagem. *O App Runner fornece tempos de execução gerenciados convenientes e específicos da plataforma.* Cada um desses tempos de execução cria uma imagem de contêiner a partir do código-fonte e adiciona dependências de tempo de execução da linguagem à sua imagem. Você não precisa fornecer instruções de configuração e criação de contêineres, como um Dockerfile. Os subtópicos deste capítulo discutem as várias plataformas suportadas pelo App Runner — *plataformas gerenciadas* que fornecem tempos de execução gerenciados para diferentes ambientes e versões de programação. **Topics** + [Provedores de repositórios de código-fonte](#service-source-code.providers) + [Diretório de origem](#service-source-code.source-directory) + [Plataformas gerenciadas do App Runner](#service-source-code.managed-platforms) + [Fim do suporte para versões de tempo de execução gerenciado](#service-source-code.managed-platforms.eos) + [Versões de tempo de execução gerenciadas e a compilação do App Runner](#service-source-code.build-detail) + [Usar a plataforma Python do](service-source-code-python.md) + [Usar a plataforma Node.js do](service-source-code-nodejs.md) + [Usando a plataforma Java](service-source-code-java.md) + [Usar a plataforma .NET do](service-source-code-net6.md) + [Usar a plataforma PHP do](service-source-code-php.md) + [Usar a plataforma Ruby do](service-source-code-ruby.md) + [Usar a plataforma Go do](service-source-code-go1.md) ## Provedores de repositórios de código-fonte O App Runner implanta seu código-fonte lendo-o em um repositório de código-fonte. [O App Runner é compatível com dois provedores de repositórios de código-fonte: [GitHub](https://github.com/)e o Bitbucket.](https://bitbucket.org/) ### Implantação a partir do seu provedor de repositório de código-fonte Para implantar seu código-fonte em um serviço do App Runner a partir de um repositório de código-fonte, o App Runner estabelece uma conexão com ele. Ao usar o console do App Runner para [criar um serviço](manage-create.md), você fornece detalhes da conexão e um diretório de origem para o App Runner implantar seu código-fonte. **Conexões** Você fornece detalhes da conexão como parte do procedimento de criação do serviço. Quando você usa a API App Runner ou a AWS CLI, uma conexão é um recurso separado. Primeiro, você cria a conexão usando a ação [CreateConnection](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateConnection.html)da API. Em seguida, você fornece o ARN da conexão durante a criação do serviço usando a ação da [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API. **Diretório de origem** Ao criar um serviço, você também fornece um diretório de origem. Por padrão, o App Runner usa o diretório raiz do seu repositório como o diretório de origem. O diretório de origem é o local no seu repositório de código-fonte que armazena o código-fonte e os arquivos de configuração do seu aplicativo. Os comandos build e start também são executados a partir do diretório de origem. Ao usar a API App Runner ou a AWS CLI para criar ou atualizar um serviço, você fornece o diretório de origem nas ações da [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)e. Para obter mais informações, consulte a seção [Diretório de origem](#service-source-code.source-directory) abaixo. Para obter mais informações sobre a criação do serviço App Runner, consulte[Criar serviços do App Runner](manage-create.md). Para obter mais informações sobre as conexões do App Runner, consulte[Gerenciando conexões do App Runner](manage-connections.md). ## Diretório de origem Ao criar um serviço App Runner, você pode fornecer o diretório de origem, junto com o repositório e a ramificação. Defina o valor do campo **Diretório de origem** para o caminho do diretório do repositório que armazena o código-fonte e os arquivos de configuração do aplicativo. O App Runner executa os comandos build e start a partir do caminho do diretório de origem fornecido por você. Insira o valor do caminho do diretório de origem como absoluto a partir do diretório raiz do repositório. Se você não especificar um valor, o padrão é o diretório de nível superior do repositório, também conhecido como diretório raiz do repositório. Você também tem a opção de fornecer caminhos de diretório de origem diferentes além do diretório de repositório de nível superior. Isso suporta uma arquitetura de repositório monorepo, o que significa que o código-fonte de vários aplicativos é armazenado em um repositório. Para criar e oferecer suporte a vários serviços do App Runner a partir de um único monorepo, especifique diretórios de origem diferentes ao criar cada serviço. **nota** Se você especificar o mesmo diretório de origem para vários serviços do App Runner, os dois serviços serão implantados e operados individualmente. Se você optar por usar um arquivo de `apprunner.yaml` configuração para definir seus parâmetros de serviço, coloque-o na pasta do diretório de origem do repositório. Se a opção de **gatilho de implantação** estiver definida como **Automática**, as alterações confirmadas no diretório de origem acionarão uma implantação automática. * Somente as alterações no caminho do diretório de origem* acionarão uma implantação automática. É importante entender como a localização do diretório de origem afeta o escopo de uma implantação automática. Para obter mais informações, consulte *Implantações automatizadas em[Métodos de implantação](manage-deploy.md#manage-deploy.methods).* **nota** Se seu serviço App Runner usa os tempos de execução gerenciados do PHP e você gostaria de designar um diretório de origem diferente do repositório raiz padrão, é importante usar a versão correta do tempo de execução do PHP. Para obter mais informações, consulte [Usar a plataforma PHP do](service-source-code-php.md). ## Plataformas gerenciadas do App Runner As plataformas gerenciadas do App Runner fornecem tempos de execução gerenciados para vários ambientes de programação. Cada tempo de execução gerenciado facilita a criação e a execução de contêineres com base em uma versão de uma linguagem de programação ou ambiente de execução. Quando você usa um tempo de execução gerenciado, o App Runner começa com uma imagem de tempo de execução gerenciada. Essa imagem é baseada na [imagem Docker do Amazon Linux](https://hub.docker.com/_/amazonlinux) e contém um pacote de execução de linguagem, bem como algumas ferramentas e pacotes de dependências populares. O App Runner usa essa imagem de tempo de execução gerenciada como imagem base e adiciona o código do aplicativo para criar uma imagem do Docker. Em seguida, ele implanta essa imagem para executar seu serviço web em um contêiner. Você especifica um tempo de execução para seu serviço App Runner ao [criar um serviço](manage-create.md) usando o console do App Runner ou a operação da [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API. Você também pode especificar um tempo de execução como parte do código-fonte. Use a `runtime` palavra-chave em um [arquivo de configuração do App Runner](config-file.md) que você inclui no seu repositório de código. A convenção de nomenclatura de um tempo de execução gerenciado é*

*. O App Runner atualiza o tempo de execução do seu serviço para a versão mais recente em cada implantação ou atualização de serviço. Se seu aplicativo exigir uma versão específica de um tempo de execução gerenciado, você poderá especificá-la usando a `runtime-version` palavra-chave no [arquivo de configuração do App Runner](config-file.md). Você pode bloquear qualquer nível de versão, incluindo uma versão principal ou secundária. O App Runner só faz atualizações de nível inferior no tempo de execução do seu serviço. ## Fim do suporte para versões de tempo de execução gerenciado *Quando o provedor oficial ou a comunidade de um runtime de linguagem gerenciada declara oficialmente que uma versão é End of Life (EOL), o App Runner segue declarando que o status da versão é End of Support.* Se seu serviço estiver sendo executado em uma versão de tempo de execução de linguagem gerenciada que tenha atingido o End of Support, as seguintes políticas e recomendações se aplicam. **Fim do Support para uma versão de tempo de execução de uma linguagem:** + **Os serviços existentes** continuarão sendo executados e fornecendo tráfego, mesmo que usem um tempo de execução que tenha atingido o End of Support. No entanto, eles serão executados em tempos de execução sem suporte que não recebem mais atualizações, patches de segurança ou suporte técnico. + **As atualizações dos serviços existentes** que usam os tempos de execução do End of Support ainda são permitidas, mas não recomendamos o uso contínuo dos tempos de execução do End of Support para um serviço. + **Novos serviços** não podem ser criados usando os tempos de execução que atingiram a data de End of Support. **Ações necessárias para versões de runtime de linguagem com status End of Support:** + Se seu serviço for **baseado em uma imagem de origem**, nenhuma ação adicional será necessária de sua parte para esse serviço. + Se seu serviço for **baseado no código-fonte**, atualize a configuração do serviço para usar uma versão de tempo de execução compatível. Para fazer isso, selecione uma versão de tempo de execução compatível no [console do App Runner](https://console.aws.amazon.com/apprunner), atualize o `runtime` campo no arquivo de configuração [apprunner.yaml](config-file.md) ou use as operações de [CreateService[UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)/API ou as ferramentas IaC para definir o parâmetro. `runtime` Para obter uma lista dos tempos de execução suportados, consulte a página de *informações sobre a versão* de qualquer tempo de execução específico neste capítulo. + Como alternativa, você pode alternar para a opção de **fonte de imagem de contêiner** do App Runner. Consulte mais detalhes em [Serviço baseado em imagem](service-source-image.md). **nota** Se você estiver migrando do Node.js 12, 14 ou 16 para o **Node.js 22**, ou do Python 3.7 ou 3.8 para o Python 3.11, saiba que o Node.js 22 e o **Python** 3.11 usam um processo de criação revisado do App Runner que oferece compilações mais rápidas e eficientes. Para garantir a compatibilidade antes da atualização, recomendamos que você revise as [diretrizes do processo de criação](#service-source-code.build-detail) na próxima seção. As tabelas a seguir listam as versões de tempo de execução gerenciadas do App Runner que têm uma data de fim de suporte designada. | **Versões Runtime** | **Data de fim do suporte do App Runner** | | --- | --- | | [Tempos de execução compatíveis com Python 3.8](service-source-code-python-releases.md) | 1 de dezembro de 2025 | | [Tempos de execução compatíveis com Python 3.7](service-source-code-python-releases.md) | 1 de dezembro de 2025 | | Node.js 18 Tempos de [execução suportados](service-source-code-nodejs-releases.md) | 1 de dezembro de 2025 | | Node.js 16 Tempos de [execução suportados](service-source-code-nodejs-releases.md) | 1 de dezembro de 2025 | | Node.js 14 Tempos de [execução suportados](service-source-code-nodejs-releases.md) | 1 de dezembro de 2025 | | Node.js 12 Tempos de [execução suportados](service-source-code-nodejs-releases.md) | 1 de dezembro de 2025 | | .NET 6 \$1 | 1 de dezembro de 2025 | | PHP 8.1 \$1 | 31 de dezembro de 2025 | | Ruby 3.1 \$1 | 1 de dezembro de 2025 | | Vá 1 \$1 | 1 de dezembro de 2025 | **\$1** O App Runner não lançará nenhuma nova versão de idioma para os tempos de execução marcados com um asterisco (\$1). Esses tempos de execução são os seguintes: .NET, PHP, Ruby e Go. Se você tiver um serviço baseado em código configurado para esses tempos de execução, recomendamos uma das seguintes ações: + Se aplicável, alterne a configuração do serviço para um tempo de execução gerenciado compatível diferente. + Como alternativa, crie uma imagem de contêiner personalizada com sua versão de tempo de execução preferida e implante-a usando a [Serviço baseado em imagem](service-source-image.md) opção do App Runner. Você pode hospedar sua imagem no Amazon ECR. ## Versões de tempo de execução gerenciadas e a compilação do App Runner O App Runner oferece um processo de compilação atualizado para aplicativos que são executados nos tempos de execução da versão principal mais recente. Esse processo de construção revisado é mais rápido e eficiente. Ele também cria uma imagem final com um espaço menor que contém apenas o código-fonte, os artefatos de construção e os tempos de execução necessários para executar seu aplicativo. Nós nos referimos ao processo de compilação mais recente como compilação *revisada do App Runner e ao processo de compilação* original como compilação *original do App* Runner. Para evitar alterações nas versões anteriores das plataformas de tempo de execução, o App Runner só aplica a compilação revisada a versões específicas de tempo de execução, normalmente lançamentos principais recém-lançados. Introduzimos um novo componente no arquivo de `apprunner.yaml` configuração para tornar a compilação revisada compatível com versões anteriores para um caso de uso muito específico e também para fornecer mais flexibilidade para configurar a compilação do seu aplicativo. Esse é o [`pre-run`](config-file-ref.md#config-file-ref.run)parâmetro opcional. Explicamos quando usar esse parâmetro junto com outras informações úteis sobre as compilações nas seções a seguir. A tabela a seguir mostra qual versão da compilação do App Runner se aplica a versões específicas de tempo de execução gerenciado. Continuaremos atualizando este documento para mantê-lo informado sobre nossos tempos de execução atuais. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/apprunner/latest/dg/service-source-code.html) **nota** Alguns dos tempos de execução listados incluem uma data **de End of Support**. Para obter mais informações, consulte [Fim do suporte para versões de tempo de execução gerenciado](#service-source-code.managed-platforms.eos). **Importante** **Python 3.11** — Temos recomendações específicas para a configuração de compilação de serviços que usam o tempo de execução gerenciado do Python 3.11. Para obter mais informações, consulte [Explicações para versões específicas de tempo de execução](service-source-code-python.md#service-source-code-python.callouts) o tópico da *plataforma Python*. ### Saiba mais sobre as compilações e a migração do App Runner Ao migrar seu aplicativo para um novo tempo de execução que usa a compilação revisada, talvez seja necessário modificar um pouco sua configuração de compilação. Para contextualizar as considerações de migração, primeiro descreveremos os processos de alto nível da compilação original do App Runner e da versão revisada. Seguiremos com uma seção que descreve atributos específicos sobre seu serviço que podem exigir algumas atualizações de configuração. #### A versão original do App Runner O processo original de criação do aplicativo App Runner aproveita o AWS CodeBuild serviço. As etapas iniciais são baseadas em imagens selecionadas pelo CodeBuild serviço. Segue um processo de criação do Docker que usa a imagem de tempo de execução gerenciada aplicável do App Runner como imagem base. As etapas gerais são as seguintes: 1. Execute `pre-build` comandos em uma imagem CodeBuild com curadoria. Os `pre-build` comandos são opcionais. Eles só podem ser especificados no arquivo `apprunner.yaml` de configuração. 1. Execute os `build` CodeBuild comandos usando a mesma imagem da etapa anterior. Os `build` comandos são obrigatórios. Eles podem ser especificados no console do App Runner, na API do App Runner ou no arquivo de `apprunner.yaml` configuração. 1. Execute uma compilação do Docker para gerar uma imagem com base na imagem de tempo de execução gerenciada do App Runner para sua plataforma e versão de tempo de execução específicas. 1. Copie o `/app` diretório da imagem que geramos na **Etapa 2**. O destino é a imagem baseada na imagem de tempo de execução gerenciada do App Runner, que geramos na **Etapa 3**. 1. Execute os `build` comandos novamente na imagem de tempo de execução gerenciada do App Runner gerada. Executamos os comandos de construção novamente para gerar artefatos de construção a partir do código-fonte no `/app` diretório que copiamos para ele na **Etapa** 4. Essa imagem será posteriormente implantada pelo App Runner para executar seu serviço web em um contêiner. Os `build` comandos são obrigatórios. Eles podem ser especificados no console do App Runner, na API do App Runner ou no arquivo de `apprunner.yaml` configuração. 1. Execute `post-build` comandos na CodeBuild imagem a partir da **Etapa 2**. Os `post-build` comandos são opcionais. Eles só podem ser especificados no arquivo `apprunner.yaml` de configuração. Após a conclusão da compilação, o App Runner implanta a imagem de tempo de execução gerenciada do App Runner gerada na **Etapa 5** para executar seu serviço web em um contêiner. #### A versão revisada do App Runner O processo de construção revisado é mais rápido e eficiente do que o processo de construção original descrito na seção anterior. Ele elimina a duplicação dos comandos de compilação que ocorre na compilação da versão anterior. Ele também cria uma imagem final com um espaço menor que contém apenas o código-fonte, os artefatos de construção e os tempos de execução necessários para executar seu aplicativo. Esse processo de compilação usa uma compilação de vários estágios do Docker. As etapas gerais do processo são as seguintes: 1. **Etapa de compilação** — inicie um processo de compilação do docker que executa `pre-build` e `build` comanda sobre as imagens de compilação do App Runner. 1. Copie o código-fonte do aplicativo para o `/app` diretório. **nota** Esse `/app` diretório é designado como o diretório de trabalho em cada estágio da compilação do Docker. 1. Execute comandos da `pre-build`. Os `pre-build` comandos são opcionais. Eles só podem ser especificados no arquivo `apprunner.yaml` de configuração. 1. Execute os `build` comandos. Os `build` comandos são obrigatórios. Eles podem ser especificados no console do App Runner, na API do App Runner ou no arquivo de `apprunner.yaml` configuração. 1. **Etapa de empacotamento** — gera a imagem final do contêiner do cliente, que também se baseia na imagem de execução do App Runner. 1. Copie o `/app` diretório do **estágio anterior de compilação** para a nova imagem Executar. Isso inclui o código-fonte do seu aplicativo e os artefatos de construção do estágio anterior. 1. Execute os `pre-run` comandos. Se você precisar modificar a imagem de tempo de execução fora do `/app` diretório usando os `build` comandos, adicione os mesmos comandos ou os obrigatórios a esse segmento do arquivo de `apprunner.yaml` configuração. Esse é um novo parâmetro que foi introduzido para dar suporte à versão revisada do App Runner. Os `pre-run` comandos são opcionais. Eles só podem ser especificados no arquivo `apprunner.yaml` de configuração. **Observações** Os `pre-run` comandos são suportados somente pela compilação revisada. Não os adicione ao arquivo de configuração se seu serviço usar versões de tempo de execução que usam a compilação original. Se você não precisar modificar nada fora do `/app` diretório com os `build` comandos, não precisará especificar `pre-run` comandos. 1. **Estágio pós-construção** — Esse estágio é retomado a partir do *estágio de compilação* e `post-build` executa comandos. 1. Execute os `post-build` comandos dentro do `/app` diretório. Os `post-build` comandos são opcionais. Eles só podem ser especificados no arquivo `apprunner.yaml` de configuração. Após a conclusão da compilação, o App Runner implanta a imagem Run para executar seu serviço Web em um contêiner. **nota** Não se deixe enganar pelas `env` entradas na seção Executar `apprunner.yaml` ao configurar o processo de compilação. Mesmo que o parâmetro do `pre-run` comando, referenciado na **Etapa 2 (b)**, resida na seção Executar, não use o `env` parâmetro na seção Executar para configurar sua compilação. Os `pre-run` comandos fazem referência apenas às `env` variáveis definidas na seção Construir do arquivo de configuração. Para obter mais informações, consulte o [Seção de execução](config-file-ref.md#config-file-ref.run) *capítulo do arquivo de configuração do App Runner*. #### Requisitos de serviço para consideração da migração Se o ambiente do seu aplicativo tiver um desses dois requisitos, você precisará revisar sua configuração de compilação adicionando `pre-run` comandos. + Se você precisar modificar qualquer coisa fora do `/app` diretório com os `build` comandos. + Se você precisar executar os `build` comandos duas vezes para criar o ambiente necessário. Esse é um requisito muito incomum. A grande maioria das construções não fará isso. **Modificações fora do `/app` diretório** + A [versão revisada do App Runner](#service-source-code.build-detail.v2) pressupõe que seu aplicativo não tenha dependências fora do diretório. `/app` + Os comandos que você fornece com o `apprunner.yaml` arquivo, a API App Runner ou o console do App Runner devem gerar artefatos de construção no diretório. `/app` + Você pode modificar os `post-build` comandos `pre-build``build`, e para garantir que todos os artefatos de construção estejam no `/app` diretório. + Se seu aplicativo exigir que a compilação modifique ainda mais a imagem gerada para seu serviço, fora do `/app` diretório, você poderá usar os novos `pre-run` comandos no`apprunner.yaml`. Para obter mais informações, consulte [Definindo as opções do serviço App Runner usando um arquivo de configuração](config-file.md). **Executando os `build` comandos duas vezes** + A [compilação original do App Runner](#service-source-code.build-detail.v1) executa `build` os comandos duas vezes, primeiro na **Etapa 2** e depois novamente na **Etapa 5**. A versão revisada do App Runner corrige essa redundância e só executa os `build` comandos uma vez. Se seu aplicativo tiver um requisito incomum para que os `build` comandos sejam executados duas vezes, a versão revisada do App Runner oferece a opção de especificar e executar os mesmos comandos novamente usando o `pre-run` parâmetro. Isso mantém o mesmo comportamento de construção dupla. # Usar a plataforma Python do **Importante** O App Runner encerrará o suporte para **Python 3.7 **e Python**** 3.8 em 1º de dezembro de 2025. Para obter recomendações e mais informações, consulte[Fim do suporte para versões de tempo de execução gerenciado](service-source-code.md#service-source-code.managed-platforms.eos). A plataforma AWS App Runner Python fornece tempos de execução gerenciados. Cada tempo de execução facilita a criação e a execução de contêineres com aplicativos web baseados em uma versão do Python. Quando você usa um tempo de execução do Python, o App Runner começa com uma imagem gerenciada do tempo de execução do Python. Essa imagem é baseada na [imagem Docker do Amazon Linux](https://hub.docker.com/_/amazonlinux) e contém o pacote de tempo de execução para uma versão do Python e algumas ferramentas e pacotes de dependências populares. O App Runner usa essa imagem de tempo de execução gerenciada como imagem base e adiciona o código do aplicativo para criar uma imagem do Docker. Em seguida, ele implanta essa imagem para executar seu serviço web em um contêiner. Você especifica um tempo de execução para seu serviço App Runner ao [criar um serviço](manage-create.md) usando o console do App Runner ou a operação da [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API. Você também pode especificar um tempo de execução como parte do seu código-fonte. Use a `runtime` palavra-chave em um [arquivo de configuração do App Runner](config-file.md) que você inclui no seu repositório de código. A convenção de nomenclatura de um tempo de execução gerenciado é*

*. Para nomes e versões válidos do tempo de execução do Python, consulte. [Informações sobre o lançamento do Python Runtime](service-source-code-python-releases.md) O App Runner atualiza o tempo de execução do seu serviço para a versão mais recente em cada implantação ou atualização de serviço. Se seu aplicativo exigir uma versão específica de um tempo de execução gerenciado, você poderá especificá-la usando a `runtime-version` palavra-chave no [arquivo de configuração do App Runner](config-file.md). Você pode bloquear qualquer nível de versão, incluindo uma versão principal ou secundária. O App Runner só faz atualizações de nível inferior no tempo de execução do seu serviço. Sintaxe da versão para tempos de execução do Python: `major[.minor[.patch]]` Por exemplo: `3.8.5` Os exemplos a seguir demonstram o bloqueio de versões: + `3.8`— Bloqueie as versões principais e secundárias. O App Runner atualiza somente as versões de patch. + `3.8.5`— Bloqueie uma versão específica do patch. O App Runner não atualiza sua versão de tempo de execução. **Topics** + [Configuração de tempo de execução do Python](#service-source-code-python.config) + [Explicações para versões específicas de tempo de execução](#service-source-code-python.callouts) + [Exemplos de tempo de execução em Python](#service-source-code-python.examples) + [Informações sobre o lançamento do Python Runtime](service-source-code-python-releases.md) ## Configuração de tempo de execução do Python Ao escolher um tempo de execução gerenciado, você também deve configurar, no mínimo, comandos de compilação e execução. Você os configura ao [criar](manage-create.md) ou [atualizar](manage-configure.md) seu serviço App Runner. Você pode fazer isso usando um dos seguintes métodos: + **Usando o console do App Runner** — Especifique os comandos na seção **Configurar compilação** do processo de criação ou da guia de configuração. + **Usando a API App Runner** — chame a operação [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)ou [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)da API. Especifique os comandos usando os `StartCommand` membros `BuildCommand` e do tipo de [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)dados. + **Usando um [arquivo de configuração](config-file.md)** — especifique um ou mais comandos de compilação em até três fases de compilação e um único comando de execução que serve para iniciar seu aplicativo. Há configurações opcionais adicionais. Fornecer um arquivo de configuração é opcional. Ao criar um serviço App Runner usando o console ou a API, você especifica se o App Runner obtém suas configurações diretamente quando é criado ou de um arquivo de configuração. ## Explicações para versões específicas de tempo de execução **nota** O App Runner agora executa um processo de compilação atualizado para aplicativos com base nas seguintes versões de tempo de execução: Python 3.11, Node.js 22 e Node.js 18. Se seu aplicativo for executado em qualquer uma dessas versões de tempo de execução, consulte [Versões de tempo de execução gerenciadas e a compilação do App Runner](service-source-code.md#service-source-code.build-detail) para obter mais informações sobre o processo de compilação revisado. Os aplicativos que usam todas as outras versões de tempo de execução não são afetados e continuam usando o processo de criação original. ### Python 3.11 (versão revisada do App Runner) Use as configurações a seguir no *apprunner.yaml para o tempo de execução gerenciado do Python* 3.11. + Defina a `runtime` chave na seção superior como `python311` **Example** ``` runtime: python311 ``` + Use o `pip3` em vez de `pip` para instalar dependências. + Use o `python3` intérprete em vez de. `python` + Execute o `pip3` instalador como um `pre-run` comando. O Python instala dependências fora do diretório. `/app` Como o App Runner executa a compilação revisada do App Runner para Python 3.11, qualquer coisa instalada fora do `/app` diretório por meio de comandos na seção Build do arquivo será perdida. `apprunner.yaml` Para obter mais informações, consulte [A versão revisada do App Runner](service-source-code.md#service-source-code.build-detail.v2). **Example** ``` run: runtime-version: 3.11 pre-run: - pip3 install pipenv - pipenv install - python3 copy-global-files.py command: pipenv run gunicorn django_apprunner.wsgi --log-file - ``` Para obter mais informações, consulte também o [exemplo de um arquivo de configuração estendido para Python 3.11](#service-source-code-python.examples.extended-v2) posteriormente neste tópico. ## Exemplos de tempo de execução em Python Os exemplos a seguir mostram os arquivos de configuração do App Runner para criar e executar um serviço Python. O último exemplo é o código-fonte de um aplicativo Python completo que você pode implantar em um serviço de tempo de execução do Python. **nota** A versão de tempo de execução usada nesses exemplos é *3.7.7* *3.11* e. Você pode substituí-lo por uma versão que você deseja usar. Para ver a versão mais recente de tempo de execução do Python compatível, consulte. [Informações sobre o lançamento do Python Runtime](service-source-code-python-releases.md) ### Arquivo mínimo de configuração do Python Este exemplo mostra um arquivo de configuração mínimo que você pode usar com um tempo de execução gerenciado em Python. Para as suposições que o App Runner faz com um arquivo de configuração mínimo, consulte. [Exemplos de arquivos de configuração](config-file-examples.md#config-file-examples.managed) O Python 3.11 usa os comandos e. `pip3` `python3` Para obter mais informações, consulte o [exemplo de um arquivo de configuração estendido para Python 3.11](#service-source-code-python.examples.extended-v2) posteriormente neste tópico. **Example apprunner.yaml** ``` version: 1.0 runtime: python3 build: commands: build: - pip install pipenv - pipenv install run: command: python app.py ``` ### Arquivo de configuração estendido do Python Este exemplo mostra o uso de todas as chaves de configuração com um tempo de execução gerenciado em Python. **nota** A versão de tempo de execução usada nesses exemplos é*3.7.7*. Você pode substituí-lo por uma versão que você deseja usar. Para ver a versão mais recente de tempo de execução do Python compatível, consulte. [Informações sobre o lançamento do Python Runtime](service-source-code-python-releases.md) O Python 3.11 usa os comandos e. `pip3` `python3` Para obter mais informações, consulte o exemplo de um arquivo de configuração estendido para Python 3.11 posteriormente neste tópico. **Example apprunner.yaml** ``` version: 1.0 runtime: python3 build: commands: pre-build: - wget -c https://s3.amazonaws.com/amzn-s3-demo-bucket/test-lib.tar.gz -O - | tar -xz build: - pip install pipenv - pipenv install post-build: - python manage.py test env: - name: DJANGO_SETTINGS_MODULE value: "django_apprunner.settings" - name: MY_VAR_EXAMPLE value: "example" run: runtime-version: 3.7.7 command: pipenv run gunicorn django_apprunner.wsgi --log-file - network: port: 8000 env: MY_APP_PORT env: - name: MY_VAR_EXAMPLE value: "example" secrets: - name: my-secret value-from: "arn:aws:secretsmanager:us-east-1:123456789012:secret:testingstackAppRunnerConstr-kJFXde2ULKbT-S7t8xR:username::" - name: my-parameter value-from: "arn:aws:ssm:us-east-1:123456789012:parameter/parameter-name" - name: my-parameter-only-name value-from: "parameter-name" ``` ### Arquivo de configuração estendido do Python — Python 3.11 (usa a versão revisada) Este exemplo mostra o uso de todas as chaves de configuração com um tempo de execução gerenciado do Python 3.11 no. `apprunner.yaml` Esse exemplo inclui uma `pre-run` seção, já que essa versão do Python usa a versão revisada do App Runner. O `pre-run` parâmetro só é compatível com a versão revisada do App Runner. Não insira esse parâmetro no arquivo de configuração se o aplicativo usar versões de tempo de execução compatíveis com a compilação original do App Runner. Para obter mais informações, consulte [Versões de tempo de execução gerenciadas e a compilação do App Runner](service-source-code.md#service-source-code.build-detail). **nota** A versão de tempo de execução usada nesses exemplos é*3.11*. Você pode substituí-lo por uma versão que você deseja usar. Para ver a versão mais recente de tempo de execução do Python compatível, consulte. [Informações sobre o lançamento do Python Runtime](service-source-code-python-releases.md) **Example apprunner.yaml** ``` version: 1.0 runtime: python311 build: commands: pre-build: - wget -c https://s3.amazonaws.com/amzn-s3-demo-bucket/test-lib.tar.gz -O - | tar -xz build: - pip3 install pipenv - pipenv install post-build: - python3 manage.py test env: - name: DJANGO_SETTINGS_MODULE value: "django_apprunner.settings" - name: MY_VAR_EXAMPLE value: "example" run: runtime-version: 3.11 pre-run: - pip3 install pipenv - pipenv install - python3 copy-global-files.py command: pipenv run gunicorn django_apprunner.wsgi --log-file - network: port: 8000 env: MY_APP_PORT env: - name: MY_VAR_EXAMPLE value: "example" secrets: - name: my-secret value-from: "arn:aws:secretsmanager:us-east-1:123456789012:secret:testingstackAppRunnerConstr-kJFXde2ULKbT-S7t8xR:username::" - name: my-parameter value-from: "arn:aws:ssm:us-east-1:123456789012:parameter/parameter-name" - name: my-parameter-only-name value-from: "parameter-name" ``` ### Fonte completa do aplicativo Python Este exemplo mostra o código-fonte de um aplicativo Python completo que você pode implantar em um serviço de tempo de execução do Python. **Example requirements.txt** ``` pyramid==2.0 ``` **Example server.py** ``` from wsgiref.simple_server import make_server from pyramid.config import Configurator from pyramid.response import Response import os def hello_world(request): name = os.environ.get('NAME') if name == None or len(name) == 0: name = "world" message = "Hello, " + name + "!\n" return Response(message) if __name__ == '__main__': port = int(os.environ.get("PORT")) with Configurator() as config: config.add_route('hello', '/') config.add_view(hello_world, route_name='hello') app = config.make_wsgi_app() server = make_server('0.0.0.0', port, app) server.serve_forever() ``` **Example apprunner.yaml** ``` version: 1.0 runtime: python3 build: commands: build: - pip install -r requirements.txt run: command: python server.py ``` # Informações sobre o lançamento do Python Runtime **Importante** O App Runner encerrará o suporte para **Python 3.7 **e Python**** 3.8 em 1º de dezembro de 2025. Para obter recomendações e mais informações, consulte[Fim do suporte para versões de tempo de execução gerenciado](service-source-code.md#service-source-code.managed-platforms.eos). Este tópico lista os detalhes completos das versões de tempo de execução do Python compatíveis com o App Runner. **Versões de tempo de execução suportadas — versão revisada do App Runner** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/apprunner/latest/dg/service-source-code-python-releases.html) **Observações** **Python 3.11** — Temos recomendações específicas para a configuração de compilação de serviços que usam o tempo de execução gerenciado do Python 3.11. Para obter mais informações, consulte [Explicações para versões específicas de tempo de execução](service-source-code-python.md#service-source-code-python.callouts) o tópico da *plataforma Python*. O App Runner fornece um processo de criação revisado para os principais tempos de execução específicos que foram lançados mais recentemente. Por isso, você verá referências à *versão revisada do App Runner e à versão* *original do App Runner* em determinadas seções deste documento. Para obter mais informações, consulte [Versões de tempo de execução gerenciadas e a compilação do App Runner](service-source-code.md#service-source-code.build-detail). **Versões de tempo de execução suportadas — versão original do App Runner** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/apprunner/latest/dg/service-source-code-python-releases.html) **nota** O App Runner fornece um processo de criação revisado para os principais tempos de execução específicos que foram lançados mais recentemente. Por isso, você verá referências à *versão revisada do App Runner e à versão* *original do App Runner* em determinadas seções deste documento. Para obter mais informações, consulte [Versões de tempo de execução gerenciadas e a compilação do App Runner](service-source-code.md#service-source-code.build-detail). # Usar a plataforma Node.js do **Importante** O App Runner encerrará o suporte para **Node.js 12**, **Node.js 14**, **Node.js 16** e **Node.js 18** em 1º de dezembro de 2025. Para obter recomendações e mais informações, consulte[Fim do suporte para versões de tempo de execução gerenciado](service-source-code.md#service-source-code.managed-platforms.eos). A plataforma AWS App Runner Node.js fornece tempos de execução gerenciados. Cada tempo de execução facilita a criação e a execução de contêineres com aplicativos da Web baseados em uma versão do Node.js. Quando você usa um tempo de execução do Node.js, o App Runner começa com uma imagem de tempo de execução do Node.js gerenciada. Essa imagem é baseada na [imagem Docker do Amazon Linux](https://hub.docker.com/_/amazonlinux) e contém o pacote de tempo de execução para uma versão do Node.js e algumas ferramentas. O App Runner usa essa imagem de tempo de execução gerenciada como imagem base e adiciona o código do aplicativo para criar uma imagem do Docker. Em seguida, ele implanta essa imagem para executar seu serviço web em um contêiner. Você especifica um tempo de execução para seu serviço App Runner ao [criar um serviço](manage-create.md) usando o console do App Runner ou a operação da [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API. Você também pode especificar um tempo de execução como parte do seu código-fonte. Use a `runtime` palavra-chave em um [arquivo de configuração do App Runner](config-file.md) que você inclui no seu repositório de código. A convenção de nomenclatura de um tempo de execução gerenciado é*

*. Para obter nomes e versões válidos do tempo de execução do Node.js, consulte[Informações sobre a versão de execução do Node.js](service-source-code-nodejs-releases.md). O App Runner atualiza o tempo de execução do seu serviço para a versão mais recente em cada implantação ou atualização de serviço. Se seu aplicativo exigir uma versão específica de um tempo de execução gerenciado, você poderá especificá-la usando a `runtime-version` palavra-chave no [arquivo de configuração do App Runner](config-file.md). Você pode bloquear qualquer nível de versão, incluindo uma versão principal ou secundária. O App Runner só faz atualizações de nível inferior no tempo de execução do seu serviço. Sintaxe da versão para tempos de execução do Node.js: `major[.minor[.patch]]` Por exemplo: `22.14.0` Os exemplos a seguir demonstram o bloqueio de versões: + `22.14`— Bloqueie as versões principais e secundárias. O App Runner atualiza somente as versões de patch. + `22.14.0`— Bloqueie uma versão específica do patch. O App Runner não atualiza sua versão de tempo de execução. **Topics** + [Configuração de tempo de execução do Node.js](#service-source-code-nodejs.config) + [Explicações para versões específicas de tempo de execução](#service-source-code-nodejs.callouts) + [Exemplos de tempo de execução do Node.js](#service-source-code-nodejs.examples) + [Informações sobre a versão de execução do Node.js](service-source-code-nodejs-releases.md) ## Configuração de tempo de execução do Node.js Ao escolher um tempo de execução gerenciado, você também deve configurar, no mínimo, comandos de compilação e execução. Você os configura ao [criar](manage-create.md) ou [atualizar](manage-configure.md) seu serviço App Runner. Você pode fazer isso usando um dos seguintes métodos: + **Usando o console do App Runner** — Especifique os comandos na seção **Configurar compilação** do processo de criação ou da guia de configuração. + **Usando a API App Runner** — chame a operação [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)ou [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API. Especifique os comandos usando os `StartCommand` membros `BuildCommand` e do tipo de [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)dados. + **Usando um [arquivo de configuração](config-file.md)** — especifique um ou mais comandos de compilação em até três fases de compilação e um único comando de execução que serve para iniciar seu aplicativo. Há configurações opcionais adicionais. Fornecer um arquivo de configuração é opcional. Ao criar um serviço App Runner usando o console ou a API, você especifica se o App Runner obtém suas configurações diretamente quando é criado ou de um arquivo de configuração. Especificamente com os tempos de execução do Node.js, você também pode configurar a compilação e o tempo de execução usando um arquivo JSON nomeado `package.json` na raiz do seu repositório de origem. Usando esse arquivo, você pode configurar a versão do mecanismo Node.js, os pacotes de dependências e vários comandos (aplicativos de linha de comando). Gerenciadores de pacotes como npm ou yarn interpretam esse arquivo como entrada para seus comandos. Por exemplo: + **npm install**instala pacotes definidos pelo `devDependencies` nó `dependencies` e em`package.json`. + **npm start**ou **npm run start** executa o comando definido pelo `scripts/start` nó em`package.json`. Veja a seguir um exemplo de arquivo `package.json`. ### package.json ``` { "name": "node-js-getting-started", "version": "0.3.0", "description": "A sample Node.js app using Express 4", "engines": { "node": "22.14.0" }, "scripts": { "start": "node index.js", "test": "node test.js" }, "dependencies": { "cool-ascii-faces": "^1.3.4", "ejs": "^2.5.6", "express": "^4.15.2" }, "devDependencies": { "got": "^11.3.0", "tape": "^4.7.0" } } ``` *Para obter mais informações sobre isso`package.json`, consulte [Criação de um arquivo package.json](https://docs.npmjs.com/creating-a-package-json-file) no site do npm Docs.* **Dicas** Se seu `package.json` arquivo definir um **start** comando, você poderá usá-lo como um **run** comando no arquivo de configuração do App Runner, conforme mostra o exemplo a seguir. **Example** package.json ``` { "scripts": { "start": "node index.js" } } ``` apprunner.yaml ``` run: command: npm start ``` Quando você executa **npm install** em seu ambiente de desenvolvimento, o npm cria o arquivo`package-lock.json`. Esse arquivo contém um instantâneo das versões do pacote que o npm acabou de instalar. Depois disso, quando o npm instala dependências, ele usa essas versões exatas. Se você instalar o yarn, ele criará um `yarn.lock` arquivo. Confirme esses arquivos em seu repositório de código-fonte para garantir que seu aplicativo seja instalado com as versões das dependências com as quais você o desenvolveu e testou. Você também pode usar um arquivo de configuração do App Runner para configurar a versão do Node.js e o comando start. Quando você faz isso, essas definições substituem as que estão em`package.json`. Um conflito entre a `node` versão `package.json` e o `runtime-version` valor no arquivo de configuração do App Runner faz com que a fase de construção do App Runner falhe. ## Explicações para versões específicas de tempo de execução ### Node.js 22 e Node.js 18 (versão revisada do App Runner) O App Runner agora executa um processo de compilação atualizado para aplicativos com base nas seguintes versões de tempo de execução: Python 3.11, Node.js 22 e Node.js 18. Se seu aplicativo for executado em qualquer uma dessas versões de tempo de execução, consulte [Versões de tempo de execução gerenciadas e a compilação do App Runner](service-source-code.md#service-source-code.build-detail) para obter mais informações sobre o processo de compilação revisado. Os aplicativos que usam todas as outras versões de tempo de execução não são afetados e continuam usando o processo de criação original. ## Exemplos de tempo de execução do Node.js Os exemplos a seguir mostram os arquivos de configuração do App Runner para criar e executar um serviço Node.js. **nota** A versão de tempo de execução usada nesses exemplos é*22.14.0*. Você pode substituí-lo por uma versão que você deseja usar. Para obter a versão de tempo de execução mais recente compatível do Node.js, consulte[Informações sobre a versão de execução do Node.js](service-source-code-nodejs-releases.md). ### Arquivo mínimo de configuração Node.js Este exemplo mostra um arquivo de configuração mínimo que você pode usar com um tempo de execução gerenciado pelo Node.js. Para as suposições que o App Runner faz com um arquivo de configuração mínimo, consulte. [Exemplos de arquivos de configuração](config-file-examples.md#config-file-examples.managed) **Example apprunner.yaml** ``` version: 1.0 runtime: nodejs22 build: commands: build: - npm install --production run: command: node app.js ``` ### Arquivo de configuração Node.js estendido Este exemplo mostra o uso de todas as chaves de configuração com um tempo de execução gerenciado pelo Node.js. **nota** A versão de tempo de execução usada nesses exemplos é*22.14.0*. Você pode substituí-lo por uma versão que você deseja usar. Para obter a versão de tempo de execução mais recente compatível do Node.js, consulte[Informações sobre a versão de execução do Node.js](service-source-code-nodejs-releases.md). **Example apprunner.yaml** ``` version: 1.0 runtime: nodejs22 build: commands: pre-build: - npm install --only=dev - node test.js build: - npm install --production post-build: - node node_modules/ejs/postinstall.js env: - name: MY_VAR_EXAMPLE value: "example" run: runtime-version: 22.14.0 command: node app.js network: port: 8000 env: APP_PORT env: - name: MY_VAR_EXAMPLE value: "example" ``` ### Arquivo de configuração Node.js estendido — Node.js 22 (usa compilação revisada) Este exemplo mostra o uso de todas as chaves de configuração com um tempo de execução gerenciado pelo Node.js no`apprunner.yaml`. Esse exemplo inclui uma `pre-run` seção, já que essa versão do Node.js usa a versão revisada do App Runner. O `pre-run` parâmetro só é compatível com a versão revisada do App Runner. Não insira esse parâmetro no arquivo de configuração se o aplicativo usar versões de tempo de execução compatíveis com a compilação original do App Runner. Para obter mais informações, consulte [Versões de tempo de execução gerenciadas e a compilação do App Runner](service-source-code.md#service-source-code.build-detail). **nota** A versão de tempo de execução usada nesses exemplos é*22.14.0*. Você pode substituí-lo por uma versão que você deseja usar. Para obter a versão de tempo de execução mais recente compatível do Node.js, consulte[Informações sobre a versão de execução do Node.js](service-source-code-nodejs-releases.md). **Example apprunner.yaml** ``` version: 1.0 runtime: nodejs22 build: commands: pre-build: - npm install --only=dev - node test.js build: - npm install --production post-build: - node node_modules/ejs/postinstall.js env: - name: MY_VAR_EXAMPLE value: "example" run: runtime-version: 22.14.0 pre-run: - node copy-global-files.js command: node app.js network: port: 8000 env: APP_PORT env: - name: MY_VAR_EXAMPLE value: "example" ``` ### Aplicativo Node.js com Grunt Este exemplo mostra como configurar um aplicativo Node.js desenvolvido com o Grunt. [O Grunt](https://gruntjs.com/) é um executor de JavaScript tarefas de linha de comando. Ele executa tarefas repetitivas e gerencia a automação de processos para reduzir o erro humano. Os plug-ins Grunt e Grunt são instalados e gerenciados usando o npm. Você configura o Grunt incluindo o `Gruntfile.js` arquivo na raiz do seu repositório de origem. **Example package.json** ``` { "scripts": { "build": "grunt uglify", "start": "node app.js" }, "devDependencies": { "grunt": "~0.4.5", "grunt-contrib-jshint": "~0.10.0", "grunt-contrib-nodeunit": "~0.4.1", "grunt-contrib-uglify": "~0.5.0" }, "dependencies": { "express": "^4.15.2" }, } ``` **Example Gruntfile.js** ``` module.exports = function(grunt) { // Project configuration. grunt.initConfig({ pkg: grunt.file.readJSON('package.json'), uglify: { options: { banner: '/*! <%= pkg.name %> <%= grunt.template.today("yyyy-mm-dd") %> */\n' }, build: { src: 'src/<%= pkg.name %>.js', dest: 'build/<%= pkg.name %>.min.js' } } }); // Load the plugin that provides the "uglify" task. grunt.loadNpmTasks('grunt-contrib-uglify'); // Default task(s). grunt.registerTask('default', ['uglify']); }; ``` **Example apprunner.yaml** A versão de tempo de execução usada nesses exemplos é*22.14.0*. Você pode substituí-lo por uma versão que você deseja usar. Para obter a versão de tempo de execução mais recente compatível do Node.js, consulte[Informações sobre a versão de execução do Node.js](service-source-code-nodejs-releases.md). ``` version: 1.0 runtime: nodejs22 build: commands: pre-build: - npm install grunt grunt-cli - npm install --only=dev - npm run build build: - npm install --production run: runtime-version: 22.14.0 command: node app.js network: port: 8000 env: APP_PORT ``` # Informações sobre a versão de execução do Node.js **Importante** O App Runner encerrará o suporte para **Node.js 12**, **Node.js 14**, **Node.js 16** e **Node.js 18** em 1º de dezembro de 2025. Para obter recomendações e mais informações, consulte[Fim do suporte para versões de tempo de execução gerenciado](service-source-code.md#service-source-code.managed-platforms.eos). **nota** A política de suspensão de uso padrão do App Runner é descontinuar um tempo de execução quando qualquer componente importante do tempo de execução chegar ao fim do suporte de longo prazo da comunidade (LTS) e as atualizações de segurança não estiverem mais disponíveis. Em alguns casos, o App Runner pode atrasar a suspensão de uso de um tempo de execução por um período limitado, além da end-of-support data da versão do idioma suportada pelo tempo de execução. Um exemplo desse caso pode ser estender o suporte a um tempo de execução para permitir que os clientes tenham tempo para a migração. Este tópico lista os detalhes completos das versões de tempo de execução do Node.js suportadas pelo App Runner. **Versões de tempo de execução suportadas — versão revisada do App Runner** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/apprunner/latest/dg/service-source-code-nodejs-releases.html) **nota** O App Runner fornece um processo de criação revisado para os principais tempos de execução específicos que foram lançados mais recentemente. Por isso, você verá referências à *versão revisada do App Runner e à versão* *original do App Runner* em determinadas seções deste documento. Para obter mais informações, consulte [Versões de tempo de execução gerenciadas e a compilação do App Runner](service-source-code.md#service-source-code.build-detail). **Versões de tempo de execução suportadas — versão revisada do App Runner** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/apprunner/latest/dg/service-source-code-nodejs-releases.html) **Versões de tempo de execução suportadas — versão original do App Runner** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/apprunner/latest/dg/service-source-code-nodejs-releases.html) # Usando a plataforma Java A plataforma AWS App Runner Java fornece tempos de execução gerenciados. Cada tempo de execução facilita a criação e a execução de contêineres com aplicativos web baseados em uma versão Java. Quando você usa um Java Runner, o App Runner começa com uma imagem de tempo de execução Java gerenciada. Essa imagem é baseada na [imagem Docker do Amazon Linux](https://hub.docker.com/_/amazonlinux) e contém o pacote de tempo de execução para uma versão do Java e algumas ferramentas. O App Runner usa essa imagem de tempo de execução gerenciada como imagem base e adiciona o código do aplicativo para criar uma imagem do Docker. Em seguida, ele implanta essa imagem para executar seu serviço web em um contêiner. Você especifica um tempo de execução para seu serviço App Runner ao [criar um serviço](manage-create.md) usando o console do App Runner ou a operação da [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API. Você também pode especificar um tempo de execução como parte do seu código-fonte. Use a `runtime` palavra-chave em um [arquivo de configuração do App Runner](config-file.md) que você inclui no seu repositório de código. A convenção de nomenclatura de um tempo de execução gerenciado é*

*. No momento, todos os tempos de execução Java compatíveis são baseados no Amazon Corretto. Para nomes e versões válidos do Java Runtime, consulte[Informações sobre a versão do Java Runtime](service-source-code-java-releases.md). O App Runner atualiza o tempo de execução do seu serviço para a versão mais recente em cada implantação ou atualização de serviço. Se seu aplicativo exigir uma versão específica de um tempo de execução gerenciado, você poderá especificá-la usando a `runtime-version` palavra-chave no [arquivo de configuração do App Runner](config-file.md). Você pode bloquear qualquer nível de versão, incluindo uma versão principal ou secundária. O App Runner só faz atualizações de nível inferior no tempo de execução do seu serviço. Sintaxe de versão para tempos de execução do Amazon Corretto: | **Runtime** | **Sintaxe** | **Exemplo** | | --- | --- | --- | | corretto11 | `11.0[.openjdk-update[.openjdk-build[.corretto-specific-revision]]]` | `11.0.13.08.1` | | corretto8 | `8[.openjdk-update[.openjdk-build[.corretto-specific-revision]]]` | `8.312.07.1` | Os exemplos a seguir demonstram o bloqueio de versões: + `11.0.13`— Bloqueie a versão de atualização do Open JDK. O App Runner atualiza somente compilações de nível inferior do Open JDK e do Amazon Corretto. + `11.0.13.08.1`— Bloqueie uma versão específica. O App Runner não atualiza sua versão de tempo de execução. **Topics** + [Configuração do Java Runtime](#service-source-code-java.config) + [Exemplos de tempo de execução em Java](#service-source-code-java.examples) + [Informações sobre a versão do Java Runtime](service-source-code-java-releases.md) ## Configuração do Java Runtime Ao escolher um tempo de execução gerenciado, você também deve configurar, no mínimo, comandos de compilação e execução. Você os configura ao [criar](manage-create.md) ou [atualizar](manage-configure.md) seu serviço App Runner. Você pode fazer isso usando um dos seguintes métodos: + **Usando o console do App Runner** — Especifique os comandos na seção **Configurar compilação** do processo de criação ou da guia de configuração. + **Usando a API App Runner** — chame a operação [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)ou [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)da API. Especifique os comandos usando os `StartCommand` membros `BuildCommand` e do tipo de [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)dados. + **Usando um [arquivo de configuração](config-file.md)** — especifique um ou mais comandos de compilação em até três fases de compilação e um único comando de execução que serve para iniciar seu aplicativo. Há configurações opcionais adicionais. Fornecer um arquivo de configuração é opcional. Ao criar um serviço App Runner usando o console ou a API, você especifica se o App Runner obtém suas configurações diretamente quando é criado ou de um arquivo de configuração. ## Exemplos de tempo de execução em Java Os exemplos a seguir mostram os arquivos de configuração do App Runner para criar e executar um serviço Java. O último exemplo é o código-fonte de um aplicativo Java completo que você pode implantar em um serviço de tempo de execução do Corretto 11. **nota** A versão de tempo de execução usada nesses exemplos é*11.0.13.08.1*. Você pode substituí-lo por uma versão que você deseja usar. Para obter a versão mais recente do Java runtime compatível, consulte[Informações sobre a versão do Java Runtime](service-source-code-java-releases.md). ### Arquivo de configuração do Minimal Corretto 11 Este exemplo mostra um arquivo de configuração mínimo que você pode usar com um tempo de execução gerenciado do Corretto 11. Para as suposições que o App Runner faz com um arquivo de configuração mínimo, consulte. **Example apprunner.yaml** ``` version: 1.0 runtime: corretto11 build: commands: build: - mvn clean package run: command: java -Xms256m -jar target/MyApp-1.0-SNAPSHOT.jar . ``` ### Arquivo de configuração do Corretto 11 estendido Este exemplo mostra como você pode usar todas as chaves de configuração com um tempo de execução gerenciado do Corretto 11. **nota** A versão de tempo de execução usada nesses exemplos é*11.0.13.08.1*. Você pode substituí-lo por uma versão que você deseja usar. Para obter a versão mais recente do Java runtime compatível, consulte[Informações sobre a versão do Java Runtime](service-source-code-java-releases.md). **Example apprunner.yaml** ``` version: 1.0 runtime: corretto11 build: commands: pre-build: - yum install some-package - scripts/prebuild.sh build: - mvn clean package post-build: - mvn clean test env: - name: M2 value: "/usr/local/apache-maven/bin" - name: M2_HOME value: "/usr/local/apache-maven/bin" run: runtime-version: 11.0.13.08.1 command: java -Xms256m -jar target/MyApp-1.0-SNAPSHOT.jar . network: port: 8000 env: APP_PORT env: - name: MY_VAR_EXAMPLE value: "example" ``` ### Fonte completa do aplicativo Corretto 11 Este exemplo mostra o código-fonte de um aplicativo Java completo que você pode implantar em um serviço de tempo de execução do Corretto 11. **Example src/main/java/com/HelloWorld/HelloWorld.java** ``` package com.HelloWorld; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; @RestController public class HelloWorld { @RequestMapping("/") public String index(){ String s = "Hello World"; return s; } } ``` **Example src/main/java/com/HelloWorld/Main.java** ``` package com.HelloWorld; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; @SpringBootApplication public class Main { public static void main(String[] args) { SpringApplication.run(Main.class, args); } } ``` **Example apprunner.yaml** ``` version: 1.0 runtime: corretto11 build: commands: build: - mvn clean package run: command: java -Xms256m -jar target/HelloWorldJavaApp-1.0-SNAPSHOT.jar . network: port: 8080 ``` **Example pom.xml** ``` 4.0.0 org.springframework.boot spring-boot-starter-parent 2.3.1.RELEASE com.HelloWorld HelloWorldJavaApp 1.0-SNAPSHOT 11 org.springframework.boot spring-boot-starter-data-rest org.springframework.boot spring-boot-starter-test test org.junit.vintage junit-vintage-engine org.springframework.boot spring-boot-maven-plugin org.apache.maven.plugins maven-compiler-plugin 3.8.0 11 ``` # Informações sobre a versão do Java Runtime Este tópico lista os detalhes completos das versões de tempo de execução do Java suportadas pelo App Runner. **Versões de tempo de execução suportadas — versão original do App Runner** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/apprunner/latest/dg/service-source-code-java-releases.html) **nota** O App Runner fornece um processo de criação revisado para os principais tempos de execução específicos que foram lançados mais recentemente. Por isso, você verá referências à *versão revisada do App Runner e à versão* *original do App Runner* em determinadas seções deste documento. Para obter mais informações, consulte [Versões de tempo de execução gerenciadas e a compilação do App Runner](service-source-code.md#service-source-code.build-detail). # Usar a plataforma .NET do **Importante** O App Runner encerrará o suporte **do.NET 6** em 1º de dezembro de 2025. Para obter recomendações e mais informações, consulte[Fim do suporte para versões de tempo de execução gerenciado](service-source-code.md#service-source-code.managed-platforms.eos). A plataforma AWS App Runner do.NET fornece tempos de execução gerenciados. Cada tempo de execução facilita a criação e a execução de contêineres com aplicativos web baseados em uma versão.NET. Quando você usa um runtime do.NET, o App Runner começa com uma imagem de tempo de execução do.NET gerenciada. Essa imagem é baseada na [imagem Docker do Amazon Linux](https://hub.docker.com/_/amazonlinux) e contém o pacote de tempo de execução para uma versão do.NET e algumas ferramentas e pacotes de dependências populares. O App Runner usa essa imagem de tempo de execução gerenciada como imagem base e adiciona o código do aplicativo para criar uma imagem do Docker. Em seguida, ele implanta essa imagem para executar seu serviço web em um contêiner. Você especifica um tempo de execução para seu serviço App Runner ao [criar um serviço](manage-create.md) usando o console do App Runner ou a operação da [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API. Você também pode especificar um tempo de execução como parte do seu código-fonte. Use a `runtime` palavra-chave em um [arquivo de configuração do App Runner](config-file.md) que você inclui no seu repositório de código. A convenção de nomenclatura de um tempo de execução gerenciado é*

*. Para nomes e versões válidos do runtime do.NET, consulte[Informações sobre a versão do runtime do.NET](service-source-code-dotnet-releases.md). O App Runner atualiza o tempo de execução do seu serviço para a versão mais recente em cada implantação ou atualização de serviço. Se seu aplicativo exigir uma versão específica de um tempo de execução gerenciado, você poderá especificá-la usando a `runtime-version` palavra-chave no [arquivo de configuração do App Runner](config-file.md). Você pode bloquear qualquer nível de versão, incluindo uma versão principal ou secundária. O App Runner só faz atualizações de nível inferior no tempo de execução do seu serviço. Sintaxe da versão para tempos de execução do.NET: `major[.minor[.patch]]` Por exemplo: `6.0.9` Os exemplos a seguir demonstram o bloqueio de versões: + `6.0`— Bloqueie as versões principais e secundárias. O App Runner atualiza somente as versões de patch. + `6.0.9`— Bloqueie uma versão específica do patch. O App Runner não atualiza sua versão de tempo de execução. **Topics** + [Configuração do runtime do.NET](#service-source-code-net6.config) + [Exemplos de runtime do.NET](#service-source-code-net6.examples) + [Informações sobre a versão do runtime do.NET](service-source-code-dotnet-releases.md) ## Configuração do runtime do.NET Ao escolher um tempo de execução gerenciado, você também deve configurar, no mínimo, comandos de compilação e execução. Você os configura ao [criar](manage-create.md) ou [atualizar](manage-configure.md) seu serviço App Runner. Você pode fazer isso usando um dos seguintes métodos: + **Usando o console do App Runner** — Especifique os comandos na seção **Configurar compilação** do processo de criação ou da guia de configuração. + **Usando a API App Runner** — chame a operação [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)ou [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)da API. Especifique os comandos usando os `StartCommand` membros `BuildCommand` e do tipo de [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)dados. + **Usando um [arquivo de configuração](config-file.md)** — especifique um ou mais comandos de compilação em até três fases de compilação e um único comando de execução que serve para iniciar seu aplicativo. Há configurações opcionais adicionais. Fornecer um arquivo de configuração é opcional. Ao criar um serviço App Runner usando o console ou a API, você especifica se o App Runner obtém suas configurações diretamente quando é criado ou de um arquivo de configuração. ## Exemplos de runtime do.NET Os exemplos a seguir mostram os arquivos de configuração do App Runner para criar e executar um serviço.NET. O último exemplo é o código-fonte de um aplicativo.NET completo que você pode implantar em um serviço de runtime do.NET. **nota** A versão de tempo de execução usada nesses exemplos é*6.0.9*. Você pode substituí-lo por uma versão que você deseja usar. Para obter a versão mais recente do runtime do.NET compatível, consulte[Informações sobre a versão do runtime do.NET](service-source-code-dotnet-releases.md). ### Arquivo mínimo de configuração.NET Este exemplo mostra um arquivo de configuração mínimo que você pode usar com um tempo de execução gerenciado.NET. Para as suposições que o App Runner faz com um arquivo de configuração mínimo, consulte. [Exemplos de arquivos de configuração](config-file-examples.md#config-file-examples.managed) **Example apprunner.yaml** ``` version: 1.0 runtime: dotnet6 build: commands: build: - dotnet publish -c Release -o out run: command: dotnet out/HelloWorldDotNetApp.dll ``` ### Arquivo de configuração extendido.NET Este exemplo mostra o uso de todas as chaves de configuração com um tempo de execução gerenciado.NET. **nota** A versão de tempo de execução usada nesses exemplos é*6.0.9*. Você pode substituí-lo por uma versão que você deseja usar. Para obter a versão mais recente do runtime do.NET compatível, consulte[Informações sobre a versão do runtime do.NET](service-source-code-dotnet-releases.md). **Example apprunner.yaml** ``` version: 1.0 runtime: dotnet6 build: commands: pre-build: - scripts/prebuild.sh build: - dotnet publish -c Release -o out post-build: - scripts/postbuild.sh env: - name: MY_VAR_EXAMPLE value: "example" run: runtime-version: 6.0.9 command: dotnet out/HelloWorldDotNetApp.dll network: port: 5000 env: APP_PORT env: - name: ASPNETCORE_URLS value: "http://*:5000" ``` ### Fonte completa do aplicativo.NET Este exemplo mostra o código-fonte de um aplicativo.NET completo que você pode implantar em um serviço de runtime do.NET. **nota** Execute o comando a seguir para criar um aplicativo web do.NET 6 simples: ` dotnet new web --name HelloWorldDotNetApp -f net6.0` Adicione o `apprunner.yaml` ao aplicativo web do.NET 6 criado. **Example HelloWorldDotNetApp** ``` version: 1.0 runtime: dotnet6 build: commands: build: - dotnet publish -c Release -o out run: command: dotnet out/HelloWorldDotNetApp.dll network: port: 5000 env: APP_PORT env: - name: ASPNETCORE_URLS value: "http://*:5000" ``` # Informações sobre a versão do runtime do.NET **Importante** O App Runner encerrará o suporte **do.NET 6** em 1º de dezembro de 2025. Para obter recomendações e mais informações, consulte[Fim do suporte para versões de tempo de execução gerenciado](service-source-code.md#service-source-code.managed-platforms.eos). Este tópico lista os detalhes completos das versões de tempo de execução do.NET suportadas pelo App Runner. **Versões de tempo de execução suportadas — versão original do App Runner** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/apprunner/latest/dg/service-source-code-dotnet-releases.html) **nota** O App Runner fornece um processo de criação revisado para os principais tempos de execução específicos que foram lançados mais recentemente. Por isso, você verá referências à *versão revisada do App Runner e à versão* *original do App Runner* em determinadas seções deste documento. Para obter mais informações, consulte [Versões de tempo de execução gerenciadas e a compilação do App Runner](service-source-code.md#service-source-code.build-detail). # Usar a plataforma PHP do **Importante** O App Runner encerrará o suporte ao **PHP 8.1** em 31 de dezembro de 2025. Para obter recomendações e mais informações, consulte[Fim do suporte para versões de tempo de execução gerenciado](service-source-code.md#service-source-code.managed-platforms.eos). A plataforma AWS App Runner PHP fornece tempos de execução gerenciados. Você pode usar cada tempo de execução para criar e executar contêineres com aplicativos web baseados em uma versão do PHP. Quando você usa um tempo de execução PHP, o App Runner começa com uma imagem de tempo de execução PHP gerenciada. Essa imagem é baseada na [imagem Docker do Amazon Linux](https://hub.docker.com/_/amazonlinux) e contém o pacote de tempo de execução para uma versão do PHP e algumas ferramentas. O App Runner usa essa imagem de tempo de execução gerenciada como imagem base e adiciona o código do aplicativo para criar uma imagem do Docker. Em seguida, ele implanta essa imagem para executar seu serviço web em um contêiner. Você especifica um tempo de execução para seu serviço App Runner ao [criar um serviço](manage-create.md) usando o console do App Runner ou a operação da [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API. Você também pode especificar um tempo de execução como parte do seu código-fonte. Use a `runtime` palavra-chave em um [arquivo de configuração do App Runner](config-file.md) que você inclui no seu repositório de código. A convenção de nomenclatura de um tempo de execução gerenciado é*

*. Para nomes e versões válidos do tempo de execução do PHP, consulte[Informações sobre a versão do PHP runtime](service-source-code-php-releases.md). O App Runner atualiza o tempo de execução do seu serviço para a versão mais recente em cada implantação ou atualização de serviço. Se seu aplicativo exigir uma versão específica de um tempo de execução gerenciado, você poderá especificá-la usando a `runtime-version` palavra-chave no [arquivo de configuração do App Runner](config-file.md). Você pode bloquear qualquer nível de versão, incluindo uma versão principal ou secundária. O App Runner só faz atualizações de nível inferior no tempo de execução do seu serviço. Sintaxe da versão para tempos de execução do PHP: `major[.minor[.patch]]` Por exemplo: `8.1.10` Veja a seguir exemplos de bloqueio de versão: + `8.1`— Bloqueie as versões principais e secundárias. O App Runner atualiza somente as versões de patch. + `8.1.10`— Bloqueie uma versão específica do patch. O App Runner não atualiza sua versão de tempo de execução. **Importante** Se você quiser especificar o [diretório de origem](service-source-code.md#service-source-code.source-directory) do repositório de código para seu serviço App Runner em um local diferente do diretório raiz padrão do repositório, sua versão de tempo de execução gerenciada do PHP deve ser PHP `8.1.22` ou posterior. As versões de tempo de execução do PHP anteriores só `8.1.22` podem usar o diretório de origem raiz padrão. **Topics** + [Configuração de tempo de execução do PHP](#service-source-code-php.config) + [Compatibilidade](#service-source-code-php.compatibility) + [Exemplos de tempo de execução em PHP](#service-source-code-php.examples) + [Informações sobre a versão do PHP runtime](service-source-code-php-releases.md) ## Configuração de tempo de execução do PHP Ao escolher um tempo de execução gerenciado, você também deve configurar, no mínimo, comandos de compilação e execução. Você os configura ao [criar](manage-create.md) ou [atualizar](manage-configure.md) seu serviço App Runner. Você pode fazer isso usando um dos seguintes métodos: + **Usando o console do App Runner** — Especifique os comandos na seção **Configurar compilação** do processo de criação ou da guia de configuração. + **Usando a API App Runner** — chame a operação [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)ou [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API. Especifique os comandos usando os `StartCommand` membros `BuildCommand` e do tipo de [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)dados. + **Usando um [arquivo de configuração](config-file.md)** — especifique um ou mais comandos de compilação em até três fases de compilação e um único comando de execução que serve para iniciar seu aplicativo. Há configurações opcionais adicionais. Fornecer um arquivo de configuração é opcional. Ao criar um serviço App Runner usando o console ou a API, você especifica se o App Runner obtém suas configurações diretamente quando é criado ou de um arquivo de configuração. ## Compatibilidade Você pode executar seus serviços do App Runner na plataforma PHP usando um dos seguintes servidores web: + Apache HTTP Server + NGINX Apache HTTP Servere NGINX são compatíveis com PHP-FPM. Você pode iniciar o *Apache HTTP Server*e *NGINX*usando uma das seguintes opções: + [Supervisord](http://supervisord.org/introduction.html#supervisor-components/) - Para obter mais informações sobre como executar um *supervisord*, consulte [Executando](http://supervisord.org/running.html#running-supervisord) supervisord. + Script de inicialização Para obter exemplos de como configurar seu serviço App Runner com a plataforma PHP usando o *Apache HTTP Server* ou *NGINX*, consulte. [Fonte completa do aplicativo PHP](#service-source-code-php.examples.end2end) ### Estrutura do arquivo O `index.php` deve ser instalado na `public` pasta abaixo do `root` diretório do servidor web. **nota** Recomendamos que os `supervisord.conf` arquivos `startup.sh` ou sejam armazenados no diretório raiz do servidor web. Certifique-se de que o `start` comando aponte para o local onde os `supervisord.conf` arquivos `startup.sh` ou estão armazenados. Veja a seguir um exemplo da estrutura do arquivo, se você estiver usando *supervisord*. ``` / ├─ public/ │ ├─ index.php ├─ apprunner.yaml ├─ supervisord.conf ``` Veja a seguir um exemplo da estrutura do arquivo se você estiver usando um *script de inicialização*. ``` / ├─ public/ │ ├─ index.php ├─ apprunner.yaml ├─ startup.sh ``` Recomendamos que você armazene essas estruturas de arquivo no [diretório de origem](service-source-code.md#service-source-code.source-directory) do repositório de código designado para o serviço App Runner. ``` // ├─ public/ │ ├─ index.php ├─ apprunner.yaml ├─ startup.sh ``` **Importante** Se você quiser especificar o [diretório de origem](service-source-code.md#service-source-code.source-directory) do repositório de código para seu serviço App Runner em um local diferente do diretório raiz padrão do repositório, sua versão de tempo de execução gerenciada do PHP deve ser PHP `8.1.22` ou posterior. As versões de tempo de execução do PHP anteriores só `8.1.22` podem usar o diretório de origem raiz padrão. O App Runner atualiza o tempo de execução do seu serviço para a versão mais recente em cada implantação ou atualização de serviço. Seu serviço usará os tempos de execução mais recentes por padrão, a menos que você tenha especificado o bloqueio de versão usando a `runtime-version` palavra-chave no arquivo de configuração do [App Runner](config-file.md). ## Exemplos de tempo de execução em PHP Veja a seguir exemplos de arquivos de configuração do App Runner usados para criar e executar um serviço PHP. ### Arquivo mínimo de configuração PHP O exemplo a seguir é um arquivo de configuração mínimo que você pode usar com um tempo de execução gerenciado por PHP. Para obter mais informações sobre um arquivo de configuração mínimo, consulte[Exemplos de arquivos de configuração](config-file-examples.md#config-file-examples.managed). **Example apprunner.yaml** ``` version: 1.0 runtime: php81 build: commands: build: - echo example build command for PHP run: command: ./startup.sh ``` ### Arquivo de configuração PHP estendido O exemplo a seguir usa todas as chaves de configuração com um tempo de execução gerenciado por PHP. **nota** A versão de tempo de execução usada nesses exemplos é*8.1.10*. Você pode substituí-lo por uma versão que você deseja usar. Para obter a versão mais recente do PHP em tempo de execução compatível, consulte[Informações sobre a versão do PHP runtime](service-source-code-php-releases.md). **Example apprunner.yaml** ``` version: 1.0 runtime: php81 build: commands: pre-build: - scripts/prebuild.sh build: - echo example build command for PHP post-build: - scripts/postbuild.sh env: - name: MY_VAR_EXAMPLE value: "example" run: runtime-version: 8.1.10 command: ./startup.sh network: port: 5000 env: APP_PORT env: - name: MY_VAR_EXAMPLE value: "example" ``` ### Fonte completa do aplicativo PHP Os exemplos a seguir são do código-fonte do aplicativo PHP que você pode usar para implantar em um serviço de tempo de execução PHP usando *Apache HTTP Server*ou *NGINX*. Esses exemplos pressupõem que você use a estrutura de arquivo padrão. #### Executando a plataforma PHP com Apache HTTP Server o uso supervisord **Example Estrutura do arquivo** + O `supervisord.conf` arquivo pode ser armazenado em qualquer lugar do repositório. Certifique-se de que o `start` comando aponte para onde o `supervisord.conf` arquivo está armazenado. + O `index.php` deve ser instalado na `public` pasta abaixo do `root` diretório. ``` / ├─ public/ │ ├─ index.php ├─ apprunner.yaml ├─ supervisord.conf ``` **Example supervisor.conf** ``` [supervisord] nodaemon=true [program:httpd] command=httpd -DFOREGROUND autostart=true autorestart=true stdout_logfile=/dev/stdout stdout_logfile_maxbytes=0 stderr_logfile=/dev/stderr stderr_logfile_maxbytes=0 [program:php-fpm] command=php-fpm -F autostart=true autorestart=true stdout_logfile=/dev/stdout stdout_logfile_maxbytes=0 stderr_logfile=/dev/stderr stderr_logfile_maxbytes=0 ``` **Example apprunner.yaml** ``` version: 1.0 runtime: php81 build: commands: build: - PYTHON=python2 amazon-linux-extras install epel - yum -y install supervisor run: command: supervisord network: port: 8080 env: APP_PORT ``` **Example index.php** ``` First PHP App "); ?> ``` #### Executando a plataforma PHP com Apache HTTP Server o uso startup script **Example Estrutura do arquivo** + O `startup.sh` arquivo pode ser armazenado em qualquer lugar do repositório. Certifique-se de que o `start` comando aponte para onde o `startup.sh` arquivo está armazenado. + O `index.php` deve ser instalado na `public` pasta abaixo do `root` diretório. ``` / ├─ public/ │ ├─ index.php ├─ apprunner.yaml ├─ startup.sh ``` **Example startup.sh** ``` #!/bin/bash set -o monitor trap exit SIGCHLD # Start apache httpd -DFOREGROUND & # Start php-fpm php-fpm -F & wait ``` **nota** Certifique-se de salvar o `startup.sh` arquivo como executável antes de confirmá-lo em um repositório Git. Use `chmod +x startup.sh` para definir a permissão de execução em seu `startup.sh` arquivo. Se você não salvar o `startup.sh` arquivo como executável, insira `chmod +x startup.sh` como `build` comando no seu `apprunner.yaml` arquivo. **Example apprunner.yaml** ``` version: 1.0 runtime: php81 build: commands: build: - echo example build command for PHP run: command: ./startup.sh network: port: 8080 env: APP_PORT ``` **Example index.php** ``` First PHP App "); ?> ``` #### Executando a plataforma PHP com NGINX o uso supervisord **Example Estrutura do arquivo** + O `supervisord.conf` arquivo pode ser armazenado em qualquer lugar do repositório. Certifique-se de que o `start` comando aponte para onde o `supervisord.conf` arquivo está armazenado. + O `index.php` deve ser instalado na `public` pasta abaixo do `root` diretório. ``` / ├─ public/ │ ├─ index.php ├─ apprunner.yaml ├─ supervisord.conf ``` **Example supervisor.conf** ``` [supervisord] nodaemon=true [program:nginx] command=nginx -g "daemon off;" autostart=true autorestart=true stdout_logfile=/dev/stdout stdout_logfile_maxbytes=0 stderr_logfile=/dev/stderr stderr_logfile_maxbytes=0 [program:php-fpm] command=php-fpm -F autostart=true autorestart=true stdout_logfile=/dev/stdout stdout_logfile_maxbytes=0 stderr_logfile=/dev/stderr stderr_logfile_maxbytes=0 ``` **Example apprunner.yaml** ``` version: 1.0 runtime: php81 build: commands: build: - PYTHON=python2 amazon-linux-extras install epel - yum -y install supervisor run: command: supervisord network: port: 8080 env: APP_PORT ``` **Example index.php** ``` First PHP App "); ?> ``` #### Executando a plataforma PHP com NGINX o uso startup script **Example Estrutura do arquivo** + O `startup.sh` arquivo pode ser armazenado em qualquer lugar do repositório. Certifique-se de que o `start` comando aponte para onde o `startup.sh` arquivo está armazenado. + O `index.php` deve ser instalado na `public` pasta abaixo do `root` diretório. ``` / ├─ public/ │ ├─ index.php ├─ apprunner.yaml ├─ startup.sh ``` **Example startup.sh** ``` #!/bin/bash set -o monitor trap exit SIGCHLD # Start nginx nginx -g 'daemon off;' & # Start php-fpm php-fpm -F & wait ``` **nota** Certifique-se de salvar o `startup.sh` arquivo como executável antes de confirmá-lo em um repositório Git. Use `chmod +x startup.sh` para definir a permissão de execução em seu `startup.sh` arquivo. Se você não salvar o `startup.sh` arquivo como executável, insira `chmod +x startup.sh` como `build` comando no seu `apprunner.yaml` arquivo. **Example apprunner.yaml** ``` version: 1.0 runtime: php81 build: commands: build: - echo example build command for PHP run: command: ./startup.sh network: port: 8080 env: APP_PORT ``` **Example index.php** ``` First PHP App "); ?> ``` # Informações sobre a versão do PHP runtime **Importante** O App Runner encerrará o suporte ao **PHP 8.1** em 31 de dezembro de 2025. Para recomendações e mais informações, consulte[Fim do suporte para versões de tempo de execução gerenciado](service-source-code.md#service-source-code.managed-platforms.eos). Este tópico lista os detalhes completos das versões de tempo de execução do PHP suportadas pelo App Runner. **Versões de tempo de execução suportadas — versão original do App Runner** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/apprunner/latest/dg/service-source-code-php-releases.html) **nota** O App Runner fornece um processo de criação revisado para os principais tempos de execução específicos que foram lançados mais recentemente. Por isso, você verá referências à *versão revisada do App Runner e à versão* *original do App Runner* em determinadas seções deste documento. Para obter mais informações, consulte [Versões de tempo de execução gerenciadas e a compilação do App Runner](service-source-code.md#service-source-code.build-detail). # Usar a plataforma Ruby do **Importante** O App Runner encerrará o suporte para **Ruby 3.1** em 1º de dezembro de 2025. Para obter recomendações e mais informações, consulte[Fim do suporte para versões de tempo de execução gerenciado](service-source-code.md#service-source-code.managed-platforms.eos). A plataforma AWS App Runner Ruby fornece tempos de execução gerenciados. Cada tempo de execução facilita a criação e a execução de contêineres com aplicativos web baseados em uma versão Ruby. Quando você usa um tempo de execução do Ruby, o App Runner começa com uma imagem gerenciada do tempo de execução do Ruby. Essa imagem é baseada na [imagem Docker do Amazon Linux](https://hub.docker.com/_/amazonlinux) e contém o pacote de tempo de execução para uma versão do Ruby e algumas ferramentas. O App Runner usa essa imagem de tempo de execução gerenciada como imagem base e adiciona o código do aplicativo para criar uma imagem do Docker. Em seguida, ele implanta essa imagem para executar seu serviço web em um contêiner. Você especifica um tempo de execução para seu serviço App Runner ao [criar um serviço](manage-create.md) usando o console do App Runner ou a operação da [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API. Você também pode especificar um tempo de execução como parte do seu código-fonte. Use a `runtime` palavra-chave em um [arquivo de configuração do App Runner](config-file.md) que você inclui no seu repositório de código. A convenção de nomenclatura de um tempo de execução gerenciado é*

*. Para nomes e versões válidos do tempo de execução do Ruby, consulte[Informações de lançamento do Ruby Runtime](service-source-code-ruby-releases.md). O App Runner atualiza o tempo de execução do seu serviço para a versão mais recente em cada implantação ou atualização de serviço. Se seu aplicativo exigir uma versão específica de um tempo de execução gerenciado, você poderá especificá-la usando a `runtime-version` palavra-chave no [arquivo de configuração do App Runner](config-file.md). Você pode bloquear qualquer nível de versão, incluindo uma versão principal ou secundária. O App Runner só faz atualizações de nível inferior no tempo de execução do seu serviço. Sintaxe da versão para tempos de execução do Ruby: `major[.minor[.patch]]` Por exemplo: `3.1.2` Os exemplos a seguir demonstram o bloqueio de versões: + `3.1`— Bloqueie as versões principais e secundárias. O App Runner atualiza somente as versões de patch. + `3.1.2`— Bloqueie uma versão específica do patch. O App Runner não atualiza sua versão de tempo de execução. **Topics** + [Configuração de tempo de execução do Ruby](#service-source-code-ruby.config) + [Exemplos de tempo de execução do Ruby](#service-source-code-ruby.examples) + [Informações de lançamento do Ruby Runtime](service-source-code-ruby-releases.md) ## Configuração de tempo de execução do Ruby Ao escolher um tempo de execução gerenciado, você também deve configurar, no mínimo, comandos de compilação e execução. Você os configura ao [criar](manage-create.md) ou [atualizar](manage-configure.md) seu serviço App Runner. Você pode fazer isso usando um dos seguintes métodos: + **Usando o console do App Runner** — Especifique os comandos na seção **Configurar compilação** do processo de criação ou da guia de configuração. + **Usando a API App Runner** — chame a operação [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)ou [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)da API. Especifique os comandos usando os `StartCommand` membros `BuildCommand` e do tipo de [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)dados. + **Usando um [arquivo de configuração](config-file.md)** — especifique um ou mais comandos de compilação em até três fases de compilação e um único comando de execução que serve para iniciar seu aplicativo. Há configurações opcionais adicionais. Fornecer um arquivo de configuração é opcional. Ao criar um serviço App Runner usando o console ou a API, você especifica se o App Runner obtém suas configurações diretamente quando é criado ou de um arquivo de configuração. ## Exemplos de tempo de execução do Ruby Os exemplos a seguir mostram os arquivos de configuração do App Runner para criar e executar um serviço Ruby. ### Arquivo de configuração mínimo do Ruby Este exemplo mostra um arquivo de configuração mínimo que você pode usar com um tempo de execução gerenciado por Ruby. Para as suposições que o App Runner faz com um arquivo de configuração mínimo, consulte. [Exemplos de arquivos de configuração](config-file-examples.md#config-file-examples.managed) **Example apprunner.yaml** ``` version: 1.0 runtime: ruby31 build: commands: build: - bundle install run: command: bundle exec rackup --host 0.0.0.0 -p 8080 ``` ### Arquivo de configuração Ruby estendido Este exemplo mostra o uso de todas as chaves de configuração com um tempo de execução gerenciado por Ruby. **nota** A versão de tempo de execução usada nesses exemplos é*3.1.2*. Você pode substituí-lo por uma versão que você deseja usar. Para obter a versão mais recente de tempo de execução do Ruby compatível, consulte[Informações de lançamento do Ruby Runtime](service-source-code-ruby-releases.md). **Example apprunner.yaml** ``` version: 1.0 runtime: ruby31 build: commands: pre-build: - scripts/prebuild.sh build: - bundle install post-build: - scripts/postbuild.sh env: - name: MY_VAR_EXAMPLE value: "example" run: runtime-version: 3.1.2 command: bundle exec rackup --host 0.0.0.0 -p 4567 network: port: 4567 env: APP_PORT env: - name: MY_VAR_EXAMPLE value: "example" ``` ### Fonte completa do aplicativo Ruby Esses exemplos mostram o código-fonte de um aplicativo Ruby completo que você pode implantar em um serviço de tempo de execução do Ruby. **Example servidor.rb** ``` # server.rb require 'sinatra' get '/' do 'Hello World!' end ``` **Example config.ru** ``` # config.ru require './server' run Sinatra::Application ``` **Example Gemfile** ``` # Gemfile source 'https://rubygems.org (https://rubygems.org/)' gem 'sinatra' gem 'puma' ``` **Example apprunner.yaml** ``` version: 1.0 runtime: ruby31 build: commands: build: - bundle install run: command: bundle exec rackup --host 0.0.0.0 -p 4567 network: port: 4567 env: APP_PORT ``` # Informações de lançamento do Ruby Runtime **Importante** O App Runner encerrará o suporte para **Ruby 3.1** em 1º de dezembro de 2025. Para obter recomendações e mais informações, consulte[Fim do suporte para versões de tempo de execução gerenciado](service-source-code.md#service-source-code.managed-platforms.eos). Este tópico lista os detalhes completos das versões de tempo de execução do Ruby suportadas pelo App Runner. **Versões de tempo de execução suportadas — versão original do App Runner** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/apprunner/latest/dg/service-source-code-ruby-releases.html) **nota** O App Runner fornece um processo de criação revisado para os principais tempos de execução específicos que foram lançados mais recentemente. Por isso, você verá referências à *versão revisada do App Runner e à versão* *original do App Runner* em determinadas seções deste documento. Para obter mais informações, consulte [Versões de tempo de execução gerenciadas e a compilação do App Runner](service-source-code.md#service-source-code.build-detail). # Usar a plataforma Go do **Importante** O App Runner encerrará o suporte para o **Go 1.18** em 1º de dezembro de 2025. Para recomendações e mais informações, consulte[Fim do suporte para versões de tempo de execução gerenciado](service-source-code.md#service-source-code.managed-platforms.eos). A plataforma AWS App Runner Go fornece tempos de execução gerenciados. Cada tempo de execução facilita a criação e a execução de contêineres com aplicativos web baseados em uma versão Go. Quando você usa um tempo de execução em Go, o App Runner começa com uma imagem gerenciada de tempo de execução em Go. Essa imagem é baseada na [imagem Docker do Amazon Linux](https://hub.docker.com/_/amazonlinux) e contém o pacote de tempo de execução para uma versão do Go e algumas ferramentas. O App Runner usa essa imagem de tempo de execução gerenciada como imagem base e adiciona o código do aplicativo para criar uma imagem do Docker. Em seguida, ele implanta essa imagem para executar seu serviço web em um contêiner. Você especifica um tempo de execução para seu serviço App Runner ao [criar um serviço](manage-create.md) usando o console do App Runner ou a operação da [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API. Você também pode especificar um tempo de execução como parte do código-fonte. Use a `runtime` palavra-chave em um [arquivo de configuração do App Runner](config-file.md) que você inclui no seu repositório de código. A convenção de nomenclatura de um tempo de execução gerenciado é*

*. Para nomes e versões válidos do tempo de execução do Go, consulte[Informações sobre a versão do Go Runtime](service-source-code-go-releases.md). O App Runner atualiza o tempo de execução do seu serviço para a versão mais recente em cada implantação ou atualização de serviço. Se seu aplicativo exigir uma versão específica de um tempo de execução gerenciado, você poderá especificá-la usando a `runtime-version` palavra-chave no [arquivo de configuração do App Runner](config-file.md). Você pode bloquear qualquer nível de versão, incluindo uma versão principal ou secundária. O App Runner só faz atualizações de nível inferior no tempo de execução do seu serviço. Sintaxe da versão para tempos de execução do Go: `major[.minor[.patch]]` Por exemplo: `1.18.7` Os exemplos a seguir demonstram o bloqueio de versões: + `1.18`— Bloqueie as versões principais e secundárias. O App Runner atualiza somente as versões de patch. + `1.18.7`— Bloqueie uma versão específica do patch. O App Runner não atualiza sua versão de tempo de execução. **Topics** + [Configuração de tempo de execução do Go](#service-source-code-go1.config) + [Exemplos de tempo de execução do Go](#service-source-code-go1.examples) + [Informações sobre a versão do Go Runtime](service-source-code-go-releases.md) ## Configuração de tempo de execução do Go Ao escolher um tempo de execução gerenciado, você também deve configurar, no mínimo, comandos de compilação e execução. Você os configura ao [criar](manage-create.md) ou [atualizar](manage-configure.md) seu serviço App Runner. Você pode fazer isso usando um dos seguintes métodos: + **Usando o console do App Runner** — Especifique os comandos na seção **Configurar compilação** do processo de criação ou da guia de configuração. + **Usando a API App Runner** — chame a operação [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)ou [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API. Especifique os comandos usando os `StartCommand` membros `BuildCommand` e do tipo de [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)dados. + **Usando um [arquivo de configuração](config-file.md)** — especifique um ou mais comandos de compilação em até três fases de compilação e um único comando de execução que serve para iniciar seu aplicativo. Há configurações opcionais adicionais. Fornecer um arquivo de configuração é opcional. Ao criar um serviço App Runner usando o console ou a API, você especifica se o App Runner obtém suas configurações diretamente quando é criado ou de um arquivo de configuração. ## Exemplos de tempo de execução do Go Os exemplos a seguir mostram os arquivos de configuração do App Runner para criar e executar um serviço Go. ### Arquivo de configuração Minimal Go Este exemplo mostra um arquivo de configuração mínimo que você pode usar com um tempo de execução gerenciado em Go. Para as suposições que o App Runner faz com um arquivo de configuração mínimo, consulte. [Exemplos de arquivos de configuração](config-file-examples.md#config-file-examples.managed) **Example apprunner.yaml** ``` version: 1.0 runtime: go1 build: commands: build: - go build main.go run: command: ./main ``` ### Arquivo de configuração Extended Go Este exemplo mostra o uso de todas as chaves de configuração com um tempo de execução gerenciado em Go. **nota** A versão de tempo de execução usada nesses exemplos é*1.18.7*. Você pode substituí-lo por uma versão que você deseja usar. Para ver a versão mais recente do Go runtime compatível, consulte[Informações sobre a versão do Go Runtime](service-source-code-go-releases.md). **Example apprunner.yaml** ``` version: 1.0 runtime: go1 build: commands: pre-build: - scripts/prebuild.sh build: - go build main.go post-build: - scripts/postbuild.sh env: - name: MY_VAR_EXAMPLE value: "example" run: runtime-version: 1.18.7 command: ./main network: port: 3000 env: APP_PORT env: - name: MY_VAR_EXAMPLE value: "example" ``` ### Fonte completa do aplicativo Go Esses exemplos mostram o código-fonte de um aplicativo Go completo que você pode implantar em um serviço de tempo de execução Go. **Example main.go** ``` package main import ( "fmt" "net/http" ) func main() { http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { fmt.Fprint(w, "

Welcome to App Runner

") }) fmt.Println("Starting the server on :3000...") http.ListenAndServe(":3000", nil) } ``` **Example apprunner.yaml** ``` version: 1.0 runtime: go1 build: commands: build: - go build main.go run: command: ./main network: port: 3000 env: APP_PORT ``` # Informações sobre a versão do Go Runtime **Importante** O App Runner encerrará o suporte para o **Go 1.18** em 1º de dezembro de 2025. Para obter recomendações e mais informações, consulte[Fim do suporte para versões de tempo de execução gerenciado](service-source-code.md#service-source-code.managed-platforms.eos). Este tópico lista os detalhes completos das versões de tempo de execução do Go compatíveis com o App Runner. **Versões de tempo de execução suportadas — versão original do App Runner** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/apprunner/latest/dg/service-source-code-go-releases.html) **nota** O App Runner fornece um processo de criação revisado para os principais tempos de execução específicos que foram lançados mais recentemente. Por isso, você verá referências à *versão revisada do App Runner e à versão* *original do App Runner* em determinadas seções deste documento. Para obter mais informações, consulte [Versões de tempo de execução gerenciadas e a compilação do App Runner](service-source-code.md#service-source-code.build-detail).