<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Partie 8 : Exploitation et fiabilité :: Teknolabs</title>
    <link>https://teknolabs.net/courses/devops-cloud/partie-8-exploitation-fiabilite/index.html</link>
    <description>Observer, tester en fonctionnement, livrer progressivement, protéger les données et piloter le trafic entre services.&#xA;TP Outil(s) Approche TP21 Prometheus, Grafana, Loki, Tempo, OpenTelemetry Observabilité : métriques, logs, traces, corrélation, SLI / SLO, alerte et runbook TP22 OWASP ZAP, k6 DAST (baseline, actif, API) et tests de charge avec seuils bloquants TP23 Argo Rollouts, OpenFeature Blue/Green, Canary, analyse Prometheus, rollback automatique, Feature Flags TP24 CloudNativePG, Velero PostgreSQL haute disponibilité, sauvegardes S3 (Floci), PITR, sauvegarde et restauration de namespace TP25 Linkerd Service mesh : mTLS, métriques dorées, répartition du trafic, retries et timeouts Prérequis : Cluster du TP14 ; la pile d’observabilité du TP21 sert aux TP23 et TP25 ; le TP22 reprend l’API du TP8, le TP23 le GitOps du TP19 et le TP24 sauvegarde vers Floci (TP13).</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <atom:link href="https://teknolabs.net/courses/devops-cloud/partie-8-exploitation-fiabilite/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>TP21 : Observabilité (Prometheus, Grafana, Loki, Tempo, OpenTelemetry, SLO)</title>
      <link>https://teknolabs.net/courses/devops-cloud/partie-8-exploitation-fiabilite/tp21-observabilite/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://teknolabs.net/courses/devops-cloud/partie-8-exploitation-fiabilite/tp21-observabilite/index.html</guid>
      <description>Surveiller (monitoring) répond à « est-ce que ça marche ? ». L’observabilité permet de répondre à « pourquoi ça ne marche pas ? », y compris pour une panne jamais vue, grâce à trois signaux reliés entre eux : les métriques (combien, à quelle vitesse), les logs (ce qui s’est passé) et les traces (le parcours d’une requête à travers les services). Ce TP instrumente une petite application et monte la pile open source de référence : Prometheus + Grafana + Loki + Tempo + OpenTelemetry, puis définit un SLO et l’alerte associée.</description>
    </item>
    <item>
      <title>TP22 : Tests dynamiques de sécurité (OWASP ZAP) et tests de charge (k6)</title>
      <link>https://teknolabs.net/courses/devops-cloud/partie-8-exploitation-fiabilite/tp22-dast-k6/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://teknolabs.net/courses/devops-cloud/partie-8-exploitation-fiabilite/tp22-dast-k6/index.html</guid>
      <description>Les scanners du TP10 lisent le code (SAST, SCA). Ils ne voient ni la configuration réelle du serveur, ni les en-têtes renvoyés, ni le comportement sous charge. Ce TP ajoute deux contrôles sur l’application en fonctionnement :&#xA;le DAST (Dynamic Application Security Testing) avec OWASP ZAP, qui explore et attaque l’application comme le ferait un attaquant externe ; les tests de charge avec k6, dont les seuils (thresholds) peuvent bloquer une promotion vers la production. ⚠️ La cible, OWASP Juice Shop, est une application volontairement vulnérable. Ne scannez jamais une application qui ne vous appartient pas : un scan actif est une attaque.</description>
    </item>
    <item>
      <title>TP23 : Progressive Delivery (Argo Rollouts, Blue/Green, Canary, analyse, Feature Flags)</title>
      <link>https://teknolabs.net/courses/devops-cloud/partie-8-exploitation-fiabilite/tp23-progressive-delivery/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://teknolabs.net/courses/devops-cloud/partie-8-exploitation-fiabilite/tp23-progressive-delivery/index.html</guid>
      <description>Un Deployment Kubernetes remplace les Pods progressivement, mais il ne sait pas juger la nouvelle version : si elle renvoie 30 % d’erreurs tout en passant ses probes, le rolling update va jusqu’au bout. La livraison progressive expose la nouvelle version à une petite partie du trafic, mesure son comportement et décide automatiquement de poursuivre ou d’annuler. Ce TP met en œuvre Argo Rollouts (Blue/Green, Canary, analyse Prometheus et rollback automatique), puis sépare le déploiement du code de l’activation d’une fonctionnalité grâce aux Feature Flags (OpenFeature + flagd).</description>
    </item>
    <item>
      <title>TP24 : Données et reprise après sinistre (CloudNativePG, Velero)</title>
      <link>https://teknolabs.net/courses/devops-cloud/partie-8-exploitation-fiabilite/tp24-cloudnativepg-velero/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://teknolabs.net/courses/devops-cloud/partie-8-exploitation-fiabilite/tp24-cloudnativepg-velero/index.html</guid>
      <description>Les applications sans état se recréent en une commande ; les données, non. Ce TP traite deux questions que tout exploitant doit savoir résoudre : comment faire tourner une base PostgreSQL hautement disponible dans Kubernetes (avec l’opérateur CloudNativePG), et comment sauvegarder puis restaurer une base ou un namespace entier après un incident (archivage continu vers S3, restauration à un instant précis, Velero). Les sauvegardes sont stockées dans le S3 émulé par Floci (TP13).</description>
    </item>
    <item>
      <title>TP25 : Service mesh avec Linkerd (mTLS, observabilité, répartition du trafic)</title>
      <link>https://teknolabs.net/courses/devops-cloud/partie-8-exploitation-fiabilite/tp25-service-mesh/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://teknolabs.net/courses/devops-cloud/partie-8-exploitation-fiabilite/tp25-service-mesh/index.html</guid>
      <description>Dans un cluster, les services se parlent en HTTP en clair et chaque équipe réimplémente à sa façon les retries, les timeouts et les métriques. Un service mesh confie ces fonctions à une couche d’infrastructure : un proxy placé à côté de chaque Pod chiffre les échanges en mTLS, mesure chaque requête et applique des règles de trafic, sans modifier le code. Ce TP utilise Linkerd, maillage CNCF diplômé, plus léger qu’Istio et adapté à un cluster K3s de lab.</description>
    </item>
  </channel>
</rss>