Ma stack de développement avec Docker sous macOS X
C’est après une discussion en ce mois de juillet 2018 sur le Slack de l’AFSY sur la question « pour une nouvelle machine… Linux ou Mac ? » que j’ai décidé d’écrire cet article.
Je pense réellement prendre un Linux pour ma prochaine machine et donc, quitter Apple qui m’énerve de plus en plus. Je n’utilise pas les applications Apple, je trouve que macOS X est de moins en moins stable, mais contrairement aux autres personnes présentes lors de la discussion, je n’ai pas vraiment à me plaindre des performances avec Docker.
Cet article n’est pas vraiment un benchmark, mais plus une explication de ma stack de développement.
Section intitulée ma-stack-de-developpementMa stack de développement
Le souci majeur est que Docker est fait à la base pour tourner sur Linux. Pour pouvoir l’utiliser sous OS X au début, j’ai donc utilisé boot2docker : une VM Linux à lancer pour pouvoir utiliser ses containers. Ça fonctionnait, mais c’était assez artisanal.
Mais depuis 3 ans, j’utilise dinghy, une VM sous stéroïdes. Dinghy se base sur un provider (Parallels, VMWare Fusion, VirtualBox, xhyve), sur docker-machine et embarque :
- un DNS permettant d’accéder à ses containers via {container_name}.docker ;
- un proxy HTTP permettant d’accéder automatiquement à des containers d’un docker-compose ;
- un serveur NFS et FSEvents permettant de transférer les événements sur le système de fichier OS X vers la VM.
Je n’utilise ni le DNS, ni le proxy HTTP, je les ai donc désactivé. Au début, j’utilisais VirtualBox en provider, je suis passé à xhyve, un portage de l’hyperviseur BSD bhyve sur OS X.
Avec cette stack, je n’ai que très peu de problèmes de performance.
Section intitulée docker-for-macDocker for Mac
Depuis, Docker for Mac est sorti. Je ne l’avais jamais essayé et les retours des développeurs ne donnent pas envie. Pour avoir quelques métriques supplémentaires, j’ai cependant fait l’exercice de l’installer et lancer le projet avec.
Sur certains de mes projets, j’ai carrément arrêté le support de Docker for Mac dans notre lib python de gestion de notre stack de développement. Je force ainsi l’utilisation de dinghy pour ne plus entendre de plainte sur les performances.
Bref, je reste donc pour l’instant sur le couple xhyve + dinghy 👍
Section intitulée installation-de-la-stackInstallation de la stack
Nous avons besoin de :
- docker
- docker-machine
- dinghy
- xhyve
$ brew install docker docker-machine
$ brew install docker-machine-nfs xhyve docker-machine-driver-xhyve
$ brew tap codekitchen/dinghy
$ brew install dinghy
xhyve a besoin d’un peu de configuration :
# docker-machine-driver-xhyve need root owner and uid
$ sudo chown root:wheel $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve
$ sudo chmod u+s $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve
Il suffit ensuite de créer sa machine, par exemple :
$ dinghy create --provider=xhyve --cpus=4 --memory=4096
Section intitulée utilisation-de-la-stackUtilisation de la stack
Et c’est parti ! Rien de particulier à mettre dans le docker-compose ou à faire.
$ dinghy up
$ $(dinghy shellinit) # parfois dinghy n'arrive pas à export ses variables d'env...
$ MY_UID=501 docker-compose -p my_project -f infrastructure/orchestration/base.yml build
$ MY_UID=501 docker-compose -p my_project -f infrastructure/orchestration/base.yml up
Section intitulée performances-de-la-stackPerformances de la stack
Sur un symfony 3.3 tournant sur PHP 7.1, avec environ 700 routes et 25 containers qui tournent :
$ php -v
PHP 7.1.17 (cli)
$ php bin/console
Symfony 3.3.13
$ php bin/console debug:router | wc -l
708
$ docker ps | wc -l
26
Voici la debug bar symfony pour 3 pages :
- Accueil sans cache
- Accueil avec cache
- Page produit
- Page favoris
Pour comparer, voici le résultat sur une machine Linux avec le même projet et les mêmes pages :
Page | OS X avec dinghy/xhyve | OS X avec Docker for Mac | Linux |
---|---|---|---|
Accueil sans cache | 7 000ms | 17 000ms | 800ms |
Accueil avec cache | 210ms | 3 500ms | 60ms |
Page produit | 180ms | 2 550ms | 150ms |
Page favoris | 105ms | 2 030ms | 85ms |
Il est à noter que Docker for Mac a été testé « brut », sans utiliser du :cached
par exemple. Cf. la documentation Docker.
Le composer install
de 93 paquets se fait en moins d’une minute :
$ MY_UID=501 docker-compose -p my_project -f infrastructure/environments/base.yml run --rm -u my_project --no-deps builder /bin/bash -c "cd projects/frontend && composer install --no-interaction --prefer-dist --no-scripts"
[...]
Package operations: 93 installs, 0 updates, 0 removals
[...]
59s
Je suis satisfait de xhyve + dinghy, la création du cache est un peu longue, mais ça n’arrive pas en continue.
Cette stack fonctionne très bien chez nous, et pour vous ? Vous utilisez Docker for Mac et vous en êtes satisfait ? Si vous passez à dinghy suite à cette article, n’hésitez pas à donner votre ressenti dans les commentaires. La discussion est ouverte ! 😀
Commentaires et discussions
Le binaire Symfony à l’usage
Après notre premier article présentant le binaire Symfony, voici enfin la suite ! Nous allons revenir sur le projet où nous l’avons utilisé et vous présenter les détails de cette mise en place. Notre projet 🙌 Pour ce projet, nous avons deux applications Symfony : le front et l’API.…
My local server with the Symfony binary
In order to develop efficiently and to be able to foresee production issues as quickly as possible, it is a good thing to have a local stack as close as possible to the production one. For this reason, Docker is the tool that we strongly recommend (and so for many years now!). However, …
Lire la suite de l’article My local server with the Symfony binary
Nos articles sur le même sujet
Ces clients ont profité de notre expertise
Dans le cadre du renouveau de sa stratégie digitale, Orpi France a fait appel à JoliCode afin de diriger la refonte du site Web orpi.com et l’intégration de nombreux nouveaux services. Pour effectuer cette migration, nous nous sommes appuyés sur une architecture en microservices à l’aide de PHP, Symfony, RabbitMQ, Elasticsearch et Docker.
Nous avons entrepris une refonte complète du site, initialement développé sur Drupal, dans le but de le consolider et de jeter les bases d’un avenir solide en adoptant Symfony. La plateforme est hautement sophistiquée et propose une pléthore de fonctionnalités, telles que la gestion des abonnements avec Stripe et Paypal, une API pour l’application…
Ouibus a pour ambition de devenir la référence du transport en bus longue distance. Dans cette optique, les enjeux à venir de la compagnie sont nombreux (vente multi-produit, agrandissement du réseau, diminution du time-to-market, amélioration de l’expérience et de la satisfaction client) et ont des conséquences sur la structuration de la nouvelle…