[otabdeveloper1]

90% of the time Docker is used to solve the problem of "how do I upload this bucket of Python crud to a production server?" (Replace 'Python' with any other language to taste.)

A slightly smarter .tar.gz would have solved the problem just as well.

[manigandham]

No it wouldn't have. What's unzipping and running that code? What's monitoring it and restarting it? How do you mount volumes and env variables? How do you open ports and maintain isolation?

A container is vastly more powerful for running an application than a tar file.

[archi42]

No offense, but you're aware you make it sound as if we used to use punch cards until the arrival of docker?

You can often run daemons as different users and set appropriate file permissions. You can add ENV variables to your start up scripts or configuration files. Volumes are mounted by the system (and you set appropriate access rights again). Monitoring and restarting services is managed by your init system (and probably some external monitoring, because sometimes physical hosts go nuts). Depending on your environment you can just produce debs, rpms, or some custom format for packaging/distribution.

Yes, sometimes you still want docker or even a real VM, and there are good reasons for that - I totally agree. But often it is not necessary. I'm often under the impression that some people forget that the currently hyped and cool tech is not always and under every circumstance the right solution to a given type of problem. But that's not an issue with docker alone...

[treis]

>You can often run daemons as different users and set appropriate file permissions. You can add ENV variables to your start up scripts or configuration files. Volumes are mounted by the system (and you set appropriate access rights again).

That sounds exactly like creating a Dockerfile. The difference is that your script has to work any number of times on an endless number of system configurations. The Dockerfile has to work once on one system which is a much easier target to hit. The "any number of times on an endless number of system configurations" is a problem taken care of by the Docker team.

[nwmcsween]

Which sounds exactly like having a proper package manager...

[loriverkutya]

You seems to be not aware of the problems docker solving “out-of-the-box” and that about 10-15 years ago, those problems was solved in-house developed toolset.

[weberc2]

The difference is that with VMs, you have to configure the things that you get for free with container runtimes. Specifically, Amazon can take care of a ton of the most mundane security and compliance burden that our org would otherwise have to own. Those differences means that developers can cost effectively be trained to do much of their own ops and I can solve more interesting problems.

[merb]

basically everything you described basically came with systemd. the thing that later made docker possible.

before it was just a mess. and it also isn't that much older than docker.

[StreamBright]

Exactly. The said reality that solving this problem helps many developers who would otherwise not capable of deploying to servers.

[yoz-y]

Much like accessibility, even if you are capable of doing everything by hand, it is usually nicer to have most of the gruntwork handled for you.

[StreamBright]

Well, not necessarily by hand. I never gave up deploying our Java application with Ansible. We could have used Docker but the team decided to use fat jars and Ansible instead. Nowadays with Java 11 you can make those fat jars even slimmer. There was no value proposition for us to change.

[yoz-y]

I did not work much with deployments but one thing I liked with Docker over Ansible is that testing the configurations locally is really easy and independent on the host platform.

[kkapelon]

You are confusing Docker = the deployment artifact with Docker = self-contained runtime perfect for CI/CD

Longer answer here https://thenewstack.io/docker-based-dynamic-tooling-a-freque...

[otabdeveloper1]

I'm not.

My point was that Docker purports to solve the sandboxing and security problems.

In reality, this is something that 90% of people who use Docker don't give a shit about. For the vast majority Docker is just a nice and easy-to-use packaging format.

The sad part is that

a) Docker failed at security.

b) In trying to solve the security problem Docker ended up with a pretty crufty (from a technical point of view) packaging format.

Maybe we need to start from scratch, listen to the devs this time and build something they actually want.

[kkapelon]

>My point was that Docker purports to solve the sandboxing and security problems.

Says who? The article I linked to you says nothing about security.

>Docker failed at security.

If somebody thinks security is the strong feature of Docker he/she is misinformed.

>For the vast majority Docker is just a nice and easy-to-use packaging format

For the vast majority of who? Developers? Sys admins? PMs?

The big advantage of docker is the self-contained environment for CI builds.

[eeZah7Ux]

> A slightly smarter .tar.gz would have solved the problem just as well.

It's called "OS package" ;) and can provide more strict sandboxing using a systemd unit file: unit files provide seccomp, cgroups and more.

[bdavis__]

docker solves 2 problems. first is you have no control over your devs and allow them to install any software from anywhere. and second is you want to sell cpu time from the cloud in an efficient way (for the seller).

[dijksterhuis]

Disagree with both statements.

1) is not a containerisation problem. It’s a team problem. I can jam in a load of npm and pip installs in to a shell install script. Maybe even delete /usr/ for the hell of it. Because the script isn’t isolated from the OS I can cause more damage.

This problem is actually solved by doing code reviews properly and team discussions.

2) errr no. Containers != infrastructure. If you want to deploy on bare metal, you can.

[StreamBright]

Agree with the first one but disagree with the second one. EC2 was selling CPU time long time ago before Docker existed.

[jarfil]

Docker containers provide seccomp, cgroups and more.

Yes, systemd unit files are containers, just like Docker.

[otabdeveloper1]

Indeed you're right, but the problem is that your devs' machines and your production systems are running different OS's/distributions.

Nix tries to solve this, but it isn't there just yet.

[Bootvis]

I know there is cost to this solution but it's a good one:

Use the same OS and similar hardware for development and production.

[randallsquared]

The cost includes making development impossible without internet access, given that devs are not going to be carrying a cluster of servers around with them.

[dijksterhuis]

^ This.

Also means developers can work in whatever environment they want, but the result will be reproducible (almost) anywhere.