Ce document décrit la méthodologie de l'application douze facteurs et sa mise en œuvre lors du développement d'applications exécutées sur Google Cloud. Cette méthodologie permet de créer des applications évolutives et robustes qui peuvent être déployées en continu avec une agilité optimale.
Ce document est destiné aux développeurs qui connaissent déjà le fonctionnement de Google Cloud, du contrôle des versions, de l'intégration continue et de la technologie des conteneurs.
Présentation
Lorsque les développeurs déplacent des applications vers le cloud, ils gagnent de l'expérience en conception et en déploiement d'applications cloud natives. C'est cette expérience qui a permis de créer un ensemble de bonnes pratiques communément appelées les douze facteurs. Tenir compte de ces facteurs vous permet de déployer dans le cloud des applications plus mobiles et robustes que les applications déployées dans des environnements sur site où le provisionnement de nouvelles ressources prend plus de temps.
Cependant, la conception d'applications cloud natives modernes exige que vous changiez de vision en termes d'ingénierie, de configuration et de déploiement logiciel, par rapport à la conception d'applications sur site. Ce document vous explique comment appliquer les douze facteurs à votre conception d'applications.
Avantages des applications douze facteurs
La conception à douze facteurs vous permet également de dissocier les composants de l'application, lesquels peuvent ainsi être remplacés, augmentés ou réduits facilement. Les facteurs étant indépendants de tout langage de programmation et de toute pile logicielle, la conception à douze facteurs peut être appliquée à une grande variété d'applications.
Les douze facteurs
1. Codebase
Vous devez gérer le code de votre application dans un système de contrôle des versions tel que Git ou Mercurial. Pour travailler sur l'application, vous extrayez le code vers votre environnement de développement local. Le stockage du code dans un système de contrôle des versions permet aux membres de votre équipe de travailler main dans la main. En effet, ce système fournit une trace d'audit des modifications apportées au code, et offre un moyen systématique de résoudre les conflits de fusion et d'effectuer un rollback du code vers une version précédente. Ce type de stockage fournit également un emplacement à partir duquel effectuer l'intégration continue (CI) et le déploiement continu (CD).
Bien que les développeurs puissent travailler sur différentes versions du code au sein de leurs environnements de développement, la véritable source est le code situé dans le système de contrôle des versions. Le code qui se trouve dans le dépôt correspond à ce qui est conçu, testé et déployé, et le nombre de dépôts est indépendant du nombre d'environnements. Le code du dépôt sert à générer une version unique, qui une fois associée à une configuration spécifique à un environnement, permet de produire une version immuable ne pouvant faire l'objet d'aucune modification, y compris de sa configuration. Cette version peut alors être déployée vers un environnement. (Toute modification requise pour la version doit entraîner la création d'une nouvelle version.)
2. Dépendances
Deux éléments sont à prendre en compte pour ce qui est des dépendances des applications douze facteurs : la déclaration et l'isolation des dépendances.
Les applications douze facteurs ne doivent en aucun cas avoir de dépendances implicites. Vous devez déclarer toutes les dépendances de manière explicite et vérifier ces dépendances dans le contrôle des versions. Cela vous permet de faire rapidement vos premiers pas avec le code de manière reproductible et de suivre facilement les modifications apportées aux dépendances. De nombreux langages de programmation permettent de déclarer explicitement des dépendances, comme par exemple avec pip pour Python et Bundler pour Ruby.
Vous devez également isoler une application et ses dépendances en les rassemblant dans un conteneur. Les conteneurs vous permettent d'isoler une application et ses dépendances de son environnement, et de garantir le fonctionnement uniforme de l'application malgré les différences entre les environnements de développement et de préproduction.
Artifact Registry est un service de gestion d'artefacts privé entièrement géré qui prend en charge divers types d'artefacts, tels que les images de conteneurs, les packages de langages (tels que Maven et npm) et les packages d'OS (tels que RPM). Pour vous aider à gérer les résultats de vos builds CI/CD et leurs dépendances, vous pouvez utiliser Cloud IAM avec Artifact Registry avec un contrôle d'accès précis. Artifact Analysis détecte les failles dans les images de conteneurs transférées vers Artifact Registry afin de vous assurer que vos images de conteneurs peuvent être déployées en toute sécurité.
Les intégrations CI/CD existantes vous permettent également de configurer des pipelines entièrement automatisés afin de recevoir rapidement des retours. Vous pouvez envoyer des images vers leur registre, puis les récupérer à l'aide d'un point de terminaison HTTP depuis n'importe quelle machine, qu'il s'agisse d'une instance Compute Engine ou de votre propre matériel.
3. Configuration
Toute application moderne requiert une configuration, d'une forme ou d'une autre. Il existe généralement des configurations différentes en fonction des environnements (développement, test et production, par exemple). Ces configurations incluent généralement des identifiants de compte de service et des descripteurs de ressources dans des services externes tels que des bases de données.
Les configurations de chaque environnement doivent être externes au code et ne doivent pas être enregistrées dans le contrôle des versions. Tous les utilisateurs travaillent sur une même version du code, mais plusieurs configurations peuvent exister. L'environnement de déploiement détermine la configuration à utiliser. Cela permet de déployer une version unique du binaire dans chaque environnement. Seule la configuration de l'environnement d'exécution diffère. Pour vérifier facilement si la configuration a été correctement externalisée, assurez-vous que le code peut être rendu public sans révéler d'identifiants.
L'une des méthodes d'externalisation de la configuration consiste à créer des fichiers de configuration. Cependant, ces fichiers sont généralement spécifiques à un langage ou à un framework de développement.
Une meilleure approche consiste à stocker la configuration dans des variables d'environnement. Celles-ci sont faciles à modifier pour chaque environnement lors de l'exécution, non susceptibles d'être vérifiées dans le contrôle des versions, et indépendantes du langage de programmation et du framework de développement. Dans Google Kubernetes Engine (GKE), vous pouvez utiliser des ConfigMaps. Ils vous permettent de lier des variables d'environnement, des numéros de port, des fichiers de configuration, des arguments de ligne de commande et d'autres éléments de configuration aux conteneurs et aux composants système de vos pods lors de l'exécution.
Cloud Functions et Cloud Run sont compatibles avec l'utilisation de variables d'environnement. Vous pouvez externaliser les configurations et les modifier à partir de la console Google Cloud ou à l'aide de Google Cloud SDK.
4. Services externes
Chaque service utilisé par l'application dans le cadre de son fonctionnement normal, tel que les systèmes de fichiers, les bases de données, les systèmes de mise en cache et les files d'attente de messages, doit être accessible en tant que service et externalisé dans la configuration. Ce sont des abstractions pour la ressource sous-jacente. Par exemple, lorsque l'application écrit des données dans l'espace de stockage, traiter celui-ci comme un service externe vous permet de modifier facilement le type de stockage sous-jacent, car il est dissocié de l'application. Vous pouvez ensuite effectuer des changements, par exemple passer d'une base de données PostgreSQL locale à Cloud SQL pour PostgreSQL sans modifier le code de l'application.
5. Compilation, release et exécution
Il est important de séparer le processus de déploiement logiciel en trois étapes distinctes : la compilation, la release et l'exécution. Chaque étape doit donner lieu à un artefact à identifiant unique. Chaque déploiement doit être associé à une release spécifique qui est le produit de la combinaison d'une configuration d'environnement et d'une version. Cela permet de simplifier les actions de rollback et de rendre plus visible la trace d'audit de l'historique de chaque déploiement de production.
Bien que vous puissiez lancer la compilation manuellement, en règle générale, elle se déclenche automatiquement lorsque vous effectuez un commit de code ayant passé tous les tests requis. L'étape de compilation récupère le code ainsi que les bibliothèques et les éléments requis, puis les regroupe dans un binaire ou un conteneur autonome. L'étape de compilation donne lieu à un artefact de version.
Une fois la compilation terminée, l'étape de release associe l'artefact de version à la configuration d'un environnement spécifique pour générer une release. Cette release peut être déployée automatiquement dans l'environnement par une application de déploiement continu, ou bien déclenchée par vos soins via la même application de déploiement continu.
Enfin, l'étape d'exécution lance la release et la démarre. Par exemple, si vous réalisez un déploiement sur GKE, Cloud Build peut appeler l'étape de compilation gke-deploy pour effectuer un déploiement sur votre cluster GKE. Cloud Build peut gérer et automatiser les étapes de compilation, de release et d'exécution dans plusieurs langages et environnements à l'aide de fichiers de configuration de compilation au format YAML ou JSON.
En outre, vous pouvez utiliser Cloud Deploy, un service entièrement géré, qui assure une livraison continue vers GKE, Cloud Run et GKE Enterprise. Avec Cloud Deploy, vous pouvez créer un pipeline de diffusion qui comprend des étapes d'approbation et une promotion transparente dans plusieurs environnements. En outre, Cloud Deploy permet d'effectuer un rollback en une seule étape d'une application déployée dans n'importe quelle cible.
6. Processus
Les applications douze facteurs sont exécutées dans l'environnement sous la forme d'un ou de plusieurs processus. Ces processus doivent être sans état et ne partager aucune donnée entre eux. Les applications peuvent ainsi évoluer grâce à la réplication de leurs processus. La création d'applications sans état favorise également la portabilité des processus dans l'infrastructure informatique.
Si vous êtes habitué au concept de sessions "persistantes", vous devez changer votre vision du traitement et de la persistance des données. Étant donné que les processus peuvent disparaître à tout moment, vous ne pouvez pas compter sur la disponibilité du contenu du stockage local, ni sur le traitement de toute requête ultérieure par le même processus. Par conséquent, vous devez explicitement conserver toutes les données qui doivent être réutilisées dans un service de sauvegarde externe tel qu'une base de données.
Si vous souhaitez conserver des données, vous pouvez utiliser les services externes Memorystore et Filestore pour mettre en cache l'état de vos applications et partager des données communes entre les processus, en vue de favoriser les couplages faibles.
7. Association de ports
Dans les environnements non basés sur le cloud, les applications Web sont souvent conçues pour s'exécuter dans des conteneurs d'applications tels que GlassFish, Apache Tomcat et le serveur HTTP Apache. En revanche, les applications douze facteurs ne reposent pas sur des conteneurs d'applications externes. Au lieu de cela, elles intègrent la bibliothèque du serveur Web directement dans l'application.
Sur le plan architectural, il est recommandé que les services exposent un numéro de port, spécifié par la variable d'environnement PORT.
Les applications qui exportent l'association de ports peuvent consommer les informations relatives à cette association en externe (en tant que variables d'environnement) lors de l'utilisation du modèle Platform as a Service. Dans Google Cloud, vous pouvez déployer des applications sur des services de plate-forme tels que Compute Engine, GKE, App Engine ou Cloud Run.
Dans ces services, une couche de routage achemine les requêtes d'un nom d'hôte public vers vos processus Web associés au port. Par exemple, lorsque vous déployez vos applications sur App Engine, vous déclarez des dépendances pour ajouter une bibliothèque de serveur Web à l'application, telle que Express (pour Node.js), Flask et Gunicorn (pour Python) ou Jetty (pour Java).
Vous ne devez pas coder en dur les numéros de port dans votre code. Indiquez plutôt les numéros de port dans l'environnement, par exemple dans une variable d'environnement. Cela favorise la portabilité de vos applications lorsque vous les exécutez sur Google Cloud.
Comme Kubernetes dispose d'une fonctionnalité de découverte de services intégrée, vous pouvez extraire des associations de ports en mappant les ports de service aux conteneurs. La découverte des services s'effectue à l'aide de noms DNS internes.
Au lieu de coder en dur le port sur lequel le serveur Web écoute, la configuration utilise une variable d'environnement. L'extrait de code suivant, issu d'une application App Engine, indique comment accepter une valeur de port transmise dans une variable d'environnement.
const express = require('express')
const request = require('got')
const app = express()
app.enable('trust proxy')
const PORT = process.env.PORT || 8080
app.listen(PORT, () => {
console.log('App listening on port ${PORT}')
console.log('Press Ctrl+C to quit.')
})
8. Concurrence
Vous devez décomposer votre application en processus indépendants en fonction des types de processus (processus d'exécution en arrière-plan, processus de nœud de calcul et processus Web, par exemple). Votre application peut ainsi évoluer en fonction des besoins de chaque charge de travail. La plupart des applications cloud natives vous permettent d'évoluer à la demande. Vous devez concevoir l'application sous forme de processus répartis multiples et indépendants, capables d'exécuter des blocs de travail et d'effectuer un scaling horizontal par l'ajout d'autres processus.
Les sections suivantes décrivent certaines structures permettant l'évolutivité des applications. Les applications conçues avec des processus jetables et sans état sont bien placées pour bénéficier de ces conceptions de scaling horizontal.
Utiliser Cloud Run
Cloud Run est une plate-forme de calcul qui vous permet d'exécuter des conteneurs directement sur une infrastructure gérée par Google. Cloud Run accepte deux méthodes pour exécuter votre code. Cloud Run services s'exécute en continu en tant que service. Il est généralement utilisée pour répondre à des requêtes Web ou à des événements. Cloud Run jobs exécute du code qui effectue un job spécifique et se ferme une fois le travail terminé. Cloud Run propose également Cloud Scheduler pour exécuter des jobs par lot. Cette structure est parfaitement adaptée à la mise en œuvre de la simultanéité et au scaling des architectures de services possibles.
Pour en savoir plus sur Cloud Run, consultez la page Qu'est-ce que Cloud Run ?
Utiliser Cloud Functions
Sans état et à usage unique, les fonctions Cloud Functions s'exécutent sur Google Cloud, où l'architecture sous-jacente sur laquelle elles s'exécutent est gérée par Google. Cloud Functions répond aux déclencheurs d'événements, tels qu'une importation dans un bucket Cloud Storage ou un message Pub/Sub. Chaque appel de fonction répond à un seul événement ou une seule demande.
Cloud Functions gère les requêtes entrantes en les attribuant à des instances de votre fonction. Lorsque le volume de requêtes entrantes dépasse le nombre d'instances existantes, Cloud Functions peut démarrer de nouvelles instances pour gérer les requêtes. Ce comportement de scaling automatique entièrement géré permet à Cloud Functions de traiter de nombreuses requêtes en parallèle, chacune utilisant une instance différente de votre fonction.
Utiliser App Engine
Vous pouvez héberger vos applications sur l'infrastructure gérée de Google Cloud à l'aide d'App Engine. Les instances sont les unités de calcul utilisées par App Engine pour faire évoluer automatiquement votre application. À tout moment, votre application peut s'exécuter sur une ou plusieurs instances, les requêtes étant réparties sur chacune d'entre elles.
Le programmeur App Engine décide comment traiter chaque nouvelle requête. Il peut utiliser une instance existante (inactive ou acceptant les requêtes simultanées), placer la requête dans une file d'attente ou démarrer une nouvelle instance pour cette requête. La décision tient compte du nombre d'instances disponibles, de la rapidité avec laquelle votre application traite les requêtes (sa latence) et du délai nécessaire pour démarrer une nouvelle instance.
Si vous utilisez le scaling automatique, vous pouvez créer un équilibre entre performances et coûts en définissant l'utilisation du processeur cible, le débit cible et le nombre maximal de requêtes simultanées.
Vous pouvez spécifier le type de scaling dans le fichier app.yaml, que vous importez pour la version de votre service. En fonction de cette configuration, l'infrastructure App Engine utilise des instances dynamiques ou résidentes. Pour plus d'informations sur les types de scaling, consultez la documentation App Engine.
Utiliser l'autoscaling GKE
Certaines structures clés de Kubernetes s'appliquent aux processus de scaling :
Autoscaling horizontal des pods (HPA). Kubernetes peut être configuré de façon à augmenter ou diminuer le nombre de pods exécutés dans le cluster en fonction de métriques standards ou personnalisées. Cela s'avère utile lorsque vous devez vous adapter à une charge variable sur votre cluster GKE.
Autoscaling des nœuds. En cas de demande accrue, vous devrez peut-être faire évoluer votre cluster de façon à ce qu'il accueille davantage de pods. Avec GKE, vous pouvez configurer de manière déclarative le cluster à faire évoluer. Lorsque l'autoscaling est activé, GKE assure le scaling automatique des nœuds lorsque des pods supplémentaires doivent être programmés et que les nœuds existants ne peuvent pas les gérer. GKE réduit également le nombre de nœuds lorsque la charge sur le cluster diminue, en fonction des seuils que vous avez configurés.
Tâches. GKE est compatible avec les tâches Kubernetes. Une tâche peut être définie de manière générale comme une action nécessitant l'exécution d'un ou de plusieurs pods. La tâche peut s'exécuter une seule fois ou ponctuellement selon un calendrier. Une fois la tâche terminée, les pods dans lesquels elle s'exécutait sont supprimés. Le fichier YAML qui configure la tâche spécifie les détails sur la gestion des erreurs, le parallélisme, la gestion des redémarrages, etc.
Utiliser Compute Engine
Il est également possible de déployer et de gérer vos applications sur Compute Engine. Dans ce cas, vous pouvez faire évoluer votre application de sorte qu'elle s'adapte aux charges variables à l'aide des groupes d'instances gérés (MIG) en fonction de l'utilisation du processeur, des demandes traitées ou d'autres signaux de télémétrie de votre application.
La figure suivante illustre les principales fonctionnalités fournies par les groupes d'instances gérés.
L'utilisation de groupes d'instances gérés permet à votre application de s'adapter à la demande entrante et de fournir une disponibilité élevée. Ce concept fonctionne parfaitement pour les applications sans état, telles que les frontends Web, et pour les charges de travail hautes performances basées sur le traitement par lot.
9. Ressources jetables
Les applications s'exécutant sur une infrastructure cloud ainsi que l'infrastructure sous-jacente doivent être traitées comme des ressources jetables. Vos applications doivent pouvoir gérer la perte temporaire de l'infrastructure sous-jacente et être en mesure de s'arrêter et de redémarrer correctement.
Les principes clés à prendre en compte sont les suivants :
- Dissociez les fonctionnalités telles que la gestion de l'état et le stockage des données transactionnelles à l'aide de services externes. Pour plus d'informations, consultez la section Services externes ci-dessus.
- Gérez les variables d'environnement en dehors de l'application afin de pouvoir les utiliser au moment de l'exécution.
- Assurez-vous que le temps de démarrage est minimal. Cela signifie que vous devez déterminer la quantité de couches à intégrer dans les images lorsque vous utilisez des machines virtuelles, telles que des images publiques ou personnalisées. Cette décision est spécifique à chaque application et doit être basée sur les tâches exécutées par les scripts de démarrage. Par exemple, si vous téléchargez plusieurs packages ou binaires et que vous les initialisez au démarrage, une grande partie de votre temps de démarrage sera consacrée à ces tâches.
- Utilisez les fonctionnalités natives de Google Cloud pour effectuer des tâches d'infrastructure. Par exemple, vous pouvez utiliser des mises à jour progressives dans GKE et gérer vos clés de sécurité à l'aide de Cloud Key Management Service (Cloud KMS).
Utilisez le signal SIGTERM (lorsqu'il est disponible) pour lancer un arrêt sans défaut. Par exemple, lorsque App Engine Flex arrête une instance, il envoie normalement un signal STOP (SIGTERM) au conteneur de l'application. Votre application peut utiliser ce signal pour effectuer des actions de nettoyage avant l'arrêt du conteneur. (Votre application n'a pas besoin de répondre à l'événement SIGTERM.) Dans des conditions normales, le système attend jusqu'à 30 secondes que l'application s'arrête, puis envoie un signal KILL (SIGKILL).
L'extrait suivant issu d'une application App Engine vous montre comment intercepter le signal SIGTERM pour fermer les connexions de base de données ouvertes.
const express = require('express') const dbConnection = require('./db') // Other business logic related code app.listen(PORT, () => { console.log('App listening on port ${PORT}') console.log('Press Ctrl+C to quit.') }) process.on('SIGTERM', () => { console.log('App Shutting down') dbConnection.close() // Other closing of database connection })
10. Parité des environnements
Les applications d'entreprise évoluent dans différents environnements au cours de leur cycle de développement. En règle générale, ces environnements sont les suivants : développement, test, préproduction et production. Il est recommandé de faire en sorte que ces environnements restent aussi semblables que possible.
La parité des environnements (ou parité dev/prod) est une fonctionnalité que la plupart des développeurs considèrent comme acquise. Néanmoins, à mesure que les entreprises se développent et que leurs écosystèmes informatiques évoluent, la parité des environnements devient difficile à maintenir.
La préservation de la parité des environnements est devenue plus facile ces dernières années, car les développeurs ont adopté le contrôle des sources, la gestion de la configuration et les fichiers de configuration modélisés. Cela facilite le déploiement des applications dans plusieurs environnements de manière cohérente. Par exemple, Docker et Docker Compose vous permettent de vous assurer que la pile d'applications conserve sa forme et son instrumentation dans tous les environnements.
Le tableau suivant répertorie les services et les outils Google Cloud à votre disposition lorsque vous concevez des applications à exécuter sur Google Cloud. Ces composants ont des usages différents et vous aident à créer des flux de travail qui rendent vos environnements plus cohérents.
| Composant Google Cloud | Purpose |
|---|---|
| Artifact Registry | Un gestionnaire de packages universel pour tous vos artefacts et dépendances de compilation. |
| Cloud Build | Un service entièrement géré qui exécute vos builds sur l'infrastructure Google Cloud |
| Cloud KMS | Conservez des clés de chiffrement dans un service cloud central pour une utilisation directe par d'autres ressources et applications cloud. |
| Cloud Storage | Stockez des images personnalisées que vous créez à partir de disques, d'images ou d'instantanés sources stockés dans Cloud Storage. Vous pouvez utiliser ces images pour créer des instances de machines virtuelles (VM) adaptées à vos applications. |
| Cloud Deploy | Assure la diffusion automatisée de vos applications dans une série de plusieurs environnements cibles selon une séquence définie. |
11. Journaux
Les journaux vous permettent de connaître l'état de vos applications. Il est important de dissocier la collecte, le traitement et l'analyse des journaux de la logique de base de vos applications. Ce découplage est particulièrement utile lorsque vos applications requièrent une évolutivité dynamique et s'exécutent sur des clouds publics, car il élimine les frais liés à la gestion de l'espace de stockage des journaux et à l'agrégation des VM distribuées (et souvent éphémères).
Google Cloud propose une suite d'outils qui facilitent la collecte, le traitement et l'analyse structurée des journaux. Il est recommandé d'installer l'agent Cloud Logging dans vos VM Compute Engine. (L'agent est préinstallé par défaut dans les images de VM App Engine et GKE.) L'agent surveille un ensemble préconfiguré d'emplacements de journalisation. Les journaux générés par vos applications exécutées dans la VM sont collectés et transférés vers Cloud Logging.
Lorsque la journalisation est activée pour un cluster GKE, un agent de journalisation est déployé sur chaque nœud faisant partie du cluster. L'agent collecte les journaux, les enrichit avec des métadonnées pertinentes et les conserve dans un datastore. Ces journaux peuvent être consultés à l'aide de Cloud Logging. Si vous avez besoin de mieux contrôler les éléments enregistrés dans les journaux, vous pouvez utiliser les daemonsets Fluentd.
Pour en savoir plus, consultez la section Configurer l'agent Logging.
12. Processus d'administration
Les processus d'administration sont généralement constitués de tâches ponctuelles ou récurrentes, telles que la création de rapports, l'exécution de scripts batch, le démarrage de sauvegardes de bases de données et la migration de schémas. Le facteur lié aux processus d'administration du manifeste des douze facteurs a été rédigé en prenant en compte les tâches ponctuelles. Pour les applications cloud natives, ce facteur devient plus pertinent lors de la création de tâches récurrentes. Par ailleurs, les instructions de cette section sont orientées vers ce type de tâche.
Les déclencheurs temporisés sont souvent créés sous forme de tâches Cron et gérés de manière inhérente par les applications elles-mêmes. Ce modèle fonctionne, mais il introduit une logique étroitement liée à l'application et qui nécessite maintenance et coordination, en particulier si vos applications sont réparties sur plusieurs fuseaux horaires.
Par conséquent, lorsque vous concevez pour des processus d'administration, vous devez dissocier la gestion de ces tâches de l'application elle-même. Selon les outils et l'infrastructure sur lesquels votre application s'exécute, utilisez les suggestions suivantes :
- Pour exécuter des applications sur GKE, démarrez des conteneurs distincts pour les tâches d'administration. Vous pouvez exploiter les CronJobs dans GKE. Les tâches Cron s'exécutent dans des conteneurs éphémères et vous permettent de contrôler la durée, la fréquence d'exécution et les nouvelles tentatives si les tâches échouent ou prennent trop de temps.
- Pour héberger des applications sur App Engine ou Compute Engine, vous pouvez externaliser le mécanisme de déclenchement et créer un point de terminaison à appeler par le déclencheur. Cette approche permet de définir des limites concernant la responsabilité des applications, à l'inverse de l'objectif unique du point de terminaison. Cloud Tasks est un service d'exécution de tâches asynchrones entièrement géré que vous pouvez utiliser pour mettre en œuvre ce schéma avec App Engine. Vous pouvez également déclencher des opérations planifiées à l'aide de Cloud Scheduler, un planificateur d'entreprise entièrement géré sur Google Cloud.
Au-delà des douze facteurs
Les douze facteurs décrits dans ce document vous aident à concevoir des applications cloud natives, lesquelles forment les éléments constitutifs d'une entreprise.
Une entreprise type dispose de nombreuses applications de ce genre, souvent développées par plusieurs équipes en collaboration pour garantir certaines capacités opérationnelles. Pour déterminer le mode de communication entre les applications, ainsi que la méthode de sécurisation et de contrôle de celles-ci, il est important d'établir des principes supplémentaires pendant le cycle de développement des applications et non après coup.
Les sections suivantes décrivent certaines considérations supplémentaires à prendre en compte lors de la conception et du développement d'applications.
Approche orientée API
Les applications communiquent à l'aide d'API. Lorsque vous créez des applications, réfléchissez à la façon dont elles seront utilisées par leur écosystème et commencez par concevoir une stratégie d'API. Une bonne conception d'API facilite son utilisation par les développeurs d'applications et les utilisateurs externes. Avant de mettre en œuvre du code, il est recommandé de commencer par récolter des données sur l'API à l'aide de la spécification OpenAPI.
Les API permettent d'abstraire les fonctionnalités sous-jacentes de l'application. Un point de terminaison API bien conçu doit isoler et dissocier les applications consommatrices de l'infrastructure d'applications qui fournit le service. Ce découplage vous permet de modifier le service sous-jacent et son infrastructure indépendamment, sans impact sur les utilisateurs de l'application.
Il est important de répertorier, de documenter et de publier les API que vous développez afin que les utilisateurs puissent les découvrir et les utiliser. Dans l'idéal, vous pouvez permettre aux utilisateurs de l'API d'y accéder par eux-mêmes. Pour ce faire, configurez un portail de développeurs. Un portail de développeurs sert de point d'entrée pour tous les utilisateurs d'une API (internes à l'entreprise ou externes, comme les développeurs de votre écosystème de partenaires).
Apigee, la suite de produits de gestion d'API de Google, vous aide à gérer le cycle de vie complet de vos API, de la conception à la publication, en passant par la compilation.
Sécurité
Le domaine de la sécurité est vaste et inclut les systèmes d'exploitation, les réseaux et pare-feu, la sécurité des données et des bases de données, la sécurité des applications et la gestion de l'authentification et des accès. Il est primordial d'aborder la sécurité sous tous les angles dans l'écosystème d'une entreprise.
En ce qui concerne les applications, les API permettent d'accéder aux applications de votre écosystème d'entreprise. Vous devez donc vous assurer que ces composants répondent aux exigences de sécurité lors des processus de conception et de compilation d'applications. Voici quelques conseils pour protéger l'accès à vos applications :
- TLS (Transport Layer Security). TLS permet de protéger les données en transit. L'authentification TLS mutuelle peut être utile pour vos applications professionnelles. Cette méthode est simplifiée si vous utilisez des maillages de services tels que Istio sur Google Kubernetes Engine. Certains cas fréquents impliquent également la création de listes d'autorisation et d'interdiction basées sur des adresses IP, qui constituent un niveau de sécurité supplémentaire. La sécurité de la couche de transport implique également de protéger vos services contre les attaques DDoS et de robots.
- Sécurité des applications et des utilisateurs finaux. Transport Security permet d'assurer la sécurité des données en transit et d'établir une relation de confiance. Toutefois, il est recommandé d'ajouter une sécurité au niveau de l'application pour contrôler les accès en fonction des utilisateurs (autres applications, employés, partenaires, clients finaux de votre entreprise). Vous pouvez renforcer la sécurité à l'aide de clés API (pour les applications grand public), de l'authentification et de l'autorisation basées sur la certification, de jetons Web JSON (JWT) ou du langage SAML (Security Assertion Markup Language).
L'environnement de sécurité évolue constamment au sein d'une entreprise, ce qui complexifie le codage des structures de sécurité dans vos applications. Les produits de gestion d'API tels qu'Apigee permettent de sécuriser les API sur toutes les couches mentionnées dans cette section.
La sécurité de la chaîne d'approvisionnement logicielle est un problème difficile à résoudre. Il est important de prendre des précautions. Software Delivery Shield est une solution entièrement gérée de bout en bout qui permet de renforcer la sécurité de la chaîne d'approvisionnement logicielle tout au long du cycle de développement des logiciels. Il propose les services suivants, entre autres :
Cloud Build. Compatible avec les builds SLSA de niveau 3 pour les images de conteneurs et génère une provenance de build authentifiée et non falsifiable pour les applications conteneurisées.
Assured Open Source Software Réduisez les risques liés à votre chaîne d'approvisionnement logicielle en utilisant les mêmes packages OSS que ceux utilisés par Google.
En outre, divers services et fonctions sont préparés pour améliorer la sécurité de votre chaîne d'approvisionnement logicielle.
Pour en savoir plus sur la sécurité de la chaîne d'approvisionnement logicielle, consultez la page Sécurité de la chaîne d'approvisionnement logicielle. Pour en savoir plus sur Software Delivery Shield, consultez la page Présentation de Software Delivery Shield.
Étapes suivantes
- Consultez l'application de démonstration des microservices, qui incarne les principes de l'application douze facteurs et est élaborée à l'aide des produits et services Google Cloud.
- Consultez le Centre d'architecture cloud et découvrez des architectures de référence, des conseils et des bonnes pratiques pour créer ou migrer vos charges de travail sur Google Cloud.
- Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.