Author: Scott McCarty (fatherlinux)

I’ve been working with the CTO of an 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 the 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.

Red Hat has always given operations teams value in deploying Red Hat Enterprise Linux (RHEL), and that’s no different in a containerized world. But, as a developer, why should I build on RHEL? Does the underlying operating system really affect me?

Background

When discussing an architecture for containerization, it’s important to have a solid grasp on the related vocabulary. One of the challenges people have is that many of the following terms are used interchangeably… often causing quite a bit of confusion for newcomers.

Container

Image

Container Image

Image Layer

Index

Registry

Repository

Tag

Base Image

Platform Image

Layer

The goal of this article is to clarify these terms, so that we can speak the same language and develop solutions and architectures leveraging the value of containers. Note that I am going to assume that you know how to run basic docker commands, but if you need a primer, I recommend starting with: A Practical Introduction to Docker Containers.

In Architecting Containers Part 1 we explored the difference between the user space and kernel space. In Architecting Containers Part 2 we explored why the user space matters to developers, administrators, and architects. In today’s post we will highlight a handful of important ways the choice of the user space can affect application deployment and maintenance.

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!

In Architecting Containers Part 1 we explored the difference between user space and kernel space. In this post, we will continue by exploring why the user space matters to developers, administrators, and architects. From a functional perspective, we will explore the connection that both ISV applications and in-house application development have to the user space.