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 recurso de CI/CD 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, consulteServiço App Runner baseado em uma imagem de origem.

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

Tópicos

• Provedores de repositórios de código-fonte
• Diretório de origem
• Plataformas gerenciadas do App Runner
• Versões de tempo de execução gerenciadas e a compilação do App Runner
• Usar a plataforma Python do
• Usar a plataforma Node.js do
• Usando a plataforma Java
• Usar a plataforma .NET do
• Usar a plataforma PHP do
• Usar a plataforma Ruby do
• Usar a plataforma Go do

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: GitHube o Bitbucket.

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, 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 CreateConnectionda API. Em seguida, você fornece o ARN da conexão durante a criação do serviço usando a ação da CreateServiceAPI.

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 em 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 UpdateServiceAPI CreateServicee. Para obter mais informações, consulte a seção Diretório de origem abaixo.

Para obter mais informações sobre a criação do serviço App Runner, consulteCriação de um serviço App Runner. Para obter mais informações sobre as conexões do App Runner, consulteGerenciando conexões do App Runner.

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 emMétodos de implantação.

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 ter mais informações, consulte Usar a plataforma PHP do .

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 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 usando o console do App Runner ou a operação da CreateServiceAPI. 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 que você inclui no seu repositório de código. A convenção de nomenclatura de um tempo de execução gerenciado é. <language-name><major-version>

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

Versões de tempo de execução gerenciadas e a compilação do App Runner

O App Runner agora oferece um processo de criação atualizado para seus aplicativos. Atualmente, ele invoca a nova compilação para serviços executados em tempos de execução gerenciados Python 3.11 e Node.js 18, lançados pela última vez em 29 de dezembro de 2023. 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 significativas nas versões anteriores das plataformas de tempo de execução, o App Runner aplica a compilação revisada somente a versões de tempo de execução específicas, geralmente 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-runparâ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.

Plataforma	Construção original	Construção revisada
Python – Informações de lançamento	Python 3.8 Python 3.7	Python 3.11 (!)
Node.js: Informações de lançamento	Node.js 16 Node.js 14 Node.js 12	Node.js 18
Correto — Informações de lançamento	Corretto 11 Corretto 8
.NET: Informações de lançamento	.NET 6
PHP: Informações de lançamento	PHP 8.1
Ruby: Informações de lançamento	Rubi 3.1
Go: Informações de lançamento	Go 1

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

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

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

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

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

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

   2. Execute comandos da pre-build.

      Os pre-build comandos são opcionais. Eles só podem ser especificados no arquivo apprunner.yaml de configuração.

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

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

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

3. 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 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 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-buildbuild, 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 noapprunner.yaml. Para ter mais informações, consulte Definindo as opções do serviço App Runner usando um arquivo de configuração.

Executando os build comandos duas vezes

• A compilação original do App Runner 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.