The Overhead of Docker Run

First published on Medium on 10/11/2016.

We use Docker a lot. Like a lot, lot. While we love it for a lot of things, it still has a lot of room for improvement. One of those areas that could use improvement is the startup/teardown time of running a container.

The Test

To test the overhead of running a Docker container, I made a script that compares execution times for various docker run options vs not using Docker at all. The script that I’m running is a simple hello world shell script that consists of the following:

echo "Hello World!"

The base Docker image is the official Alpine linux image plus the script above.

4 Things to Compare

  1. As a baseline, the first measurement is sans Docker. This is just running the hello.sh script directly.
  2. The second measure is just docker run IMAGE.
  3. The third measure adds the “rm” flag to remove the container after execution.
  4. The final one is to use docker start instead of run, so we can see the effect of reusing an already created container.

Docker for Mac

Server Version: 1.12.2-rc1

Running: ./hello.sh
avg: 5.897752ms
Running: docker run treeder/hello:sh
avg: 988.098391ms
Running: docker run — rm treeder/hello:sh
avg: 999.637832ms
Running: docker start -a reuse
avg: 986.875089ms

(Note: looks like using Ubuntu as a base image is slightly faster than Alpine, in the 10–50ms range).

Docker on Ubuntu

Server Version: 1.12.1

Running: ./hello.sh
avg: 2.139666ms
Running: docker run treeder/hello:sh
avg: 391.171656ms
Running: docker run — rm treeder/hello:sh
avg: 396.385453ms
Running: docker start -a reuse
each: 340.793602ms

Results

As you can see from the results above, using Docker adds nearly a full second to the execution time of our script on Mac and ~390ms on Linux (~175x slower than running the script without Docker).

Now this may not be much of an issue if your script/application runs for a long period of time, but it is certainly an issue if you run short lived programs.

Try it yourself

Feel free to try running the script on your system and share the results! You can find everything you need here:https://github.com/treeder/dockers/tree/master/hello

Just clone that repo, cd into the hello directory and run:

go run time.go

What is Serverless Computing and Why is it Important

serverless-largeServerless computing has blown up in the past 6 months and along with all the excitement is a lot of questions. I’ll attempt to address some of the questions and talk about the pros and cons of serverless.

We created Iron.io five years ago to solve the problems that serverless computing solves. In fact we built the company on this premise. We were trying to solve a problem we were having at our previous company, where we had to setup a DIY data processing system for each one of our customers, then manage and monitor all these servers. We wanted (needed!) a system that allowed us to write code that could crunch a lot of data and have that run on an as needed basis on a system where we wouldn’t have to think about or manage the servers. And we wanted to be able to use that same system for all of our clients and have it easily scale out to many more.

So like any self respecting engineers, we went ahead and solved our own problem and that solution became Iron.io. (more…)

Hybrid Iron.io – On-Premise Job Processing with the Help of the Cloud

Hybrid_IronioHybridOne of our main goals for the Iron.io platform is run anywhere. This means we enable customers to use our services on any cloud, public or private. With Hybrid Iron.io, we’re making it drop dead simple to get the benefits of the public cloud, with the security and control of a private cloud. 

Using Iron.io’s public cloud service is easy, you just sign up and start using it. No servers to deal with, no setup and no maintenance. You can be up and running with a very powerful technology in a matter of minutes. It’s a beautiful thing. (more…)

Microcontainers – Tiny, Portable Docker Containers

microwhale-vs-bigwhale

Docker enables you to package up your application along with all of the application’s dependencies into a nice self-contained image. You can then use use that image to run your application in containers. The problem is you usually package up a lot more than what you need so you end up with a huge image and therefore huge containers. Most people who start using Docker will use Docker’s official repositories for their language of choice, but unfortunately if you use them, you’ll end up with images the size of the empire state building when you could be building images the size of a bird house. You simply don’t need all of the cruft that comes along with those images. If you build a Node image for your application using the official Node image, it will be a minimum of 643 MB because that’s the size of the official Node image.

I created a simple Hello World Node app and built it on top of the official Node image and it weighs in at 644MB.

That’s huge! My app is less than 1 MB with dependencies and the Node.js runtime is ~20MB, what’s taking up the other ~620 MB?? We must be able to do better.

What is a Microcontainer?

A Microcontainer contains only the OS libraries and language dependencies required to run an application and the application itself. Nothing more.

Rather than starting with everything but the kitchen sink, start with the bare minimum and add dependencies on an as needed basis.

Taking the exact same Node app above, using a really small base image and installing just the essentials, namely Node.js and its dependencies, it comes out to 29MB. A full 22 times smaller!

pasted_image_at_2016_01_22_11_20_am

Regular Image vs MicroImage

Try running both of those yourself right now if you’d like, docker run –rm -p 8080:8080 treeder/tiny-node:fat, then docker run –rm -p 8080:8080 treeder/tiny-node:latest. Exact same app, vastly different sizes.

(more…)

Introducing Custom Docker Images, Private Docker Repositories and Environment Variables

customcontainer

We’re happy to announce three awesome new IronWorker features:

  • Custom Docker Images for all and Docker is now the default code packaging mechanism
  • Support for private Docker images on any Docker Registry, including Docker Hub
  • Support for custom environment variables

I’ll explain each of these features in more detail below.

Custom Docker Images for All!

Previously only available to customers on dedicated plans, this is now available to everyone! You can create custom Docker images and run them at scale on the Iron.io Platform. And as usual, you don’t need to think about servers or scaling or managing anything, you just queue up jobs/tasks. Jobs are executed using your Docker image + a message/payload that defines that job. 

To read how to make your own Docker Worker using the language of your choice, please see our Docker Worker GitHub repository for full documentation for most languages. 

There is a size limit to custom images on our small/free plans of 200MB so you’ll definitely want to use our iron/x base images that we use in our examples to keep them small. If you need bigger images, you can upgrade your account. 

Once you’ve pushed your image to Docker Hub, simply let Iron.io know about it:

Then you can start queuing up jobs for it.

You can see the full API here and client libraries for the language of your choice here.

Private Docker Repositories

Not only can you use your own custom images, you can store those images privately and still use them on IronWorker. Obviously you don’t want other people to access your code inside your image or any type of config files you might have put in the image (although we recommend using environment variables for that, see next section) so you can use a private Docker repository to keep it private.  

To use your private images on Iron.io, you need to login like you do with Docker:

Then just do everything else like normal.

Environment Variables

Instead of uploading a config file as json, we’ve added support for custom environment variables that will be passed into your Docker container at runtime. This allows you to set options that you don’t want to include in your Docker image, such as database credentials or variables that might change based on the environment (development vs production for instance). 

These are set by using -e flags on iron register, for example:

That’s it for Now

These new features give you full capability to use Docker to it’s full potential. Now that this is in place, there’s a lot of exciting new things to come that will build on this.

Docker + Iron.io = Super Easy Batch Processing

lotsocontainers

There is a ton of use cases for batch processing and every business is probably doing it in some way or another. Unfortunately, many of these approaches take much longer than need be. In a world of ever increasing data, the old way can now hinder the flow of business. Some examples of where you’ll see batch processing used are:

  • Image/video processing
  • ETL – Extract Transform Load
  • Genome processing
  • Big data processing
  • Billing (create and send bills to customers)
  • Report generation
  • Notifications – mobile, email, etc.

We’ve all seen something that was created during a batch process (whether we like it or not).

Now, I’m going to show you how to take a process that would typically take a long time to run, and break it down into small pieces so it can be distributed and processed in parallel. Doing so will turn a really long process into a very quick one.

We’ll use Docker to package our worker and Iron.io to do the actual processing. Why Docker? Because, we can package our code and all our dependencies into an image for easy distribution. Why Iron.io?  It’s the easiest way to do batch processing. I don’t need to think about servers or deal with distributing my tasks among a bunch of servers.

Alright, so let’s go through how to do our own batch processing.

(more…)

The Easiest Way to Develop with Go — Introducing a Docker Based Go Tool

Via Medium

While trying to make a drop dead simple example for running Go programs on IronWorker, I realized there’s just no simple way to for us to point someone at an example repo with Go code and have them up and running in a few minutes. This can be done in other languages fairly easily because they don’t have special requirements like a GOPATH, a specific directory structure, and they typically have easier dependency management.

(more…)

IronMQ v3 is 10x Faster than RabbitMQ

mideast-iran-asiatic-_horo-2NEWLast year, we announced IronMQ v3, which was rewritten from the ground up to focus on performance and easy deployment/management for on premise installations. Since then, we’ve put all of our highest volume customers on it, some doing billions of requests per day, and nobody has hit the limits yet.

As our technology continues to evolve, it’s important that we continue to measure and benchmark. Here are the results of benchmarks we’ve run comparing IronMQ to RabbitMQ. (more…)

An Easier Way to Create Tiny Golang Docker Images

Docker_Golang_IronAtlassian just posted a blog post about creating Static Go binaries with Docker on OSX which shows how to make a tiny little Docker image (~6MB total) with your Go program inside. When I read it, I thought “this is cool… but way too complicated”. I’ve been using Docker a lot lately and knew there had to be an easier way. Here is that way. (more…)

How to Cross Compile Go Programs using Docker

cross-compile-image

There are several ways to cross compile Go programs, but the way we’re going to show you is awesome because you don’t have to install any libs or anything. That said, you do need Docker installed, but you already have that anyways, right?

We use this to create our Iron.io command line tool binaries. You can find our tool and build scripts here: https://github.com/iron-io/ironcli

(more…)