Developing with Docker
danielquinn.org
Developing with Docker
1–10 of 66 posts
Re: Developing with Docker
#2Thank you. This is a great resource!
Re: Developing with Docker
#3I love Docker (more so the idea of containers). Use it almost everywhere: self hosting services, at work everything is deployed as a docker container.
Except local development. Absolutely hate the "oh need to add a dependency, gotta rebuild everything" flow.
I do use it if the project I'm developing against needs a DB/redis/etc, but I don't think there's a chance I'm going back to using it for local development.
In fact, at work, the project where we do use docker in development actually causes the most headaches getting up and running.
I use a combination of CPU architectures, so the idea of running _exactly_ what's in production when developing is already out the window.
Re: Developing with Docker
#4>but importantly, the image at each of these stages is exactly the same: reproducible at every turn
This is wrong. Hadn't read any further.
Regards,
NixOS adept
Re: Developing with Docker
#5But wait how do you write code if the services are all in docker like that?
What about my strongly typed monorepo?
(I prefer a variation of this where all artefacts like databases are in docker compose, but my monorepo services run outside docker)
Re: Developing with Docker
#6This is all very good and true, but as usual the devil is found in the details. For instance, my company sells Docker images that depend on a very old and recently unmaintained binary. Over the years, I've found issues with that binary that make it very hard to be sure issues are completely reproducible from system to system (or, as the article suggests, from local to production). Sometimes, it's as simple as a newer base image updating a core dependency (e.g. Alpine updating musl), but other times it seems like nothing changes but the host machine, and diagnosing kernel-level issues - say, your local Mac OS' LinuxKit kernel versus your production Amazon Linux or Ubuntu, and don't forget x86 emulation! - make "test what you develop and deploy what you test" occasionally very daunting.
Re: Developing with Docker
#7I love Docker (more so the idea of containers). Use it almost everywhere: self hosting services, at work everything is deployed as a docker container. Except local development. Absolutely hate the "oh need to add a dependency, gotta rebuild everything" flow. I do use it if the project I'm developing against needs a DB/redis/etc, but I don't think there's a chance I'm going back to using it for local development. In f…
Docker for local development is only useful for running services like Postgresql and Redis, or doing hot reloads using something like vite or air. The development in a box paradigm is really difficult to maintain, much prefer direnv or nix.
Re: Developing with Docker
#8I love Docker (more so the idea of containers). Use it almost everywhere: self hosting services, at work everything is deployed as a docker container. Except local development. Absolutely hate the "oh need to add a dependency, gotta rebuild everything" flow. I do use it if the project I'm developing against needs a DB/redis/etc, but I don't think there's a chance I'm going back to using it for local development. In f…
I hate container and Docker in ANY use-case where there is an alternative that is same, or even "a little bit" more involved.
I reserve Docker and Containers for that use case where I really would have headaches if it is no there, and have not still found such a case in all the works I've done.
Re: Developing with Docker
#9I love Docker (more so the idea of containers). Use it almost everywhere: self hosting services, at work everything is deployed as a docker container. Except local development. Absolutely hate the "oh need to add a dependency, gotta rebuild everything" flow. I do use it if the project I'm developing against needs a DB/redis/etc, but I don't think there's a chance I'm going back to using it for local development. In f…
At least for python, I typically just add another RUN statement instead of changing a file used in a layer up the layer stack. That way the change is fast.
Then when I need to commit, I'll update the requirements file or whatever would cause all the layers to rebuild. And CI can rebuild the whole thing while I move to something else.
It is a bit of a pain, but the other benefits of containers are probably worth the trade off.
Re: Developing with Docker
#10That last point about differences between dev, test and prod should be right at the top. It's rare to find teams that have set themselves up for success (for reasons I do not fully understand)