3 ms·

These all feel pretty dead-on to me. One thing that I think Docker has struggled with is successfully mapping the mental model of working with VMs to working wi

These all feel pretty dead-on to me. One thing that I think Docker has struggled with is successfully mapping the mental model of working with VMs to working with containers. I doubt I'm alone in having tried and failed to wrap my head around the concepts. Is there any comprehensive guide on "this is how you do X with VMs, and here is how you do the same thing with containers"? Or are the use cases sufficiently disjunct that this wouldn't even be a reasonable thing?

majewsky 9y ago
It depends. Maybe you know the "pet vs. cattle" analogy; VMs are used on both sides of the spectrum, whereas containers are squarely on the "cattle" side of things. VMs are often used in a pet-style workflow, where an individual VM is long-lived and serviced (e.g. you install security or feature updates and maybe reboot it once in a while). So the VM is a "pet" that you give a name and care for. You can also deal with VMs in the "cattle" manner: When the VM is having trouble, you just kill it and spin up a new one. (Only when problems cannot be solved by this do you start investigating more closely.) When you want to apply a package update or new configuration, you build a new VM image, spin up the new VM with the new image, and kill the old one when the new one is up and running. That approach requires that you can spin VMs up and down within very short notice, so you would see that approach more often in cloud environments vs. traditional hosting environments (where you, as the customer, book each VM individually, e.g. via a ticket). And the whole toolchain around containers is manufactured around this cattle-like workflow, since containers are easier (and quicker) to launch than a VM, and can be thrown away more quickly as well. So if you're managing your VMs with a cattle-like workflow, it should be possible to map the tasks that you're doing there to Docker commands (or, more likely, Kubernetes commands etc.). But if you're working in a pet-like workflow, that's not going to map as easily. Note: All of this is about VMs/containers in production. During development, different tools may be used (in the same way that, for instance, you wouldn't use Vagrant to manage production VMs). I'm skeptical if there's enough of a unified approach that you could make a guide like "command X maps to command Y". (For example, I develop applications that are packaged in Docker for shipping to prod, but I don't use Docker at all during development.) If in doubt, I would look at the program in question, and see if it has instructions around how to use the Docker image in development.

majewsky 9y ago

It depends. Maybe you know the "pet vs. cattle" analogy; VMs are used on both sides of the spectrum, whereas containers are squarely on the "cattle" side of things. VMs are often used in a pet-style workflow, where an individual VM is long-lived and serviced (e.g. you install security or feature updates and maybe reboot it once in a while). So the VM is a "pet" that you give a name and care for. You can also deal with VMs in the "cattle" manner: When the VM is having trouble, you just kill it and spin up a new one. (Only when problems cannot be solved by this do you start investigating more closely.) When you want to apply a package update or new configuration, you build a new VM image, spin up the new VM with the new image, and kill the old one when the new one is up and running. That approach requires that you can spin VMs up and down within very short notice, so you would see that approach more often in cloud environments vs. traditional hosting environments (where you, as the customer, book each VM individually, e.g. via a ticket). And the whole toolchain around containers is manufactured around this cattle-like workflow, since containers are easier (and quicker) to launch than a VM, and can be thrown away more quickly as well. So if you're managing your VMs with a cattle-like workflow, it should be possible to map the tasks that you're doing there to Docker commands (or, more likely, Kubernetes commands etc.). But if you're working in a pet-like workflow, that's not going to map as easily. Note: All of this is about VMs/containers in production. During development, different tools may be used (in the same way that, for instance, you wouldn't use Vagrant to manage production VMs). I'm skeptical if there's enough of a unified approach that you could make a guide like "command X maps to command Y". (For example, I develop applications that are packaged in Docker for shipping to prod, but I don't use Docker at all during development.) If in doubt, I would look at the program in question, and see if it has instructions around how to use the Docker image in development.