It Runs on My Cluster - II - Les débuts
Deuxième blog post de la série It Runs on My Cluster

II - 😇 Les débuts
Ma découverte de Docker et ensuite de Kubernetes n'a pas été de tout repos.
Étape 1 : Docker, j'ai d'abord commencé avec Docker sur mon poste Windows puis sur des serveurs sous Linux (Ubuntu, Debian et Redhat). Les concepts me paraissaient assez simples, on créé un Dockerfile, on lui donne notre recette avec une image de base et on lui précise ce que l'on veut mettre dedans et hop 🚀 en envoie ça sur DockerHub et le tour et joué. Ensuite on lance la commande docker run
et c'est réglé. Enfin presque, car je n'ai pas partagé de volume, pas partagé de port réseau donc il faut encore un peu de configuration. Finalement une fois que c'est fait ça fonctionne bien, j'ai mon frontend qui est correctement servie et je suis content.
Étape 2 : DockerCompose, après avoir démarré un conteneur dans un coin je voulais avoir une application complète. Je voulais donc que mon frontend, mon backend et ma base de données tournent chacun dans leur conteneur et surtout qu'ils puissent communiquer ensemble. Pour cela je suis passé à DockerCompose, je faisais des choses assez simple et là encore ça fonctionnait pas mal. Quand je mettais à jour mon applicatif je faisais le même processus en modifiant le tag de mes images et c'était fini. Artisanal mais fini! Dans tout ce que j'évoque ici, je suis dans une optique d'expérimentation pas encore de production.
Déjà après ces deux étapes j'étais persuadé que c'était l'avenir, à la fois pour le développement où je peux jouer avec différentes versions de mon application et des middlewares mais aussi sur mon environnement d'expérimentation où je démarrais simplement mon application sans installer pleins de packages sur mes machines.
Surtout qu'à cette époque je connaissais un peu Linux mais ma principale qualité c'était de casser mes machines virtuelles. Avec des choses parfois étranges pour moi, des choses bêtes, des upgrades qui ne se passaient pas bien ou encore des destructions en grandes pompes! Vous allez me dire "qu'est-ce que ça veut dire une "destruction en grandes pompes 👢" ?". Oh c'est assez simple, prenez une personne qui est toujours en root
(c'est le mal 📛!!!), prenez un dossier dans lequel vous êtes qui se nomme /home/user/test1158
et le besoin de le vider, puis lancez une commande sans aucun risque 🧌 du type rm -rf /*
et lancez la sans problème. Oups... J'ai zappé le .
devant le /
. Eh Pouf 🧙♀️ plus de système fonctionnel.
Bon je pense que ça arrive à beaucoup de débutants et ça m'a donné une bonne leçon! Donc à part réinstaller le système avec docker dessus je n'avais pas perdu grand chose et pour ça, je remercie Docker et DockerCompose.
Cependant, j'ai aussi compris qu'il y avait pas mal d'enjeux à utiliser Docker. J'avais un certains nombre de questions : Pourquoi je suis obligé de lancer docker run
avec root ou en sudo? Est-ce que niveau sécurité je n'ai pas de problème ou des choses auxquelles je dois faire attention? (spoiler alert : si!) Comment je fais pour gérer un plus grand nombre de conteneurs, de DockerCompose? Comment je fais pour gérer le cycle de vie de mon application? Et tant d'autres questions auxquelles je n'avais pas encore de réponse.
Étape 3 : L'orchestration, c'est là que j'ai découvert l'existence des technologies d'orchestration avec Docker Swarm et Kubernetes. Je me suis vite penché vers Kubernetes, pas parce que c'était l'outil parfait ou parce qu'il répondait à mon besoin, simplement parce qu'il commençait à faire beaucoup parler de lui. C'est d'abord un outil qui me paraissait obscur mais surtout extrêmement complexe. J'ai tenté dans un premier temps de l'installer sans y parvenir, il n'y avait pas encore de solutions clé en main comme aujourd'hui avec des KubeAdm, K3S, Kind et j'en passe. J'ai donc laissé tomber et c'est comme ça que mon expérience avec Kubernetes se termine... Ou devrais-je dire commence ! J'ai eu la chance de participer à plusieurs expérimentations Kubernetes dans mon entreprise et là j'étais utilisateur de la plateforme elle était donc déjà installée (ouf! 🥵). C'est là que j'ai commencé à comprendre les concepts d'orchestration de Kubernetes avec les deployments
, les pods
, les ingress
ou encore les services
. Je ne comprenais pas encore tout mais j'arrivais à faire fonctionner mon application avec quelques Yaml. Enfin beaucoup de Yaml! Trop de Yaml? Je ne sais pas, en tout cas je n'étais pas super à l'aise avec tout ces manifests j'utilisais pas mal d'exemples du net et ça finissait pas fonctionner en faisant un beau kubectl apply
. C'était super mais encore flou pour moi. Et plus je testais plus je créais de ressources sur Kubernetes (dans pleins de namespaces, dont default 🤡) et c'était le BOR-DEL! Je ne savais plus comment retrouver mes ressources, je ne savais même plus ce que j'avais créé. L'avantage avec tout ça c'est que ça m'a fait découvrir Kubernetes en douceur et m'a fait prendre conscience que ce n'est pas un outil magique qui résout tout et surtout il faut de l'organisation.