Como migrar do app Java do Google App Engine para o Cloud Run com Docker

1. Visão geral

Esta série de codelabs (tutoriais práticos e autoguiados) tem como objetivo ajudar os desenvolvedores Java do Google App Engine (Padrão) a modernizar os aplicativos por meio de uma série de migrações. Seguindo estas etapas, você pode atualizar seu app para que ele seja mais portátil e decidir colocá-lo em um contêiner para o Cloud Run, o serviço irmã de hospedagem de contêiner do Google Cloud no App Engine e outros serviços de hospedagem de contêiner.

Neste tutorial, você vai aprender a colocar um aplicativo do App Engine em contêiner para implantação no serviço totalmente gerenciado do Cloud Run com um Dockerfile. Os Dockerfiles são o método de implantação mais prático para esta migração, mas também oferecem mais opções para personalizar seu processo de build.

Além de ensinar as etapas necessárias para migrar do App Engine para o Cloud Run, você também vai aprender a fazer upgrade de um app do Java 8 do App Engine para o Java 17.

Se o aplicativo que você quer migrar usa muitos serviços agrupados legados do App Engine ou outros recursos específicos do App Engine, o guia Como acessar serviços agrupados do App Engine para Java 11/17 pode ser um ponto de partida melhor do que este codelab.

Você vai aprender a

  • Usar o Cloud Shell
  • Ative as APIs Cloud Run, Artifact Registry e Cloud Build.
  • Conteinerizar o app usando o Docker, o Docker e o Cloud Build
  • Implantar imagens de contêiner no Cloud Run

O que é necessário

Pesquisa

Como você vai usar este tutorial?

Apenas leitura Leitura e exercícios

Como você classificaria sua experiência com Java?

Iniciante Intermediário Proficiente

Como você classificaria sua experiência de uso dos serviços do Google Cloud?

Iniciante Intermediário Proficiente

2. Contexto

Os sistemas PaaS, como o App Engine e o Cloud Functions, oferecem muitas conveniências para sua equipe e aplicativo, como permitir que SysAdmins e Devops se concentrem na criação de soluções. Com plataformas sem servidor, seu app pode escalonar automaticamente conforme necessário, reduzir a escala vertical até zero com o pagamento por utilização para ajudar a controlar custos e usar uma variedade de linguagens de desenvolvimento comuns.

No entanto, a flexibilidade dos contêineres também é atraente. Com a capacidade de escolher qualquer linguagem, biblioteca e binário, os contêineres oferecem o melhor dos dois mundos: a conveniência da computação sem servidor e a flexibilidade dos contêineres. Isso é do que se trata o Google Cloud Run.

Aprender a usar o Cloud Run não está no escopo deste codelab, mas isso é abordado na documentação do Cloud Run. O objetivo aqui é você saber como colocar o aplicativo do App Engine em um contêiner para o Cloud Run (ou outros serviços hospedados em contêineres). Há algumas coisas que você deve saber antes de avançar, principalmente que a experiência do usuário será um pouco diferente.

Neste codelab, você vai aprender a criar e implantar contêineres. Você vai aprender a colocar seu app em contêiner com um Dockerfile, migrar da configuração do App Engine e (opcionalmente) definir etapas de build para o Cloud Build. Isso envolve a retirada de certos recursos específicos do App Engine. Se preferir não seguir esse caminho, ainda é possível fazer upgrade para um ambiente de execução do Java 11/17 e manter seus apps no App Engine.

3. Configuração/Pré-trabalho

1. Configurar o projeto

Neste tutorial, você vai usar um app de exemplo do repositório appengine-java-migration-samples em um projeto novo. Verifique se o projeto tem uma conta de faturamento ativa.

Se você pretende mover um app do App Engine para o Cloud Run, use esse app para acompanhar o tutorial.

Execute o seguinte comando para ativar as APIs necessárias para o projeto:

gcloud services enable artifactregistry.googleapis.com cloudbuild.googleapis.com run.googleapis.com

2. Fazer o download do app de exemplo de valor de referência

Clone o app de exemplo na sua máquina ou no Cloud Shell e navegue até a pasta baseline.

O exemplo é um app do Datastore baseado em servlet Java 8 destinado à implantação no App Engine. Siga as instruções no README sobre como preparar este aplicativo para a implantação do App Engine.

3. (Opcional) Implantar o app de referência

As etapas a seguir são necessárias apenas se você quiser confirmar que o app funciona no App Engine antes da migração para o Cloud Run.

Consulte as etapas no README.md:

  1. Instale a CLI gcloud e se familiarize novamente
  2. Inicialize a CLI gcloud para seu projeto com gcloud init
  3. Crie o projeto do App Engine com gcloud app create
  4. Implantar o app de exemplo no App Engine
./mvnw package appengine:deploy -Dapp.projectId=$PROJECT_ID
  1. Confirmar se o aplicativo é executado no App Engine sem problemas

4. Criar um repositório do Artifact Registry

Depois de conteinerizar seu app, você vai precisar de algum lugar para enviar e armazenar suas imagens. A maneira recomendada de fazer isso no Google Cloud é com o Artifact Registry.

Crie o repositório com o nome migration usando o gcloud:

gcloud artifacts repositories create migration --repository-format=docker \
--description="Docker repository for the migrated app" \
--location="northamerica-northeast1"

Esse repositório usa o tipo de formato docker, mas há vários tipos de repositório disponíveis.

Neste ponto, você tem o aplicativo do App Engine de referência e seu projeto do Google Cloud está preparado para a migração para o Cloud Run.

4. Modificar arquivos do aplicativo

Nos casos em que o aplicativo usa muito os serviços incluídos legados, a configuração ou outros recursos exclusivos do App Engine do App Engine, recomendamos continuar acessando esses serviços durante o upgrade para o novo ambiente de execução. Este codelab demonstra um caminho de migração para aplicativos que já usam serviços independentes ou podem ser refatorados para isso.

1. Como fazer upgrade para o Java 17

Caso seu app use Java 8, considere fazer upgrade para um candidato a LTS posterior, como 11 ou 17, para acompanhar as atualizações de segurança e ter acesso a novos recursos da linguagem.

Comece atualizando as propriedades no pom.xml para incluir o seguinte:

<properties>
    <java.version>17</java.version>
    <maven.compiler.source>17</maven.compiler.source>
    <maven.compiler.target>17</maven.compiler.target>
</properties>

Isso vai definir a versão do projeto como 17, informar ao plug-in do compilador que você quer acessar os recursos da linguagem Java 17 e que quer que as classes compiladas sejam compatíveis com a JVM Java 17.

2. Incluir um servidor da Web

Há várias diferenças entre o App Engine e o Cloud Run que valem a pena considerar ao alternar entre eles. Uma diferença é que, enquanto o ambiente de execução do Java 8 do App Engine fornece e gerencia um servidor Jetty para os apps hospedados, o Cloud Run não faz isso. Vamos usar o Spring Boot para nos fornecer um servidor da Web e um contêiner de servlet.

Adicione as seguintes dependências:

<dependencies>
<!-- ... -->
   <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-web</artifactId>
       <version>2.6.6</version>
       <exclusions>
           <!-- Exclude the Tomcat dependency -->
           <exclusion>
               <groupId>org.springframework.boot</groupId>
               <artifactId>spring-boot-starter-tomcat</artifactId>
           </exclusion>
       </exclusions>
   </dependency>
   <!-- Use Jetty instead -->
   <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-jetty</artifactId>
       <version>2.6.6</version>
   </dependency>
<!-- ... -->
</dependencies>

O Spring Boot incorpora um servidor Tomcat por padrão, mas este exemplo exclui esse artefato e fica com o Jetty para minimizar as diferenças no comportamento padrão após a migração.

3. Configuração do Spring Boot

Embora o Spring Boot possa reutilizar seus servlets sem modificações, ele vai precisar de alguma configuração para garantir que eles sejam detectáveis.

Crie a seguinte classe MigratedServletApplication.java no pacote com.example.appengine:

package com.example.appengine;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.EnableAutoConfiguration;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.web.servlet.ServletComponentScan;

@ServletComponentScan
@SpringBootApplication
@EnableAutoConfiguration
public class MigratedServletApplication {
    public static void main(String[] args) {
        SpringApplication.run(MigratedServletApplication.class, args);
    }
}

Isso inclui a anotação @ServletComponentScan, que vai procurar (no pacote atual por padrão) por qualquer @WebServlets e disponibilizá-los conforme o esperado.

4. Como empacotar o app como um JAR

Embora seja possível contentorizar seu app a partir de um war, fica mais fácil se você empacotar o app como um JAR executável. Isso não vai exigir muita configuração, principalmente para projetos que usam o Maven como uma ferramenta de build, já que a embalagem jar é o comportamento padrão.

Remova a tag packaging no arquivo pom.xml:

<packaging>war</packaging>

Em seguida, adicione a spring-boot-maven-plugin:

<plugins>
<!-- ... -->
  <plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <version>2.6.6</version>
  </plugin>
<!-- ... -->
</plugins>

5. Como migrar da configuração, dos serviços e das dependências do App Engine

Como mencionado no início do codelab, o Cloud Run e o App Engine foram projetados para oferecer diferentes experiências do usuário. Alguns recursos que o App Engine oferece de forma imediata, como os serviços Cron e Task Queue, precisam ser recriados manualmente e serão abordados com mais detalhes em módulos posteriores.

O app de exemplo não usa os serviços incluídos no pacote legados, mas os usuários cujos apps usam podem consultar os seguintes guias:

Como você vai implantar no Cloud Run, o appengine-maven-plugin pode ser removido:

<plugin>
 <groupId>com.google.cloud.tools</groupId>
 <artifactId>appengine-maven-plugin</artifactId>
 <version>2.4.1</version>
 <configuration>
   <!-- can be set w/ -DprojectId=myProjectId on command line -->
   <projectId>${app.projectId}</projectId>
   <!-- set the GAE version or use "GCLOUD_CONFIG" for an autogenerated GAE version -->
   <version>GCLOUD_CONFIG</version>
 </configuration>
</plugin>

5. Conteinerizar o aplicativo

Agora você pode informar ao Cloud Build como criar o contêiner do seu aplicativo. Com esse método de contêinerização, não é necessário um arquivo de configuração de build separado (cloudbuild.yaml). Basta definir um Dockerfile mínimo como ponto de partida:

FROM eclipse-temurin

ARG JAR_FILE=JAR_FILE_MUST_BE_SPECIFIED_AS_BUILD_ARG

COPY ${JAR_FILE} app.jar

ENTRYPOINT ["java", "-jar","/app.jar"]

Esse dockerfile agrupa a versão uber-jar do seu serviço de inicialização por mola em uma única camada. É a abordagem mais simples para contêinerização do Dockerfile, mas tem várias desvantagens, especialmente quando comparada a tempos repetidos em que as dependências são relativamente estáveis. Preocupações como essa são o motivo pelo qual esse método de conteinerização é considerado mais avançado. Por outro lado, escrever seu próprio dockerfile oferece controle total sobre a imagem base e acesso aos benefícios de desempenho de escrever uma imagem cuidadosamente organizada em camadas.

2**. Executar o processo de build**

Agora que você informou ao Cloud Build as etapas de build desejadas, está tudo pronto para uma implantação com um clique.

Execute este comando:

gcloud builds submit --tag LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE_NAME

Substitua os valores de marcador no comando acima pelo seguinte:

  • LOCATION: o local regional ou multirregional do repositório.
  • PROJECT_ID: o ID do projeto do Cloud.
  • REPOSITORY: o nome do repositório do Artifact Registry.
  • IMAGE_NAME: o nome da imagem do contêiner.

Quando o processo for concluído, a imagem do contêiner será criada, armazenada no Artifact Registry e implantada no Cloud Run.

Ao final deste codelab, seu app vai ficar igual ao da pasta mod4-migrate-to-cloud-run.

Pronto! Você migrou um app do App Engine Java 8 para o Java 17 e o Cloud Run e agora tem um entendimento mais claro do trabalho envolvido na troca e na escolha entre as opções de hospedagem.

6. Resumo/limpeza

Parabéns! Você fez upgrade, criou um contêiner, migrou e seu app, o que conclui este tutorial.

A próxima etapa é saber mais sobre os recursos de segurança de CI/CD e da cadeia de suprimentos de software disponíveis para implantação com o Cloud Build:

Opcional: limpar e/ou desativar o serviço

Se você implantou o app de exemplo no App Engine durante este tutorial, desative o app para evitar cobranças. Quando estiver tudo pronto para passar para o próximo codelab, você poderá reativá-lo. Enquanto os apps do App Engine estão desativados, eles não recebem tráfego, mas o uso do Datastore pode ser cobrado se exceder a cota sem custo financeiro. Exclua o suficiente para ficar abaixo desse limite.

Por outro lado, se você não for continuar com as migrações e quiser excluir tudo por completo, poderá excluir seu serviço ou encerrar seu projeto totalmente.

7. Outros recursos

Problemas/comentários do módulo de migração do App Engine

Se você encontrar problemas com este codelab, pesquise seu problema antes de preenchê-lo. Links para pesquisar e criar novos problemas:

Recursos de migração

Recursos on-line

Confira abaixo alguns recursos on-line que podem ser relevantes para este tutorial:

App Engine

Outras informações do Cloud

Vídeos

Licença

Este conteúdo está sob a licença Atribuição 2.0 Genérica da Creative Commons.