Skip to content
Extraits de code Groupes Projets
Valider 4addb068 rédigé par Frédéric Minne's avatar Frédéric Minne
Parcourir les fichiers

conclusion : difficultés + version finale à relire

parent a5053383
Aucune branche associée trouvée
Aucune étiquette associée trouvée
Aucune requête de fusion associée trouvée
# Conclusion # Conclusion
J'ai appris beaucoup lors de la réalisation de ce brevet et y a encore énormément de choses que j'aurais aimé aborder et expérimenter dans ce brevet (les contextes Docker, les labels sur les noeuds du Swarm...). 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 de ce brevet car elles pourraient servir à d'autres équipes. 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 et qui a bien failli me faire abandonner purement et simplement mon brevet, j'ai finalement abouti à quelque chose que je pense être « montrable » avec cette infrastructure Docker Swarm.
La mise en place de mon infrastructure de démonstration et sa duplication pour différent projet 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). 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 de ce brevet, car elles pourraient servir à d'autres équipes.
## Accomplissements
La mise en place de mon infrastructure de démonstration et sa duplication pour différent projet 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. 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 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. Docker et les conteneurs s'intègrent 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 pour mener à bien 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 (rachat par Mirantis et rumeurs d'arrêt de Docker Swarm,) m'ont durant un temps fait envisager l'abandon de Docker au profit de Kubernetes. Toutefois, la constitution d'un banc de test local avec Kubernetes s'est révélée des plus ardues et les outils de déploiement d'un cluster local se sont révélés un peu limité pour l'objectif de mon brevet. 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.
Ces pertes de temps m'ont demandé de revoir plusieurs fois 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 mon travail obsolète.
Heureusement, 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 points à résoudre pour la mise en place d'une infrastructure 100% prête pour la production, mais ceux-ci pourront l'être au fur et à mesure de son utilisation et des besoins. Il reste des points à résoudre pour la mise en place d'une infrastructure 100% prête pour la production, mais ceux-ci pourront l'être au fur et à mesure de son utilisation et des besoins.
Le problème point qu'il reste à résoudre est la question du stockage redondant. En effet, à ce stade, l'export du système de fichier via NFS depuis l'un des manager 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. Le premier point qu'il reste à résoudre est 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 problème 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 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 que ces plages sont suffisantes et configurer les infrastructures pour les utiliser. 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 que 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 les autres équipes pourront construire leurs propres infrastructures. Malgré ces points non résolus, je pense que mon travail constitue une bonne base sur laquelle les autres équipes pourront construire leurs propres infrastructures.
## L'avenir
Mais 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 de 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"). D'autres comme Open Shift intègre l'entièreté de la gestion d'un cloud d'entreprise dans une solution. Mais 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 de 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"). 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. Il faudra donc suivre l'évolution du marché dans les années qui viennent pour voir quelles solutions s'imposeront.
...@@ -30,4 +54,4 @@ Je tiens également à remercier François Micaux qui m'a conforté dans mes cho ...@@ -30,4 +54,4 @@ Je tiens également à remercier François Micaux qui m'a conforté dans mes cho
Mon coach Thomas Koetgen dont les conseils et le soutien m'ont permis de mener à bien mon brevet. Mes évaluateurs Freddy Gridelet, même s'il n'a pas pu accompagner ce projet jusqu'au bout, et Jean-Luc Martou pour ses encouragements à terminer mon projet. Mon coach Thomas Koetgen dont les conseils et le soutien m'ont permis de mener à bien mon brevet. Mes évaluateurs Freddy Gridelet, même s'il n'a pas pu accompagner ce projet jusqu'au bout, et Jean-Luc Martou pour ses encouragements à terminer mon projet.
Et bien entendu Valérie qui m'inspire tous les jours. Et bien entendu Valérie qui m'inspire tous les jours.
\ No newline at end of file
0% Chargement en cours ou .
You are about to add 0 people to the discussion. Proceed with caution.
Terminez d'abord l'édition de ce message.
Veuillez vous inscrire ou vous pour commenter