Pourquoi travailler avec un devcontainer est une sacrée bonne idée… (avec VSCode)
Si tu ne sais pas ce qu’est un devcontainer, je t’explique.
Si tu sais ce que c’est et que tu ne les utilise pas, je t’explique pourquoi tu devrais.
Ce que ce billet explique:
- ce que c’est un devcontainer
- comment configurer VSCode pour les utiliser
- pourquoi c’est une bonne idée de les utiliser avec des exemples
- pourquoi y a des gens ils aiment pas (et des fois ils ont raison les gens)
Ce que ce billet n’explique pas:
- qu’est-ce que VSCode, comment l’utiliser, créer un projet, versionner, etc…
- qu’est-ce que c’est docker
- qu’est-ce que c’est linux
- qu’est-ce que c’est qui est vert, qui monte et qui descend
C’est quoi un devcontainer?
Globalement, imagine que pour chaque nouveau projet, tu aies un ordinateur qui lui est dédié. Tu as ton environnement, tu as installé la bonne version de ton langage de programmation préféré (Node, PHP, Rust, Cobol, etc…), tes services associés (MySQL, MongoDB, nginx, etc…), tes plugins et tes thèmes VSCode, ton shell (pour les linuxiens)…
Ben un devcontainer c’est ça!
Configurer VSCode
Trop facile! Il suffit d’avoir:
– VSCode Sans blagues?!?
– Docker. Ben oui, c’est un container, donc il faut Docker. Si tu ne sais pas ce qu’est un container, il y en a d’autres qui expliquent ça mieux que moi, mais en gros c’est une machine virtuelle light qui fait tourner un OS (linux principalement) dans ton OS (macOS, Windows, Linux…). Il existe en version Desktop pour Mac et PC.
– L’extensions officielle de VSCode Dev Containers s’installe en deux secondes.
Configurer ton projet
Alors tu vas dans ton projet… ou t’en crée un.
Et si tu sais pas comment faire ben tu te renseigne, j’ai dis que j’expliquais pas comment marche VSCode: t’as lu le début ou quoi?
Tu cliques en bas à droite sur le bouton avec les deux flèches qui se pécho, ou alors tu lances ton prompt de commande (CTRL+SHIFT+P), et tu choisis « Reopen in Container ».
Et là VSCode il est cool parce qu’il a plein déjà plein d’options déjà prédéfinies avec des langages de prog (Node, Rust, Python, Go…), des combos pratiques (Node+MongoDB, PHP+MariaDB…) ou même des sytèmes basiques à configurer soi-même ensuite (Alpine Linux, Debian, Ubuntu…). Ouais parce que le poto il gère aussi docker-compose.
Et puis t’as aussi le choix des versions et de logiciels supplémentaires à installer. Tu fais tes courses et à la fin il te crée un répertoire .devcontaineravec tout ce qu’il faut dedans (notamment le fichier devcontainer.json très bien documenté ici). Et même que si t’es un cador de Docker, tu peux même modifier ton Dockerfile ou ton docker-compose.yml aprés coup. Et si t’es pas un cador, franchement les fichiers sont bien commentés et avec un peu de recherche sur la doc de Docker et VSCode tu peux faire a peu prés tout ce que tu veux (c’est pas pire que d’installer son ordi).
Et là, il te relance ton projet VSCode dans un container sur-mesure, et tu peux coder comme avant: tu lances tes scripts, tes compilations, tes linters, tes git push/git pull/git rebase/git reblochon et autres git quelquechose…
Pourquoi c’est une bonne idée
Premier exemple: le projet legacy
Je réouvre un ancien projet qui n’utilise pas de devcontainer pour un bug rapide a corriger. Le plan c’est: on fix, on build, on déploie et c’est plié.
C’est le code que j’ai développé qui était resté sur mon ordi (pas un checkout from scratch). Je suis le seul dessus, donc à priori pas besoin de faire un git pullni un npm install… sauf que la ca build pas!
Ben oui: je l’ai codé sur Node 14! Et là c’est Node 18 maintenant sur mon ordi! Et comme j’utilisais des packages du genre node-sass qui ont du code compilé au moment de l’installation avec npm (ou yarn ou pnpm, ca va hein on va pas chipoter!)… et c’est au moment de la compilation qu’il crée ses bindings spécifique à la version de node… fuck! Et trouve les packages concernés, et vas-y de ton npm rebuild, gnagnagna…
Alors oui gnagnagna j’ai nvm (tu fais beaucoup gnagnagna je trouve), je peux changer la version de Node qu’utilise mon OS, mais bon c’est chiant: faut redémarrer VSCode, et puis mon autre projet ouvert en même temps il utilise Node 18 et je veux faire du copier/coller entre les deux, et puis d’abord je fais ce que je veux et puis Node il fait rien qu’à m’embêter! Et puis là le problème c’est que Node, imagine si on parle de version de glibc ou de chromium (puppeteer friends, êtes-vous là?)
Si j’avais utilisé un devcontainer, il m’aurait ouvert tranquilou mon système avec la bonne version de Node et tout ce qui est censé être installé pour développer sur ce projet puisque c’est le système entier qui est figé (ou réinstallé avec les bonnes versions si tu as supprimé l’image entre temps)
Deuxième exemple: le devcontainer « bootstrap » pour add-on de Home Assistant
Home Assistant est un serveur domotique développé en Python. Leur OS est un superviseur de containers Docker, et pour développer un add-on, il faut du coup créer un container soi-même. Ben ils fournissent un devcontainer pour VSCode, qui lance leur container (donc le core du système) en mappant ton projet dedans en bind mount (ouais, le truc fait du Docker dans du Docker, c’est une véritable boucherie à l’intérieur)
Du coup, tu développes tranquillou avec direct le bon environnement, les tâches déjà prédéfinies pour lancer le serveur, les bon ports déjà ouvert et mappés comme il faut… bref en 10min, sans capter une ligne de python, je pouvais communiquer en javascript avec la librairie de socket JS qu’ils ont développé…
Troisième exemple: le projet où qu’on est plusieurs dessus
Très pratique pour la collaboration sur un projet: avec un devcontainer (versionné bien sûr), tous les participant au projet ont le même environnement: qu’ils aient un PC avec Windows, avec Linux, ou un Mac, tout le monde peut travailler sur le même projet sans se préoccuper du reste…
…sauf de l’architecture du processeur. Et oui, on en parle plus bas chez les gens qui aiment pas
Pourquoi il y a des gens ils aiment pas
Alors Docker c’est mignon, mais ca a quand-même ses inconvénients:
– ca reste de la virtualisation. Ca veut dire qu’il y a perte de performances, et que ca prend plus de place sur le disque dur (même si un alpine c’est pas lourd, c’est là quand-même). Si tu a trois projets qui tournent, tu as trois systèmes qui tournent en plus de ton OS « host » (c’est celui de ton ordi, tu suis ou quoi?)
Aprés, t’es un développeur, tu boostes la RAM et t’arrêtes de râler. Mieux vaut prévoir plus que pas assez pour le coup…
– l’architecture processeur a son importance, et tout le monde a pas suivi. Ben oui, mac c’est de l’arm64 maintenant et même si Docker peut faire tourner du x86/x64 surARM64 la ton mac il a les yeux qui piquent. Et il faut que les images Docker soient pensées multi-architecture. Par exemple, j’ai fait un devcontainer qui installe les mongodb tools directement dans l’image docker via le télécharghement d’un .deb… étant le seul a bosser dessus, j’ai pas voulu m’embêter à gérer plusieurs architectures (et en plus je suis une quiche en shell) mais si je devais bosser avec des codeurs sur PC, il faudrait le prévoir (mais c’est faisable)
MySQL a mis trois plombes à rendre sa version arm disponible pour Docker, c’est d’autres qui ont du le faire avant qu’on ait une version officielle. Raspberry PI a fait du bien la disponibilité des images ARM vu qu’ils y en a beaucoup qui servent a faire tourner du Docker…
– il faut maintenir l’image. Ben oui, si tu mets à jour une version de pnpm ou chromium par exemple, il faut aussi changer le Dockerfile pour qu’il installe cette version, sinon aprés avoir supprimé ton image Docker de ton ordi, quand tu vas la remonter elle va installer la version prévue à l’initialisation. Il suffit pas de faire son apt-get dans la ligne de commande quoi…
– c’est du spécifique VSCode. Ben oui, moi je suis un fan, mais il y en a ils préfèrent Eclipse… non, j’déconne!
Mais il y a plein d’autres IDE qu’ils sont super bien et que je les utilise pas parce que la flemme…
Bref, t’as compris, moi je trouve que les devcontainers c’est la vie, juste aprés le typescript et l’emmental.
Alors, convaincu?