[hhh]

I don't see the point of evading Dockerfiles. All of these customizations to me seem like they're just doing what you would do in a Dockerfile for creating a base image, but in a non-friendly way for people not using Dock.

From reading, there seems to be planned support for VMs, which is where the mental click is for evading dockerfiles to me, but when creating VMs you have the same thing. The equivalent (in my mind) of this for VMs exists as Multipass, where you pass a cloud-init file for configuration.

I think it's cool for playing, but if I could create a Dockerfile in the directory of the project, as simple as "FROM ubuntu:latest" and when I run Dock it takes this Dockerfile and then builds a new image ontop of it (with all these customizations, dropping me into a shell) that is where this would shine to me. It may just be a workflow thing, but if I am building a container, I am already building Dockerfiles. They're not just for Docker, many many tools use them for containers more generically.

The painful part when building a container is when I am doing something decently involved (e.g. implementing a proprietary software daemon & driver for a German camera manufacturer that has to have custom udev rules and many, many customizations,) and just want to extend my natural terminal environment into that space to explore what's up. Then when I am done, I should be able to run docker build and get the clean, bare container. It's very rare that I just need an arbitrary container that will go away when working on a project. Periodically I may generate an ubuntu pod or something, but it goes away fast and generally lives for less than 10 commands.

With that being said, I don't mean to poo-poo, as I do really like the aesthetic, the documentation is beautiful, and the thought put into it. I just don't see where it fits into my (or many people I know)'s workflow pretty much strictly because of the Dockerfile thing. Some of the other tools look cool though, so I threw a buck or two in the hat :)

[smoochy]

Thank you. Yeah, I guess it's a matter of what you're used to. For me personally, I've never gotten used to Dockerfiles. It seemed like another configuration file format invented for nothing. With rules I had to remember. Entrypoint? Ugh. So I've just done everything in Bash, made it imply which container/image I want from $PWD and it saved me a ton of time. And, actually, I do tend to create/destroy containers quite often because of how easy it is (no editing files or even providing cli arguments to `dock`).

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.

[cortesoft]

Maybe I am missing the use case, but a dockerfile seems so useful for having an easily readable declaration of what exactly is inside the container. If I need to upgrade a package at a later date, I can simply change a line and rebuild the container. The same goes if I need to remove something; just delete the line in the dockerfile. You can copy things from one dockerfile to another. You can see how it has changed over time by checking it into git. You can have multiple people make changes to it and develop it over time. You can reorder things. You can build containers from other containers, etc.

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?

[smoochy]

That's the point. This tool is not for the teams. It's for your personal development needs. I often find myself working on multiple projects, which require roughly the same environments. Say, I may need a container with PHP for multiple projects, but each would differ slightly in some way. Maybe some configuration file, maybe something else. I would just `cd` to the project's dir, type `dock php8` and it would create a container based on the "dock/php8:stable" image. Then I'd install whatever else I need. I wouldn't need to bother editing a Dockerfile. I would get a nice shell immediately as I type the command. And I wouldn't need to remember that I'm running a container (even if it was stopped), because if I go the same directory and type `dock` (no arguments), it would automatically start/connect to the right container.

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.

[adastra22]

Every developer works on a team by default: a team made up of you and future-you. Even for personal projects it is very important to document and commit this stuff.

[ParetoOptimal]

> Dockerfiles effectively make system configuration and setup a part of your vcs repo.

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.

[cortesoft]

If you don’t think dockerfiles are good for development, do you use them for deployment? If not, how are you building your production containers?

The great thing about dockerfiles is you can use the same thing for local testing as you deploy to production.

[smoochy]

I've never used Docker in production, there was no need for containers. We did use heavier VM, but kept the environment and configuration such that it wouldn't need some kind of special handling. That is to say, once a team member cloned the project(s), set up the environment on their machine and successfully made the project run, there wouldn't be any constant tweaking with the environment afterwards.

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.

[CoolCold]

I may be wrong, but this

> 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.

[smoochy]

I think you're not seeing the actual point. The review isn't solving the issue. If you have two branches with alternating environments and you switch back and forth between them, how do you suppose your Dockerfile would handle it? What if that change isn't as simple as switching the Ruby version, but "compile and install some software" or some obscure config changes? I mean, it would be breaking all of the time, you'd end up having two containers anyway and you'd be scratching your head as to how to switch between them easily.

[IanCal]

You just build it. I'm not sure I understand the issue.

If you really want then just tag them, but building with a cache would be very quick when you swap.

[pmoriarty]

"a dockerfile seems so useful for having an easily readable declaration of what exactly is inside the container"

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.

[drvdevd]

> Perhaps it would make sense to have a VM with FreeBSD running on a machine and then multiple BSD jails running inside

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.

[smoochy]

AFAIK, there's a port of FreeBSD's bhyve to MacOSX called xhyve. You might want to check it out.

[XorNot]

You could get something like this using a Bubblewrap script. I have one which marks everything but the current directory read only and drops me into a shell in that container.

So a similar idea would be to overlay mount your system for that container so you can edit, and then on exit the changes vanish. Might try this actually :)

https://github.com/containers/bubblewrap