Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing Docker ToolBox

blog.docker.com

Post reply on HN
Print view View original

21–30 of 73 posts

Re: Announcing Docker ToolBox

#21

Post by rcarmo »

msravi wrote: post #11

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 th…

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.

Re: Announcing Docker ToolBox

#22

Post by Rapzid »

elvis635 wrote: post #9
girvo wrote: post #3

Nice one. However, VirtualBox's shared-folder support is so god-awfully slow, that here at work we all swapped out the regular boot2docker setup for boot2docker-xhyve[0] which is so much faster at nearly everything that it's not even a comparison. Now, with ailispaw's dockeroot-xhyve you can even get a VM root image that can be grown on the fly, so you never run out of space on your VM when building large Docker imag…

Docker under OSX is a real pain to solve ASAP. I've set Docker on my Linux machine and it's working like a charm. Then I had to do the same for my coworkers running OSX, the vbox shared folders are definitely unusable. Now it's been few days that I'm trying to find the best way to have a two-way sync in order to sync back changes from docker to the OSX folder (eg. when you upload a file and it's saved in the /public…

Shared folder performance has been a known issue for as long as I can remember, with the recommended solution being to use NFS.. Is this not possible on OSX?

Re: Announcing Docker ToolBox

#23

Post by msravi »

rcarmo wrote: post #21
msravi wrote: post #11

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 th…

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) -…

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?

Re: Announcing Docker ToolBox

#24

Post by eknkc »

msravi wrote: post #15
jon-wood wrote: post #14

Earlier quoted context omitted.

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).

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..

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.

Re: Announcing Docker ToolBox

#25

Post by Kudos »

msravi wrote: post #23
rcarmo wrote: post #21

Earlier quoted context omitted.

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) -…

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 t…

> 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.

Re: Announcing Docker ToolBox

#26

Post by msravi »

Kudos wrote: post #25
msravi wrote: post #23

Earlier quoted context omitted.

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 t…

> 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.

Thanks. Any idea about this?

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

Re: Announcing Docker ToolBox

#28

Post by Kudos »

msravi wrote: post #26
Kudos wrote: post #25

Earlier quoted context omitted.

> 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.

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.

Re: Announcing Docker ToolBox

#29

Post by xienze »

msravi wrote: post #15
jon-wood wrote: post #14

Earlier quoted context omitted.

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).

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..

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.).
Post reply on HN