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] :

1. Un cluster contenant toutes les instances de production

2. Un cluster contenant toutes les instances de staging et sandbox

3. 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.