Subscribe to our blog

The promise of Docker is that it simplifies application deployment, allows greater application density on hosts, and features a portable format that offers unparalleled flexibility over standard packaging. But one thing Docker doesn’t get you is the simplicity of `yum install foo` to install an application. Nor can Docker define or process a directed graph of container orchestration dependencies. We aim to change that.

The Air Gap between Docker and Delivery

Many enterprise developers and ISVs have begun exploring containers as an application delivery system. This is pretty good if you can put one application on a single container, but very few have gone beyond the simple one container per app model.

Google released Kubernetes as a way to add orchestration to those applications that stretch across multiple containers. This at least gives developers a way forward to defining multi-container applications. However, the effort required to piece together orchestration via Kubernetes for an application is still mostly piecemeal with no standardized methodology for delivering an application.

In fact, going beyond the typical basic use case of deploying applications on containers requires much DIY and highly customized processes that are difficult to repeat for different types of applications. There remains a gap in the application delivery via containers model in the form of standardized packaging and deployment tools that are portable, container format agnostic, host platform agnostic, and orchestration engine agnostic. Putting together all three would make the devops model attainable for the rest of us and greatly improve the lives of enterprise IT and developers.

Composite The Birth of a Nulecule

First, let’s look at packaging. How can we package an application for deployment in a container or pods of containers? How do you distribute this package? And how do you run it? In much the same way as yum and RPM combine to form the application management tooling for Red Hat Enterprise Linux, Nulecule is the basis for container-based application packaging. After thinking about this problem, the container tools team at Red Hat decided that we needed a packaging format that met these criteria:

  1. Support any Linux container format and runtime
    1. We don’t want to lock in users to a particular format.
  2. Support any host platform (as long as it can run Linux containers)
    1. We don’t want to lock in users to a particular Linux platform.
  3. Support any orchestration provider
    1. See above (except for orchestration).
  4. Build on existing, available container images
    1. It’s important that developers be able to construct composite applications using off-the-shelf “parts” - in this case, other containers. Think of it as application development via Lego construction.

To do this, we needed an easy way to define the parameters of an application. After looking at the OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) and some other application definition efforts, we decided to create a specification tailored specifically for containers. Thus, Nulecule (...it’s a Simpsons reference: “It all starts when a nulecule leaves the nest…”). The idea is that you should be able to define an application in terms of container images published to a registry, configuration parameters, and orchestration providers.

In the Nulecule file, you define which container layers are needed, the orchestration targets, and the dependencies of each. For example, to use an existing wordpress image, you’ll need another container that supplies a database, such as MariaDB. Or to use OpenShift as an orchestration provider, you may need to inherit some parameters from Kubernetes. The end result is an application definition that, when combined with a root container and a runtime, should be self-contained.

Implementing Nulecule

Now that we have a specification, what then? The next step was to create the tools one could use for deployment. It’s important to note that Nulecule is a specification that can be used by myriad tools. We are creating a reference implementation in the form of Atomic App, but the idea is for Nulecule to be used by anyone looking to solve the problem of packaging container-based applications.

Having said that, we’ve put together our implementation, called Atomic App, that utilizes Docker, Kubernetes, and sometimes OpenShift. Even then, when desired, various pieces can be switched out. Using Atomic App with Rkt, for example, should be feasible. Or, if you don’t want Kubernetes or OpenShift, you can use Just Plain Docker (JPD) as the deployment target - assuming, of course, that you don’t need multiple hosts for your container pods.

Atomic_App_Process How to Get Started

The Nulecule getting started guide walks you through creating an Atomic App.  Using the Atomic App container as your starting point, you define your application graph in Nulecule and then launch the application from inside Atomic App. Note: to use Kubernetes, OpenShift, or any other deployment provider, including Docker, you will minimally need their respective client tools installed on your root container.

After creating your Nulecule file, you simply build a container image from the Atomic App base image:

docker build -t IMAGE [TAG]

This packages the application metadata with the Atomic App deployment tool.

We’ve built up quite a number of example applications that you can find on the Nulecule specification repository. All of the Atomic App containers you see in that repo have been added to DockerHub for ease of use. You can find most of them under the Project Atomic image repository on DockerHub, including the Atomic App base image.

So pull one down, tailor it for your use, and then happy hacking! You’ll find that by using Atomic App, you’ll significantly reduce the time to delivery for an enterprise application in production. Instead of the 5-page readme generally required for these types of applications, you can significantly reduce the learning curve to run, not to mention the virtual trees you’ll save with your simpler deployment instructions.

In addition to trying out Atomic App, we’d like to implement more deployment targets, including Ansible, Puppet, Chef, et al. There is currently a plugin in development to support Nulecule applications from the Cockpit dashboard, and we would love to see support for Atomic App in ManageIQ and other management frameworks. If you’re interested in working on client development tools, management integration, or deployment targets, we’d love to talk to you.


关于作者

按频道浏览

automation icon

自动化

涵盖技术、团队和环境的最新自动化平台

AI icon

人工智能

平台更新使客户可以在任何地方运行人工智能工作负载

cloud services icon

云服务

有关我们的托管云服务组合的更多信息

security icon

安全防护

有关我们如何跨环境和技术减少风险的最新信息

edge icon

边缘计算

简化边缘运维的平台更新

Infrastructure icon

基础架构

全球领先企业 Linux 平台的最新动态

application development icon

应用领域

我们针对最严峻的应用挑战的解决方案

Original series icon

原创节目

关于企业技术领域的创客和领导者们有趣的故事