[unethical_ban]

Container tech can be used for small scale "pet" deployment, but my understanding is that the true benefit of containers come with seeing them as "cattle".

You should never login to the shell of a container for config. All application state lives elsewhere, and any new commit to your app triggers a new build.

If that's not for you, then while containers like proxmox/LXC can still be handy, you're just doing VM at a different layer.

The article was a bit hand wavey about how "they" complain about containers, and then uses the analogy more than explaining the problems and solutions.

[foobar33333]

>You should never login to the shell of a container for config

I absolutely do this and think it works great. Fedora has built a tool called "toolbox" which is basically a wrapper on podman which can create and enter containers where you can install development tools without touching your actual OS.

I basically do all of my development inside a container where the source code is volume mounted in but git/ruby/etc only exist in the container.

This has the benefit of letting me very quickly create a fresh env to test something out. Recently I wanted to try doing a git pull using project access tokens on gitlab and containers let me have a copy of git which does not have my ssh keys in it.

This is somewhat of an edge case though, for a server deployment, yes you shouldn't rely on anything changed inside the container and should use volume mounts or modify the image.

[Sparkyte]

Only time it should be utilized as a small scale "pet" is when you externalize the storage mounts and it is an on-demand non-persistent virtual environment not directly connected to a data sensitive environment. That's mainly my take on it. I will often use docker locally to test out some kubernetes service connectivity, but never bring my Frankenstein stuff into an environment any higher than local.