De plus en plus de projets utilisent la conteneurisation comme outil d’accélération du déploiement de systèmes informatiques. Malheureusement ces nouvelles technologies autour de la conteneurisationsont pas sans impacts sur l'architecture de la solution mise en place et quand aux choix à réaliser avant de démarrer un projet.

Voici un ensemble de questions que je juge pertinents de se poser avant de démarrer un projet avec des containers Docker. Les containers apportent de nouveaux paradigmes auxquels nous n'avons pas encore suffisamment de reculs pour adopter des réflexes naturels.

1. Qui va déployer les patchs de sécurité sur les containers livrés ?

Si l'équipe de développement a en charge la livraison des images, il est donc nécessaire donc mettre en place une gouvernance commune avec les OPS quant aux mises à jour des patchs de sécurité des containers. Cela peut signifier une charge plus importante pour l'équipe de développement lors de la phase de maintenance applicative.

2. Combien de ressources physiques mes images vont consommer en production ?

Créer des containers et les déployer de manière magique sur un cluster c'est super, faut-il encore se poser la bonne question : de combien de ressources physiques ont besoin mes containers pour fonctionner ? Il faut se poser cette question dès le démarrage du projet pour anticiper les coûts d'infrastructure et anticiper les besoins en CPU / IO / RAM de chacun des containers.

L'erreur est de surcharger des machines physiques avec trop de containers et voir les performances de son application s'écrouler à cause du nombre de threads sur chaque container et la consommation mémoire des processus démarrés. L'autre erreur commune est de surestimer les I/O d'un NAS, trop de containers sur un même NAS peut créer des performances désastreuses en écriture.

3. Quelle stratégie de sauvegarde dois-je envisager ?

Comment mes données sont sauvegardées / mutualisées entre les containers ? Quelle solution NAS de haute performance dois-je retenir pour permettre à tous mes containers de mutualiser des données ? Dois-je plutôt mettre en place du Rsync ? Dois-je sauvegarder l'état de mes containers régulièrement ? Ou alors créer des volumes persistants sur mon hôte Docker ?

4. Quelle stratégie de déploiement dois-je prévoir pour atteindre les engagements de SLA pris ?

Dois-je favoriser une stratégie de déploiement de type Blue/Green pour permettre de l'AB testing ? Ou alors, dois-je réaliser un déploiement en mode "big-bang" sur mon cluster ?

5. Est-ce que l'architecture réseau mise en oeuvre respecte les principes de sécurité ?

Est-ce que l'architecture réseau entre les containers est bien multicouche ? Est-ce que les ports ouverts entre les containers sont correctement maîtrisés pour assurer une sécurité suffisante ?

6. Comment vais-je livrer et versionner mes containers pour les OPS ?

Qui met en place un registry docker ? Est-ce une fourniture des OPS ou de l'équipe de DEV ? Quelle stratégie de versionning mettre en oeuvre sur mes containers ? Dois-je versionner mes images depuis mon intégration continue à chaque build ou depuis ma plateforme de recette dès lors que mon container a atteint un niveau de qualité correcte pour partir en préproduction ?

7. Comment seront supervisées les ressources consommées par chacun de mes containers ?

Quels outils doivent être déployés pour superviser chacun des containers et permettre d'identifier les containers plus consommateurs en ressources que d'autres ? Comment mettre en place une stratégie de supervision sur les ressources consommées par mes containers ?

8. Quelle stratégie ai-je prévue pour assurer une redondance applicative de mes composants ?

Comment est assurée la haute disponibilité des mes containers ? Quelle stratégie de réplication active/active ou redondance, ai-je mis en place pour assurer la haute disponibilité de l'ensemble de ma solution ?

9. Quelle solution d'Auto-scalling ai-je prévue pour permettre de bénéficier de l'élasticité du cluster hébergeant mes containers ?

Comment sera gérée les montées en charge et baisse de charge sur la solution ? Comment j'utilise au maximum les fonctions de containérisation pour réduire les coûts d'infrastructure de la solution ? Quelle solution d'orchestration de mes containers dois-je déployer en production ?

10. Quelle solution de distribution de charge dois-je mettre en place au-dessus de mon cluster ?

Comment distribuer la charge réseau sur l'ensemble de mon cluster de manière uniforme ? Comme s'assurer que la distribution du trafic réseau dépend du bon fonctionnement de l'application adressée ? En cas de "failover", est-ce que la session de l'utilisateur sera correctement accessible au travers de l'autre nœud qui reprendra la session de l'utilisateur ?


Bref, voici une liste de questions clefs, malheureusement les réponses à ces questions dépendront beaucoup du contexte de votre projet et des enjeux métiers. Les choix pris pour répondre à chacune de ces questions peuvent avoir des impacts financiers importants sur votre projet, il est important de se les poser dès le démarrage de votre projet pour éviter des dépassement non maîtrisés sur le budget de votre projet.

1. Le , 09:42 par Xfennec
857bb444bcf8f3f3eedb6edf97d8b782

Super intéressant, merci. Ca permet de remettre quelques pendules à l'heure.

Juste une question : tu parles d'archi réseau multicouche entre les conteneurs. Concrètement, il s'agit de quoi ?

2. Le , 22:51 par Ludovic
9ab09dd3e305f924f8930e20e1a35843

Merci Julien !

Quand au réseau "multicouche", je ne pensais aux empilements de switch cybertek que l'on faisait quand on était jeune ;-)

Mais plutôt à la création de réseaux virtuels pour séparer chaque couche applicative :
- Réseau frontend : Communication vers les systèmes tiers
- Réseau middle : Communication entre services
- Réseau back : Communication avec les sources de données

3. Le , 09:05 par Xfennec
857bb444bcf8f3f3eedb6edf97d8b782

OK, c'est logique, on parle de couche au niveau applicatif. Merci pour la précision !

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.