Comment appliquer un correctif à 40 sites Drupal sans avoir à effectuer 40 déploiements manuels

Standardisation du parc : mises à jour automatisées pour la gestion multisite

Il y a un type de mise à jour que les agences Drupal et les équipes d’entreprise redoutent particulièrement : une mise à jour de sécurité concernant un élément sur lequel tout le parc fonctionne, comme le runtime PHP, le moteur de base de données ou un service partagé, avec une version corrigée déjà disponible et une date limite à respecter. Pour une équipe qui gère un seul site, passer à la version corrigée, c’est une après-midi de travail. Pour une équipe gérant 40 installations Drupal réparties entre un portefeuille de clients ou une structure de filiales, c’est une course contre la montre avec 40 déploiements manuels à effectuer avant d’en avoir fini.

À la fin de la journée, la plupart des sites sont mis à jour. Quelques-uns ne le sont pas, parce qu’un problème est survenu en cours de route et qu’ils ont été relégués au second plan. Ces quelques sites restent dans la file d’attente, sans correctif, plus longtemps que prévu.

C’est là tout le problème de la gestion de parc. Ça ne concerne pas un site en particulier. Ça concerne ce qui se passe quand tu multiplies la charge de travail liée à la gestion d’un site par le nombre de sites du parc. Et ça ne concerne pas que Drupal : n’importe quel parc de sites fonctionnant avec la même stack se heurte au même mur, que ce soit Symfony, WordPress ou un frontend Node.js. Drupal n’est qu’un exemple concret ici.

Pourquoi la gestion manuelle d’un parc de sites n’est pas évolutive

Point clé à retenir : les mises à jour manuelles, ça marche pour un seul site. Pour un parc de sites, la charge de travail augmente linéairement avec le nombre de sites, tandis que le risque d’incohérence s’amplifie. Tout processus qui oblige une personne à répéter la même action 40 fois finira par laisser un site de côté.

L’approche standard pour gérer un parc d’installations de frameworks consiste essentiellement à répéter le même processus que pour une installation unique : se connecter à chaque site, appliquer la mise à jour, vérifier le déploiement, puis passer au suivant. Pour un parc de dix sites, c’est fastidieux. Pour un parc de cinquante, ça occupe quelqu’un pendant des jours. Pour un parc de deux cents, ça devient un poste à part entière.

La répétition n’est pas seulement coûteuse, elle est particulièrement source d’erreurs. Les processus manuels appliqués à grande échelle produisent des résultats incohérents, non pas parce que quelqu’un est négligent, mais parce que les humains ne peuvent pas appliquer exactement la même procédure de manière identique dans des dizaines d’environnements. Un site se retrouve avec une configuration légèrement différente. Un autre est oublié lors d’un déploiement qui a échoué et qui n’a pas été réessayé. Un troisième est mis à jour avec une version différente de PHP parce que la personne chargée de l’opération n’a pas vérifié le fichier de configuration.

Au départ, tous les sites sont identiques. Mais avec le temps, ils divergent. Des sites lancés à partir du même modèle il y a six mois tournent désormais avec des versions PHP différentes, des versions de services différentes et des configurations d’infrastructure différentes. Cette divergence passe inaperçue jusqu’à ce que quelque chose plante ; à ce moment-là, le débogage doit tenir compte du fait que le site qui plante ne correspond peut-être pas au site qui fonctionne.

La dérive des versions : un problème qui s’aggrave

Point clé : la dérive des versions au sein d’un parc n’est pas seulement un problème de maintenance. C’est une faille de sécurité et un obstacle au débogage. Un parc où chaque site utilise la même configuration est fondamentalement plus facile à sécuriser et à maintenir qu’un parc où chaque site est légèrement différent.

La dérive des versions a tendance à être considérée comme un problème superficiel, quelque chose à régler un jour ou l’autre, quand on aura le temps. En réalité, c’est un risque pour la sécurité et l’exploitation qui coûte de plus en plus cher à mesure qu’il persiste.

Du point de vue de la sécurité, un parc dont les niveaux de correctifs ne sont pas uniformes présente une surface d’attaque hétérogène. Une vulnérabilité corrigée sur 38 de tes 40 sites Drupal reste une vulnérabilité ouverte, car les deux sites non corrigés constituent de véritables cibles. La sécurité du parc dépend du site le moins bien corrigé.

Du point de vue du support, un parc où chaque site est légèrement différent signifie qu’une solution qui fonctionne pour un site peut ne pas fonctionner pour un autre. Pour déboguer un problème signalé, il faut d’abord déterminer ce qui tourne réellement sur ce site précis, ce qui peut différer de ce que tu penses qu’il y a, car le fichier de configuration a été mis à jour il y a six mois, mais ce site en particulier n’était pas inclus dans ce lot de déploiement.

La seule réponse viable au décalage de version, c’est de le rendre structurellement inutile : non pas en étant plus rigoureux sur les mises à jour manuelles, mais en rendant ces mises à jour inutiles dès le départ.

À quoi ressemble concrètement l’automatisation ?

Point clé à retenir : l’automatisation d’un parc de sites n’est pas un projet d’outils sur mesure. Il s’agit d’utiliser conjointement l’API de la plateforme et un fichier de configuration sous contrôle de version : la configuration définit ce que chaque site doit exécuter, et l’API applique cette définition à l’ensemble du parc sans intervention site par site.

Upsun est une plateforme en tant que service (PaaS) qui gère la couche d’infrastructure de ta pile d’applications pour que ton équipe n’ait pas à s’en occuper. Pour la gestion de flotte, ça signifie combiner un fichier de configuration partagé avec l’API Upsun pour propager automatiquement les changements sur tous les sites de la flotte.

Le fichier de configuration définit l’état cible pour chaque site. Une configuration de parc Drupal pourrait ressembler à ça :

applications:
  drupal:
    type: php:8.3                          # change this once to update the whole fleet
    variables:
      env:
        DRUPAL_HASH_SALT: "change-per-site" # overridden at the project level per site
    relationships:
      database:
        service: db
        endpoint: mysql
      cache:
        service: redis
        endpoint: redis

services:
  db:
    type: mariadb:10.11                    # platform manages patching within this version
  redis:
    type: redis:7.2

Quand PHP 8.3 doit passer à la version 8.4, ou que MariaDB a besoin d’une mise à jour de version, ce changement s’effectue dans le fichier de configuration. Une modification, un commit, une revue de code. Ensuite, un script parcourt tous les projets du parc et déclenche un déploiement :

import requests

API_TOKEN = "your-api-token"
FLEET_PROJECT_IDS = ["project-1", "project-2", "project-3"]  # or fetched dynamically via API

# Exchange the API token for a short-lived access token (valid ~15 minutes)
auth = requests.post(
    "https://auth.upsun.com/oauth2/token",
    auth=("platform-api-user", ""),
    data={"grant_type": "api_token", "api_token": API_TOKEN},
)
access_token = auth.json()["access_token"]

for project_id in FLEET_PROJECT_IDS:
    response = requests.post(
        f"https://api.upsun.com/projects/{project_id}/environments/main/redeploy",
        headers={"Authorization": f"Bearer {access_token}"},
    )
    if response.status_code in (200, 201, 202):
        print(f"{project_id}: redeploy triggered")
    else:
        print(f"{project_id}: redeploy failed - {response.status_code}")

Le script ne configure rien. Le fichier de configuration définit déjà l’état cible. Le script se contente de demander à chaque projet de l’appliquer. Chaque redéploiement est déclenché indépendamment, donc un projet n’attend pas l’autre, et le résultat te donne un aperçu clair des projets qui ont réussi et de ceux qui nécessitent une attention particulière.

Voilà à quoi ressemble la gestion d’un parc d’applications quand ce n’est pas un processus manuel. Le cycle de mise à jour est le suivant : modifier le fichier de configuration, le valider, puis exécuter le script. L’intervention humaine se limite à la décision de ce qu’il faut changer, pas à appliquer cette modification 40 fois.

Ce qu’une flotte homogène permet de faire

Point clé : un parc où l’on sait que chaque site exécute exactement ce qui est indiqué dans le fichier de configuration élimine toute une catégorie d’incertitudes au niveau des opérations, du support et de la sécurité. Tu n’as plus besoin de te demander « qu’est-ce que ce site exécute ? », tu le sais tout simplement.

Les avantages opérationnels d’un parc homogène vont bien au-delà du gain de temps sur les mises à jour.

Le support devient plus rapide car chaque site du parc a une configuration connue. Lorsqu’un client signale un problème, tu débogues l’application, pas l’environnement. L’environnement est identique à tous les autres environnements du parc.

La sécurité devient vérifiable. « Tous les sites tournent sous PHP 8.3.x avec la couche de service MariaDB 10.11 » est une affirmation que tu peux faire et vérifier, car le fichier de configuration est géré par contrôle de version et les journaux de déploiement de l’API confirment quels projets exécutent quelle version de celui-ci.

L’intégration d’une nouvelle filiale ou d’un nouveau site client dans la flotte, c’est simple. Fais un fork du fichier de configuration, personnalise les variables propres à chaque site (identifiants de base de données, configuration spécifique au site), puis déploie. Le nouveau site démarre avec la même base de référence que tous les autres sites de la flotte.

Et quand un avis critique tombe un vendredi après-midi concernant un environnement d’exécution ou un service dont le parc dépend, la réponse est simple : mets à jour le fichier de configuration, lance le script, vérifie le résultat. Pas besoin de 40 déploiements manuels.

Tu gères déjà un parc manuellement ?

L’approche par fichier de configuration ne nécessite pas de reconstruire les sites existants à partir de zéro. Le fichier de configuration décrit l’état cible ; la migration consiste donc simplement à noter ce que chaque site exécute déjà : la version de PHP, les services, les relations entre eux. Commence par un site qui servira de modèle, vérifie qu’il correspond à l’environnement de production, puis étends-le au reste de la flotte. La flotte commence à converger à partir du premier site qui passe à la nouvelle configuration.

Foire aux questions (FAQ)

Est-ce que tous les sites du parc doivent être identiques ?

Le fichier de configuration définit la base commune : version d’exécution, versions des services et configuration de l’infrastructure. Les variables propres à chaque site (identifiants de base de données, paramètres spécifiques à l’environnement, domaines personnalisés) sont configurées séparément pour chaque projet et remplacent ou complètent la configuration de base. Le parc peut partager une définition d’infrastructure commune tout en permettant à chaque site de rester configurable indépendamment.

Comment gérer le fichier de configuration sur une grande flotte sans monorepo ?

Une pratique courante consiste à utiliser un dépôt dédié, appelé « modèle de flotte », qui contient le fichier de configuration partagé. Les dépôts de chaque site récupèrent ou font référence à ce modèle. Lorsque le modèle est mis à jour, un pipeline d’intégration continue (CI) peut parcourir tous les projets enregistrés dans la flotte et déclencher des déploiements via l’API. L’API de la plateforme prend directement en charge ce modèle.

Que se passe-t-il si un déploiement échoue sur un site en cours de mise à jour de la flotte ?

L’approche par script signifie que chaque déploiement est indépendant. Un échec sur un projet ne bloque pas les autres. La sortie du script t’indique quels projets ont réussi et lesquels ont échoué, ce qui te donne une liste claire pour réessayer ou enquêter, plutôt que de devoir déterminer quels sites ont été atteints et lesquels ne l’ont pas été.

Peut-on revenir en arrière après une mise à jour de la flotte si quelque chose tourne mal ?

Oui. Comme le fichier de configuration est géré par contrôle de version, revenir en arrière revient à annuler la validation et à redéployer. Upsun conserve également l’historique des déploiements par environnement, ce qui permet de revenir en arrière sur des environnements individuels via la plateforme si nécessaire.

Comment gérons-nous les sites qui ont légitimement besoin d’une configuration différente du reste de la flotte ?

Les exceptions sont gérées au niveau du projet. Un site qui a besoin de PHP 8.2 alors que la flotte utilise PHP 8.3 par défaut peut le préciser dans son propre fichier de configuration, qui prévaut alors. Le principe est le suivant : un modèle partagé pour la base de référence de la flotte, des modifications par projet pour les exceptions justifiées. La différence principale par rapport à une approche entièrement manuelle, c’est que les exceptions sont explicites et documentées, plutôt qu’accidentelles.