En octobre 2019 nous avons lancé notre campagne “Numigi adopte le K”. L’un des axes de cette campagne, visait une évolution majeure de l'infrastructure qui héberge nos applications.
Avantages escomptés
À ce moment, nous avions déjà identifié la solution Kubernetes.
C'était de facto la solution recommandée pour orchestrer des applications dans le cloud.
Nous espérions bénéficier (et par la même occasion, faire profiter nos clients) des avantages suivants par rapport à cette future infrastructure :
Faciliter l'inventaire de ressources à maintenir en réduisant le parc (machines virtuelles, certificats, noms de domaines, etc)
Réduire la quantité de scripts de déploiement et de maintenance
Éviter les partages de clés ssh artisanaux entre les machines virtuelles
Centraliser la gestion des accès
En effet, durant les mois suivants, après avoir migré différentes applications vers Kubernetes, nous avons constaté ces différents avantages.
Un an plus tard, la grande majorité de nos instances Odoo sont sur Kubernetes.
Nous constatons que :
Le temps passé en maintenance de l'infrastructure est fortement réduit
Le temps de mise en production et de staging est amélioré
La performance des instances Odoo est équivalente à celle des instances sous l'ancienne infrastructure
Remplacer les instances
Un autre point très intéressant est que les machines virtuelles peuvent être remplacées en moins de deux minutes ; même pour les instances de production.
Par exemple, on pourrait vouloir remplacer 3 machines à 32Go de RAM par 2 machines à 64Go.
Sous l'ancienne infrastructure, ce genre de choix était structurant.
Aujourd'hui, c'est du détail.
Choix d'architecture
Au démarrage du projet, nous avions certains choix structurants à faire. Nous avons recherché des spécialistes dans notre réseau. Puis, nous nous sommes appuyés sur les conseils d’experts identifiés et sélectionnés par la plateforme Pige.Québec à l’initiative d’Alexandre Comtois.
Pour le projet dans sa globalité et afin de faire des choix éclairés, nous avons été accompagnés par notre partenaire Québecois, Julien de Kumojin
Répartition des ressources
Le plus important était de définir combien de clusters seraient créés et qu'est-ce que ceux-ci contiendraient.
Différentes approches ont été évaluées.
Nous avons finalement tranché pour 3 clusters [1] :
Un cluster contenant toutes les instances de production
Un cluster contenant toutes les instances de staging et sandbox
Un cluster contenant nos outils internes
Les raisons de ce choix sont les suivantes :
Isoler les instances de production
Pouvoir tester une nouvelle configuration sur le cluster de staging avant de l'appliquer en production
Les noeuds de la production sont plus performantes (plus de RAM, plus de CPU)
Solution rejetée
Une solution alternative était d'avoir un cluster séparé pour chaque client de Numigi.
Nous avons rejeté cette alternative : l'administration de chaque cluster Kubernetes additionnel demande un effort additionnel en maintenance d'infrastructure. Cela, au même titre qu'une machine virtuelle gérée manuellement.
En contraste, créer un nouveau namespace dans un cluster existant ajoute très peu d'efforts en maintenance.
Sauvegardes automatisées
La capacité de sauvegarder les données efficacement et de manière simple était un besoin essentiel dans la nouvelle infrastructure.
Des sauvegardes des bases de données de production sont faites toutes les heures.
Ces sauvegardes sont automatiquement distribuées vers des objects storages.
Elles peuvent ensuite être utilisées pour restaurer les instances de staging.
Le fait d'avoir tous nos clients hébergés sur le même cluster nous permet de réutiliser les mêmes ressources pour la distribution des sauvegardes.
Ingress Nginx
Pour les certificats HTTPS, nous utilisons Certmanager [2] en combinaison avec le contrôleur ingress nginx [3] de Kubernetes.
Cette solution permet de gérer de façon automatisée la création et le renouvellement des certificats Let's Encrypt [4]
Au niveau DNS, nous utilisons des sous-domaines avec wildcard [5]
Par exemple, toutes les instances de productions ont un sous-domaine qui leur est dédié.
De cette façon, chaque service additionnel sur le cluster ne demande pas d'entrée DNS à créer manuellement.
Monitoring
Pour la surveillance de l'infrastructure, nous avons opté pour la solution open source Prometheus [6] (avec Grafana [7] pour les dashboard).
Le but de ce système est de nous donner une meilleure visibilité sur l'utilisation des ressources sur les clusters et de recevoir des alertes automatiques selon différentes métriques.
Conclusion
Après un an, nous sommes satisfaits d'avoir entrepris le virage vers une infrastructure orchestrée par Kubernetes.
Les investissements et le temps passé en maintenance de l'infrastructure sont à faible valeur ajoutée pour nos clients.
On souhaite donc avoir une infrastructure flexible et facilement maintenable.
Cela nous permet de passer plus de temps sur des activités à valeur ajoutée, comme la conception et
le développement d'applications.
Liens et références