[FoRK] Docker 1.0 was Re: OSX VMs/backup, Re: Dunning-Kruger effect discriminatory environs

Gregory Alan Bolcer greg at bolcer.org
Thu Jun 12 06:36:21 PDT 2014


It's extremely useful for some types of software.

Greg

On 6/12/2014 5:03 AM, Stephen Williams wrote:
> A container isn't a VM, even though it feels like it is.  Processes are
> running on the host OS natively. It is just an extension of chroot:
> Certain system calls look at a certain table among a set of tables.  The
> "host" is just the default table.  I haven't looked at the code for a
> long time, but I believe every involved system call already pays the
> tiny price to decide whether you are the "host" or a container even for
> "native" process system calls.
>
> In other words, containers are effectively free.  Additionally, as
> opposed to a VM, there is no emulation at all, no additional copy of a
> kernel and kernel data, completely shared use of buffers, over
> subscription of memory, text images of processes running in unrelated
> containers, etc.  All the benefits of running multiple processes on a
> Linux kernel with strict security and logical separation of networking,
> process ID/etc. space, sockets, file systems (chroot), etc.
>
> The main negative is that a process hogging CPU or memory can affect
> other containers in ways you can prevent more completely with a VM.
> However, there is a lot of existing practice managing this as all of the
> cheap web hosting has been done by containers for a very long time.  The
> security issues were addressed long ago due to that severe test.  In
> running your own services on containers, you can decide how to balance
> CPU cores, load, storage access, memory, etc.  You might put 20
> lightweight / infrequent services on one machine and just 1 of a
> heavyweight system role on another.  And "machine" can be a raw machine
> or a VM.
>
> The power of Docker et al is being able to easily develop, build, and
> test system configurations more like edit/compile/debugging for
> software.  We automate complex software builds for a reason. Finally we
> have that for system configuration.  Since getting certain system
> administrators to document or knowledge share anything seems to be
> impossible, this becomes invaluable fast.
>
> Stephen
>


More information about the FoRK mailing list