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

1. Visão geral

Esta série de codelabs (tutoriais práticos e individualizados) tem como objetivo ajudar os desenvolvedores Java do Google App Engine (padrão) a modernizar os apps, orientando-os em uma série de migrações. Seguindo essas etapas, é possível atualizar seu aplicativo para torná-lo mais portátil e decidir colocá-lo em contêineres para o Cloud Run, o serviço associado de hospedagem de contêineres do Google Cloud para o App Engine e outros serviços de hospedagem de contêineres.

Neste tutorial, ensinamos como conteinerizar um aplicativo do App Engine para implantação no serviço totalmente gerenciado do Cloud Run usando o Jib. Com ele, é possível criar imagens do Docker, uma plataforma conhecida no setor para desenvolvimento, envio e execução de aplicativos em contêineres.

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 App Engine em Java 8 para o Java 17.

Caso seu aplicativo faça uso intenso de serviços incluídos legados do App Engine ou de outros recursos do App Engine, recomendamos migrar dos serviços em pacote ou substituí-los antes de migrar para o Cloud Run. Se você precisar de mais tempo para investigar as opções de migração ou quiser continuar usando os serviços em pacote legados por enquanto, continue a acessar os serviços agrupados do App Engine para Java 11/17 ao fazer upgrade para um ambiente de execução mais recente. Quando o app estiver mais portátil, volte a este codelab para aprender a aplicar as instruções.

Você vai aprender a

  • Usar o Cloud Shell
  • Ative as APIs Cloud Run, Artifact Registry e Cloud Build
  • Conteinerizar o app usando o Jib e o Cloud Build
  • implante as 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

Sistemas de plataforma como serviço (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 é interessante. Com a capacidade de escolher qualquer linguagem, qualquer biblioteca e qualquer binário, os contêineres oferecem o melhor dos dois mundos: a conveniência de usar um ambiente sem servidor e a flexibilidade dos contêineres. Isso é o que é o Cloud Run.

Aprender a usar o Cloud Run não está no escopo deste codelab. que são abordados na documentação do Cloud Run. O objetivo é que você se familiarize com a conteinerização do seu aplicativo do App Engine para o Cloud Run ou de outros serviços hospedados em contêineres. Há algumas coisas que você precisa saber antes de prosseguir, principalmente que sua experiência de usuário será um pouco diferente.

Neste codelab, você vai aprender a criar e implantar contêineres. Você vai aprender a:

  • Conteinerizar o app com o Jib
  • Migrar da configuração do App Engine
  • e, opcionalmente, definir as 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, você ainda pode fazer upgrade para um ambiente de execução Java 11/17 enquanto mantém seus aplicativos 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 aplicativo atual do App Engine para o Cloud Run, use esse aplicativo para acompanhar.

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

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

2. Instalar o app de exemplo de referência

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

A amostra é um aplicativo do Datastore em Java 8 baseado em servlets para 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 um aplicativo de referência

As informações abaixo só são necessárias se você quiser confirmar se o app funciona no App Engine antes da migração para o Cloud Run.

Consulte as etapas em README.md:

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

4. Crie 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 chamado migration com a gcloud da seguinte maneira:

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 seu aplicativo de referência do App Engine e seu projeto do Google Cloud está preparado para migrá-lo para o Cloud Run.

4. Modificar arquivos do aplicativo

Nos casos em que o aplicativo faz uso intenso de serviços incluídos legados, 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, faça 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 gostaria que as classes compiladas fossem compatíveis com a JVM do Java 17.

2. Incluir um servidor da Web

Há várias diferenças entre o App Engine e o Cloud Run que vale a pena considerar ao migrar entre eles. Uma diferença é que, embora o ambiente de execução do Java 8 do App Engine fornecesse e gerenciasse um servidor Jetty para os aplicativos hospedados, o Cloud Run não. 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 excluirá esse artefato e seguirá com o Jetty para minimizar as diferenças no comportamento padrão após a migração. Também podemos configurar a versão do Jetty para corresponder àquela fornecida pelo App Engine.

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

3. Configuração do Spring Boot

Embora o Spring Boot seja capaz de reutilizar seus servlets sem modificação, será necessária alguma configuração para detecção.

Crie a classe MigratedServletApplication.java abaixo 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 procurará qualquer @WebServlets (no pacote atual por padrão) e os disponibilizará conforme esperado.

4. Como empacotar o app como um JAR

Embora seja possível conteinerizar seu app com o Jib começando de uma guerra, isso fica mais fácil se você empacotar o aplicativo como um JAR executável. Isso não exige muita configuração, principalmente para projetos que usam o Maven como uma ferramenta de build, já que o empacotamento de jar é o comportamento padrão.

Remova a tag packaging do arquivo pom.xml:

<packaging>war</packaging>

Em seguida, adicione 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. 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. Certos recursos que o App Engine oferece prontos para uso, como os serviços Cron e Task Queue, precisam ser recriados manualmente e serão abordados em mais detalhes em módulos posteriores.

O app de exemplo não usa pacotes de serviços legados, mas os usuários desses apps podem consultar os seguintes guias:

Como você vai implantar no Cloud Run a partir de agora, 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 aplicativo

Neste ponto, você pode implantar manualmente seu app no Cloud Run diretamente do seu código-fonte. Essa é uma excelente opção que usa o Cloud Build em segundo plano para oferecer uma experiência de implantação prática. Vamos saber mais sobre implantações de origem nos próximos módulos.

Como alternativa, se você precisar de mais controle sobre a forma como seu app é implantado, defina um arquivo cloudbuild.yaml que mostre explicitamente as etapas de build pretendidas:

1. Definir um arquivo cloudbuild.yaml

Crie o seguinte arquivo cloudbuild.yaml no mesmo nível de pom.xml:

steps:
  # Test your build
  - name: maven:eclipse-temurin
    entrypoint: mvn
    args: ["test"]
  # Build with Jib
  - name: maven:eclipse-temurin
    entrypoint: mvn
    args: [ "compile", "com.google.cloud.tools:jib-maven-plugin:3.2.1:build", "-Dimage=northamerica-northeast1-docker.pkg.dev/PROJECT_ID/migration/visitors:jib"]
  # Deploy to Cloud Run
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: gcloud
    args: [ 'run', 'deploy', 'visitors', '--image', 'northamerica-northeast1-docker.pkg.dev/PROJECT_ID/migration/visitors:jib', '--region', 'northamerica-northeast1', '--allow-unauthenticated']

Depois de instruir o Cloud Build a seguir essas etapas, ele vai:

  1. Executar testes com ./mvnw test
  2. Crie, envie e marque sua imagem no Artifact Registry com Jib
  3. Implantar a imagem no Cloud Run com gcloud run deploy

Observe que ‘visitors' é fornecido ao Cloud Run como o nome de serviço desejado. A sinalização –allow-unauthenticated permite que os usuários acessem o app da Web sem exigir autenticação. Substitua PROJECT_ID pelo ID do seu projeto no arquivo cloudbuild.yaml .

Em seguida, adicione as seguintes vinculações de política do IAM para permitir que a conta de serviço do Cloud Build acesse o Artifact Registry:

export PROJECT_ID=$(gcloud config list --format 'value(core.project)')
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)" )

gcloud projects add-iam-policy-binding $PROJECT_ID \
--member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
--role=roles/run.admin \
--project=$PROJECT_ID
gcloud iam service-accounts add-iam-policy-binding $PROJECT_NUMBER-compute@developer.gserviceaccount.com \
--member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
--role roles/iam.serviceAccountUser --project=$PROJECT_ID

2. Executar o processo de build

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

Execute este comando:

gcloud builds submit

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 mostrado em java17-and-cloud-run/finish.

Pronto! Você migrou um app do App Engine em Java 8 para o Java 17 e o Cloud Run e agora tem uma compreensão mais clara do trabalho envolvido ao alternar e escolher entre opções de hospedagem.

6. Resumo/limpeza

Parabéns! Você fez upgrade, conteinerizou e migrou seu app. Isso 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 aplicativo de amostra no App Engine durante este tutorial, lembre-se de desativar o aplicativo para evitar cobranças. Quando quiser avançar para o próximo codelab, você poderá reativá-lo. Enquanto os aplicativos do App Engine estiverem desativados, eles não terão tráfego para gerar cobranças. No entanto, o uso do Datastore poderá ser faturado se exceder a cota sem custo financeiro. Por isso, 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

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

App Engine

Outras informações sobre a nuvem

Vídeos

Licença

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