Can't We Just Run Boot2Docker in Production?

Background

I’ve been working with the CTO of a online video game company to develop a container architecture for his business. The goal is to simplify the deployment of new applications as well as make it easier to go back and change code on older applications. The desired state is environmental parity across the infrastructure — this will simplify the assignment of work on different applications to different developers. From developer laptops to production servers, the code will just work!

While Video game production has unique technical and business requirements, infrastructure parity from developer laptops to production servers is a common desire that touches every industry that relies on application delivery.

An Interesting Problem

While discussing possible architectures something interesting came up – When doing video game programming, it is common to embed a scripting language into your main programming language. Lua happens to be a popular language for scripting video games. This company compiles their own Ruby interpreter because they need to embed to script game play logic.

Following the LuaJIT installation instructions, they started on a development server that was set up like production. Ruby compiled without a problem and they began development. As they moved further into the development lifecycle, it became clear that it would be easier and more convenient to move most of the development work to the developer laptops.

So, they began the process of installing all of the developer tools on Mac OSX. Once complete, they began the process of compiling Ruby with LuaJIT. Everything compiled fine, but every time they ran the binary it would exit with a segmentation fault (segfault). The development team worked for four solid hours debugging. Eventually, they realized that they had missed a small piece of documentation.

From the LuaJIT installation guide:

If you’re building a 64 bit application on OSX which links directly or indirectly against LuaJIT, you need to link your main executable with these flags:

-pagezero_size 10000 -image_base 100000000

Also, it’s recommended to rebase all (self-compiled) shared libraries which are loaded at runtime on OSX/x64 (e.g. C extension modules for Lua). See: man rebase

Lesson Learned

Well, the user space matters to developers. Though most non-video game developers are not compiling their own Ruby, almost every language has C based modules that do need compiled. Compiled modules are popular in Perl, Ruby, PHP, Python, and even Java has JNI. Even if you utilize the system() function to execute a shell script, you are relying on the user space and things can get hairy.

User Space vs. Kernel Space - Infrastrcuture Parity

At the end of the day, the CTO said, “By using Docker, I can avoid this [compile problem] and create a documented and reproducible Linux environment. Docker lets me develop an image on OS X and then deploy to Linux servers in production.”

Infrastructure parity from developer laptops to production servers allows development teams to leverage the power of container images. These container images make it easy to avoid bugs created by user space differences between platforms. Let’s shave less Yaks and write more code!


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!