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

[ParetoOptimal]

I'm pretty sure everyone prefers "check out branch, run build command" to transparently do the right thing rather than mental book-keeping of "does the state of my docker container match the Dockerfile of my feature branch"?

[IanCal]

Yes, that would be "docker build". Or docker compose if you want to do more things and organise the volume mapping side/other dependencies.

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

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