Migration PrestaShop Kubernetes : TLS, DNS et configuration multiboutique

Table des matières :

1. Architecture Kubernetes réaliste pour une migration PrestaShop multiboutique
2. TLS sur Kubernetes : terminaison, cert-manager, SNI et pièges PrestaShop
3. DNS : bascule contrôlée, propagation, ExternalDNS et stratégies multi-domaines
4. Configuration multiboutique PrestaShop derrière un Ingress : domains, URLs, cookies, reverse-proxy
5. Checklist opérationnelle de bascule : contrôle TLS, DNS et multiboutique (avec rollback)

Architecture Kubernetes réaliste pour une migration PrestaShop multiboutique

Une migration PrestaShop Kubernetes qui tient en prod ne se résume pas à “mettre le container derrière un Ingress”. Pour un socle viable, je pars ici sur PrestaShop 8.1.x ou 9.x, PHP 8.2/8.3 (vérifiez l’écart entre recommandations et réalité projet : PrestaShop 9 : versions PHP recommandées et incohérences de documentation), et Kubernetes ≥ 1.28. Côté composants, le trio qui conditionne directement TLS/DNS/multiboutique est : Ingress Controller (souvent ingress-nginx ou Traefik), cert-manager (gestion de certificats ACME), ExternalDNS (gestion des enregistrements DNS), plus un mécanisme sérieux de gestion des secrets (par exemple External Secrets Operator).

Kubernetes rappelle très clairement le rôle du point d’entrée HTTP : “An Ingress is an API object that manages external access to the services in a cluster, typically HTTP.” (Documentation : Kubernetes — Ingress). En pratique, l’Ingress Controller fait de la terminaison TLS, applique des règles host/path, et transmet ensuite au Service/Pod. Pour PrestaShop, ça veut dire : les en-têtes proxy (X-Forwarded-Proto, X-Forwarded-Host) sont désormais une dépendance fonctionnelle, pas un détail d’infra.

Avant d’attaquer TLS et DNS, stabilisez un environnement de test “prod-like”. Si vous n’avez pas déjà une base de comparaison reproductible, vous allez chasser des effets de bord (cookies, canonical, redirections, multiboutique) pendant la bascule. Construisez d’abord un staging conforme (images, configs, volumes, DB, Redis) via Staging PrestaShop : créer un environnement Docker fidèle à la production puis déclinez ce modèle en manifests/Helm. Et si votre plan de mise en prod n’est pas incrémental, vous jouez la boutique sur un kubectl apply : référez-vous à Migration PrestaShop : audit technique et plan incrémental blue/green.

Pour éviter le classique “tout marche sauf X”, je recommande de formaliser (même rapidement) une architecture cible minimale, par exemple sous forme de tableau. Ça clarifie aussi les responsabilités entre infra, dev et SEO :

Brique	Rôle en migration PrestaShop	Point de vigilance multiboutique
Ingress Controller	Terminaison TLS, règles host/path, redirections	SNI, host exact, headers X-Forwarded-*, tailles d’upload (images)
cert-manager	Provision/renouvellement certs ACME	SAN multiples / wildcard pour sous-domaines, rate limits
ExternalDNS	Crée/maintient A/AAAA/CNAME vers le LB	Ownership TXT, domaines autorisés, rollback
Redis	Cache + (souvent) sessions	Cohérence entre pods, TTL, taille mémoire
DB (MySQL/MariaDB)	Source de vérité (multiboutique = données)	Latence réseau, sauvegardes, migrations de schéma
Stockage (PVC / objet)	img/, thèmes, modules (selon stratégie)	ReadWriteMany rare : décider “build image” vs volume partagé
Observabilité	Détecter redirections, 5xx, expirations	Corréler par host (shop-a, shop-b)

Mini-scénario fréquent en France : une enseigne a 3 boutiques (B2C FR, B2C BE, B2B) qui partagent une même base, mais des domaines différents. Sur un cluster (ex. OVHcloud Public Cloud région GRA/Gravelines), vous gagnez à isoler dès le départ :

• un namespace par environnement (staging/prod),
• des Ingress séparés (au moins par environnement, parfois par gamme de boutiques),
• des secrets scindés (ACME + tokens DNS + credentials DB/Redis),
• et un plan de scalabilité : PrestaShop peut scaler en front, mais la base et les tâches (cron, indexation, modules) doivent être orchestrées proprement.

L’objectif ici est simple : quand vous abordez TLS/DNS, votre socle applicatif doit déjà être “prévisible”, sinon les symptômes (boucles HTTPS, contenu cross-shop) se confondent avec des problèmes de sessions, de cache ou de base de données.

TLS sur Kubernetes : terminaison, cert-manager, SNI et pièges PrestaShop

Dans une migration PrestaShop Kubernetes, le TLS se découpe en trois sujets : où vous terminez le TLS (Ingress / service mesh / app), comment vous provisionnez/renouvelez les certificats, et comment l’application réagit à la présence d’un proxy. L’approche la plus simple et la plus fréquente est une terminaison TLS au niveau Ingress avec un secret Kubernetes (kubernetes.io/tls). Le serveur applicatif (Apache/Nginx+PHP-FPM) reçoit du trafic HTTP interne, et doit déduire que le client final est en HTTPS via X-Forwarded-Proto=https. C’est exactement le point où PrestaShop casse si on ne “déclare” pas le proxy comme confiance.

Pour l’automatisation, cert-manager est le standard de facto : “cert-manager adds certificates and certificate issuers as first-class resource types in Kubernetes…” (Documentation cert-manager). Côté ACME, Let’s Encrypt résume son service ainsi : “Let’s Encrypt is a free, automated, and open Certificate Authority.” (Let’s Encrypt — À propos). Traduction opérationnelle : vous créez un ClusterIssuer ACME, puis des ressources Certificate par domaine (ou un wildcard). Attention aux limites de taux : Let’s Encrypt impose notamment des rate limits (ex. Duplicate Certificate limit et Certificates per Registered Domain), ce qui rend les itérations “delete/recreate” coûteuses si vous ne maîtrisez pas vos SANs. Doc : Let’s Encrypt — rate limits.

Deux pratiques très “terrain” réduisent le risque :

• Utiliser l’environnement staging Let’s Encrypt au début (certificats non reconnus par les navigateurs, mais parfaits pour valider DNS-01/HTTP-01 et éviter les rate limits), puis basculer en prod.
• Stabiliser les noms de secrets TLS (tls-multistore-example etc.). En migration, les secrets “jetables” compliquent le rollback et les comparaisons.

Le choix HTTP-01 vs DNS-01 n’est pas idéologique : il dépend de votre DNS et de votre besoin de wildcard. Pour une configuration multiboutique basée sur des sous-domaines (fr.shop.tld, de.shop.tld), DNS-01 + wildcard *.shop.tld simplifie la gestion de certificats (un secret, renouvellement unique), mais vous oblige à automatiser l’API DNS (ou à maintenir des tokens, donc des secrets). Pour des domaines indépendants (boutique-a.tld, boutique-b.tld), HTTP-01 fonctionne bien si chaque host pointe déjà vers l’Ingress au moment du challenge.

Sur l’axe SEO, le HTTPS est aussi un signal (léger) côté Google depuis 2014, et surtout une base de qualité (contenu mixte, canonicals, HSTS, chaînes de redirection). Référence : Google — HTTPS as ranking signal. Pour la partie audit et exigences SEO HTTPS, gardez une base de contrôle : HTTPS SEO : bonnes pratiques, certificats SSL et audit technique.

Exemple minimaliste (ingress-nginx + cert-manager) sur un host unique :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: prestashop
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/proxy-body-size: "64m"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "120"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "120"
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - shop.example.com
      secretName: tls-shop-example-com
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: prestashop
                port:
                  number: 80

Le point d’attention PrestaShop : si l’appli ne fait pas confiance au proxy, vous allez voir des symptômes typiques (boucles de redirection HTTP↔HTTPS, URL générées en HTTP dans le front/back-office, cookie Secure incohérent). Le correctif se joue à deux niveaux : (1) Ingress qui passe bien X-Forwarded-Proto (ingress-nginx le fait) et (2) PrestaShop/Symfony configuré avec des trusted proxies.

Sur PrestaShop 1.7/8, c’est généralement dans app/config/parameters.php (clé trusted_proxies). Sur PrestaShop 9, l’emplacement dépend de l’arborescence du projet (cf. changements Symfony 6.4 : PrestaShop 9 : nouveautés Symfony 6.4, Hummingbird et API Platform). Dans tous les cas : ne mettez pas 0.0.0.0/0 en prod “par flemme”, c’est une surface de spoofing sur les headers.

Checklist TLS spécifique à la migration (utile quand vous avez 5–20 domaines) :

• vérifier que SNI répond correctement : un host = le bon certificat = le bon contenu ;
• s’assurer que l’Ingress redirige vers une seule version canonique (http→https, avec ou sans www, mais pas les deux) ;
• valider la taille d’upload (proxy-body-size) pour éviter l’échec silencieux sur l’upload d’images produit ;
• décider si vous activez HSTS après la bascule (c’est efficace, mais un HSTS mal configuré rend le rollback navigateur plus pénible).

DNS : bascule contrôlée, propagation, ExternalDNS et stratégies multi-domaines

Le DNS est la partie la plus sous-estimée des migrations Kubernetes, parce qu’on confond “ça résout” avec “ça se bascule sans dégâts”. Pour une migration PrestaShop Kubernetes, le DNS doit permettre : (1) une bascule rapide (TTL bas), (2) une coexistence (blue/green, ou ancien LB + nouveau LB), (3) un rollback immédiat. Le schéma “je change l’A record le jour J avec TTL à 3600” est un classique… et un piège. Travaillez au moins 24–48h avant la bascule avec un TTL réduit sur les enregistrements concernés, puis remontez ensuite.

Sur OVHcloud (cas courant en FR), la mécanique TTL/propagation et les erreurs de zone (A/CNAME incompatibles, apex) sont détaillées ici : Zone DNS OVHcloud : propagation, TTL et bonnes pratiques de configuration. Dans une multiboutique, vous aurez souvent une combinaison :

• A/AAAA vers une IP publique de LoadBalancer (MetalLB, cloud LB) ;
• ou CNAME vers un nom de LB (cloud managé) ;
• parfois des contraintes d’apex (example.com) qui exigent ALIAS/ANAME chez certains DNS.

Ce n’est pas un détail : un mauvais design DNS entraîne des comportements “intermittents” (clients qui touchent l’ancien stack, Googlebot qui crawl un mix), donc des risques SEO et de cohérence de session.

Une méthode simple de bascule “propre” quand vous avez plusieurs domaines (et que vous voulez garder une porte de sortie) :

1. Créer un hostname technique côté nouveau cluster (ex. k8s-green.example.com) pointant vers le nouveau LoadBalancer.
2. Valider TLS + contenu sur ce hostname (même si ce n’est pas l’URL finale) : vous validez l’Ingress, le certificat, et la réponse applicative.
3. Le jour J, vous basculez les domaines finaux via CNAME/A vers le nouveau LB, avec TTL déjà bas.
4. Après stabilisation, vous remontez les TTL et vous conservez l’ancien LB quelques heures/jours (selon volume) pour rollback.

Si vous voulez arrêter de faire du DNS “à la main”, ExternalDNS permet de synchroniser automatiquement vos Ingress/Services vers votre provider DNS. Le bénéfice n’est pas magique : c’est surtout la réduction des erreurs humaines pendant une phase à fort stress. ExternalDNS reste une brique à traiter comme du code infra (RBAC strict, ownership via txtOwnerId, politique de domaines autorisés) et comme une brique sécurité (tokens d’API DNS en secret). C’est là qu’un opérateur de secrets (ex. External Secrets Operator + KMS) fait la différence, sinon vous finissez avec un token OVH qui traîne en clair dans un repo.

Exemple de pattern (indicatif) : vous laissez ExternalDNS piloter les enregistrements via annotation sur l’Ingress, plutôt que d’éditer la zone à la main :

metadata:
  annotations:
    external-dns.alpha.kubernetes.io/hostname: shop-a.example.com,shop-b.example.com
    external-dns.alpha.kubernetes.io/ttl: "300"

Pour une bascule propre, appliquez une méthode simple de validation DNS : dig +trace, contrôle des TTL, et vérification de la cohérence globale avant de toucher à l’ancienne infra. Exemple de contrôle (après changement) :

# Résolution + TTL
DIG="dig +noall +answer"
$DIG shop.example.com A
$DIG shop.example.com AAAA

# Vérifier la propagation via résolveurs publics (à adapter)
dig @1.1.1.1 shop.example.com A +noall +answer
dig @8.8.8.8 shop.example.com A +noall +answer

En prod, je vise un indicateur binaire et observable : “tous les résolveurs testés pointent sur le nouveau LB” + “le certificat servi correspond au bon host”. Tant que ces deux points ne sont pas vrais, le reste (sessions, BO, checkout) reste du bruit.

Configuration multiboutique PrestaShop derrière un Ingress : domains, URLs, cookies, reverse-proxy

La configuration multiboutique de PrestaShop n’est pas un simple mapping de hosts côté Ingress. La vérité est dans la base (table ps_shop_url principalement), et dans la manière dont PrestaShop fabrique ses URLs, cookies et redirections. PrestaShop documente la finalité de la fonctionnalité ainsi : “The multistore feature allows you to manage multiple stores from the same back office.” (PrestaShop — multistore). En Kubernetes, vous ajoutez une couche de complexité : la boutique n’est plus “le serveur”, c’est une appli derrière un proxy, et c’est souvent stateless (plusieurs pods).

Concrètement, la table ps_shop_url contient (selon versions) des champs du type domain, domain_ssl, physical_uri, virtual_uri, main. C’est ce mapping qui doit correspondre à vos règles d’Ingress. Avant la bascule, auditez vos URLs multiboutique :

SELECT su.id_shop, su.domain, su.domain_ssl, su.physical_uri, su.virtual_uri, su.main, su.active
FROM ps_shop_url su
ORDER BY su.id_shop, su.main DESC;

Points de contrôle concrets (souvent responsables de bugs “fantômes”) :

• domain / domain_ssl : doivent correspondre exactement au host attendu (sans schéma, sans slash). Une simple confusion shop-a.tld vs www.shop-a.tld peut déclencher des redirections ou un canonical inattendu.
• physical_uri : souvent / (mais pas toujours). Une différence entre / et /boutique/ se traduit immédiatement en chemins, et donc en règles d’Ingress (path prefix).
• main : si plusieurs lignes sont actives pour une boutique, vous pouvez servir du contenu “correct” mais avec des canonicals qui pointent ailleurs (mauvais domaine principal).
• active : en migration, on trouve parfois des URLs historiques “actives” qui n’ont plus de DNS : elles reviennent vous hanter au moment du crawl.

Si vous changez de stratégie (ex. passage de /fr/ à fr.example.com), vous n’êtes pas juste en train d’éditer du DNS/TLS : vous modifiez l’architecture d’URL, donc vous impactez redirections, canonicals, sitemaps, et probablement des modules. Traitez ça comme une migration SEO/URL, avec plan de redirections (sinon vous allez recréer les symptômes décrits dans SEO PrestaShop : checklist technique 2025 pour indexation et performance).

Côté Ingress, la multiboutique la plus stable est généralement multi-host, même backend : chaque domaine pointe vers le même Service PrestaShop, et c’est PrestaShop qui route en fonction du host. Exemple (deux boutiques, deux domaines, un seul service) :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: prestashop-multistore
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - shop-a.example.com
        - shop-b.example.com
      secretName: tls-multistore-example
  rules:
    - host: shop-a.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: prestashop
                port:
                  number: 80
    - host: shop-b.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: prestashop
                port:
                  number: 80

Le piège récurrent est le couple cookies + sessions. Par défaut, si vous scalez à N pods et que PHP stocke les sessions sur disque local, vous créez un “aléatoire” de connexion (BO/front) dès que la requête tape un autre pod. TLS/DNS peuvent être parfaits, la boutique semblera cassée. Deux options : sticky sessions au niveau Ingress (pas idéal : masquage de problèmes, scalabilité limitée) ou sessions externalisées (Redis, Memcached) avec une configuration applicative cohérente.

Autre piège multiboutique très fréquent en reverse-proxy : le “mauvais domaine dans le cookie”. Sans entrer dans le détail des modules, retenez ceci :

• si une boutique A et B partagent un domaine racine commun, un cookie mal scoping peut “déborder” (ex. .example.com) ;
• et si PrestaShop croit être en HTTP (proxy non approuvé), il peut émettre des cookies sans attribut Secure, ce qui perturbe la session en HTTPS.

Enfin, gardez en tête que PrestaShop évolue sur le multiboutique : par exemple PrestaShop 9.2 : Extra Properties natif pour champs multiboutique change la façon dont certains champs sont gérés multi-shop. Si vous migrez en même temps que vous upgradez (8→9), vous cumulez deux axes de risque. Le meilleur compromis reste : figer une version, migrer l’infra, puis upgrader.

Checklist opérationnelle de bascule : contrôle TLS, DNS et multiboutique (avec rollback)

Une migration PrestaShop Kubernetes se gagne sur les tests répétables et l’observabilité, pas sur la beauté des manifests. Le minimum côté supervision : métriques Ingress (codes HTTP, latence, rate), métriques applicatives (PHP-FPM, Redis, DB), et alerting sur expirations TLS. Pour l’alerting, Prometheus reste une base solide (voir Prometheus : configuration des alertes, métriques et requêtes PromQL), et pour une visibilité “terrain” rapide sur les serveurs/nœuds : Netdata : activer et configurer les collectors pour monitoring temps réel. L’objectif : détecter en 2 minutes une boucle de redirection, un TLS invalide sur un host, ou une hausse de 5xx pendant la propagation DNS.

Avant le jour J (pragmatique, et très efficace) :

• Lister tous les hosts (toutes les boutiques + variantes www si elles existent) et décider explicitement : lesquels doivent répondre, lesquels doivent rediriger, lesquels doivent 404.
• Baisser les TTL 24–48h avant sur les enregistrements qui basculeront.
• Pré-provisionner les certificats (ou au minimum vérifier que cert-manager sait émettre/renouveler) ; sur un multistore à 10 domaines, ce point évite des surprises pendant la fenêtre.
• Valider un crawl de contrôle (même basique) sur staging “prod-like” : canonicals, robots, sitemaps, et cohérence des domaines par boutique.

Pour la validation TLS/DNS, je recommande une batterie de tests CLI qui ne dépend pas du navigateur (donc pas de cache/extension) :

# Certificat présenté + SNI correct
echo | openssl s_client -servername shop-a.example.com -connect shop-a.example.com:443 2>/dev/null | openssl x509 -noout -issuer -subject -dates

# Redirection HTTP -> HTTPS et canonical host (à adapter)
curl -sI http://shop-a.example.com/ | egrep -i 'HTTP/|location:'
curl -sI https://shop-a.example.com/ | egrep -i 'HTTP/|set-cookie:|strict-transport-security'

# Vérifier qu’un host ne répond pas avec le mauvais contenu (multistore)
curl -s https://shop-a.example.com/ | head -n 30
curl -s https://shop-b.example.com/ | head -n 30

Deux contrôles Kubernetes simples, souvent oubliés, mais très utiles en bascule :

• état cert-manager : kubectl describe certificate -n <namespace> (expiration, renouvellement, erreurs ACME),
• logs Ingress (spécifiquement sur le host en erreur) : pour distinguer “mauvais backend” vs “mauvaise redirection”.

Pour la validation multiboutique, ne testez pas uniquement la home. Testez au moins : page produit, panier, login client, checkout, page BO (si exposée), webservice/API si utilisé. Et testez les invariants SEO : canonical, hreflang si multilingue, robots, sitemap. Les symptômes typiques d’un mapping ps_shop_url incorrect derrière Ingress sont : canonical qui pointe vers un autre domaine, contenu de la boutique A servi sur le domaine B, cookie domain incohérent, ou redirections surprenantes (301 en chaîne). En cas de doute, revenez au SQL ps_shop_url et vérifiez l’alignement host ↔ shop_id.

Le rollback doit être planifié au niveau DNS et au niveau Ingress. DNS : si vous avez baissé le TTL en amont, revenir sur l’ancien LB est un changement rapide. Ingress : si vous faites du blue/green via deux Ingress (ou deux namespaces) et un ExternalDNS piloté par labels, vous pouvez rebasculer en “dépubliant” l’Ingress vert plutôt qu’en touchant au DNS manuellement. Si vous n’avez pas ce mécanisme, vous allez modifier DNS dans l’urgence, exactement quand la propagation est la plus critique.

Après la bascule (les 2–24h qui comptent) :

• surveiller le ratio 301/302, 4xx, 5xx par host (sinon une boutique peut souffrir “dans le bruit” des autres) ;
• vérifier l’absence de contenu mixte et de canonicals incohérents ;
• remonter les TTL quand la situation est stable ;
• et documenter ce qui a été changé (Ingress annotations, secrets ACME, enregistrements DNS), pour que la prochaine bascule soit une routine.

Pour les risques transverses (secrets, WAF, supply chain), gardez aussi un cadre : PrestaShop : sécuriser APIs et modules avec SBOM, WAF et CI/CD.