Why using docker in your local dev environment is probably not a great idea

Let me preface this by saying that docker is an amazing tool. We use it every day in our CI to run our different pipelines in a prod-like environment making our functional and performance tests very reliable. However, we tried to use docker as a development tool in myCANAL, and when I say development tool I mean executing our application and every commands in a docker container, and it was kind of a mess.

When docker was introduced in our stack the first thing we noticed is that, while it simplified our initial setup and launch, it made our day to day development process much more complex. Each part of our environment was launched in a separate container and we had a Nginx server used as a reverse proxy to be able to access our application in https. This does not sound like much, but this caused a lot of little inconveniences which when taken individually aren’t that big of a deal but if you pile them together you get a really deteriorated development experience. There were few cases that were particularly annoying:

• We have to restart our application to ensure that our modifications do not break the Server Side Rendering. Sometimes the restart would go well, but when it didn’t Nginx would not be able to pick the upstream back up and you’d lose a few minutes wondering if the problem was the server or Nginx
• When switching from one branch to another, especially when you have a lot of differences between the two, would cause tens of files to change at once and could make our docker crash into a state where we weren’t able to start the application again. If you forgot, you would have to reset docker to factory default and setup your docker environment again
• Sometimes webpack would bug for no reason and would fail to detect files modifications, wasting us a lot of time thinking that our changes did not work while it was just not taken into account.

The second, and most impactful, drawback was that every command took almost twice as long to complete. From eslint verification to our unit test suite every task seemed to take forever compared to before docker. This caused the apparition of unhealthy behaviors in our development team, everybody skipped the pre-commit hooks since it took too much time to complete and relied on the CI to know if their tests failed or if they missed a code style error. This seriously slowed down our development process and even if it was kind of expected when executing everything in a virtual machine, it was much worse than anticipated.

After a few weeks of that, every developer in the team was completely fed up with docker, and regularly they would just work around it by executing our tests suites or commands outside of it. So we asked ourselves, why did we set up docker in the first place? Well, we wanted to keep the same environment from the development to the production to avoid any platform-specific bugs that we would not be able to reproduce locally, but those bugs were extremely unusual so… was it worth it to degrade our development experience that much for something that happens only once in a while? Obviously the answer was no so we removed docker almost completely , just keeping a container to be able to reproduce CI specifics bug when they occur.

In conclusion a lot of troubles could have been avoided by simply “beta test” the changes to set performance thresholds that would need to be met for docker to be successfully integrated to our development environment. However if you ever feel the need to add docker to your local stack, just ask yourself this simple question: does my application need docker to run locally?