La petite histoire
Je rédige cet article afin de partager l’évolution de mon d’environnement de travail de développeur.
Hier soir, avec Frédéric Léger, nous avons participé au meetup Docker Aix/Marseille qui a eu lieu chez Easy Partner, et, nous avons présenté Docker, du Hello world à l’environnement de dev complet.
Quand j’ai commencé à coder chez Mobivillage, l’infrastructure de développement était basé autour de serveurs locaux et le projet était édité directement depuis mon poste de travail. Ce schéma est très souvent rencontré dès que la société a quelques années et qu’il s’agit d’une ou plusieurs équipes de développement avec une gestion de cette infrastructure par des administrateurs systèmes. Selon moi, cette solution était totalement justifiée et adaptée. Pendant longtemps, j’ai voulu passé sur un environnement embarqué sur mon poste travail. Docker a clairement changer les choses et, depuis des mois, j’ai quitté ce schéma vers une solution basée à 100% sur Docker. Aujourd’hui rien ne me donne envie de revenir en arrière. Bien sûr, tout n’est pas parfait mais les avantages font une réelle différence.
Après de nombreuses années sur Windows puis Linux – je suis sur Mac et de la même manière que Docker, je ne souhaite pas revenir en arrière. Mais, il y a des inconvénients et je voulais vous partager les solutions que j’utilises.
Etat de l’art
Il existe plein de solutions pour avoir un environnement de développement. Malheureusement, je ne crois pas qu’il existe de solution parfaite et modestement, je vous invite à consulter ce « projet dev-environnement » qui, vous proposera un socle de base pour créer votre environnement de développement pour des projets PHP et plus encore.
Les solutions aux problèmes
Performance
Les volumes partagés avec Virtualbox ont de très mauvaises performances. Les projets sous des framework comme Symfony, ont un très grand nombre de fichier. De ce fait l’impact est fortement visible sur les performances.
Il existe une solution qui vise à changer la gestion de ces volumes partagés: Docker Machine NFS.
Pour résumer, une fois que votre VM docker est fonctionnel, il suffit de lancer docker-machine-nfs dessus et laisser faire.
docker-machine-nfs MAVM
Selon les tests que j’ai effectué, on peut observer un gain avec un facteur 10.
Accès à l’application
Ce n’est pas tout à fait un problème, c’est plutôt une gestion d’un simple vs cas complexe. Dans de nombreux exemples, on montre un cas très simple à base d’un container – il est suffit de lancer le container et d’y accéder via l’ip locale et le port configuré. Etant donné que j’ai pas mal de projets en même temps, cette solution n’est pas adapté. J’ai fait le choix d’avoir un environ qui soit capable de gérer plusieurs projets à base d’url http://*.docker/. La solution est simple: envoyer tout ce qui match avec *.docker à Docker.
Voici les solutions possibles:
- Dns local: Installer un dnsmasq sur votre machine et envoyer tout ce qui concerne *.docker à Docker. Pour cela, il faudra modifier votre configuration réseau pour utiliser votre dns local.
<span style="font-family: verdana, geneva, sans-serif;"> #Configuration file for dnsmasq. address=/docker/172.17.0.1 server=192.168.1.1 cache-size=0 port=53 </span>
- Dns Docker: Quand votre environnement Docker est lancé, il faut modifier votre configuration réseau pour utiliser le DNS Docker.
Configuration réseau pour utiliser le DNS Docker
Intéressant. A noter qu’avec des versions plus actuelles de docker il est surement possible de se passer de dnsdock. Je vais essayer de valider cela. Bon job !
Thanks, great article.