WTF is a container?

I could maybe see the advantage if you had no control over the environment that the app was going to be run in like you might have with a downloaded executable for example. However, if your product is just some kind of web application, I don't see the need for containers.

I was expecting this kind of thread long ago, thanks guys for sharing your concerns, I am learning a lot from them!

IMO we can't compare containers vs VMs like many are doing now - and I was too when first heard about Docker and containers.

I hold almost all VMware certs (VCP/VSP/VTSP for 3.1/4.x/5.x and VCDX), I sign the 3 major VMware P2V migrations in BR/LA (287 P2Vs in 2005, 1600/2008 and 2500/2011). I was REALLY into VMware from 2000 to 2010, so I feel confident using it and recommending to many environments. I even manage some of them still today.

When we clone or migrate a physical machine to virtual, or whenever deploying a VM from scratch (or even using templates or copying VMdks etc) into production, we aim to develop the environment in order to see it lasting "forever". We want this to be flawless, because even with given most-players virtualization deploying resources (hyper-V, VMware, xen, kVM, vbox+vagrant, etc), nobody wants to troubleshoot a production environment, we cheer to see the VMs always up and running. I remember when P2V in mentioned projects during the night, and needed to fallback physical servers because the cloned VM didn't behaved accordingly. Please VMware, clone it ok, otherwise the troubleshoot for legacy shit will be a pain.

On the other side, containers are made to be replaced. They are impermanent. You can tune your images as your app/env needs. You can have an image for each service you have. You can have many images running many containers, and some of them providing services you have. You are able to customize an image in a txt file called Dockerfile, and generate an image from this file.

So imagine we got this infrastructure to "Dockerize" , a website with a DB. Does your webserver runs apache? so you can code a Dockerfile, that will deploy an apache instance to you. It could deploy FROM an ubuntu:16.10 or 10.04, depends on what is better for your app. OR, we could just pickup Apache's own image, like in FROM apache. You can save this image as yourid/apache. And you can do the same regardless of what DB you are using, just install it (the mysql using apt-get in a FROM ubuntu/debian based system), or use mysql images directly. You are able to publish the website cloning your site dev repo direct in Dockerfile itself, or you could have the website at some dir in your host, using ADD or CP to make it available in the right container dir (eg /var/www/) You could even use Volumes, to mount some host dir (or a blob, or a storage account, or a partition in your storage, something available in the host itself). This is specially interesting for DB in my opinion. Once you have your Dockerfile ok, you can name it yourid/db.

And if you have a main website, and a blog website, you could use the same apache Dockerfile changing only the git clone line, and save them as yourid/apache:website and yourid/apache:blog for example.

And when redeploying the container, you will have the same volume data available in the same container dir. Even if you redeployed it from ubuntu:15.10 to ubuntu 16:10.You can use the latest improvements from the freshest image (or patching some vuln), and redeploy all your containers that uses this same image at once.

The same goes on, you can test jenkins without knowing what OS jenkins image is made off. You dont have to worry about it. It will just work. You pull the image and run the container and voila.

NOW, my Docker instances are like this: I use Docker-machine, and locally I got the default and local envs. I got also an Azure instance at Docker-machine (that runs on Azure), and another instance configured in Docker-cloud using Azure as cloud provider (I use Azure due bizspark credits). So, 4 of them. All those instances, are VMs themselves. Ubuntu VMs to be sure.

You just replace the container (probably published in a cluster if you care enough your prod env). Not the same as with VMs at all.

I see Docker as a hypervisor for containers the same way VMware and hyperv are to VMs.

So I understand my Docker hosts VMs have the same HA, failover, load balance, resources allocation, and so many resources VMs have. I use Docker on those VMs to make easy deploys, images, tune images, really guys I was the VMware guy for so long, I went just crazy in the resources Docker gives to us.

Docker has many weak points indeed (NAT networking, privileged containers must be run sometimes, security concerns, etc), but again, I don't see Docker to be erasing VMs from my life and now on I can deploy everything that will run happy forever in containers. We still need HA, failover, load balance, resources allocation and so on. Docker needs to be used together with TOOLS that allows it to run smoothly, and allows us to maintain our environments easier.

One of those tools are containers clusters. I work mostly with Google Kubernetes, but there are other as Docker Swarm, Apache Mesos, DCOS... Azure has its Azure Container Services ACS, IBM has its BlueMix containers, etc. Using a cluster and a deploy methodology, you are able to deploy your containers in different namespaces such as DEV / STAGING / PROD. You can use a BUILD environment to read your Dockerfile, build the image and deploy containers to the namespace you need. You can configure this build to trigger with a commit in the git repo for exemple.

So lets say we have a developer, and he needs our yourid/apache:website to be deployed, with the new website version. If the website is already updated in your git repo, you just clone it. The Dockerfile would look like this:

  FROM apache
  MAINTAINER Your Name 
  WORKDIR /var/www/
  RUN git clone https://github.com/yourid/website/website.git .
  EXPOSE 80
  CMD ["/run.sh"]

You can customize your Dockerfile of course and add support to specific codes like installing PHP, Ruby, Python, etc. You could even use Configuration Managers (CMs) as Ansible, Salt, Chef, Puppet, juju etc to apply those changes.

Lets say we will start the build now. We are developing this image together. So I just changed my git url on the Dockerfile. When we commit, the autobuild triggers this build in our build system (in my case, Docker-cloud or jenkins). This is what Continuous Integration (CI) and Continuous Deployment (CD) are about.

So when build is triggered, it gets the Dockerfile from the repo, builds from its image, deploys the container in the namespace you wanted (our case, DEV). This service could be published as website.dev.mydomain.com for example. Same concerning to staging namespace. And to www.mydomain.com when ready to production, in the PROD kubernetes namespace for example. Kubernetes is a distributed thing, so you could have minions (nodes) splitted across different datacenters, or geo locations. This pretty much reminds me of VMware VMs running inside VMfs storage made available through a set of ESXi servers, all with access to the same luns/partitions/volumes.

This is just my point of view, so please feel free to comment and ask me anything.

Please, just dont blame Docker because you aren't aware of mainstream techs available nowadays. If you are comparing Docker to VMs, or SSHing inside the containers, and often mad cause your data vanished while redeploying your Docker Containers, believe me you are doing it wrong.

Being a pioneer is often the same: in the 90s we had to explain why Linux was good for the enterprise, in the 2000's we had to prove VMware was really going to cluster your legacy systems, and now we have to explain what's possible to do with Docker. And, as the tech is new (I know there were previously solaris zones, google borg, etc), but I see Docker will mature its features relying in other tools (and even copying features from k8s to Swarm eg). Docker is just one skill needed to run your stuff.

Cheers!

M Matos https://keybase.io/mmatos