Conclusion

Presque 10 ans ! C'est le temps qu'il m'aura fallu pour enfin terminer mon brevet principal. Après un premier projet avorté qui avait pour thème le développement agile dans le projet Portail, j'ai finalement abouti à quelque chose que je pense être « montrable » avec cette infrastructure Docker Swarm.

J'ai en tous cas beaucoup appris lors de la réalisation de ce brevet et il y a encore énormément de choses que j'aurais aimé aborder et expérimenter (les contextes Docker qui permettent de contrôler plusieurs environnements Dockerdepuis une même machine, les labels sur les noeuds du Swarm pour une gestion plus fine du cluster et des déploiements, la manière dont Docker et Docker Swarm ont accéléré le développement du Portail UCLouvain...). Mais à un moment, il a bien fallu faire des choix sans quoi ce document n'aurait jamais été terminé.

J'ai aussi exploré des pistes que j'ai dû abandonner, mais dont j'ai laissé le contenu en annexe car elles pourraient servir à d'autres équipes.

Accomplissements

La mise en place de mon infrastructure de démonstration et sa duplication pour différents projets ont montré que des infrastructures basées sur Docker Swarm tenaient la route que ce soit pour du développement (projet Portail) ou de la production (bibliothèques et bientôt le Portail). Pour ma part, j'utilise Docker et Docker Swarm sur ma machine locale pour la quasi-totalité de mes projets de développement ou de déploiement.

Je pense avoir montré que Docker Swarm est un environnement à la fois puissant et simple à mettre en place et à utiliser. Ses possibilités sont énormes depuis le déploiement sur la machine locale d'un développeur, jusqu'au cluster multi-noeud, et depuis l'hébergement d'applications web jusqu'aux pratiques CI/CD.

Docker et les conteneurs s'intègrent de plus parfaitement dans les pratiques agiles ou les cycles de livraison court, et simplifient la déploiement, la maintenance et la mise à jour des infrastructures. Ils permettent un partage de pratiques et d'outils depuis les développeurs jusqu'aux équipes de production. Les fichiers de déploiement de piles applicatives permettent une grande souplesse et la déclinaison d'une même pile applicative sur différents environnement de production.

Difficultés rencontrées

J'aimerais dire un petit mot concernant les difficultés que j'ai rencontrées durant ce projet.

Outre la crise COVID ou les difficultés rencontrées dans le projet Portail, qui ont fortement impacté mon travail sur ce brevet et sur lesquels je ne m'étendrai pas, d'autres éléments plus spécifiques ont contribué à retarder la réalisation de mon projet.

Tout d'abord, la mise en place d'un cluster de test avec Vagrant, bien que très intéressante d'un point de vue technique (voir Annexes), s'est révélée plus compliquée que je ne l'avais anticipé. Heureusement, la possibilité de déployer un Swarm Docker sur ma machine locale a débloqué la situation et m'a permis de rattraper rapidement le temps perdu.

Les bouleversements qui ont touché le monde de Docker en 2019 m'ont durant un temps fait envisager l'abandon de Docker au profit d'une autre technologie comme Rancher ou Kubernetes. Cette situation était d'autant plus problématique que j'avais déjà bien avancé sur la piste Docker Swarm et que la mise en place d'un banc de test local pour Kubernetes s'est révélée des plus ardues. En effet, une grande partie des tutoriels et de la documentation que j'ai pu trouver ne fonctionnait tout simplement plus avec les dernières versions de ces technologies ! Après quelques semaines perdues sur cette piste, la fin de la période de doute autour de la survie de Docker Swarm a finalement débloqué la situation et m'a permis de reprendre mon idée originale.

Toutefois, ces pertes de temps m'ont demandé de revoir une partie de mon document (en particulier la mise en place de mon infrastructure de démonstration), tant les technologies que j'utilise évoluent rapidement et avaient rendu une partie de mon travail obsolète.

Heureusement, et malgré quelques longues périodes de doute, de découragement et de questionnement, j'ai pu mener ce projet à terme !

Améliorations

Il reste des améliorations à effectuer sur mon infrastructure pour la rendre 100% prête pour la production, mais celles-ci pourront être faites au fur et à mesure de son utilisation et des besoins.

La plupart d'entre elles ont été listées dans la section Perspective, mais je pense important de revenir ici sur les principales.

Le premier point qu'il reste à résoudre est le plus important : il s'agit de la question du stockage redondant. En effet, à ce stade, l'export du système de fichier via NFS depuis l'un des managers constitue un "single point of failure" pour l'infrastructure. Je n'ai pas encore trouvé d'alternative offrant des performances suffisantes pour l'écriture des fichiers. Une piste serait l'utilisation de Ceph FS, mais les tests demandent la mise en place d'un cluster Ceph qui aurait pris trop de temps dans le cadre de ce brevet.

Un autre point concerne la gestion des images Docker et le registre qui les stocke. Dans une infrastructure de production, il est indispensable d'avoir un plus grand contrôle sur les images Docker déployées et exécutées. En particulier, la mise à jour des images Docker est un enjeu crucial pour la sécurité. Des images trop anciennes peuvent en effet contenir des failles de sécurité mettant en danger l'ensemble de l'infrastructure. L'utilisation d'un registre centralisé couplés à des outils de CI/CD pour les images maison et à des outils de mise à jour automatique d'images (comme Watchtower) pour les images "officielles" pourraient constituer une piste de solution.

Un troisième point d'attention concerne les plages d'adresse IP pour les réseaux internes de Docker qui peuvent entrer en collision avec celles utilisées dans les Data Center. J'ai déjà eu une discussion avec SIPR à ce sujet et certaines plages d'adresse sont réservées pour Docker. Il faudra toutefois vérifier si ces plages sont suffisantes et configurer les infrastructures pour les utiliser.

Malgré ces points non résolus, je pense que mon travail constitue une bonne base sur laquelle de futures infrastructures pourront être construites.

L'avenir

Il faut également regarder vers le futur. Docker a été la technologie de conteneur la plus populaire durant de nombreuses années. Mais d'autres solutions, portées par des acteurs majeurs, s'imposent peu à peu comme des nouveaux standards, Kubernetes en tête. Des alternatives à Docker lui-même se développent, par exemple Podman qui est l'outil de référence pour le déploiement d'un cluster Ceph. Le cloud a également fortement transformé les pratiques avec des outils comme Terraform qui permettent de définir les infrastructures sur base de code (paradigme "infrastructure as code" dont j'ai déjà parlé). D'autres comme Open Shift intègre l'entièreté de la gestion d'un cloud d'entreprise dans une solution.

Il faudra donc suivre l'évolution du marché dans les années qui viennent pour voir quelles solutions s'imposeront.

Remerciements

Je tiens tout d'abord à remercier mon collègue Mike De Man avec qui j'ai pu explorer les possibilités offertes par Docker pour le portail UCLouvain et sans lequel ce brevet n'aurait peut-être pas existé. Un grand merci à mes collègues Laurent Dubois, Raphaël Lebacq, Laurent Grawet, Fabrice Charlier, Olivier Delcourt, ainsi que les membres du groupe de travail Docker que nous avons mis en place, et dont les apports ont enrichi mon travail.

Je tiens également à remercier François Micaux qui m'a conforté dans mes choix techniques lors de la formation Docker qu'il a animée pour les équipes du SGSI et qui m'a permis d'améliorer ma maîtrise de Docker.

Je remercie aussi mon coach Thomas Keutgen dont les conseils et le soutien m'ont permis de mener à bien ce brevet, ainsi que mon évaluateur Jean-Luc Martou pour ses encouragements à terminer mon projet.

Et bien entendu, je remercie Valérie qui m'inspire tous les jours.