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

Monter de version Traefik et revenir en arrière : de la 3.7.6 à la 3.7.15

Par mis à jour le

Améliorer cette page

Logo Traefik Proxy

Monter de version Traefik dans la série 3.7 est une opération courte, à condition de la préparer : lire les notes de chaque version intermédiaire, changer l'image épinglée, vérifier la réponse réelle du service et garder une définition de retour arrière prête. Les versions correctives d'une même série ne changent pas le modèle de configuration, mais elles corrigent des failles et modifient parfois un comportement précis. Cette leçon donne la méthode, pas une recette à copier.

La leçon suit l'ordre d'une fenêtre de changement : se renseigner, changer, vérifier, puis savoir défaire.

  • Lire des notes de version pour une série de correctifs.
  • Épingler une image par tag et digest.
  • Préparer un retour arrière avant de toucher au déploiement.
  • Vérifier la version active et la réponse réelle du service.
  • Distinguer une mise à jour corrective d'une migration majeure.

Cette leçon suppose que vous publiez déjà un service avec Traefik et que vous savez relancer un conteneur.

Un reverse proxy est le point par lequel passe tout le trafic : une mise à jour ratée se voit sur tous les services publiés. C'est aussi le composant exposé à Internet, donc celui dont les failles sont corrigées le plus vite. Deux risques se tirent donc en sens opposé : ne pas mettre à jour expose à une faille connue, mettre à jour sans précaution expose à une panne.

La méthode consiste à rendre le changement petit, lisible et réversible. Petit, parce qu'on ne change que la version de l'image. Lisible, parce que la nouvelle version est écrite en clair dans le fichier de déploiement. Réversible, parce que la version précédente reste définie et que l'on sait la remettre en place.

Lisez les notes de toutes les versions comprises entre la vôtre et la cible, pas seulement la dernière. Un changement de comportement peut figurer dans une version intermédiaire et ne plus être rappelé ensuite. De la 3.7.6 à la 3.7.15, cela représente neuf versions à parcourir sur la page des versions du dépôt traefik/traefik.

Quelques changements de cette série montrent ce qu'il faut chercher.

  • La 3.7.9 et la 3.7.15 modifient le traitement des requêtes CONNECT : elles sont rejetées ou différées. Un client qui passe par un tunnel CONNECT doit être testé.
  • La 3.7.12 ajoute le nom du fichier dans les erreurs du fournisseur fichier, ce qui facilite le diagnostic d'une route mal écrite.
  • Les 3.7.13 et 3.7.14 changent le comportement du challenge ACME DNS et de la bibliothèque lego qui le porte : vérifiez-les si vous utilisez DNS-01.
  • Plusieurs versions renvoient au guide de migration de la série 3 : lisez la section de la version concernée avant de continuer.

Écrivez la version et le digest dans le fichier de déploiement, jamais un tag flottant. Un tag comme v3.7 désigne une image qui change au fil des publications : le même fichier ne produit plus le même proxy d'un jour à l'autre. Le digest sha256:… désigne au contraire une image unique et immuable.

services:
traefik:
image: traefik:v3.7.15@sha256:0f6150202bc1fed72a7bd2107460eaa510e5b8a905f3fdb5b84f2c8619c33368

Ce fichier dit exactement quelle version tourne et permet à n'importe quel collègue de rejouer la même opération. Le digest d'une version se lit sur la page de l'image dans le registre ; recopiez-le depuis cette source, pas depuis un message de conversation.

Le retour arrière se prépare avant la mise à jour : il suffit de garder la définition de la version précédente. Dans un dépôt de déploiement, c'est un commit précédent. Sur un hôte sans dépôt, c'est une copie du fichier de déploiement à côté de l'original, avec l'image de la version qui fonctionnait.

Trois points rendent ce retour fiable.

  • Gardez l'ancienne référence complète, tag et digest, pas seulement un numéro de version.
  • Vérifiez que l'ancienne version sait relire la configuration actuelle. Un retour vers une version qui ne comprend pas un champ récent échoue.
  • Répétez le retour arrière une fois, hors urgence : un retour jamais joué n'est pas une procédure, c'est une hypothèse.

Une mise à jour est réussie quand la version active est la bonne et que le service répond comme avant, pas quand le conteneur est simplement démarré. Deux vérifications se complètent.

La première lit la version réellement active, par la commande traefik version exécutée dans le conteneur ou par le tableau de bord de lecture. La seconde envoie une requête réelle avec curl sur le nom publié et contrôle le code, le certificat et le contenu de la réponse.

Fenêtre de terminal
docker compose exec traefik traefik version
curl -sS -o /dev/null -w '%{http_code}\n' https://app.example.test/

Si la version est la bonne mais que la réponse a changé, la montée de version n'est pas en cause en premier : relisez le journal d'accès, puis les notes de la version fautive.

Une migration majeure est un autre exercice : le modèle de règles de routage change, et le guide officiel de migration prévoit trois étapes. Il s'agit de préparer la configuration existante en gardant la syntaxe de règles de la v2, de migrer la production progressivement avec un plan de retour arrière, puis de migrer la configuration de routage progressivement.

Cette leçon reste dans la série 3 : la mise à jour de la 3.7.6 à la 3.7.15 ne fait pas intervenir ces changements incompatibles. Le guide de migration vous sert de contexte pour une future version majeure, et ses étapes confirment le principe de cette leçon : avancer par petits pas, et garder le chemin du retour.

Mettre en pratique : monter de version et prouver le retour arrière

Section intitulée « Mettre en pratique : monter de version et prouver le retour arrière »

Le lab part d'un point d'entrée sous Traefik 3.7.6 dont le service publié ne répond plus. Il vous demande de lire la situation, de passer à la 3.7.15 avec l'image épinglée, de remettre la route attendue et de conserver une définition de retour arrière. Le contrôle exécute ensuite ce retour, vérifie que l'ancienne version sert le trafic, puis restaure la version mise à niveau.

Une montée de version se juge sur la réponse du service, pas sur le démarrage du conteneur.

  • Lisez les notes de toutes les versions intermédiaires.
  • Épinglez l'image par tag et digest, jamais par un tag flottant.
  • Préparez et répétez le retour arrière avant la mise à jour.
  • Vérifiez la version active puis la réponse réelle du service.
  • Une migration majeure v2 vers v3 suit le guide officiel, en trois étapes progressives.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

8 questions
8 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