Cette épreuve termine le niveau 2 : vous reprenez un point d'entrée Traefik que vous ne connaissez pas, vous le protégez, vous le rendez observable, puis vous retrouvez la cause d'une panne non documentée à partir des seules preuves. Elle mobilise les middlewares, la protection du point d'entrée, les journaux et métriques et le dépannage. Comptez une heure et quart. Elle s'adresse à celui qui a suivi les modules « Traefik : protéger » et « Traefik : observer et exploiter ».
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »L'épreuve n'enseigne aucun geste nouveau : elle vous apprend à mobiliser seul les gestes du niveau 2 dans une situation réaliste, où l'incident n'est pas expliqué. Vous saurez :
- Sécuriser l'administration d'un déploiement hérité
- Ajouter des en-têtes de sécurité et une limitation de débit
- Rendre observable le proxy par des journaux JSON filtrés et des métriques
- Alerter sur les réponses 5xx
- Diagnostiquer une panne et la consigner dans un rapport
Le besoin
Section intitulée « Le besoin »Vous prenez en charge un déploiement Traefik que vous ne connaissez pas, et
les utilisateurs signalent que app.lab.test est indisponible. La route
d'administration n'a pas été revue et le proxy ne dispose pas d'une supervision
exploitable. Vous disposez de 75 minutes.
L'incident initial n'est pas documenté : rien ne vous dit quel composant est en cause. Vous vous appuyez sur la réponse HTTP observée et sur les journaux de Traefik, exactement comme sur un vrai poste d'astreinte.
Les contraintes
Section intitulée « Les contraintes »Chaque exigence se prouve par un état observable : une réponse, une ligne de journal, une métrique. Une configuration relue dit ce que vous avez voulu faire ; une réponse obtenue dit ce que le système fait réellement.
| # | Exigence | Ce qui sera observé |
|---|---|---|
| 1 | L'administration est sécurisée | un accès non autorisé refusé |
| 2 | Des en-têtes de sécurité sont ajoutés | les en-têtes présents dans les réponses |
| 3 | Une limitation de débit protège l'application | un excès de requêtes refusé |
| 4 | Les journaux d'accès sont en JSON et filtrés | des lignes JSON exploitables, sans le bruit à écarter |
| 5 | Les métriques Prometheus sont exposées | les métriques lisibles |
| 6 | Une alerte porte sur les réponses 5xx | une règle d'alerte sur ces réponses |
| 7 | L'application est rétablie | la bonne réponse obtenue après réparation |
Ce que vous devez livrer
Section intitulée « Ce que vous devez livrer »Un rapport d'incident, en plus de l'état final du déploiement. Consignez
dans /opt/pub-epreuve-niveau-deux/incident-report.txt cinq éléments : le
symptôme observé, la preuve tirée des journaux, la cause, la
correction appliquée et la réponse obtenue après réparation.
Ce rapport doit pouvoir être lu par quelqu'un qui n'a pas assisté à la séance. Il s'appuie sur ce que vous avez observé, pas sur ce que vous supposez : une cause sans preuve n'est qu'une hypothèse.
Comment vous auto-évaluer
Section intitulée « Comment vous auto-évaluer »Relisez les sept exigences puis le rapport : une exigence est réussie ou ratée, et un rapport sans preuve ne compte pas. Une panne réparée mais mal expliquée reste un échec de diagnostic, parce que le même incident reviendra.
Une exigence ratée n'appelle pas la recherche d'une solution toute faite : le corrigé de référence ne figure pas dans les guides. Revenez à la leçon qui enseigne le geste manquant, puis recommencez dans un état propre. Le contrôle automatisé du lab fait foi : l'épreuve est réussie quand il passe.
Mettre en pratique : passer l'épreuve
Section intitulée « Mettre en pratique : passer l'épreuve »L'épreuve se déroule dans le lab. Elle dure 75 minutes et ne fournit aucun indice. Lancez-la quand vous avez le temps de la finir d'une traite.
À retenir
Section intitulée « À retenir »Une épreuve de niveau 2 prouve un état et un raisonnement.
- L'administration, les en-têtes et la limitation de débit se prouvent par des réponses.
- Les journaux JSON et les métriques rendent le proxy observable.
- Une alerte 5xx prévient avant que les utilisateurs ne le fassent.
- Le diagnostic part de la réponse HTTP et des journaux, pas d'une intuition.
- Le rapport d'incident relie symptôme, preuve, cause et correction.