DevOps, Docker

Lightbulb moment with Docker

I’ve heard the word, played with Docker 101 and still was left wondering why this technology is important.  After all, we have VMs we can run applications on and they obviously support a lot more apps than Docker does.  Something drew me back though to actually spin up my own machine with a real Docker Engine and get my hands dirty.

Just a recap to explain the difference between containers and VMs.  VMs are full Guest OS running their own libraries and executable, etc.  They should be pretty familiar concepts to most people at this point.  You can use orchestration and provisioning to stand up the OS, Hypervisor, guest OS, and applications.  Normally, many of us on the Tech Ops side of the house are used to doing it the old fashioned way, we have our shortcuts but we’re still touching or tweaking a few things.  Those of us on larger deployments lean much more towards automation, but it’s often overkill for smaller deployments. Let’s place ourselves in the automated camp and say we have templates for the OS, we can provision on bare metal and even push and configure applications.

Containers, on the other hand, sit on top of an engine (Docker, in this case). You have a base OS and then Docker.  Docker isn’t a hypervisor, it does not map hardware virtually as a standard OS does.  It will take applications (and an OS) and allow them to share resources (mainly libraries and bins) with some, all or isolated from each other.  The biggest thing to keep in mind here is persistence.  When Docker updates a container, it doesn’t apply a patch or update, it rebuilds the entire container.  Sure, you can modify in a container, but that isn’t docker, that’s you doing this.  When you want to update or improve, you’ll lose your changes.  What you ought to do is use the Dockerfile to add the applications and components you need.

First thought I had, is how the heck are you supposed to use a database then?  Can’t really afford to wipe that data. The answer is (and pardon the poor terminology) is mapping a container to a volume on the host (can the host see it? Good, you can have a container hit it). Hope that makes sense, so keeping this in mind, I still struggled to find why Docker matters.

In a past life, I spent over a year on a development team (I had little business being there) but techops didn’t like me because I kept thinking like a developer.  So before DevOps was coined, I was a TechOps person planted into Development and it was great.  I learned a lot by managing deployments and watching the process of SVN and code push.

Now, developers usually checkin code they develop on their machine.  Code is supposed to be merged and then run in a test environment (if one exists).  Then it’s deployed in Production (I’m simplifying this).  Most modern methods of Agile development involve streamlining the code deployment (so developer 1 isn’t waiting for developer 2 to finish so they can work).  Also that code should be complete and automated testing should be used.

I know the big problem coming from devops. It’s the environment.  While some shops can afford multiple copies of Prod, they always lack things.  Let’s say we isolate DEV and copy it from PROD.  It’s stale the second you’re done, often it’s not used, there are differences in testing and eventually it’s flushed down the toilet and rebuilt.  Automation can fix this, cloning environments and data is great.  Technology can’t fix people issues though.

With this in mind, Docker clicked for me.  The issue with most environments is the tweaks or the shadow IT that adds things after a deployment.  Every time I heard the word “done” I ask again and usually find out that the person means 90-99.9% done, which is not done, only 100% is done.  Dockers solves this because you deploy on the same engine and if you changed something, you’re caught. It’s rebuilt EVERYTIME.  This is a GOOD thing.  This means that Dev, QA, Preprod and prod are the same and the infrastructure doesn’t get stale because there isn’t much to manage.

Developers like this because there is no change to the infrastructure, ops should like this because it takes them out of the blame.  I think most will not like giving up control, but if you think hard about this, they aren’t, there is nothing to control.  You can backup the container data and have that persist, but just as easily clone and restore if needed.

I have a lot further to go, I’m just a beginner but I thought I’d share how I’m getting some uses for Docker and I really do see it as the future (no clue what date that will come).  BTW, Docker runs on VMware, generic Linux, AWS, Google Cloud and many more.  If the Engine is the same, the apps under it can be used on whatever platform you have.  Think of the savings in management on all those Guest OSes.  What about the licensing and support?!?

Granted, not everything runs on Docker, but everyday more does.  If I were a vendor, I’d be integrating it to utilize Docker before your competitor does.

PS – I didn’t even edit this thing so please pardon the grammar or runons.

2 thoughts on “Lightbulb moment with Docker

  1. I also played with docker- yes, it seems nice, but I still struggle to understand how it would improve my build-release cycle.(ignoring for a moment that you can set cpu and memory limits, that sure is a nice feature).

    I think you have a major mistake in your writeup on dev/qa/prod.
    You should never create Dev by cloning Prod.
    You clone Prod from Dev,for example by releasing into both from version control by tag.
    Data is another story, and yes, you must clone it Prod->Dev, but I dont see how Docker changes anything here.
    So, Docker or not, good SDLC practices are a must, and so far I cant see how Docker makes anything easier, while I do see tremendous complexity it brings to cluster deployments.

    I think this is an area where good use case examples are missing from documentation.
    Instead, their page one focuses on mechanics of Docker-it should first address “what’s the big deal” question.

    1. Let’s say prod is on postgres 9.2.4, but the dev/qa version is being bumped to 9.2.9, but 9.2.10 was just released (latest).

      You have a big server (40 cores, 128 GB RAM, 12 SSDs) that runs multiple environments (multiple QA, Dev, Demo environments) on-demand.

      You want the convenience and management that comes with using apt-get for package management, but you can’t just “apt-get install postgres”, because, that will install 9.2.10.

      Ok, so pass some extra args to apt-get to install a specific version.. well you can’t just do that because 9.2.9 and 9.2.4 have different system library dependencies, etc.

      Sure, you can manually install everything, but now it’s become a huge PITA.

      “docker run postgres:9.2.9”
      “docker run postgres:9.2.4”

      Now you have what you want, but you have no “host pollution”

      For me, this type of scenario is the biggest win for docker. I think of it as “encapsulated and isolated runtime environments”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s