Migrer de l'application Java Google App Engine vers Cloud Run avec Jib

1. Présentation

Cette série d'ateliers de programmation (tutoriels pratiques à suivre à votre rythme) est destinée à aider les développeurs Java Google App Engine (standard) à moderniser leurs applications en les guidant tout au long d'une série de migrations. En suivant ces étapes, vous pouvez rendre votre application plus portable et choisir de la conteneuriser pour Cloud Run, le service d'hébergement de conteneurs de Google Cloud étroitement lié à App Engine, ainsi que pour d'autres services d'hébergement de conteneurs.

Ce tutoriel explique comment conteneuriser une application App Engine afin de la déployer sur le service entièrement géré Cloud Run en utilisant Jib. Avec Jib, vous pouvez créer des images Docker, une plate-forme bien connue du secteur pour le développement, l'hébergement et l'exécution d'applications en conteneur.

En plus de vous apprendre les étapes nécessaires pour passer d'App Engine à Cloud Run, vous découvrirez également comment mettre à niveau une application App Engine Java 8 vers Java 17.

Si votre application utilise intensivement les anciens services groupés App Engine ou d'autres fonctionnalités App Engine, nous vous recommandons de migrer depuis ces services groupés ou de remplacer ces fonctionnalités avant de passer à Cloud Run. Si vous avez besoin de plus de temps pour étudier vos options de migration ou si vous souhaitez continuer à utiliser les anciens services groupés pour le moment, vous pouvez continuer à accéder aux services groupés App Engine pour Java 11/17 lorsque vous passez à un environnement d'exécution plus récent. Lorsque votre application sera plus portable, revenez à cet atelier de programmation pour apprendre à appliquer les instructions à votre application.

Vous apprendrez à

  • Utiliser Cloud Shell
  • Activer les API Cloud Run, Artifact Registry et Cloud Build
  • Conteneuriser votre application à l'aide de Jib et Cloud Build
  • Déployer vos images de conteneur dans Cloud Run

Prérequis

Enquête

Comment allez-vous utiliser ce tutoriel ?

Je vais le lire uniquement Je vais le lire et effectuer les exercices

Quel est votre niveau d'expérience avec Java ?

Débutant Intermédiaire Expert

Quel est votre niveau d'expérience avec les services Google Cloud ?

Débutant Intermédiaire Expert

2. Arrière-plan

Les systèmes PaaS (Platform as a Service) tels qu'App Engine et Cloud Functions offrent de nombreux avantages pour vos équipes et vos applications, par exemple en permettant aux administrateurs système et aux équipes DevOps de se concentrer sur la création de solutions. Avec les plates-formes sans serveur, votre application peut évoluer automatiquement en fonction de vos besoins, voire même jusqu'à s'interrompre entièrement pour ne plus générer aucuns frais avec la facturation à l'utilisation. Elle peut également être rédigée dans de nombreux langages de développement courants.

La flexibilité des conteneurs est un autre atout majeur. Les conteneurs vous offrent le meilleur des deux mondes : la commodité de l'informatique sans serveur et la flexibilité des conteneurs. Vous pouvez choisir n'importe quel langage, n'importe quelle bibliothèque et n'importe quels binaires. C'est tout l'intérêt de Cloud Run.

Apprendre à utiliser Cloud Run dépasse le cadre de cet atelier de programmation. Pour cela, consultez la documentation de Cloud Run. L'objectif ici est de vous familiariser avec la conteneurisation de votre application App Engine pour Cloud Run (ou d'autres services hébergés dans des conteneurs). Avant de continuer, vous devez comprendre que votre expérience utilisateur sera légèrement différente.

Dans cet atelier de programmation, vous allez apprendre à créer et à déployer des conteneurs. Vous allez apprendre à effectuer les opérations suivantes :

  • Conteneuriser votre application avec Jib
  • Migrer depuis la configuration App Engine
  • et, éventuellement, définir des étapes de compilation pour Cloud Build.

Cela impliquera d'abandonner certaines fonctionnalités spécifiques à App Engine. Si vous ne souhaitez pas fonctionner de cette manière, vous pouvez toujours passer à un environnement d'exécution Java 11/17 tout en conservant vos applications sur App Engine.

3. Configuration/Préparation

1. Configurer le projet

Pour ce tutoriel, vous utiliserez un exemple d'application du dépôt appengine-java-migration-samples sur un tout nouveau projet. Assurez-vous que le projet dispose d'un compte de facturation actif.

Si vous prévoyez de migrer une application App Engine existante vers Cloud Run, vous pouvez utiliser cette application pour suivre le tutoriel.

Exécutez la commande suivante pour activer les API nécessaires pour votre projet :

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

2. Obtenir un exemple d'application de référence

Clonez l'exemple d'application sur votre propre machine ou dans Cloud Shell, puis accédez au dossier baseline.

L'exemple est une application Datastore basée sur Java 8 et Servlet, destinée à être déployée sur App Engine. Suivez les instructions du fichier README pour préparer cette application au déploiement App Engine.

3. (Facultatif) Déployer l'application de référence

La procédure suivante n'est nécessaire que si vous souhaitez vérifier que l'application fonctionne sur App Engine avant de migrer vers Cloud Run.

Suivez les étapes décrites dans le fichier README.md :

  1. Installer/Se familiariser à nouveau avec la CLI gcloud
  2. Initialisez la gcloud CLI pour votre projet avec gcloud init.
  3. Créez le projet App Engine avec gcloud app create.
  4. Déployer l'exemple d'application sur App Engine
./mvnw package appengine:deploy -Dapp.projectId=$PROJECT_ID
  1. Vérifier que l'application s'exécute sans problème sur App Engine

4. Créer un dépôt Artifact Registry

Une fois votre application conteneurisée, vous aurez besoin d'un emplacement pour transférer et stocker vos images. Sur Google Cloud, la méthode recommandée consiste à utiliser Artifact Registry.

Créez le dépôt nommé migration avec gcloud comme suit :

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

Notez que ce dépôt utilise le type de format docker, mais il existe plusieurs types de dépôts.

À ce stade, vous disposez de votre application App Engine de référence et votre projet Google Cloud est prêt à la migrer vers Cloud Run.

4. Modifier les fichiers d'application

Si votre application utilise intensivement les anciens services groupés, la configuration ou d'autres fonctionnalités propres à App Engine, nous vous recommandons de continuer à accéder à ces services tout en passant au nouvel environnement d'exécution. Cet atelier de programmation présente un chemin de migration pour les applications qui utilisent déjà des services autonomes ou qui peuvent être refactorisées de manière réaliste pour le faire.

1. Mettre à niveau vers Java 17

Si votre application est sur Java 8, envisagez de passer à une version LTS ultérieure, comme la version 11 ou 17, pour bénéficier des mises à jour de sécurité et accéder aux nouvelles fonctionnalités du langage.

Commencez par mettre à jour les propriétés de votre pom.xml pour inclure les éléments suivants :

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

Cela définira la version du projet sur 17, informera le plug-in du compilateur que vous souhaitez accéder aux fonctionnalités du langage Java 17 et que vous souhaitez que les classes compilées soient compatibles avec la JVM Java 17.

2. Inclure un serveur Web

Il existe un certain nombre de différences entre App Engine et Cloud Run à prendre en compte lorsque vous passez de l'un à l'autre. Une différence est que, alors que l'environnement d'exécution Java 8 d'App Engine fournissait et gérait un serveur Jetty pour les applications qu'il hébergeait, Cloud Run ne le fait pas. Nous allons utiliser Spring Boot pour obtenir un serveur Web et un conteneur de servlet.

Ajoutez les dépendances suivantes :

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

Spring Boot intègre un serveur Tomcat par défaut, mais cet exemple exclut cet artefact et s'en tient à Jetty pour minimiser les différences de comportement par défaut après la migration. Nous pouvons également configurer la version de Jetty pour qu'elle corresponde à celle fournie par 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. Configuration de Spring Boot

Bien que Spring Boot puisse réutiliser vos servlets sans modification, il nécessitera une certaine configuration pour la détectabilité.

Créez la classe MigratedServletApplication.java suivante dans le package 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);
    }
}

Notez que cela inclut l'annotation @ServletComponentScan, qui recherchera (dans le package actuel par défaut) tous les @WebServlets et les rendra disponibles comme prévu.

4. Empaqueter l'application en tant que fichier JAR

Bien qu'il soit possible de conteneuriser votre application avec Jib à partir d'un fichier WAR, cela devient plus facile si vous packagez votre application en tant que fichier JAR exécutable. Cela ne nécessitera pas beaucoup de configuration, en particulier pour les projets utilisant Maven comme outil de compilation, car l'empaquetage jar est le comportement par défaut.

Supprimez la balise packaging dans le fichier pom.xml :

<packaging>war</packaging>

Ajoutez ensuite 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. Migrer depuis la configuration, les services et les dépendances App Engine

Comme indiqué au début de l'atelier de programmation, Cloud Run et App Engine sont conçus pour offrir des expériences utilisateur différentes. Certaines fonctionnalités proposées par App Engine, comme les services Cron et Task Queue, doivent être recréées manuellement. Elles seront abordées plus en détail dans les modules suivants.

L'exemple d'application n'utilise pas les anciens services groupés, mais les utilisateurs dont les applications les utilisent peuvent consulter les guides suivants :

Étant donné que vous allez désormais effectuer le déploiement sur Cloud Run, vous pouvez supprimer appengine-maven-plugin :

<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. Conteneuriser l'application

À ce stade, vous pouvez déployer manuellement votre application sur Cloud Run directement à partir de votre code source. Il s'agit d'une excellente option qui utilise Cloud Build en arrière-plan pour offrir une expérience de déploiement sans intervention manuelle. Nous aborderons les déploiements de code source plus en détail dans les modules suivants.

Si vous avez besoin de mieux contrôler la façon dont votre application est déployée, vous pouvez le faire en définissant un fichier cloudbuild.yaml qui décrit explicitement les étapes de compilation souhaitées :

1. Définir un fichier cloudbuild.yaml

Créez le fichier cloudbuild.yaml suivant au même niveau que le fichier 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']

Une fois que nous aurons indiqué à Cloud Build de suivre ces étapes, il effectuera les actions suivantes :

  1. Exécuter vos tests avec ./mvnw test
  2. Créez votre image, transférez-la et ajoutez-lui un tag dans Artifact Registry avec Jib.
  3. Déployer votre image sur Cloud Run avec gcloud run deploy

Notez que ‘visitors' est fourni à Cloud Run comme nom de service souhaité. L'option –allow-unauthenticated permet aux utilisateurs d'accéder à l'application Web sans authentification. Veillez à remplacer PROJECT_ID par l'ID de votre projet dans le fichier cloudbuild.yaml.

Ensuite, ajoutez les liaisons de stratégie IAM suivantes pour autoriser le compte de service Cloud Build à accéder à 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. Exécuter le processus de compilation

Maintenant que vous avez informé Cloud Build des étapes de compilation souhaitées, vous êtes prêt pour un déploiement en un clic.

Exécutez la commande suivante :

gcloud builds submit

Une fois le processus terminé, votre image de conteneur est créée, stockée dans Artifact Registry et déployée sur Cloud Run.

À la fin de cet atelier de programmation, votre application devrait ressembler à celle de java17-and-cloud-run/finish.

Et voilà ! Vous avez migré une application App Engine Java 8 vers Java 17 et Cloud Run. Vous comprenez désormais mieux le travail à effectuer lors du changement et du choix entre les options d'hébergement.

6. Résumé/Nettoyage

Félicitations ! Vous avez mis à niveau, conteneurisé et migré votre application. Ce tutoriel est désormais terminé.

À présent que vous pouvez déployer avec Cloud Build, l'étape suivante consiste à en savoir plus sur les fonctionnalités de sécurité de la chaîne d'approvisionnement logicielle et de CI/CD qui sont à votre portée :

Facultatif : Nettoyer et/ou désactiver le service

Si vous avez déployé l'application exemple sur App Engine au cours de ce tutoriel, n'oubliez pas de désactiver l'application pour éviter d'encourir des frais. Lorsque vous serez prêt à passer au prochain atelier de programmation, vous pourrez le réactiver. Les applications App Engine étant désactivées, elles ne reçoivent aucun trafic et ne génèrent aucuns frais. Toutefois, l'utilisation de Datastore peut être facturable si elle dépasse son quota sans frais. Supprimez donc suffisamment d'éléments pour rester dans la limite.

En revanche, si vous ne souhaitez pas poursuivre vos migrations et que vous souhaitez tout supprimer complètement, vous pouvez supprimer votre service ou arrêter le projet complètement.

7. Ressources supplémentaires

Problèmes/commentaires concernant le module de migration App Engine en atelier de programmation

Si vous rencontrez des problèmes avec cet atelier de programmation, commencez par faire une recherche avant de les signaler. Liens vers la recherche et la création d'un signalement :

Ressources de migration

Ressources en ligne

Vous trouverez ci-dessous des ressources en ligne qui peuvent être utiles pour ce tutoriel :

App Engine

Informations sur les autres clouds

Vidéos

Licence

Ce document est publié sous une licence Creative Commons Attribution 2.0 Generic.