Comment by esperent
13 days ago
> Dockerfiles are clunky and the rather extreme level of isolation is usually unnecessary and makes things overly complicated
I agree, for local development docker is often overkill.
However, for production it's absolutely not overkill. And since pretty much all projects are intended for production at some point, they'll need a Dockerfile and docker compose or some other equivalent.
And at that point, you're maintaining the Dockerfile anyway, so why not use it for local dev as well? That way your dev and production environments can be close to identical.
Guix looks nice - probably nicer than docker for dev work. But is it nice enough to justify maintaining two separate systems and have your dev and production diverge?
While not directly mentioned in this article, guix pack[1] allows you to distribute your software in multiple formats, including Docker images.
The general philosophy of Guix is to have a single definition for how to build your software and use it for the entire dev to production pipeline.
[1]: https://guix.gnu.org/manual/1.5.0/en/html_node/Invoking-guix...
In Nix (and, I’d assume, for Guix) you can go the other way around: https://mitchellh.com/writing/nix-with-dockerfiles.
As a side benefit, the generated docker image can be very tiny.
Yeah Guix has a Dockerfile export
Your production deployment might be done with container images, but Dockerfile is not the only way to build them. Guix has builtin support to build container images without Dockerfile.
You'd be nuts to run the Docker daemon anywhere near production.
Why is that? I also used to hold this opinion, but we use it for 99% of our production deployments (or k8s where we need it) and it has been maximally reliable, and super convenient for fault-finding. Maybe I didn't understand your take.