Last year, we released our Docker Starter project. This starter kit is the working basis for nearly every project here at JoliCode. It’s a real pleasure for us to work with, shared with some gentle contributors 💛.
Today, we are very happy to announce the release of the version 3.0! 🎉
Docker Starter in it’s previous version was based on Fabric, and therefore Python 2. To follow the lifecycle of these technologies, we had to make huge modifications, including a BC break.
Python 2.7 has reached his End Of Life
Since we had Fabric as a main dependency, locked on Python 2.7, we were trapped in this version of Python. We had 2 choices:
- using a fork 😕
- moving forward and upgrading Python and finding a new way to run our stack.
Section intitulée but-why-did-we-need-fabricBut why did we need Fabric?
Fabric was used as a task launcher in Docker Starter since the beginning, when it was just a Python file we used to copy and paste from project to project.
Internally, we discussed other solutions like switching to one of the dozen existing task launchers, or eventually writing our own with PHP. Beyond the challenges of writing such a tool, we finally decided to be pragmatic and chose to stay on a Python based tool, to ease the maintenance of our existing project based on Docker Starter, and avoid rewriting all our tasks.
So let’s find another task launcher, … by the way, is Fabric based on a library? 😏
Section intitulée invokeInvoke
Since Fabric is built on top of Invoke, we decided to use Invoke directly as our new task launcher 😎.
It’s fully Python 3 compliant, and exposes quite the same API as Fabric!
The only difference is with CLI task names. If one of your tasks is named “webpack_watch”, Invoke will expose it in CLI as “webpack-watch” (note the “-” in place of the “_”). To avoid misunderstanding issues, we recommend to use the autocomplete script included in Invoke using the following command, and copying/pasting the output it in your shell configuration file (.bashrc, .zshrc, …):
$ invoke --print-completion-script=$SHELL
All the commands are now
inv [cmd] instead of
Section intitulée good-bye-alpineGood bye Alpine
The second main change in Docker Starter 3.0 is the switch from Alpine to Debian based image for PHP.
After a very interesting discussion about switching from Alpine to Debian in our Github repository we finally decided to switch. The main advantages were the need to have a dev environment closer to the production one and the possibility to have latest versions of PHP which were not available on Alpine.
Section intitulée services-updatesServices updates
Traefik, used as a reverse proxy, has been updated from 2.0 to 2.2 without needed changes in our configuration.
PostgreSQL version has also been upgraded from 11 to 12, with a dedicated test in CircleCI to ensure the database responds correctly 🎉.
Elasticsearch cookbook was upgraded to 7.8 too and we removed the very small HEAP site default value.
Section intitulée macos-and-windows-supportMacOS and Windows support
We took another deep look at Docker Desktop for Windows and it was hard!
One of the biggest challenges we faced was this strange error:
frontend_1 | runsv nginx: fatal: unable to start ./run: file does not exist
After some digging we found out that any file destined to run inside a container must use Unix style \n line endings on Windows.
The solution was to add a .gitattributes file to force the End Of Line:
We also had issues with PowerShell and Invoke, the environment variables are not passed along properly so Windows users will get a warning and must initialize them via a copy and paste.
Another difference is that the awesome
network_mode=host is not available on Windows and MacOS. That’s our default value because it allows us to run multiple projects at the same time, we just had to override this for the two Docker Desktop runtime and use ports instead.
Our Docker Compose stack is now fully operational on MacOS. On Windows, we still miss a critical part of the tooling: the “builder” as we call it is a container where the developer can run commands. We connect to it via Invoke but sadly, there is no PTY on Windows and that makes the shell unusable.
Section intitulée new-cookbooksNew Cookbooks
Time flies, and our different projects stacks too, so we added some new cookbooks in the documentation:
- Webpack Encore, to get benefit of the hot-reload. It’s quite useful for frontend developers who work mainly with CSS and JS files.
- Mercure, the real-time communications protocol designed and developed by our friends from Les-Tilleuls.
Section intitulée you-want-to-upgradeYou want to upgrade?
If you are using Docker Starter and want to upgrade to this new version, you can follow our guide! However, if you are comfortable with the old version, it’s of course not mandatory to upgrade.
The complete changelog is available here.
Feel free to contribute if you like Docker Starter, don’t hesitate to open an issue if you have any problem with, or just open a PR to share with us your cookbooks!
Commentaires et discussions
Pourquoi nous aimons le FOSDEM 💛
Le FOSDEM, c’est le Free and Open source Softwares Developers European Meeting, ou en Français : rassemblement européen des développeurs de logiciels libres et Open Source. Cette conférence se tient sur deux jours et a habituellement lieu au sein de l’Université Libre de Bruxelles, …
Introducing Docker Starter 2.0
For this first article of the year 2020 on our blog, we wanted to wish you all the best for this coming year! ✨ Six months ago we released our docker-starter. This is a starter-kit for our projects based on Docker, PHP and Nginx. Since then, we have enhanced the project a lot. Here…
Nos articles sur le même sujet
Ces clients ont profité de notre expertise
Axiatel à fait appel à JoliCode afin d’évaluer les développements effectués par la société. A l’issue d’un audit court, nous avons présenté un bilan de la situation actuelle, une architecture applicative cible, et nos recommandations en vue d’une migration en douceur vers le modèle applicatif présenté.
L’équipe de Finarta a fait appel à JoliCode pour le développement de leur plateforme Web. Basée sur le framework Symfony 2, l’application est un réseau privé de galerie et se veut être une place de communication et de vente d’oeuvres d’art entre ses membres. Pour cela, de nombreuses règles de droits ont été mises en places et une administration poussée…
Afin de poursuivre son déploiement sur le Web, Arte a souhaité être accompagné dans le développement de son API REST “OPA” (API destinée à exposer les programmes et le catalogue vidéo de la chaine). En collaboration avec l’équipe technique Arte, JoliCode a mené un travail spécifique à l’amélioration des performances et de la fiabilité de l’API. Ces…