If you’re like me—a developer who works with customers who rely on the tried-and-true Red Hat Enterprise Linux (RHEL), works with containerized applications, and also prefers to work with Fedora Linux as their desktop operating system—you’re excited by the announcement of the Universal Base Images (UBI). This article shows how UBI actually works, by building the container image for a simple PHP application.
With UBI, you can build and redistribute container images based on Red Hat Enterprise Linux without requiring a Red Hat subscription. Users of UBI-based container images do not need Red Hat subscriptions. No more extra work creating CentOS-based container images for your community projects or for your customers that prefer self-support.
I tested all these steps on my personal Fedora 29 system, and they should work on any Linux distribution. I am also a big fan of the new container tools such as Podman, which should be available to your favorite Linux distribution. If you are working on a Windows or MacOS system, you can replace the Podman commands with Docker.
Continue reading “Working with Red Hat Enterprise Linux Universal Base Images (UBI)”
I think Red Hat Enterprise Linux 8 is the most developer-friendly Red Hat Enterprise Linux that we’ve delivered, and I hope you agree. Let’s get down to business, or rather coding, so you can see for yourself. You can read the Red Hat corporate press release.
For this article, I’ll quickly recap Red Hat Enterprise Linux 8 features (architecture, containers), introduce the very new and cool Red Hat Universal Base Image (UBI), and provide a handy list of developer resources to get you started on Red Hat Enterprise Linux 8.
Download RHEL 8 now
Download RHEL 8 image
Continue reading “Red Hat Enterprise Linux 8 now generally available”
Here and elsewhere, we get a lot of questions about post-Docker container tools in Red Hat Enterprise Linux 7.6 and Red Hat Enterprise Linux 8 beta. Tools like podman, buildah, and skopeo enable you to create and manage rootless containers, which are containers that don’t require root access to be built and deployed. To help you master the basics, we’re happy to offer a new podman basics cheat sheet.
Continue reading “Podman basics cheat sheet”
I have been talking about systemd in a container for a long time. Way back in 2014, I wrote “Running systemd within a Docker Container.” And, a couple of years later, I wrote another article, “Running systemd in a non-privileged container,” explaining how things hadn’t gotten much better. In that article, I stated, “Sadly, two years later if you google Docker systemd, this is still the article people see—it’s time for an update.” I also linked to a talk about how upstream Docker and upstream systemd would not compromise. In this article, I’ll look at the progress that’s been made and how Podman can help.
Continue reading “How to run systemd in a container”
Not long after Podman developed a certain level of stability and functionality we started to hear questions like, “What about container healthchecks?” It was a tough question with no easy, obvious answers. My colleagues and I would occasionally discuss healthchecks, but we are a daemonless environment, which makes this kind of thing challenging. Without a long-running process or daemon to schedule healthchecks, we needed to look at other parts of the operating system to launch them. Recently, the questions grew more pronounced, and it was high time we resolved this for our users.
I am pleased to say that the latest Podman release 1.2 now has the ability to perform container healthchecks. This article describes healthchecks and explains how we implemented them for Podman.
Continue reading “Monitoring container vitality and availability with Podman”
This past Christmas I gave my wife a set of nesting dolls similar to Russian Matryoshka dolls. If you’re not familiar with them, they consist of a wooden doll, which opens to reveal another doll, inside which you’ll find another doll, and so on until you get to the smallest and often most ornate doll of them all. This concept got me thinking about nesting containers.
I thought I’d try building my own nesting container using Podman to create a container in which I could do Buildah development and also spin up Buildah containers and images. Once this Podman container was created, I could move it to any Linux platform that supported Podman and do development on Buildah from it. In this article, I’ll show how I set it up.
Continue reading “Build and run Buildah inside a Podman container”
A Java runtime environment should be able to run compiled source code, whereas a development kit, for example, OpenJDK, would include all the libraries/binaries to compile and run the source code. Essentially the latter is a superset of the runtime environment. More details on OpenJDK support and lifecycle can be found here.
Red Hat ships and supports container images with OpenJDK for both Java 8 and 11. More details are here. If you are using Red Hat Middleware, the s2i images shipped are also useful to deploy, for example, on Red Hat Openshift Container Platform.
Note that Red Hat only provides OpenJDK-based Java 8 and 11 images. With that said, there will certainly be situations where developers would like to create their own Java runtime images. For example, there could be reasons such as minimizing storage to run a runtime image. On the other hand, a lot of manual work around libraries such as Jolokio or Hawkular and even security parameters would need to be set up as well. If you’d prefer not to get into those details, I would recommend using the container images for OpenJDK shipped by Red Hat.
In this article we will:
- Build an image with Docker as well as Buildah.
- We will run that image with Docker as well as Podman on localhost.
- We will push our image to Quay.
- Finally, we will run our app by importing a stream into OpenShift.
This article was written for both OpenShift 3.11 and 4.0 beta. Let’s jump right into it.
Continue reading “Creating and deploying a Java 8 runtime container image”
I was asked recently on Twitter to better explain Podman and Buildah for someone familiar with Docker. Though there are many blogs and tutorials out there, which I will list later, we in the community have not centralized an explanation of how Docker users move from Docker to Podman and Buildah. Also what role does Buildah play? Is Podman deficient in some way that we need both Podman and Buildah to replace Docker?
This article answers those questions and shows how to migrate to Podman.
Continue reading “Podman and Buildah for Docker users”
Usually, we think about IoT applications as something very special made for low power devices that have limited capabilities. For this reason, we tend to use completely different technologies for IoT application development than the technology we use for creating a datacenter’s services.
This article is part 1 of a two-part series. In it, we’ll explore some techniques that may give you a chance to use containers as a medium for application builds—techniques that enable the portability of containers across different environments. Through these techniques, you may be able to use the same language, framework, or tool used in your datacenter straight to the “edge,” even with different CPU architectures!
We usually use “edge” to refer to the geographic distribution of computing nodes in a network of IoT devices that are at the “edge” of an enterprise. The “edge” could be a remote datacenter or maybe multiple geo-distributed factories, ships, oil plants, and so on.
Continue reading “IoT edge development and deployment with containers through OpenShift: Part 1”
Configuring Kubernetes is an exercise in defining objects in YAML files. While not required, it is nice to have an editor that can at least understand YAML, and it’s even better if it knows the Kubernetes language. Kubernetes YAML is descriptive and powerful. We love the modeling of the desired state in a declarative language. That said, if you are used to something simple like
podman run, the transition to YAML descriptions can be a bitter pill to swallow.
As the development of Podman has continued, we have had more discussions focused on developer use cases and developer workflows. These conversations are fueled by user feedback on our various principles, and it seems clear that the proliferation of container runtimes and technologies has some users scratching their heads. One of these recent conversations was centered around orchestration and specifically, local orchestration. Then Scott McCarty tossed out an idea: “What I would really like to do is help users get from Podman to orchestrating their containers with Kubernetes.” And just like that, the proverbial light bulb went on.
A recent pull request to libpod has started to deliver on that very idea. Read on to learn more.
Continue reading “Podman can now ease the transition to Kubernetes and CRI-O”