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 différentes manières par divers acteurs du pipeline SaaS. Si votre travail correspond à l'un de ces rôles, vous pouvez utiliser SaaS Runtime :

  • 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 (comme le déploiement, les déploiements progressifs et la gestion des flags de fonctionnalité) pour vos locataires SaaS.
  • Améliorez 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 écosystème Google Cloud en gérant les services dans différents produits Google Cloud , y compris Google CloudGoogle Distributed Cloud, la facturation, l'observabilité 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 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 disposer d'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 SaaS Runtime.

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 pour votre charge de travail sur SaaS Runtime, vous pouvez créer votre offre SaaS et vos types d'unités, 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 d'exécution SaaS

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

  • Compte de service 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, comme interagir avec d'autres services Google Cloud lors du provisionnement des unités.

  • Compte de service d'actionnement (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 fichier Terraform. Les autorisations du compte de service d'actionnement sont directement liées aux ressources que votre configuration Terraform gère.

    Vous pouvez disposer de plusieurs comptes de service d'actionnement. Nous vous recommandons d'avoir un compte de service d'actionnement 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 SaaS.

Compte de service 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 et utilisé par l'environnement d'exécution SaaS pour effectuer des opérations dans votre projet.

Ce compte de service est automatiquement provisionné lorsque vous créez votre première ressource SaaS Runtime. 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'actionnement 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 fichier Terraform.

Il vous incombe de créer 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'actionnement 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'actionnement :

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

Autorisations requises

Le compte de service d'actionnement doit disposer des autorisations suffisantes pour gérer les ressources définies dans votre configuration Terraform. Pour effectuer cette opération, vous devez disposer au minimum des autorisations suivantes :

  • 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 le contrôle total de Cloud Storage.

Le compte de service d'actionnement 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 configuration 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 fichier Terraform crée des instances Compute Engine, le compte de service doit disposer du rôle roles/compute.admin.
  • Si votre fichier 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 d'exécution SaaS et d'activation. Il crée 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 distinct pour la création d'artefacts.

À la place, 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 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 permettant d'utiliser Developer Connect.
  • roles/developerconnect.readTokenAccessor : autorisations permettant d'obtenir le jeton de lecture Developer Connect.
  • roles/logging.logWriter : autorisations permettant d'écrire des journaux.
  • Si vous déployez votre configuration Terraform à l'aide de Developer Connect : roles/cloudbuild.builds.builder : pour exécuter des compilations.
  • 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 façon dont les unités de votre offre SaaS sont mises à jour. Ces stratégies de déploiement suivent l'approche deGoogle Cloudconcernant 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 qui spécifie l'une des stratégies de déploiement suivantes :

  • Un emplacement à la fois (simple) : un emplacement est déployé à la fois, sans délai d'attente entre les emplacements. Les unités sont sélectionnées de manière arbitraire dans un établissement, avec un maximum de 20 % des unités de l'établissement 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 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.

  • Progressive (graduelle) : dans chaque emplacement, les unités sont déployées par lots statiques basés sur des pourcentages (par exemple, 1 %, 10 %, 20 %, 30 %, ~40 %) avec des temps de stabilisation entre les lots. Le déploiement progresse dans les différents lieux avec une augmentation exponentielle du nombre de lieux simultanés (par exemple, un lieu, 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 plusieurs emplacements.

  • Progressif (un seul emplacement) : les unités sont mises à jour par lots statiques basés sur des pourcentages (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 du 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 établissement.

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

Régionalisation de SaaS Runtime

Les ressources SaaS Offering définissent 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 d'informations 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 la console Google Cloud , il automatise la réplication des ressources que vous définissez dans votre offre SaaS dans 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.

SaaS Runtime réplique les ressources suivantes :

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

Utiliser global comme région

Il est généralement déconseillé d'inclure global en tant que région dans votre offre SaaS 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 être exécutés dans la région global.

Régionalisation du déploiement

Les zones géographiques compatibles avec les déploiements sont déterminées 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 la mise à jour des ressources pour 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 :

  • Zones géographiques ajoutées : les ressources sont répliquées dans les zones géographiques nouvellement ajoutées.
  • Emplacements avec d'anciennes copies : le contenu est mis à jour.

Régions Artifact Registry et Developer Connect

L'emplacement de votre dépôt Artifact Registry et de votre instance Developer Connect doit répondre à 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. Vous n'avez pas besoin de les inclure dans les régions disponibles de votre offre SaaS.

  • 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 d'offre SaaS, de version et de type 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 montrer comment fonctionne la régionalisation lorsque vous utilisez SaaS Runtime avec la réplication des ressources gérées.

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 SaaS Runtime ressemblera à ceci :

  • Régions où l'offre SaaS 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 type d'unité et version : SaaS Runtime gère la création et la mise à 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 des artefacts dans une troisième région distincte avec réplication automatisée des ressources. Vous devez examiner attentivement vos exigences en termes de latence, de conformité et de résidence des données lorsque vous sélectionnez vos régions.

Étapes suivantes