Présentation de l'environnement d'exécution SaaS

L'environnement d'exécution SaaS vous permet de stocker, d'héberger, de gérer et de surveiller des applications Software as a Service (SaaS) sur Google Cloud. L'environnement d'exécution SaaS 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.

L'environnement d'exécution SaaS peut être utilisé de nombreuses manières par différents intervenants du pipeline SaaS. Si votre travail correspond à l'un de ces rôles, vous pouvez être intéressé par l'utilisation de l'environnement d'exécution SaaS :

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

L'environnement d'exécution SaaS offre les avantages suivants :

  • Simplifiez la gestion de vos services à grande échelle en automatisant les tâches de gestion des services (telles que le déploiement, les déploiements et la gestion des indicateurs de fonctionnalité) dans vos locataires SaaS.
  • Développez votre observabilité et votre contrôle en affinant vos mises à jour et vos versions sur des unités configurables pour gérer votre offre SaaS avec précision à grande échelle.
  • Assurez la cohérence de votre Google Cloud écosystème en gérant les services sur différents Google Cloud produits, 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 une efficacité et une réutilisabilité accrues.

Comment fonctionne l'environnement d'exécution SaaS ?

L'environnement d'exécution SaaS déploie des artefacts qui définissent votre offre SaaS. 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 apportées à votre offre via un processus de déploiement configurable.

Pour en savoir plus sur la nomenclature de l'environnement d'exécution SaaS, consultez le glossaire.

Préparer votre charge de travail pour l'environnement d'exécution SaaS

Avant de déployer votre offre SaaS, nous vous recommandons de déterminer l'arrangement idéal de votre offre SaaS dans l'écosystème de l'environnement d'exécution SaaS.

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

Une fois que vous avez déterminé la structure idéale de votre charge de travail sur l'environnement d'exécution SaaS, vous pouvez créer votre offre SaaS, vos genres d'unité, puis déployer vos unités à l'aide d'un déploiement.

Pour obtenir un exemple de configuration de l'environnement d'exécution SaaS, consultez le guide de démarrage rapide.

Comptes de service de l'environnement d'exécution SaaS

L'environnement d'exécution SaaS utilise une combinaison de comptes de service gérés par Google et gérés par l'utilisateur :

  • Compte de service de l'environnement d'exécution SaaS (géré par Google) : ce compte est créé automatiquement après la création de la première ressource d'offre SaaS. Il est géré par Google. Il effectue des actions en votre nom, par exemple en interagissant avec d'autres Google Cloud services 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. L'environnement d'exécution SaaS (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 disposer de plusieurs comptes de service d'activation. Nous vous recommandons d'avoir 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 Terraform empaqueté 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 SaaS.

Compte de service de l'environnement d'exécution SaaS (géré par Google)

Le compte de service de l'environnement d'exécution SaaS est un agent de service géré par Google qui est utilisé par l'environnement d'exécution SaaS pour effectuer des opérations dans votre projet.

Ce compte de service est provisionné automatiquement lorsque vous créez votre première ressource d'environnement d'exécution SaaS. Le compte de service de l'environnement d'exécution SaaS 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. L'environnement d'exécution SaaS (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 de 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 nécessite des autorisations suffisantes pour gérer les ressources définies dans votre configuration Terraform. Il a besoin au minimum des éléments suivants :

  • roles/iam.serviceAccountTokenCreator: permet au compte de service de générer des jetons pour l'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 a également besoin d'autorisations pour créer et gérer les ressources spécifiques Google Cloud utilisées par votre application.

Exemple :

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

Consultez la documentation de chaque Google Cloud ressource que vous utilisez dans votre 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 d'environnement d'exécution SaaS et d'activation. Il compile votre code Terraform et envoie l'artefact résultant à 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 (à l'aide de Docker build et Docker push directement, par exemple), vous n'avez pas besoin d'un compte de service de création d'artefacts distinct.

Au lieu de cela, vous devez 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 envoyer des artefacts à 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'utilisation de Developer Connect.
  • roles/developerconnect.readTokenAccessor : autorisations permettant d'obtenir le 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.
  • Toutes les autres autorisations requises par votre processus de compilation (par exemple, l'accès aux dépôts de code source).

Stratégies de déploiement

L'environnement d'exécution SaaS utilise plusieurs stratégies de déploiement pour gérer la mise à jour des unités de votre offre SaaS. Ces stratégies de déploiement suivent Google Cloud's approche pour le changement en appliquant des approches cohérentes au déploiement des modifications dans votre offre SaaS.

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 déployé à la fois, sans attente entre les emplacements. Les unités sont sélectionnées de manière arbitraire dans un emplacement, avec un maximum de 20 % 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.

  • Tout à la fois (simple) : tous les emplacements commencent à être déployés en même temps.

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

  • Progressif (graduel) : dans chaque emplacement, les unités sont déployées par lots statiques basés sur un pourcentage (par exemple, 1 %, 10 %, 20 %, 30 %, ~40 %) avec des temps de stabilisation entre les lots. Dans les emplacements, le déploiement progresse 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 avec plus d'un emplacement.

  • Progressif (emplacement unique) : 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 la détection des problèmes et limiter l'impact négatif des modifications de déploiement.

    Cette stratégie est adaptée aux offres SaaS fonctionnant dans un emplacement unique. Elle donne 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 genres de déploiement, consultez la section Créer un genre de déploiement.

Régionalisation de l'environnement d'exécution SaaS

Les ressources d'offre SaaS définissent l'emplacement où vos unités d'environnement d'exécution SaaS peuvent résider et comment vos déploiements sont gérés. Lorsque vous créez une offre SaaS, les régions que vous sélectionnez servent de source unique de vérité pour les régions compatibles de votre offre SaaS. Les régions que vous sélectionnez sont les régions disponibles que vous avez définies pour votre offre SaaS.

Lorsque vous utilisez l'environnement d'exécution SaaS via Google Cloud laconsole, il automatise la réplication des ressources que vous définissez dans votre offre SaaS entre les régions. Cela garantit la cohérence et la disponibilité de vos ressources d'environnement d'exécution SaaS dans toutes les régions disponibles que vous avez définies dans votre offre SaaS.

L'environnement d'exécution SaaS réplique les ressources suivantes :

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

Utiliser global comme région

L'inclusion de global en tant que région dans votre offre SaaS est généralement déconseillée pour les cibles de déploiement. L'environnement d'exécution SaaS utilise la région global pour propager les déploiements régionaux. Les déploiements régionaux ne peuvent pas s'exécuter 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 SaaS.

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

Réplication des ressources

L'environnement d'exécution SaaS gère la création et les mises à jour des ressources dans toutes les régions disponibles de votre offre SaaS.

Lorsque vous mettez à jour les régions disponibles de votre offre SaaS, l'environnement d'exécution SaaS gère la réplication :

  • Emplacements ajoutés : les ressources sont répliquées dans les emplacements nouvellement ajoutés.
  • Emplacements avec 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 valide Google Cloud . Il n'est pas nécessaire de les inclure dans les régions disponibles de votre offre SaaS.

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

    Cela nécessite la présence de ressources d'offre SaaS, de version et de genre d'unité dans toutes les régions définies dans votre offre SaaS, 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 SaaS.

Exemple de configuration des régions de l'environnement d'exécution SaaS

Nous avons fourni cet exemple pour illustrer le fonctionnement de la régionalisation lorsque vous utilisez l'environnement d'exécution SaaS avec la réplication de ressources gérée.

Par exemple, si vous souhaitez déployer votre offre SaaS 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 de vos régions d'environnement d'exécution SaaS se présentera comme suit :

  • Régions disponibles de l'offre SaaS : ['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 genre d'unité et de version : l'environnement d'exécution SaaS 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 de ressources automatisée. Vous devez tenir compte attentivement de vos exigences en matière de latence, de conformité et de résidence des données lorsque vous sélectionnez vos régions.

Étape suivante