Pour travailler en environnement windows avec Docker (prévu à la base pour linux), pas d’autre choix pour l’instant que de passer par une VM de base linux.
Pour cela l’outil de base fourni par l’écosystème docker c’est boot2docker dont la recette de cuisine se trouve ici (ce qui est drôle c’est que l’iso est construit grace à docker, bref si vous voulez construire vous même et que vous n’avez qu’un windows c’est pas gagné) En gros cela installe un virtualbox avec une image iso boot2docker basé sur une distribution tinycore réduite au maxi.
A l’usage c’est pas totalement pratique et avec des collègues le choix s’est plutôt orienté vers un système piloté à base de vagrant. Cela permet avec un simple vagrantfile et un petit vagrant up de démarrer (avec même une perso dans le provision de vagrant si besoin).
Le vagrant cloud comporte deux images intéressantes de boot2docker, celle dduportal (pas tout à fait à jour hélas) dont la recette est ici et celle de yungsang dont la recette est ici.
Boot2docker a l’avantage d’être très light, efficace et permettre de démarrer des conteneurs docker sans souci. Le souci, c’est qu’il est en fait trop light (c’est pour dire que même la commande more ne marche plus car ils ont viré un peu vite ncurses…). Et si jamais vous voulez installer un truc supplémentaire c’est pas évidement. Ok avec des commandes style tce-load -wi make.tcz vous pouvez installer make, sauf que comme presque tout boot2docker est en ram (hormis /var/lib/docker et /var/lib/boot2docker) c’est pas persistant. Après il faut ruser et c’est moche. Enfin dernier problème, tinycore c’est bien mais ça a pas l’air top maintenu et à jour (quand on voit l’age des paquets sur leur repo, ca fait juste flipper : 2010 au plus récent).
Alors je me suis mis à vouloir construire ma docker box. Mais…. C’est compliqué… Pour mémoire, la box doit contenir vraiment l’essentiel et que l’essentiel et rester d’une taille raisonnable (le max de la logique doit être dans les conteneurs dockers). Pour mémoire boot2docker fait environ 90Mo… Donc après quelques installations en mode serveur d’une débian ou d’une ubuntu avec l’iso dans virtualbox, on a un linux de base qui fait malheureusement entre 400 et 500Mo. Et faire le ménage devient fastidieu… Sans compter l’install spéciale docker, les bricoles pour virtualbox et vagrant.
C’est alors que j’ai vu qu’ubuntu fournit des packages officiels. Et williamyeh a la bonne idée de fournir une image basée dessus dont la recette est ici (il a aussi une image debian jessie dans vagrant cloud). Cette base d’image donne tout ce qu’il faut pré-configuré pour la modique somme de 360Mo environ (pour la base ubuntu). Avec un peu de ménage simpliste (ya des trucs vraiment inutiles pour ce qu’on veut comme juju-core dans l’image unbutu) j’arrive a environ 260Mo. Ca devient mieux mais ça reste trop et aller plus loin dans le ménage commence a demander des connaissances / du taf un peu plus avancé… De plus je reste persuadé qu’on embarque encore trop de trucs au runtime dans cette image. Pour rappel elle doit être vraiment minimaliste (et a l’usage, je ne suis pas sur de l’efficacité de mon image).
C’est alors qu’en lisant la recette officielle de boot2docker (en gros le dockerfile) j’ai vu une référence à une image d’unclejack.
Et là je tombe sur la recette d’unclejack. Et la miracle, enfin ce que je cherchais à faire une debian2docker ultra light ! Miracle. En plus je ne connais pas le personnage mais il ambitionne de servir de nouvelle base à boot2docker. En plus il prend en base une debian jessie. Une distrib maintenue et à jour qu’on devrait pouvoir personnaliser relativement facilement avec un bon apt-get ! La ou il est fort l’annimal, c’est qu’il arrive à pondre à priori une image debian avec docker d’une taille de 50Mo O_ô soit 40Mo de moins que celle boot2docker officielle… Et la technique pour la générer est bigrement inventive (pour moi) en gros il crée un environnement chrooté dans une linux avec vraiment le mini requis des packages sélectionnés à la main et en fait un iso. Bon à priori je doute qu’avec 50mo il y ait grangd chose (genre les outils de base de tout linux) mais c’est surement une base foncitonnelle qu’on doit pouvoir utiliser sans trop tomber dans une taille énorme. A creuser !
Bref, aujourd’hui je vais creuser cette piste pour avoir une image sympa avec make (idée d’un collègue qui pourrait se révéler plus personnasiable et maléable que fig pour piloter des conteneurs) et fig installé de base. Peut être deux trois autres bricoles genre docker-gen pou pipework.
Sinon restera la solution de partir de la recette du boot2docker (qui au passage semble contenir les éléments que dduportal prévoit genre virtualbox guest addition, bizarre à creuser) mais bon tinycore j’ai donné mon avis dessus. Reste que le montage en ram c’est plutôt pas mal d’un certain sens (même si à chaque reboot de la vm tout est parterre ce qui est aussi assez chiant pour certaines choses).
Sinon en remarques en vrac
- J’ai vu plusieurs fois dans les recettes un outil nommé packer utilisé pour standardiser et outiller la créations d’images, à creuser donc.
- Terrywang fournit quelques box de base pour vagrant des principaux systèmes et ça semble bien foutu
- Le projet bento semble intéressant pour constuire proprement (et de manière répétable) des box pour vagrant (d’ailleurs il utilise packer)
- Si vous vous demandez comment installer un package sur tinycore avec le gestionnaire de packet c’est ici (bizarre d’ailleurs ca fait râler mon antivirus).
- A un moment donné je me suis demandé si pour construire une distrib minimale Arch linux (releases ici) serait peut être un bon choix (mais compte tenu du travail d’unclejack je vais lacher l’affaire…)
- Si vous compter travailler avec un partage entre votre vm linux et votre windows avec le partage virtualbox, d’après mes mesures (à la louche) comptez un temps de réaction x2 pour les écritures disque (autrement dit ne faites pas tourner des volumes partagés avec votre host win et vos conteneurs dockers).
- Par contre les partages de file système entre docker et sont host linux semblent n’engendrer que peu voir pas de perte de performance (par contre j’ai l’impressio que la perf est moins régulière).
- Attention, pour les deux points précédents, les tests ont été effectués sur boot2docker et un fs qui est donc monté en mémoire (ça doit probablement jouer aussi !). A confirmer donc avec un fs non mémoire.
Voilà ç’est tout pour mes réflexions en vrac (pour l’instant).
