With this tool, how do you even know what has been installed in the container? How do you share them, or make changes, or update them? Is this just for personal use where you don't care about sharing your work?
I've tried using Dockerfiles with teams. Over time it gets absolutely ugly, because you have to keep track of yet another configuration file collectively. It's all fun and games until someone creates a branch with an updated Dockerfile, you check it out, it alters your container and then you go back to master only to find out nothing works. That's just one example of madness.
We cannot rely on containers as a collective development tool. They're not, it was a dumb idea in the first place. Dockerfiles effectively make system configuration and setup a part of your vcs repo. And that is wrong. We might as well check in the root filesystem into the repo altogether then.
I think this is a very good thing.
I feel pain with docker for some reason and always seem to have to delete some state though.
Maybe my workflow is wrong.
With Nix though, its so convenient knowing everything is reproducible, stateless, and only the written configuration matters.
The great thing about dockerfiles is you can use the same thing for local testing as you deploy to production.
Even you're running a lot of micro-services, your goal is NOT to make it so that they are impossible to run without hours and hours of environment setup. In fact, even though they are different micro-services, you'd probably want to make their environment similar or the same where it's possible.
The purpose of containers for me personally is to isolate potential crap coming my way from various package managers, such as nodejs and, if I were to use them in production, to minimize a potential security breach impact.
But the idea that it's the same environment on the developer's machine and that we should deploy containers and not code, is absurd to me.
> It's all fun and games until someone creates a branch with an updated Dockerfile, you check it out, it alters your container and then you go back to master only to find out nothing works.
ticks some boxes for me - author prefer/works best in solo mode, otherwise such change would be reviewed by team members, before being put into master branch.
If you really want then just tag them, but building with a cache would be very quick when you swap.
> does the state of my docker container match the Dockerfile of my feature branch"
Why track the state of your docker container? Just build it.
I wish this was the case, but unfortunately it doesn't tell you what's in the base/parent image.
It also doesn't ensure you get bit-exact reproduceable builds. You need something like Guix/Nix for that.
I was recently considering creating this specifically for FreeBSD on ARM, or at least getting FreeBSD working on QEMU+arm64 and running some jails in there.
I’ve been working with lima and colima on macOS for a Linux VM docker type wrapper and wanted a FreeBSD equivalent.
Thanks for this tool (dock), it looks great.
As for supporting VMs - you misunderstood. I meant support for other container engines. To me, it would most notably be BSD jails. In fact, if I get to it, I'd like to do something much more cool... Perhaps it would make sense to have a VM with FreeBSD running on a machine and then multiple BSD jails running inside - all managed by a relatively small tool-set, such as `dock` - I'd probably have to rename or fork it. But the cool part of it all is that containers won't even depend on an architecture, since they'd be running inside a VM.