Comment utiliser Docker pour son environnement de dev en local?

[augustin]

Hello les human coders,

J’ai rédigé un duo d’articles sur comment utiliser Docker pour son environnement de dev en local. En ce qui me concerne je ne travaille plus que comme cela, donc je me dis que ça peut en intéresser d’autres.

The definitive guide to using Docker as a local development environment (part 1)

Vous utilisez Docker en local ? Ca se passe comment pour vous ?

[amirouche]

C’est quoi la difference entre Docker et LXC?

[amirouche]

Pour moi Docker, c’est:

• Un pseudo langage (DSL) pourri basé sur YAML (docker-compose.yml)
• Un autre pseudo langage pourri qui veux imiter bash sans avoir la facilité et la flexbilité de Python (Dockerfile)
• Du mount --bind née une abstraction aka. volumes dont je ne comprend pas l’intérêt dans aucune étape du projet.
• Je vois pas l’intérêt du port forwarding en quelques caractère aka. Docker re-invente le reseau
• Je comprend pas pourquoi passer par docker run pour simplement lancer dans le container un bash, pourquoi ssh c’est pas assez simple?
• Docker re-invente la roue de la gestion de configuration d’un noeud sans que je ne comprenne l’interet
• Docker donne l’illusion de pouvoir scaler facilement alors que des modifications dans l’infrastructure de la prod et dans le code de l’application reste nécessaire pour scaler
• Je comprend pas pourquoi lancer systemd ou supervisord dans un docker est une anti-pattern
• Docker c’est du buzz

LXC 1, c’est:

• Une abstraction très proche des VM et donc de l’hote
• Toutes les commandes classiques utilisée pour faire de la VM et pour l’hôte
• La légèreté de Docker
• Un environnement connu et maitrisé par déjà par beaucoup de sysadmin, la connaissance de GNU/Linux
• Supporté par Ubuntu
• Ne prétend pas faussement simplifier le déploiement et la montée en charge

[augustin]

Hello,

Je ne connaissais pas LXC. Après de rapides recherches, je ne suis pas sûr de comprendre l’enjeu de ton post : Docker est basé sur LXC et propose un ensemble d’outils par dessus afin de simplifier le déploiement d’applications.

Je ne vois pas en quoi cela illégitime l’utilisation de Docker, si c’est l’outil qui répond au besoin.

Afin d’appuyer tes dires, je t’inviterais bien volontiers à proposer à ton tour un tutoriel permettant de configurer un environnement de dev local sandboxé comme le permet Docker dans mon post.

Une fois que ce sera fait, viendra le moment d’aborder la question du déploiement des applis mais chaque chose en son temps.

[amirouche]

Héllo!

Je ne connaissais pas LXC. Après de rapides recherches, je ne suis pas sûr de comprendre l’enjeu de ton post

Mon post est un questionnemenet pour lancer une etude comparative entre LxC et Docker.

Docker est basé sur LXC

C’est du passé ça.

[quote]et propose un ensemble d’outils par dessus afin de simplifier le déploiement d’applications.

Je ne vois pas en quoi cela illégitime l’utilisation de Docker, si c’est l’outil qui répond au besoin.[/quote]

Justement je ne ressent pas le besoin d’utiliser Docker, mise à part que ça offre de la reproductibilité dans l’architecture mais incomplete car elle n’est pas basé sur des sources.

[quote]Afin d’appuyer tes dires, je t’inviterais bien volontiers à proposer à ton tour un tutoriel permettant de configurer un environnement de dev local sandboxé comme le permet Docker dans mon post.

Une fois que ce sera fait, viendra le moment d’aborder la question du déploiement des applis mais chaque chose en son temps.
[/quote]

Ok, je vais faire ça.

[loganm]

Un pseudo langage (DSL) pourri basé sur YAML (docker-compose.yml)

docker compose ne fait que de l’orchestration. Si cela ne te convient pas un script Bash fera relativement bien l’affaire ou d’autres outils types Ansible.

Concernant la syntaxe, je trouve qu’elle est bien adapté au mode “déclaratif” de l’outil.

Un autre pseudo langage pourri qui veux imiter bash sans avoir la facilité et la flexbilité de Python (Dockerfile)

Là par contre, entièrement d’accord. La syntaxe est vraiment trop simpliste et mal conçu. Dommage qu’ils aient accepté de faire évoluer la syntaxe de docker compose mais pas pour le Dockerfile.

Après il ne faut pas oublier que la syntaxe est orienté sur le principe de “layer” qui est un élément structurant de Docker.

Du mount --bind née une abstraction aka. volumes dont je ne comprend pas l’intérêt dans aucune étape du projet.

La mutualisation de données entre images.

Je vois pas l’intérêt du port forwarding en quelques caractère aka. Docker re-invente le reseau

Non, il fournit de la virtualisation de réseau, load-balancing inclus ! Au même titre qu’il fournit de la virtualisation de disque et de process. Bref comme toute bonne solution de virtualisation/cloud, il offre une abstraction réseau, disque et process (mémoire + CPU).

Je comprend pas pourquoi passer par docker run pour simplement lancer dans le container un bash, pourquoi ssh c’est pas assez simple?

Rien ne t’oblige à lancer Bash … Et comme toute solution de “cloud”, il s’agit de s’abstraire de l’environnement physique.

Docker re-invente la roue de la gestion de configuration d’un noeud sans que je ne comprenne l’interet

Il ne réinvente rien, c’est simpement un wrapper pour orchestrer des “drivers”. C’est comme dire que Oracle réinvente DB2 …

Docker donne l’illusion de pouvoir scaler facilement alors que des modifications dans l’infrastructure de la prod et dans le code de l’application reste nécessaire pour scaler

Tu peux scaler facilement à partir du moment où tu respectes quelques règles. Et ces règles sont nullement spécifiques à Docker … Sa seule prétention c’est de pouvoir exécuter un “package” dans un environnement d’exécution. Exactement ce que propose les solutions PaaS (et éventuellement IaaS).

Je comprend pas pourquoi lancer systemd ou supervisord dans un docker est une anti-pattern

Pour les mêmes raisons que les exécutables Linux sont conçus tels qu’ils sont. Plus une chose est petite mieux elle fait son travail et plus elles sont faciles à composer. Mais rien ne contredire de faire un “package” plus gros. Il faut juste le faire consciemment (“to be aware”, comme dirait l’autre).

Docker c’est du buzz

on est relativement d’accord :)

LXC 1, c’est:

c’est surtout le niveau d’abstraction en dessous de Docker ; la plomberie quoi.

[xavierpriour]

J’utilise docker pour tous les projets sur lesquels je développe, pour les mêmes raisons que @augustin:

• chaque projet a son environnement totalement isolé, quelle que soit la machine hôte
• la configuration exacte (y compris infra et version) est partagée avec tous les autres développeurs (via les fichiers Dockerfile et docker-compore)
• l’installation/mise à jour de l’environnement est simplissime (docker-compose build)

J’apprécie docker pour sa documentation, sa communauté, et le langage de déclaration est “good enough” pour moi.

Honnêtement, sur les 3 dernières années, c’est de loin la technologie qui a eu le plus gros impact sur ma façon de développer, je le conseille à tous!

[augustin]

Mon post est un questionnemenet pour lancer une etude comparative entre LxC et Docker.

D’aucuns pourraient t’accuser de troll :smile: je pense qu’un thread dédié eut été plus à propos.

[amirouche]

Je trouve cette presentation de LXC interessante: http://tech.novapost.fr/lxc-demystification.html

Pour moi LXC c’est une VM legère.