back

by rcarmo·11y ago·view on hn ↗
You're misunderstanding what Docker does.

The most important function of Docker is dependency management (allowing you to pack your own runtime with your apps with consummate ease), followed by standardising image distribution and deployment across environments.

A Docker image is not a VM image - it doesn't have a kernel, for starters, and is not designed to be booted in the usual sense (i.e., kernel+init+scripts) - it just has a Linux userland (often quite restricted) and will run _a single process_ by design[1].

Also, AWS and Google Cloud already allow you to run Docker images (on EC2 Container Service and Kubernetes).

Cloud providers won't accept existing VM images in the sense that large-scale hypervisor platforms usually use different formats and they don't need the hassle involved in building and supporting VM conversion services.

It's pointless to have those as a service when anyone can grab Packer or a similar tool and convert a .vbox/.vmdk to an AWS AMI or an Azure Hyper-V image - and support the resulting images themselves (which is another reason why providers make a clear distinction between certified/tested images and third-party ones).

[1]: of course you can launch supervisord and a bunch of stuff underneath it, but if you're doing that, you're doing it wrong.

1 comments
Ok, this is starting to clear things up for me.

When you say that it runs a single process by design, does it mean that if my application creates a fork(), the image will be unable to handle scheduling of the additional process?

Let's say I have an application that talks to MySQL. What is the right way in docker? Should I have two separate docker images, one running the application and the other running MySQL, with them talking to each other across the host OS? Or can they be configured in a single docker image?

> Should I have two separate docker images, one running the application and the other running MySQL, with them talking to each other across the host OS?

Yes.

> Or can they be configured in a single docker image?

They can, but it's an anti-pattern and there are hurdles to overcome if you try managing processes using an init system.

People differ on this point. Discourse, for example, ships a single Docker container which runs the Rails-based webapp, a database server (PostgreSQL), and a key-value store (Redis). They have been using this same setup in production for quite a while now.
So how do they run multiple application servers to scale horizontally? Or a cluster of Redis servers?
Thanks. Any idea about this?

> ...if my application creates a fork(), will the container be unable to handle scheduling of the additional process?

Forking works fine.
Hmm... if there's no kernel, who manages the process scheduling?
There is a kernel, Docker uses the host's kernel it runs on.
It uses the host OS kernel, which is why its limited to a subset of Linux host machines.

Honestly Docker is the epitome of the incorrect understanding of "DevOps".