In our third and final installment (see: part one & part two), let’s take a look at some high-level use cases for Linux containers as well as finally (finally) defending what I like to call “pet” containers. From a general perspective, we see three repeated high-level use cases for containerizing applications:
- The fully orchestrated, multi-container application as you would create in OpenShift via the Red Hat Container Development Kit;
- Loosely orchestrated containers that don’t use advanced features like application templates and Kubernetes; and
- Pet containers.
Continue reading “In Defense of the Pet Container, Part 3: Puppies, Kittens and… Containers”
In our first post defending the pet container, we looked at the challenge of complexity facing modern software stacks and one way that containers address this challenge through aggregation. In essence, the Docker “wrapper” consolidates the next level of the stack, much like RPM did at the component level, but aggregation is just the beginning of what the project provides.
If we take a step back and look at the Docker project in context, there are four aspects that contribute to its exceptional popularity:
- it simplifies the way users interact with the kernel, for features we have come to call Linux containers;
- it’s a tool and format for aggregate packaging of software stacks to be deployed into containers;
- it is a model for layering generations of changes on top of each other in a single inheritance model;
- it adds a transport for these aggregate packages.
Continue reading “In Defense of the Pet Container, Part 2: Wrappers, Aggregates and Models… Oh My!”
It’s been just over three years since Solomon Hykes presented the world with the (so far) most creative way to use the tar command: the Docker project. Not only does the project combine existing container-technologies and make them easier to use, but its well-timed introduction drove an unprecedented rate of adoption for new technology.
Did people run containers before the Docker project? Yes, but it was harder to do so. The broader community was favoring LXC, and Red Hat was working on a libvirt-based model for Red Hat Enterprise Linux. With OpenShift 2, Red Hat had already been running containers in production for several years – both in an online PaaS as well as on-premise for enterprise customers. The model pre-Docker however was fundamentally different from what we are seeing today: rather than enabling completely independent runtimes inside the containers, the approach in
Continue reading “In Defense of the Pet Container, Part 1: Prelude – The Only Constant is Complexity”
In a recent blog post on the appc spec, I mentioned Project Atomic’s evolving Nulecule [pronounced: noo-le-kyul] spec as an attempt to move beyond the current limitations of the container model. Let’s dig a bit deeper into that.
Continue reading “The Atomic App Concept…”It All Starts When a Nulecule Comes Out of its Nest””
At this week’s CoreOS Fest in San Francisco, CoreOS is – unsurprisingly – pushing hard on the Application Container Spec (appc) and its first implementation, rkt, making it the topic of the first session after the keynote and a bold story about broad adoption.
When making technology decisions, Red Hat continuously evaluates all available options with the goal of selecting the best technologies that are supported by upstream communities. This is why Red Hat is engaging upstream in appc to actively contribute to the specification.
Red Hat engages in many upstream communities. However, this engagement should not imply full support, or that we consider appc or rkt ready for
Continue reading “rkt, appc, and Docker: A Take on the Linux Container Upstream”
If you’re working with container images on Red Hat Enterprise Linux 7.1 or Red Hat Enterprise Linux Atomic Host, you might have noticed that the search and pull behavior of the included docker tool works slightly differently than it does if you’re working with that of the upstream project. This is intentional.
When we started the planning process for containers in RHEL 7.1, we had 3 goals in mind:
- Give control over the search path to the end-user administrator
- Enable a federated approach to search and discovery of docker-formatted container images
- Support the ability for Red Hat customers to consume container images and other content included as part of their Red Hat Subscription
The changes we implemented, which are documented on the Red Hat Customer Portal, affect three different areas of the tool:
Continue reading “Understanding the Changes to ‘docker search’ and ‘docker pull’ in Red Hat Enterprise Linux 7.1”