3 ms·

I really, really, don't understand the docker fixation, but maybe I'm missing something. The most important function of docker, IMHO, is that it standardizes t

by msravi 11y ago

I really, really, don't understand the docker fixation, but maybe I'm missing something. The most important function of docker, IMHO, is that it standardizes the creation of a VM using Virtualbox across platforms. Unless Amazon AWS, DigitalOcean, GoogleCompute, etc. allow a docker image (aka a VirtualBox image) to run directly on their base virtualization platform (without me putting together an AMI or whatever on their platform), this just adds another layer of virtualization that I can do without. Do they do this already? If and when they do that, docker would be tremendously useful because I wouldn't need to rebuild my image for that particular platform (AWS/DO/GC). And if they do that already, then why aren't they just accepting existing popular VM images (VMWare/VirtualBox)?

jon-wood 11y ago
AWS supports deploying Docker images on both Elastic Beanstalk and their new Elastic Container Service. While it doesn't completely remove the need to worry about VMs, it does abstract them away somewhat (ECS much more so).
- msravi 11y ago
  Does the docker image run directly on their base virtualization platform or does it run on top of another OS (that I install) that runs on their virtualization platform? I have an OS in my docker image already, so..
  - eknkc 11y ago
    But you don't have an OS in your docker image really. There's no kernel, no init or system services running if you don't do that yourself. A running docker container is just a process on the host OS with it's own environment. ECS abstracts this away, and from your perspective, containers are running on their virtualization platform.
  - xienze 11y ago
    The "OS" part of a Docker image is really just a minimal environment that "looks and feels" like Ubuntu, CentOS, etc. You're not actually virtualizing a full OS. Running a Docker image is essentially equivalent to running a process (whatever process is defined by your image, i.e. Apache, MySQL, etc.).
bradgessler 11y ago
Docker Machine alone knocks out the entire list of hosts you laid out: https://docs.docker.com/machine/ https://docs.docker.com/machine/ For more sophisticated scheduling needs there is http://www.replicated.com/ http://www.replicated.com/, https://cloud.google.com/container-engine/ https://cloud.google.com/container-engine/, and https://aws.amazon.com/ecs/ https://aws.amazon.com/ecs/ Related to what you say about "don't VM's solve this problem?" is a project called https://hyper.sh https://hyper.sh. They're coming at it from the angle that if VM's can boot really fast, containers are a moot point.
- msravi 11y ago
  So docker machine will create an image for that particular host (AWS/DO/GC...) and create a docker image on TOP of that, correct? It solves the problem of me configuring multiple hosts, but there's still an extra OS layer in there, isn't it?
  - shykes 11y ago
    Docker machine creates and manages VMs, then you can run any number of containers on those VMs.
rcarmo 11y ago
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.
- msravi 11y ago
  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?
  - Kudos 11y ago
    > 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.
saynay 11y ago
I think you are confusing Docker with Vagrant. Vagrant provisions VM, Docker is about containers (which may or may not run on a VM)

by msravi 11y ago

jon-wood 11y ago

AWS supports deploying Docker images on both Elastic Beanstalk and their new Elastic Container Service. While it doesn't completely remove the need to worry about VMs, it does abstract them away somewhat (ECS much more so).

msravi 11y ago
Does the docker image run directly on their base virtualization platform or does it run on top of another OS (that I install) that runs on their virtualization platform? I have an OS in my docker image already, so..
- eknkc 11y ago
  But you don't have an OS in your docker image really. There's no kernel, no init or system services running if you don't do that yourself. A running docker container is just a process on the host OS with it's own environment. ECS abstracts this away, and from your perspective, containers are running on their virtualization platform.
- xienze 11y ago
  The "OS" part of a Docker image is really just a minimal environment that "looks and feels" like Ubuntu, CentOS, etc. You're not actually virtualizing a full OS. Running a Docker image is essentially equivalent to running a process (whatever process is defined by your image, i.e. Apache, MySQL, etc.).

bradgessler 11y ago

Docker Machine alone knocks out the entire list of hosts you laid out: https://docs.docker.com/machine/ https://docs.docker.com/machine/ For more sophisticated scheduling needs there is http://www.replicated.com/ http://www.replicated.com/, https://cloud.google.com/container-engine/ https://cloud.google.com/container-engine/, and https://aws.amazon.com/ecs/ https://aws.amazon.com/ecs/ Related to what you say about "don't VM's solve this problem?" is a project called https://hyper.sh https://hyper.sh. They're coming at it from the angle that if VM's can boot really fast, containers are a moot point.

msravi 11y ago
So docker machine will create an image for that particular host (AWS/DO/GC...) and create a docker image on TOP of that, correct? It solves the problem of me configuring multiple hosts, but there's still an extra OS layer in there, isn't it?
- shykes 11y ago
  Docker machine creates and manages VMs, then you can run any number of containers on those VMs.

rcarmo 11y ago

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.

msravi 11y ago
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?
- Kudos 11y ago
  > 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.

saynay 11y ago

I think you are confusing Docker with Vagrant. Vagrant provisions VM, Docker is about containers (which may or may not run on a VM)