Aller au contenu
English
Compte : non connecté, synchronisation possible Mon apprentissage
Selectionner le thème
English

Checkpoint Plateforme : dépendances transverses et frontières de confiance

Par mis à jour le

Améliorer cette page

Ce checkpoint vérifie que vous savez lire ce qu'un diagramme met d'habitude de côté : les services transverses dont dépend l'application, le moment où leur panne se révèle, et les frontières de confiance que franchissent ses flux. Il monte d'un cran par rapport au checkpoint Échanger : il faut toujours suivre les flux et classer l'état, mais aussi distinguer ce qui casse tout de suite de ce qui casse au redémarrage. Le diagramme n'est pas la boutique : c'est une plateforme de prise de rendez-vous médicaux.

  • Prédire, pour chaque dépendance transverse, ce qui casse tout de suite et ce qui casse au redémarrage
  • Repérer les frontières de confiance qu'une requête franchit
  • Distinguer service consommé et plateforme d'exécution sur un diagramme inconnu
  • Dire ce qu'il faut sauvegarder, et ce qui rend la sauvegarde lisible

Un patient se connecte auprès de Keycloak, puis prend rendez-vous par une API qui tourne dans un cluster Kubernetes et enregistre les rendez-vous dans PostgreSQL, isolé dans une zone de données. L'API vérifie les jetons avec la clé publique de Keycloak, obtient un compte de base temporaire auprès d'OpenBao, qui se déverrouille grâce au KMS du cloud, et résout les noms par le DNS interne du cluster. Les images viennent de Harbor, et Prometheus, installé dans le cluster, évalue les alertes.

Trois zones : un cluster Kubernetes contenant l'entrée, l'API de rendez-vous, le DNS interne et Prometheus ; une zone de données avec PostgreSQL ; une zone de services partagés avec Keycloak, l'annuaire du personnel, OpenBao et le registre Harbor. Le patient se connecte à Keycloak et envoie ses requêtes en HTTPS à l'entrée du cluster ; l'API écrit en SQL dans PostgreSQL ; en pointillé, l'API dépend du DNS interne, de Prometheus, de la clé publique de Keycloak et d'OpenBao, qui se déverrouille par le KMS du cloud placé hors des zones ; le cluster tire ses images de Harbor.PatientnavigateurKMSdu cloudCluster KubernetesZone donnéesServices partagésEntréeingressAPIrendez-vousDNSinternePrometheusalertesPostgreSQLrendez-vousKeycloakAnnuairedu personnelOpenBaosecretsHarborregistrerésolutionmétriquescomptesHTTPSSQLconnexionclé publiquecompte de basedéverrouillageimages
Diagramme du checkpoint : une plateforme de rendez-vous médicaux, pas la boutique. Les zones marquent les frontières de confiance. Source · SVG
Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 %

Chaque question se résout en se demandant, pour la brique en panne : est-ce que l'API l'appelle à chaque requête, ou seulement au démarrage ? Ce qui est appelé à chaque requête casse tout de suite ; ce qui ne sert qu'au démarrage casse au prochain redémarrage, déploiement ou nœud perdu. Les jetons et les réponses en cache ajoutent un troisième temps : la panne arrive à leur expiration.

Pour les questions de confiance, chaque zone du diagramme est une frontière : comptez celles qu'une flèche traverse, et demandez qui authentifie l'appel. Les questions reprennent aussi les acquis précédents : source de vérité, sauvegarde et domaine de panne. Le seuil de réussite est de 70 %.

Le module se referme sur les trois questions de chaque module : qu'ai-je ajouté, pourquoi, et quel nouveau problème ai-je créé ? Il n'a ajouté aucune fonction visible à la boutique. Il a rendu visibles les briques dont elle dépendait déjà, et chacune apporte sa propre façon de tomber, souvent retardée : c'est la leçon du module.

J'ai ajoutéPourMais j'ai créé
DNS, temps et configuration distribuée sur le schémasavoir de quoi dépend chaque démarragedes briques transverses à rendre redondantes, chacune
un fournisseur d'identité et une IAMne plus garder de mots de passe, décider des droits au même endroitune dépendance de chaque connexion, une clé de signature à protéger
un gestionnaire de secrets, une PKI et un KMSne plus écrire de secret nulle part, chiffrer les donnéesdes démarrages qui dépendent du KMS, des certificats qui expirent
un registre, une forge et un miroirne déployer que des images signées et tracéesune frontière de confiance sensible, un registre dont dépend chaque relance
un orchestrateurrelancer seul ce qui tombeun plan de contrôle à tenir, un domaine de panne partagé
une observabilité hors du clustervoir et être prévenuun pipeline à tenir, et une surveillance à surveiller

La dernière colonne a un point commun : la plupart de ces problèmes ne se voient pas en marche, mais au redémarrage ou pendant un incident. Le module Services d'exploitation et d'administration s'occupe de ces moments : l'accès pour réparer, la sauvegarde pour restaurer, et le plan de reprise.

  • Ce qui est appelé à chaque requête casse tout de suite ; ce qui sert au démarrage casse au redémarrage.
  • Jetons et caches font arriver la panne à leur expiration.
  • Chaque zone est une frontière de confiance ; chaque flèche qui la traverse doit être authentifiée.
  • Une plateforme exécute, un service est consommé.
  • Une sauvegarde chiffrée ne se restaure qu'avec ce qui la déverrouille.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

8 questions
10 min.
70% requis

Informations

  • Le chronomètre démarre au clic sur Démarrer
  • Questions à choix multiples, vrai/faux et réponses courtes
  • Vous pouvez naviguer entre les questions
  • Les résultats détaillés sont affichés à la fin

Lance le quiz et démarre le chronomètre

Ce projet vous est utile ?

Les guides, formations, quiz et labs restent gratuits. Si vous les utilisez régulièrement, vous pouvez contribuer à leur maintenance et à leur développement.

Devenir membre de soutien (nouvel onglet) Soutenir une fois (nouvel onglet) En savoir plus

Suivez aussi le projet sur LinkedIn