Containers are not VMs

So lately I have been digging deeper and deeper into containers and there usefulness. It seems that a lot of people blur the line between VM’s and Containers. I think its important that we define the two here before we get to invested in this article.

VM Concepts

A VM per its name is a Virtual Machine, so this by default is Read/Write enabled. Where your changes aren’t lost in reboots or host shutdowns. This is great for things where your not using source control. And your machine isn’t defined as Code!.

LXC Containers

Now lxc containers are read/write or even read only containers. This have the same issue as VM’s and that is they arent defined by code. They have act like VM’s or act in the ideaism’s of Docker containers if you wish. This dont have a hypervisor, cgroups can be a nightmare to get working depending on our OS they my or not work.

Docker Containers

Now Docker containers are defined as Code, but they are read only. So you can’t use them as a vm and except your changes to stick unless you define it in the code that makes the container. These typically only host one service, or one task. Such as a Web Server or a Database server. Their cgroups work out of the box.

Container Concepts

So the ideaism behind containers is this you have a service say nginx and your going to host your website. 99% of the time your not going to need to increase the number of nginx servers but the services that run php, ruby,etc. So you would a nginx docker container, a php-fpm container set and haproxy. Your nginx container would point to the HAProxy container which in turn points to the php-fpm containers that you would scale based on demand. This is called one service or one task containerism.

So now that we have that cleared up. At work we are making the move to containers and really considering docker over lxc. We have a lot of old school thought of we need to make a quick fix just ssh to the containers and make the fix. This is all good as long as you make sure the change is done at the container code level before its forgotten. So that the next build of the container has those changes. Moving to Infrastructure as Code from a Infrastructure with 500 physical machines is a hard concept for a lot of people to get behind. It requires a whole different train of thought. You have to forget the idea of oh I can just ssh to there and do what I need. This is called system drift. Your system configuration management tool should be the only thing making changes. This is what I call Infrastructure as Pseudo Code.

So how do we avoid drift in machines, or never having a machine at its originally state ? Well this is where containers come in to play. You have the host machine that is completely bare nothing more than what it needs to do its job configured. Only services that should be installed are sshd, iscsi for storage and nfs also for storage. Along with your container service of choice. You only connect to the host when you want to get a container setup and running.

So you probably wondering what about a development environment. Local development is how it should be done. Your developers should be able to have access to resources to stand up a small production environment on their machines. This eliminates the need to have a VM in production for developers to work from. Since our Infrastructure is code now, the developer can just do something simple like using a docker compose file to stand up a web, cache, search and db all in a few minutes.

This is a new way of thinking and it takes a lot of time to get people to see that this style is how the industry is moving and to understand it. This is a change that will not happen over night. If you grab some of your senior developers and show them the process and how they can finally have a replica environment that our clients have, this is priceless to them. Now they can truly debug and aren’t tied to a vpn connection or a local network connection.