Présentation d'App Lifecycle Manager

App Lifecycle Manager (anciennement SaaS Runtime) vous permet de stocker, d'héberger, de gérer et de surveiller des applications SaaS (Software as a Service) sur Google Cloud. App Lifecycle Manager gère les déploiements Terraform à grande échelle, ce qui vous permet de gérer à la fois votre application SaaS et l'infrastructure sur laquelle elle s'exécute.

App Lifecycle Manager peut être utilisé de différentes manières par divers intervenants du pipeline SaaS. Si votre travail correspond à l'un de ces rôles, vous pourriez être intéressé par l'utilisation d'App Lifecycle Manager :

  • Administrateur de plate-forme
  • Développeur d'applications
  • Architecte
  • Administrateur de la conformité
  • Ingénieur de plate-forme
  • Opérations financières

App Lifecycle Manager offre les avantages suivants :

  • Simplifiez la gestion de vos services à grande échelle en automatisant les tâches de gestion des services (comme le déploiement, les lancements et la gestion des flags de fonctionnalités) sur l'ensemble de vos locataires SaaS.
  • Améliorez votre observabilité et votre contrôle en affinant vos mises à jour et vos versions sur des unités configurables afin de gérer votre offre d'applications avec précision et à grande échelle.
  • Assurez la cohérence de votre écosystème Google Cloud en gérant les services sur différents produits Google Cloud , y compris Google Cloud, Google Distributed Cloud, Billing, Observability et Resource Manager.
  • Utilisez une architecture flexible et basée sur des modèles qui favorise les mises à jour et les déploiements de groupes basés sur des unités pour améliorer l'efficacité et la réutilisabilité.

Comment fonctionne App Lifecycle Manager ?

App Lifecycle Manager déploie des artefacts qui définissent votre offre d'application. Ces artefacts doivent avoir une configuration Terraform. Le déploiement est organisé en unités distinctes qui peuvent être mises à jour avec des versions contenant des modifications de votre offre via un déploiement configurable.

Pour en savoir plus sur la nomenclature d'App Lifecycle Manager, consultez le glossaire.

Préparer votre charge de travail pour App Lifecycle Manager

Avant de déployer votre offre d'application, nous vous recommandons de déterminer l'organisation idéale de votre offre d'application dans l'écosystème App Lifecycle Manager.

Organisez les parties de votre offre d'application qui doivent être mises à jour ou modifiées ensemble dans des configurations Terraform distinctes. Lorsque vous planifiez votre offre d'application, utilisez des types d'unités pour chaque regroupement de votre offre d'application.

Une fois que vous avez défini la structure idéale pour votre charge de travail dans App Lifecycle Manager, vous pouvez créer votre offre d'application, vos types d'unités, puis déployer vos unités à l'aide d'un déploiement.

Pour obtenir un exemple de configuration d'App Lifecycle Manager, consultez le guide de démarrage rapide.

Utiliser des modèles composites avec App Lifecycle Manager

Vous pouvez utiliser des modèles composites via Application Design Center pour définir l'infrastructure de vos offres d'applications App Lifecycle Manager.

Une fois que vous avez associé un modèle composite à votre offre d'application, App Lifecycle Manager renseigne les types d'unités définis dans votre modèle. Cela vous permet de déployer des unités en fonction de la structure et des ressources définies dans votre modèle composite.

Vous pouvez modifier vos modèles composites dans App Design Center et voir les modifications reflétées dans vos offres d'applications App Lifecycle Manager.

Pour en savoir plus sur les modèles composites, consultez la documentation Concevoir des modèles composites. Pour en savoir plus sur l'association de modèles composites à des offres App Lifecycle Manager, consultez Modéliser et empaqueter des unités de déploiement.

Comptes de service App Lifecycle Manager

App Lifecycle Manager utilise une combinaison de comptes de service gérés par Google et par l'utilisateur :

  • Compte de service App Lifecycle Manager (géré par Google) : ce compte est créé automatiquement après la création de la première ressource d'offre d'application. Il est géré par Google. Il effectue des actions en votre nom, comme interagir avec d'autres services Google Cloud lors du provisionnement des unités.

  • Compte de service d'activation (géré par l'utilisateur) : vous créez et gérez ce compte de service. App Lifecycle Manager (via Infrastructure Manager) utilise ce compte pour exécuter vos configurations Terraform lors du provisionnement ou de la mise à jour des unités. Ce compte sert d'identité pour créer et gérer les ressources définies dans votre Terraform. Les autorisations du compte de service d'activation sont directement liées aux ressources gérées par votre configuration Terraform.

    Vous pouvez avoir plusieurs comptes de service d'activation. Nous vous recommandons de disposer d'un compte de service d'activation pour chaque locataire.

  • Facultatif : Compte de service de création d'artefacts (géré par l'utilisateur) : ce compte de service est utilisé pour créer et importer votre package Terraform dans des artefacts OCI. Il s'agit souvent d'un compte de service Cloud Build, mais il peut s'agir de n'importe quel compte de service disposant des autorisations appropriées pour votre offre d'application.

Compte de service App Lifecycle Manager (géré par Google)

Le compte de service App Lifecycle Manager est un agent de service géré par Google, utilisé par App Lifecycle Manager pour effectuer des opérations dans votre projet.

Ce compte de service est automatiquement provisionné lorsque vous créez votre première ressource App Lifecycle Manager. Le compte de service App Lifecycle Manager est créé au format suivant :

  service-PROJECT_NUMBER@gcp-sa-saasservicemgmt.iam.gserviceaccount.com

Remplacez :

  • PROJECT_NUMBER : numéro de votre projet.

Compte de service d'activation (géré par l'utilisateur)

Le compte de service d'activation est un compte de service géré par l'utilisateur que vous devez créer. App Lifecycle Manager (via Infra Manager) utilise ce compte de service pour exécuter vos configurations Terraform. Il s'agit de l'identité qui crée, modifie et supprime les ressources définies dans votre Terraform.

Vous êtes responsable de la création de ce compte de service dans votre projet ou dans votre projet locataire.

Variables d'entrée du compte de service d'activation

Lorsque vous créez une unité, vous devez fournir le compte de service d'activation en tant que variable d'entrée de paire clé-valeur pour la configuration Terraform :

  • Nom : actuation_sa
  • Type de variable : String

  • Valeur de la variable : adresse e-mail du compte de service d'activation :

    my-actuation-sa@my-identifier.iam.gserviceaccount.com

Autorisations requises

Le compte de service d'activation doit disposer des autorisations suffisantes pour gérer les ressources définies dans votre configuration Terraform. Il doit au moins inclure les éléments suivants :

  • roles/iam.serviceAccountTokenCreator : permet au compte de service de générer des jetons d'authentification.
  • roles/config.admin : accorde un contrôle total sur les ressources Infra Manager.
  • roles/storage.admin : accorde un contrôle total sur Cloud Storage.

Le compte de service d'activation doit également disposer des autorisations nécessaires pour créer et gérer les ressources Google Cloud spécifiques utilisées par votre application.

Exemple :

  • Si votre Terraform crée des clusters Google Kubernetes Engine (GKE), le compte de service doit disposer des rôles GKE appropriés (roles/container.admin, par exemple).
  • Si votre Terraform crée des instances Compute Engine, le compte de service doit disposer du rôle roles/compute.admin.
  • Si votre Terraform crée des instances Cloud SQL, le compte de service doit disposer des rôles Cloud SQL appropriés (roles/cloudsql.admin, par exemple).

Consultez la documentation de chaque ressource Google Cloud que vous utilisez dans Terraform pour déterminer les autorisations nécessaires. Accordez le moindre privilège nécessaire au fonctionnement de votre application.

Compte de service de création d'artefacts (géré par l'utilisateur)

Le compte de service de création d'artefacts est un compte de service géré par l'utilisateur que vous créez pour utiliser un système de compilation (tel que Cloud Build) afin d'empaqueter et d'importer vos artefacts Terraform dans Artifact Registry.

Ce compte de service est distinct des comptes de service App Lifecycle Manager et d'activation. Il crée votre code Terraform et transfère l'artefact obtenu vers Artifact Registry. Il s'agit souvent du compte de service Cloud Build.

Création manuelle d'artefacts

Si vous créez et importez manuellement vos artefacts Terraform (en utilisant directement Docker build et Docker push, par exemple), vous n'avez pas besoin d'un compte de service distinct pour la création d'artefacts.

Vous devez plutôt vous authentifier à l'aide de vos propres identifiants ou d'un compte de service disposant des autorisations Artifact Registry nécessaires.

Autorisations requises

Si vous utilisez Cloud Build, le compte de service Cloud Build a généralement besoin des rôles suivants :

  • roles/artifactregistry.writer : pour transférer des artefacts vers Artifact Registry.
  • roles/artifactregistry.repoAdmin : pour gérer le dépôt Artifact Registry.
  • roles/storage.admin : pour gérer les buckets Cloud Storage.
  • roles/developerconnect.admin : autorisations d'utiliser Developer Connect.
  • roles/developerconnect.readTokenAccessor : autorisations permettant d'obtenir un jeton de lecture Developer Connect.
  • roles/logging.logWriter : autorisations d'écriture des journaux.
  • Si vous déployez votre configuration Terraform à l'aide de Developer Connect : roles/cloudbuild.builds.builder : pour exécuter des builds.
  • Toute autre autorisation requise par votre processus de compilation (par exemple, l'accès aux dépôts de code source).

Stratégies de déploiement

App Lifecycle Manager utilise plusieurs stratégies de déploiement pour gérer la mise à jour des unités de votre offre d'application. Ces stratégies de déploiement suivent l'approche deGoogle Clouden matière de changement en appliquant des approches cohérentes au déploiement des modifications dans votre offre d'applications.

Utilisez des stratégies de déploiement pour minimiser les impacts négatifs pour les clients et isoler les problèmes dans des domaines de défaillance logiques et physiques individuels. Définissez vos stratégies de déploiement en créant un genre de déploiement spécifiant l'une des stratégies de déploiement suivantes :

  • Un emplacement à la fois (simple) : un emplacement est mis à jour à la fois, sans délai d'attente entre les emplacements. Les unités sont sélectionnées arbitrairement dans un emplacement, avec un maximum de 5% des unités de l'emplacement mises à jour à un moment donné.

    Cette stratégie est recommandée pour les environnements de développement et les scénarios d'urgence.

  • Tous en même temps (simple) : tous les emplacements commencent à être mis à jour en même temps.

    Cette stratégie est recommandée pour les environnements de développement et les scénarios d'urgence.

  • Progressive (graduelle) : dans chaque emplacement, les unités sont mises à jour par lots statiques basés sur un pourcentage (par exemple, 1%, 10%, 20%, 30%, ~40%) avec des temps de stabilisation entre les lots. Le déploiement progresse d'un emplacement à l'autre avec une augmentation exponentielle du nombre d'emplacements simultanés (par exemple, un emplacement, puis deux, puis quatre) avec des temps de stabilisation (18 heures, par exemple) entre les vagues. Les unités d'un emplacement sont sélectionnées de manière aléatoire.

    Cette stratégie est conçue pour permettre des déploiements sécurisés et prévisibles dans plusieurs emplacements. Elle commence par un faible encombrement et s'étend progressivement à mesure que la confiance grandit. Cette stratégie est recommandée dans les environnements de production comportant plusieurs emplacements.

  • Progressif (un seul emplacement) : les unités sont mises à jour par lots statiques basés sur un pourcentage (par exemple, 1%, 10%, 20%, 30%, ~40%) avec des temps de stabilisation plus longs (18 heures, par exemple) entre les lots pour laisser suffisamment de temps pour détecter les problèmes et limiter l'impact négatif des modifications de déploiement.

    Cette stratégie est adaptée aux offres d'applications fonctionnant dans un emplacement unique, en donnant la priorité à la sécurité et à la prudence. Nous recommandons cette stratégie dans les environnements de production avec un seul emplacement.

Pour en savoir plus sur la création de types de déploiement, consultez Créer un type de déploiement.

Régionalisation d'App Lifecycle Manager

Les ressources d'offre d'application définissent où vos unités App Lifecycle Manager peuvent résider et comment vos déploiements sont gérés. Lorsque vous créez une offre d'application, les régions que vous sélectionnez servent de source unique de vérité pour les régions prises en charge par votre offre d'application. Les régions que vous sélectionnez sont les régions disponibles que vous avez définies pour votre offre d'application.

Lorsque vous utilisez App Lifecycle Manager via la console Google Cloud , App Lifecycle Manager automatise la réplication des ressources que vous définissez dans votre offre d'application dans plusieurs régions. Cela garantit la cohérence et la disponibilité de vos ressources App Lifecycle Manager dans toutes les régions disponibles que vous avez définies dans votre offre d'application.

App Lifecycle Manager réplique les ressources suivantes :

  • Offre d'applications (Saas)
  • Genre d'unité (UnitKind)
  • Version (Release)

Utiliser global comme région

Il n'est généralement pas recommandé d'inclure global en tant que région dans votre offre d'application pour les cibles de déploiement. App Lifecycle Manager utilise la région global pour propager les déploiements régionaux. Les déploiements régionaux ne peuvent pas être exécutés dans la région global.

Régionalisation du déploiement

Les emplacements compatibles avec les déploiements sont déterminés par les régions de premier niveau définies dans les régions disponibles de votre offre d'application.

Les déploiements lisent la liste des régions disponibles à partir de l'offre d'application associée.

Réplication des ressources

App Lifecycle Manager gère la création et les mises à jour des ressources dans toutes les régions disponibles de votre offre d'application.

Lorsque vous mettez à jour les régions disponibles de votre offre d'application, App Lifecycle Manager gère la réplication :

  • Emplacements ajoutés : les ressources sont répliquées dans les emplacements nouvellement ajoutés.
  • Emplacements contenant d'anciennes copies : le contenu est mis à jour.

Emplacements Artifact Registry et Developer Connect

Les emplacements de votre dépôt Artifact Registry et de votre instance Developer Connect sont soumis à des exigences spécifiques :

  • La région de votre dépôt Artifact Registry et de votre instance Developer Connect peut être n'importe quelle région Google Cloud valide. Il n'est pas nécessaire de les inclure dans les régions disponibles de votre offre d'application.

  • La région de votre dépôt Artifact Registry doit correspondre à celle de votre instance Developer Connect.

    Cela nécessite la présence de ressources de type offre, version et unité d'application dans toutes les régions définies dans votre offre d'application, même si Artifact Registry et Developer Connect résident dans une seule région (potentiellement différente).

  • Les unités ne peuvent être créées que dans les régions spécifiées dans votre offre d'application.

Exemple de configuration des régions App Lifecycle Manager

Nous avons fourni cet exemple pour illustrer le fonctionnement de la régionalisation lorsque vous utilisez App Lifecycle Manager avec la réplication des ressources gérées.

Par exemple, si vous souhaitez déployer votre offre d'application dans us-central1 et europe-west4, tout en hébergeant votre dépôt Artifact Registry et votre instance Developer Connect dans us-east1, l'infrastructure des régions App Lifecycle Manager ressemblerait à ceci :

  • Régions où l'application est disponible : ['us-central1', 'europe-west4']
  • Région du dépôt Artifact Registry : us-east1
  • Région de l'instance Developer Connect : us-east1
  • Ressources de type d'unité et de version : App Lifecycle Manager gère la création et les mises à jour de ces ressources dans les régions global, us-central1 et europe-west4.
  • Unités : les unités peuvent être créées dans us-central1 ou europe-west4.

Cette configuration vous permet de gérer vos déploiements dans deux régions tout en centralisant la gestion de vos artefacts dans une troisième région distincte, avec une réplication automatisée des ressources. Vous devez tenir compte de vos exigences de latence, de conformité et de résidence des données lorsque vous sélectionnez vos régions.

Étapes suivantes