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.
A slightly smarter .tar.gz would have solved the problem just as well.
A container is vastly more powerful for running an application than a tar file.
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...
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.
before it was just a mess. and it also isn't that much older than docker.
Longer answer here https://thenewstack.io/docker-based-dynamic-tooling-a-freque...
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.
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.
It's called "OS package" ;) and can provide more strict sandboxing using a systemd unit file: unit files provide seccomp, cgroups and more.
Nix tries to solve this, but it isn't there just yet.
Use the same OS and similar hardware for development and production.
Also means developers can work in whatever environment they want, but the result will be reproducible (almost) anywhere.
Yes, systemd unit files are containers, just like Docker.
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.