Re: [PLUG] small business server virtualization?

[Laird Hariu <lhariu@verizon.net>]

Hi All,

I’ve been looking at VMs vs. Containers for some time. I am a developer and an operations person; the so called DevOPs person so I see both sides of the coin.

KVM does run Windows Server. A KVM virtual machine is completely isolated from the host that runs it. You might have play around with the Windows installer but I’ve installed Windows Server 2008 and 2012 on KVM machines.

Docker and LXD containers share the kernel with the host. They are not isolated like a KVM VM.  The main benefit is it allows you to run Redhat applications on Debian/Ubuntu hosts and the reverse. Another big benefit is that a “Dockerized” App can be moved from machine to machine easily. Docker can be seen as an app delivery system. I’ve used Docker to spin up web App demo’s for people to play with without having to invest a lot of operations time. 

Docker is oriented towards micro services. There is no network stack, init system or crontab inside the container.  A large app very often needs to be broken up and placed into multiple Docker containers. Typically, the web server and application code is in one container, the database is in another but it can get much more complicated than that if there are multiple processes talking to each other with web services. 

I have found that it is hard to apply security updates inside Docker containers. One thing I’ve observed is they tend to grow every time a change is made to the code and it’s not clear how to purge the layered file system. Also, the base images at Docker Hub may not change in a timely manner when a zero-day security flaw is announced. This is something I’d love to hear from others because I suspect there is something I am missing somewhere. This problem makes me nervous because the app developers who dominate the Docker world tend not to worry much about down the road system maintenance. Everything is “agile” and quick and dirty. I develop using Agile (Jira) so I can vouch for that.

Ubuntu LXD containers look more like KVM virtual machines. They have their own network stack, init system, crontabs, updating mechanism, etc. You can run a Redhat LXD container on an Ubuntu server. The containers share as much code as possible with the host and with other LXD containers in the in-memory process. They use a Linux kernel facility called CGROUPS to accomplish this while maintaining security. They always share the host machines kernel. I have seen tests that demonstrate that the same hardware can host 10X more Ubuntu LXD containers than Ubuntu KVM virtual machines. 

Large monolithic applications can be hosted in one LXD container. You do not have to break it up into micro services. In general, I consider a LXD container to be a compromise between a KVM VM and a Docker container. You can ssh into a LXD container and you get the feeling that you are on a self contained VM.

I have also seen the nightmare of having to migrate complex Ruby on Rails apps to a newer and/or different OS.  The environment is so complex that I can see why people want to put the App into a container. You can just move the whole mess inside the container to a new host without having to change any application code. This still begs the question of how in the world do you practice proper security update discipline inside the containers. 

Cheers,

Laird Hariu


On 11/7/17, 11:50 AM, "plug on behalf of Rich Freeman" <plug-bounces@lists.phillylinux.org on behalf of r-plug@thefreemanclan.net> wrote:

    On Tue, Nov 7, 2017 at 8:14 AM, Lee H. Marzke <lee@marzke.net> wrote:
    >
    > Again as I understand it , proper containerization is separating an application
    > into it's components, so you wind up with many more components than VM's.
    >
    
    I'd argue that this is proper hosting, and not proper
    containerization, but since containers are cheap you see it more
    there.
    
    > A developer that wants to use the latest release of some library for instance,  can't
    > do that on an LTS release of Ubuntu provided by IT, but in a container he can put together
    > his small application, custom lib, etc and now run it.   IT now has to deal with a huge
    > number of variants of the same lib in production, not to mention that this lib might be only an
    > alpha release, and some how the production app is now failing, or has security
    > issues because of vulnerabilities in that lib.   IT operations cares about different
    > things that developers.   So developers start using more versions of libraries,
    > and perhaps less stable.
    
    So, custom libraries and containers are orthogonal issues.
    
    You can tell your developers to stick to the Ubuntu LTS and run it all
    in a container.  Heck, Ubuntu even publishes Docker images for this
    already.
    
    You can also let your developers deploy whatever library versions they
    want on your VMs or physical hosts.  It will cost you all the hassles
    you bring up, but you can do that.
    
    The image management in Docker makes it easier to add layers with
    things like different library versions.  Separating all your services
    of course also helps because your custom library only impacts one
    service and not 47 of them.
    
    However, the fact that Docker makes it easier doesn't mean that it
    will ever be as easy as just telling everybody to stick to Ubuntu LTS,
    and you can certainly still do that.  Sticking only to the distro libs
    is obviously going to come with some drawbacks, but you can do it just
    as easily with containers.
    
    I wouldn't equate containers with
    have-developers-run-production-servers.  It can make that approach
    easier, but it certainly doesn't necessitate it.
    
    I think the fact that containers are popular in the whole devops crowd
    has led to a bit of conflation.  Containers are just a way to isolate
    processes, nothing more or less. Anything else is an application of
    the technology.  And Docker does WAY more than just containers.
    
    If you can stick to Ubuntu LTS in a VM you can stick to it in a
    container.  It is just a root filesystem.
    
    -- 
    Rich
    ___________________________________________________________________________
    Philadelphia Linux Users Group         --        http://www.phillylinux.org
    Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
    General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug
    


___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug