Because you have to provide it with the libraries it needs and ensure the library will run on the targeted dockerhost machine (i.e. linux).
>But I don't want to worry about library dependencies
So that's why they provide the FROM statement which allows you to base it on a community-delivered "bare-bones" OS
>But that just sounds like a worse type of VM
Yes. Except it spins up slightly faster.
enjoy the pain
VM : you package your application into an executable runnable by the VM.
Docker : you tell all the instruction to run the application, as if you started from a fresh os. So basically a glorified Makefile.
It allows you to build your application's environment with perfect consistency which is great because if you are/were doing that manually then there's going to be something that you don't set up the same exact way every time and you're going to get quirks.
Updating applications is also super easy in that if you want to update or change any piece of the environment, you just edit a text file and rebuild the container. If you're doing compose then you need to edit a second text file and you probably need to push the updated container image to a registry.
Docker Swarm and Kubernetes let you have "muh cloud" high availability and fault tolerance on your own infrastructure with minimal setup.
Containers also use less resources than VMs so you can run more of them on less powerful hardware and save money, and the whole container build and deploy process can be easily automated. While you can automate VM deploy and build, it has in my experience been more convoluted and more difficult.
The biggest problem that I've found with Docker is that by default it fucks with your iptables, but if you're semi-competent you can tell docker not to do that and just do the iptables fuckery yourself.
docker is already dying and being replaced by kubernetes that copied all the good stuff of docker (there wasn't that much)
>asking a bunch of anime watchers instead of just googling it
Should I always run docker+kubernetes on a KVM? Anyone here run it directly on their development machine?
Don't you need containers on kubernetes anyway? How are you going to manage pods without docker?
kubernetes can work with any containerization technology - eg. rkt of coreos
as well docker can run with other orchestration engines (docker swarm would be one of them)
>docker is already dying
imagine being this unemployed
Docker has become, for better or for worse (mostly worse imo), the de facto standard. The big three cloud platforms all advertise Docker support in big bold letters in their whitepapers. The only thing Kubernetes has killed is Docker Swarm. Insofar as AWS and Azure nudge their customers into not using Docker, both promote their own proprietary layers "on top" of Docker like Fargate and App Service.
I use Docker for local development. My host OS (Ubango 18.04 LTS) has neither Python nor Node installed. Instead, I use VS Code with the Remote extension to create custom dev environments as needed. The extension creates and connects to local containers whenever you open a project within VS Code.