Choisir une stratégie conforme à l'OCI

Cette page présente le processus de compilation Cloud Foundry à partir duquel vous devez migrer et fournit une description des différentes manières de migrer depuis celui-ci vers un processus qui crée des conteneurs conformes à la norme OCI.

Présentation du processus de compilation de Cloud Foundry

Lorsqu'une application est transférée vers Cloud Foundry, elle passe par une étape de compilation où le code source est compilé par les packs de création Cloud Foundry v2.

Le résultat d'un processus de compilation Cloud Foundry crée une archive exécutable appelée droplet. Les Droplets ne sont pas directement compatibles avec la spécification OCI (Open Container Initiative) pour l'exécution de conteneurs sur Cloud Run.

Lors de la migration d'applications depuis Cloud Foundry vers Cloud Run, vous devez modifier le processus de compilation de l'application pour générer des images OCI standards dans l'industrie (parfois appelées images Docker).

Schéma décrivant la création des Droplets Cloud Foundry

Stratégies pour obtenir des images conformes à la norme OCI

Vous pouvez choisir parmi trois stratégies de migration pour créer des conteneurs compatibles OCI:

Modifier une application Cloud Foundry (migration Lift and Shift)

Les principaux composants de l'écosystème Cloud Foundry (packs de création v2, cellules souches, etc.) sont Open Source. Cela signifie que vous pouvez recréer le processus de conteneurisation d'applications en suivant le guide pour "Dockeriser" les composants de base pour créer une image conforme à l'OCI.

Avantages :

  • Il nécessite le moins de refactorisation et de personnalisation d'application.
  • Le processus est reproductible pour toutes les instances d'applications.

Inconvénients :

  • Le pipeline permettant de créer des conteneurs d'applications est autogéré.
  • Les anciens composants Cloud Foundry présentent une maintenance et une assistance réduites.
  • Les coûts récurrents de maintenance de la sécurité sont les suivants :
    • Recompilez régulièrement les composants de compilation pour vous assurer d'obtenir des correctifs de sécurité.
    • Recompiler régulièrement les applications "dockerizées" pour prendre en compte les mises à jour de sécurité des composants de compilation recompilés.

Utiliser des packs de création cloud natifs

La spécification Cloud Native Buildpacks (CNB) a été créée pour moderniser et unifier l'écosystème des packs de création. Les compilateurs compatibles avec la spécification CNB respectent les normes ouvertes et créent des images conformes à l'OCI. Voici trois fournisseurs CNB courants:

Avantages :

  • Les responsables de compilation et les fournisseurs de plate-forme sont responsables de la maintenance du buildpack.
  • Les packs de création permettent de redéfinir les conteneurs sur de nouvelles images pour des mises à jour de sécurité rapides sans reconstruire les conteneurs d'applications.
  • Les packs de création génèrent des images OCI portables.
  • Le projet CNB est en cours d'introduction dans la Cloud Native Computing Foundation (CNCF) et dispose d'une communauté active de responsables et de contributeurs.

Inconvénients :

  • Des écarts de fonctionnalités et de configuration entre les buildpacks v2 et v3.
  • Les frameworks et les intégrations installés en votre nom dans les packs de création Java v2 peuvent ne pas être disponibles dans le buildpack Java CNB.

Utiliser des fichiers Dockerfile autogérés

Vous pouvez créer des fichiers Dockerfile complètement nouveaux pour conteneuriser votre application. Consultez la section Créer des conteneurs pour en savoir plus sur les images de conteneurs acceptées par Cloud Run.

Avantages :

  • Offre la plus grande flexibilité dans la conception de vos applications.
  • Exploitez les outils de compilation et les stratégies de création de conteneurs existants de votre entreprise.

Inconvénients :

  • La "dockerization" et la configuration personnalisée doivent être effectuées pour chaque application, ce qui peut prendre beaucoup de temps avec le débogage et les réécritures.
  • Il est difficile de standardiser les mises en œuvre entre plusieurs équipes.
  • La correction des images nécessite une recompilation et un redéploiement complets.

Recommandations

Les équipes limitées en ressources et qui cherchent à déplacer autant d'applications que possible doivent d'abord envisager la stratégie Lift and Shift pour modifier Cloud Foundry. Une fois les applications modernisées pour devenir des images conformes à la norme OCI, nous vous recommandons d'utiliser des buildpacks cloud natifs ou des fichiers Dockerfile autogérés.

Les équipes qui sont prêtes à migrer immédiatement doivent essayer les packs de création cloud natifs, puis passer à des fichiers Dockerfile autogérés s'ils ont besoin d'un niveau de contrôle élevé sur leur environnement.

Étape suivante