Après plusieurs mois de qualification, nous avons le plaisir de vous annoncer la validation du passage en production de la version 3 de Traefik Proxy.
Cette mise à jour majeure apporte toujours plus de sécurité, de fonctionnalités et de suivi.
Ce dernier point nous a permis entre autre d'enrichir la gestion des routes sur vos domaines h8l.io :
Pour plus d'information sur les nouveautés de cette release :
Planning de migration
Comme à notre habitude, nous mettons tout en oeuvre pour minimiser votre intervention et éviter toute indisponibilité de vos services durant cette migration.
Vous serez notifiés des dates de réalisation des étapes suivantes sur notre status page (pensez à vous inscrire).
Si vous avez des remarques générales sur cette migration, vous pouvez commenter le ticket Traefik 3.0 prévu à cet effet.
Pour toutes autres questions liées spécifiquement à votre domaine, vous pouvez toujours nous envoyer un mail à hello@h8l.io.
Etape 1 : Migration de l'API group
Depuis la version 2.10+, l'API group des ressources Kubernetes de Traefik traefik.containo.us a été remplacé par traefik.io.
Cette étape est un prérequis nécessaire à la mise à jour en version 3.0 (référence).
Sur la version actuelle (2.11+), nous avons réalisé et qualifié une routine qui migre l'ensemble des ressources Traefik (IngressRoutes, Middlewares...) :
- Déployées dans le cluster kube.h8l.io
- Présentes dans les pipelines de déploiement sur cd.h8l.io
Aucune interruption de service n'a été constatée lors de cette étape en qualification.
Ce que vous avez à faire :
- Migrer l'API group de vos manifests, scripts, Helm charts... Vous pouvez le faire dès maintenant.
- Les deux API groups peuvent coexister dans la version actuelle, vérifier bien que vous ressources déployées Traefik n'existent que sous l'API group traefik.io. Vous pouvez le vérifier soit dans les CRDs Traefik du dashboard Kubernetes soit en ligne de commande, exemple : kubectl get ingressroutes.traefik.io et kubectl get ingressroutes.traefik.containo.us (cette dernière commande ne devrait pas retourner de ressources)
- Si vous en faites la demande, nous pourrons vous fournir le rapport de migration de votre domaine (incluant les ressources avant et après migration).
Etape 2 : Mise à jour en version 3
A ce jour, la version 3.0.4 est la première release à passer notre qualification.
Nous allons effectuer cette mise à jour en spécifiant le support de la syntaxe de définition des règles de routing au format v2 pour conserver la compatibilité avec les routes existantes.
Aucune interruption de service n'a été constatée lors de cette étape en qualification.
Ce que vous avez à faire :
Aucune action n'est requise de votre part.
Etape 3 : Migration des règles de routing en syntaxe v3
Nous avons réalisé une routine de migration des changements majeurs des règles de routing déployées et présentes dans vos pipelines de déploiement :
- Renomme respectivement HostHeader, Headers et HeadersRegexp en Host, Header et HeaderRegexp
- Si PathPrefix utilise une regex en argument, la règle est migrée en PathRegexp
- Si les règles Host, HostRegexp, Method, Path, PathPrefix, PathRegexp et ClientIP ont plusieurs arguments, elles sont migrées en plusieurs règles conditionnelles à un seul argument, exemple : Host(`d1.com`, `d2.com`) && PathPrefix(`/apis`) est migré en (Host(`d1.com`) || Host(`d2.com`)) && PathPrefix(`/apis`)
Cette routine devrait assurer la migration de la grande majorité des routes. Si nous avons un doute sur une des règles, vous serez notifiés pour participer à sa migration.
Aucune interruption de service n'a été constatée lors de cette étape en qualification.
Ce que vous avez à faire :
- Migrer les règles de vos manifests, scripts, Helm charts...
- Si vous en faites la demande, nous pourrons vous fournir le rapport de migration de votre domaine (incluant les ressources avant et après migration).
Etape 4 : Retrait du support de la syntaxe v2
Dans un second temps, nous retirerons le support de la syntaxe en version 2 au niveau global.
Vous pourrez toujours l'utiliser au niveau de vos routes jusqu'à ce que Traefik décide d'abandonner son support (sûrement en version 4).
Aucune interruption de service n'a été constatée lors de cette étape en qualification.
Ce que vous avez à faire :
- Si vous utilisez encore la syntaxe v2, configurez la au niveau de vos routes.
