Sélectionner une langue
With the release of the Red Hat Enterprise Linux 8, there is a new set of container tools which allow users to find, run, build, and share containers. This set of tools allows you to start simple with podman, and adopt more sophisticated tools (buildah, and skopeo) as you discover advanced use cases. They are released in two streams, fast and stable, to meet developer and operations use cases. Finally, these tools are compliant with the same Open Containers Initiative (OCI) standards, just like Docker, allowing you go build once, and run anywhere.
Reasons for a New Set of Tools
When you first start building software, it’s OK to start simple--when I first started cooking, I cut everything with a chef’s knife. But, as you gain experience in your discipline, you start to look for ways to refine your selection of tools.
You add a paring knife for detail, a serrated knife to cut foods with waxy surfaces, and of course a honing steel for daily sharpening and a whetstone for when it’s time to get down to business (I spent hours online finding the right whetstone #justsayin). The same is true with my auto tools, carpentry tools, and even the tools I carry when snowboarding or mountain biking. Most of us are on the hunt for the lighter, better, stronger tool to carry day to day. And, let’s be honest, it’s fun to share and talk about these tools too.
This is especially true with software, we even call it software craftsmanship. We love finding the best JSON library, the most elegant CLI parser and most secure role based access control system (RBAC). This extends to tools for building and running containers as well. After a bit of experience, we start to appreciate the little things, the refinements, the things that help us shave fewer yaks. We fall in love with the tools that help us focus on faster, smaller, and more secure containers. We scour the tools landscape looking for tools that can help us easily deploy on Kubernetes (more on that later).
You might be saying to yourself, "but I’m not in the market to buy a new set of knives!" That’s alright, you will be—you will be. Also, when you decide that you need those new knives, you’ll find that we have already curated a beautiful set as part of RHEL 8. If you are already using RHEL, you won’t have to buy anything extra.
So, what does it take to go from a chef’s knife to a full fledged kitchen anyway? Well, it depends because we are five years into this container journey. Your organization might already be well on its path to a cloud native world - and let’s be clear - that’s where we think it’s going, hence the level of automation we have built into OpenShift 4. That said, you may be just beginning your journey, you might even straddle both worlds for a number of years. Moreover, if you look over the past five years of containers, this looks to be the common path from traditional software development to cloud native development.
It starts pretty simple with just finding a new container and running it. The first time you do this, the elegance is striking. You can immediately see the potential to simplify so many things. You might ask yourself, how can I add some value to this, and start to build new containers? Finding, running, and building containers is the first phase of the journey:
Once you build a new container, the next step is sharing them with others. This is the point where you start to research what registry server to use, how to name repositories, how to tag them, etc. This is where true collaboration starts. You go from a chef in your kitchen, to a professional chef working with a team:
But, these first steps aren’t enough. This is where some flounder. They try to abuse this system to run things in production (they use the chef knife to cut everything). They avoid moving to container orchestration, because it requires learning a lot of new concepts. But, inevitably, as your environment expands and grows, you realize that containers can’t be managed with just a container engine. You need container orchestration, you need cloud native services enabled by automation called Operators:
That’s why Red Hat has a portfolio of tools to help you on this journey:
The container landscape can be intimidating for the uninitiated which can lead to a lot of confusion. To get to a cloud native world, you need all of the tools described above. You need RHEL and OpenShift, and Red Hat is making that journey easier with this new set of tools.
Introducing The Container Tools Module
As was announced in RHEL 8 Beta, we are enabling the next generation of containers with a new set of tools. There are several main things to understand about this new set of tools:
New Tool - Podman with help from Buildah and Skopeo
Two Streams - fast for developers, stable for production
OCI Compatible - you can still use your "Docker containers"
Now, let’s explain each in more detail:
When we begin cooking, we start with a chef’s knife. We typically start by cutting anything and everything with it - protein, vegetables, cardboard (maybe this is just me). Podman is the new chef’s knife.
If you started with the
docker CLI, this will be an easy transition. With Podman, you can: find, run, build, and share containers:
podman pull ubi8/ubi podman run -it ubi8/ubi bash podman build . podman push ubi8 quay.io/fatherlinux/ubi8-share
After you use
podman for a while, you will notice all kinds of little features that differentiate it. From simple things like removing all containers/images or running containers as a regular user (Rootless) to sophisticated features which enable transitioning between Podman and Kubernetes/OpenShift:
podman run -it ubi8 bash podman rm --all podman rmi --all podman kube generate podman kube play
As we cook more and more, we often buy a paring knife for detail. Buildah is the paring knife of building containers. Think of it as specializing in the "build" portion of the finding, running, building and sharing journey. Check out features like build time mounts, and granular commits:
buildah from ubi8 buildah mount buildah commit
After we add a paring knife to our kitchen, sometimes we need a Swiss Army Chainsaw. Skopeo is the said chainsaw for the "share" part of finding, running, building, and sharing containers. You can move container images from server to server, or even convert between storage mechanisms on a single server. There’s pretty much no format that Skopeo doesn’t understand:
skopeo inspect docker://registry.access.redhat.com/ubi8/ubi skopeo copy docker://registry.access.redhat.com/ubi8/ubi docker://quay.io/fatherlinux/ubi8 skopeo copy containers-storage://qualy.io/fatherlinux/ubi8 docker-daemon://qualy.io/fatherlinux/ubi8
This article is not intended to go deep into the features of each tool, but for more, check out some of these great articles:
How are these new container tools delivered in RHEL 8? As a module, of course. But, what’s a module?
With the launch of RHEL 8, software is now delivered through what Red Hat calls Application Streams or AppStreams for short. AppStreams enable the flexible delivery of multiple versions of software during a major release of RHEL.
Gone are the days of running
scl commands, or being stuck with an older version of PHP once RHEL is five years old. With AppStreams, you have access to a wide variety of up to date software. AppStreams can be packaged as RPMs or Modules. For more, see Introducing AppStreams in RHEL 8. Here are some example AppStreams to get the idea:
Podman and its dependencies are delivered in two AppStreams in RHEL 8 - one fast stream updated up to four times per year and multiple stable streams released once a year. The feature hungry user can get access to the latest tools, while the stability seeking production user can install once, and defer to Red Hat to worry about security updates:
The fast stream enables developers to get access to the latest version of podman, buildah, and skopeo delivered up to four times per year. These releases will rebase on the latest, stable upstream versions. They will include new features, bug fixes, and security updates. Years into RHEL 8, we still plan to deliver cutting edge features.
The stable stream helps users manage risk. This is a traditional value proposition for Red Hat Enterprise Linux, and the container-tools module continues to deliver on this. Users who just want to install, can "lock in" on a stable version. The version of podman, buildah, and skopeo will remain the same, but critical security fixes will be backported for the life cycle of the stream. New stable streams are planned to be delivered once a year, and supported for two years.
AppStreams enable the delivery of software in a sophisticated new way, but consumption is super simple. The container-tools module offers users the flexibility they want, meeting multiple use cases for years to come.
To install the fast stream with the latest versions delivered each quarter, you'll use
yum module install:
yum module install container-tools:rhel8
To install the stable stream:
yum module install container-tools:1.0
You might be saying to yourself, "but, I want to use my Docker containers!" No problem. We’ve got you covered. Podman can pull and run containers created from Docker, as well as other tools that create OCI-compatible container images. Podman creates OCI-compatible container images, so they will run with other tools that support OCI-compatible container images if you need to go in that direction.
Like many Internet standards, Docker containers are open containers. With the Internet, we don’t use Mozilla web pages, or Chrome web pages—all browsers and web servers communicate with each other using the same protocol governed by the HTTP standard and HTML specifications, CSS, etc. Each browser and web server, is able to focus on the features and capabilities that it sees as useful while ensuring compatibility, providing all users the benefits of innovation.
The same is true with containers. Each container engine, runtime and registry is able to focus on innovation where it sees fit, while ensuring compatibility, enabling users to build and run containers in innovative new ways.
The Open Containers Initiative (OCI), a project within The Linux Foundation, works to create industry standards for container formats and runtimes. Within the OCI, a number of vendors, cloud providers, and other parties have worked to offer specifications and a reference implementation of the runtime (runc, used by almost every container engine including Docker, podman and CRI-O).
This means you can use your existing container images, build systems, and tooling without fear, while still adopting new tools where you see fit. These standards are what allow Red Hat, its partners and competitors to innovate, yet interoperate. If you build OCI compatible containers on one platform, you can run them on another OCI compatible platform. If you push container images to one registry server, you can pull them from another. A healthy ecosystem is good for everyone.
With the release of Red Hat Enterprise Linux 8, Red Hat is showing its leadership with new, high quality, innovative tools, based on open standards.
Red Hat believes it can lead by developing innovations in the container engine, and runtime space that remain compatible with OCI specifications. This will lead to creative new features in OpenShift, and others in the community will pivot off of our ideas. This leads to better technology for everyone. At Red Hat, we love tackling difficult engineering problems.
Thank you to all the great work done through the OCI—you allow us to do our work. Hail the Maintainers!
About the authors
Scott McCarty is technical product manager for the container subsystem team, which enables key product capabilities in OpenShift Container Platform and Red Hat Enterprise Linux. Focus areas includes container runtimes, tools, and images. Working closely with engineering teams, at both a product and upstream project level, he combines personal experience with customer and partner feedback to enhance and tailor strategic container features and capabilities.
Daniel Walsh has worked in the computer security field for over 30 years. Dan is a Senior Distinguished Engineer at Red Hat. He joined Red Hat in August 2001. Dan leads the Red Hat Container Engineering team since August 2013, but has been working on container technology for several years.