Understanding Docker, Containers and Safer Software Delivery

Databases, dependencies, cron jobs … Applications today have so many layers that it isn't a surprise when moving things takes a lot of time. But it doesn't have to be that way. Today, you can ship software to virtually any environment, and be up and running in seconds. Enter Docker.

Software delivery

Delivering software used to be easy. The hard part was programming, but once you finished you would just handle the product, maybe fix some bugs, and that'd be all.

Later, with the "LAMP stack" (Linux, Apache, MySQL, PHP) --- which was widely supported by hosting companies --- things got slightly more complicated, but were still manageable. You could deliver dynamic sites linked to databases and set everything up via control panels.

But in more recent times, the scenario has gotten even more diverse and demanding, as new technologies have broken in. NoSQL databases and Node.js, programming languages like Python and Ruby, have gained in prominence. All of these and more have opened lots of possibilities, but now delivering software is not so easy anymore.

Implementation

Applications have become hard to implement. Even if you get yourself a dedicated server, you still have to deal with installing and settings things up, and even some of the maintenance that's needed to get everything up and running. And yet, with everything working, given that now you are in complex and tightly coupled systems with different services and programming languages, there's always the chance that things will break all of a sudden.

Docker to the rescue

Docker makes delivering software easy again. Docker allows you to set up everything --- the software you've developed, the OS in which it will run, the services that it needs, the modules and back-end tools such as cron jobs. All of it can be set up to run in minutes, with the guarantee that it will work on the target system as well as it works on your development environment.

The Problems Docker Solves

These are some of the issues you'll come across at some point or another when delivering software:

• The application you carefully developed with your favorite language (Python, Ruby, PHP, C) doesn’t seem to work on the target system, and you can’t quite figure why.
• Everything was working just fine … until someone updated something on the server, and now it doesn’t anymore.
• An otherwise minor dependency (e.g. a module that’s used only occasionally, or a cron job) causes problems when your client uses the software … But it was working just fine on your computer when you tested it!
• A service your product relies on, like a database or a web server, has some problem (e.g. high traffic for a website, or some problematic SQL code) and acts as a bottleneck slowing down the entire system.
• A security breach compromises some component of the system and, as a result, everything goes down.

These issues fall within the somewhat fuzzy territory of "DevOps", with some of them involving maintenance issues (server updates), some testing issues (checking modules versions), and some deployment issues (installing and setting up everything on a different location). It's a real pain when deployment of something that's already working doesn't go smoothly, instead becoming problematic and time consuming.

Software Containers

You're probably familiar with those large, standardized shipping containers that exist to simplify delivery around the world --- the intermodal container:

You can put pretty much anything in one, ship it anywhere, and at the other end unload what's there --- a car, some furniture, a piano --- in exactly the same, original condition.

In software development, we may spend days trying to get things working on a different environment --- only for them to fail a couple of days later. It's easier and faster to ship a working car to a different continent than to deliver software that works reliably. Isn't that kind of embarrassing?

So people started thinking of something similar to shipping containers for delivering software --- something you could use to ship software in a reliable way, that would actually work as expected: software containers.

This might make you thinks of software installers, like those used to easily distribute desktop applications. With an installer, all you can distribute is an executable and some runtime libraries (small programs that the main application needs for running) --- as long as these don't conflict with those that the system has already installed. In contrast, software containers enable us to ship pretty much anything --- just as with physical containers.

Examples of what you can put in software containers include:

• a Python, Ruby or PHP interpreter, packed with all of the required modules
• any runtime libraries
• specific versions of certain modules (because you never know when a newer version will cause some problems)
• services your application needs, like a web server or a database
• some specific tweaks for the system
• maintenance back end tools, such as cron jobs and other automation.

Simplified operations

Containers simplify operations dramatically. And they're so practical, easy to create and easy to handle that there's no need to put everything into a single one.

You can put the core of your application with the libraries in one container, and call services such as Apache, MySQL or MongoDB, from different containers. This all may sound strange and even complicated, but bear with me and you'll see how doing so not only makes a lot of sense, but it's way easier that it sounds.

Continue reading %Understanding Docker, Containers and Safer Software Delivery%

by Lucero del Alba via SitePoint