Maîtriser le cycle de vie applicatif : les clés d'une montée de version réussie sans rupture de service (le cas d'une plateforme Gravitee installée avec des paquets RPM)

La montée de version d’une plateforme Gravitee apporte correctifs, sécurité et améliorations fonctionnelles. Installée par RPM, elle doit préserver la disponibilité des APIs, la configuration et les parcours d’authentification. La méthode repose sur une préparation, une mise à niveau progressive, des tests et un rollback vérifiable.

1. Périmètre et références

Le périmètre comprend APIM (Management API, Console, Portal et Gateway), Access Management, MongoDB, Elasticsearch, reverse proxy, certificats TLS, DNS, load balancer et services systemd. La validation suit Dev, Recette puis Production.

Figure 1 — Packages RPM Access Management 4.11.12. Les packages AM sont distincts : Management UI, Management API et Gateway. Vérifier chaque version.

Figure 2 — Référence officielle « Upgrade with RPM » : documentation APIM 4.11.

Figure 3 — Packages RPM APIM 4.9.12 : REST API, Portal UI, Management UI et Gateway.

2. Préparation obligatoire

• Confirmer versions source/cible, prérequis Java, breaking changes, plugins et policies.
• Inventorier les services, ports, fichiers gravitee.yml, certificats, secrets, DNS et health checks.
• Sauvegarder MongoDB APIM/AM ; tester la restauration avant la Production.
• Copier configurations, certificats, keystores/truststores ; exporter les versions RPM et plugins.
• Contrôler Elasticsearch et réaliser un snapshot si les analytics doivent être conservés.

Une sauvegarde qui n’a pas été restaurée en environnement de validation ne constitue pas un rollback fiable.

3. Mise à niveau contrôlée

L’approche composant par composant limite le risque et facilite le diagnostic. Ne pas redémarrer l’ensemble de la plateforme simultanément.

1. Management API : mettre à niveau, redémarrer, attendre la fin des migrations et contrôler les logs.
2. Management Console : mettre à niveau puis valider l’accès administrateur, les APIs, plans et applications.
3. Developer Portal : mettre à niveau puis vérifier catalogue, documentation et accès consommateur.
4. Gateway(s) : mettre à niveau progressivement ; retirer une instance du load balancer, tester, puis la remettre dans le pool. Avec une seule Gateway, le redémarrage peut créer une interruption : prévoir une fenêtre de maintenance ou une capacité de relève.

Commandes RPM indicatives

rpm -qa | grep -i gravitee
sudo yum check-update
sudo yum upgrade <paquet-gravitee>
sudo systemctl restart <service-gravitee>
sudo systemctl status <service-gravitee>
journalctl -u <service-gravitee> -f

N.B. : les deux versions APIM 4.9.12 et AM 4.11.12 sont compatibles.

4. Validation par environnement

En Dev puis en Recette : appliquer la séquence, comparer les configurations et tester avant toute Production. En Production, traiter les Gateways une par une et surveiller les logs, erreurs, disponibilité et latence.

Contrôles APIM

• Health checks, DNS et certificat TLS.
• Appel API de référence ; API Key valide/invalide ; JWT/OAuth2 (valide, expiré, scope insuffisant).
• CORS, rate limiting, quotas et policies critiques.
• Console, Portal, Management API et analytics.

Contrôles AM

• Login/logout, OAuth2/OIDC, callbacks, token et userinfo selon l’usage.
• SMTP, certificats, sessions et expiration.
• Enrôlement TOTP initial et challenge TOTP lors d’une nouvelle session.
• Domaines, clients, utilisateurs et rôles.

MongoDB et Elasticsearch

Après la migration, contrôler MongoDB via APIs, applications, abonnements et données AM. Pour Elasticsearch : état du cluster, index de trafic, ingestion d’un appel de test, absence d’erreur critique et délai d’indexation normal.

5. Rollback et checklist

Un downgrade RPM seul est insuffisant si MongoDB a été migrée. En cas d’échec : arrêter la progression, isoler la Gateway concernée, restaurer MongoDB pré-upgrade, restaurer configurations/certificats, réinstaller les RPM précédents, redémarrer les services puis rejouer les tests.

• ☐ Versions, prérequis et breaking changes validés
• ☐ Sauvegardes MongoDB et configurations disponibles et restauration testée
• ☐ Dev et Recette validés
• ☐ APIM, AM, OAuth2/OIDC, MFA et analytics testés
• ☐ Gateways renouvelées progressivement
• ☐ Critères de rollback et communication de fin approuvés

Conclusion

La réussite d’une montée de version Gravitee par RPM dépend d’un ordre maîtrisé — Management API, Console, Portal, puis Gateways —, de sauvegardes restaurables, de validations progressives et de tests complets APIM/AM. Cette démarche réduit le risque et garantit une opération réversible.

Références

• APIM Upgrade with RPM : documentation.gravitee.io/apim/4.11/upgrade-guides/upgrade-with-rpm
• Guides Access Management : documentation.gravitee.io/am/getting-started/install-and-upgrade-guides
• Dépôt RPM Gravitee : packagecloud.io/app/graviteeio/rpms