Archived content

Archive date: 2026-01-01

This content is no longer being updated or maintained. The content is provided “as is.” Given the rapid evolution of technology, some content, steps, or illustrations may have changed.

The Source-to-Image functionality of Red Hat OpenShift, an enterprise Kubernetes environment, is very useful and expedient. Simply point the runtime image of your choice (for example Node.js) at a GitHub repository that contains your code. With a few clicks, your resulting application is up and running. But for more complex applications, templating makes a deployment that contains multiple components just as easy to start up. Templating starts with base images and builds on them to create coherent applications.

This article examines how templating works, with examples on Red Hat OpenShift on IBM Cloud. It examines Podman as a means to create the images that templates rely on.

The name Podman might sound a lot like something you use to play MP3s. In reality it is software that you can use to create or manage pods, containers, and container images - all without a container daemon.

The following graphic shows how pods, containers, and images work together:

In Kubernetes, you create pods on a particular node to host your application. Depending on your requirements, that pod consists of one or more containers. You run a container from a single image (which you create from instructions that provide an executable version of your application). Podman comes into play as the builder of your image.

History

The Open Container Initative (OCI) is important to the history of Podman. OCI, a Linux Foundation project, is tasked with creating a formal specification for container image formats and runtime environments. The initiative was established in June 2015, and was (and still is) primarily supported by Docker.

The Podman technology developed out of work with OCI. Podman Alpha Version 0.6.1, released in June 2018, was barely a year old at the time of writing this article.

Advantages of using Podman

There are two predominant types of images Podman understands: docker and oci.

One of the main benefits of using Podman is enhanced security. For starters, Podman can run without root privileges, maintaining almost all functionality. Podman also uses a traditional fork/execution model, as opposed to the client/server model that Docker uses. This model allows passing down connected sockets from systemd and returning notices up through the stack where Podman is ready to receive tasks.

What Podman definitely does not do

Podman does not support docker-compose functionality. It also does not handle container runtime daemons that work with the Kubernetes Container Runtime Interface (CRI). For that work, you can use another tool: CRI-O.

Release milestones and the future of Podman

Podman 1.2 introduced healthchecks.

In upcoming releases, Podman will allow using a varlink back end to connect to remote Podman instances through the command-line interface.

Basic Podman setup steps and common tasks

Podman is a utility provided as part of the libpod library. Installation is as straight-forward as yum install podman, but for specifics for your operating system, or for information on building yourself, see the installation instructions.

Running a container is podman run (use the -d switch for detached mode). And podman ps shows you a list of running containers and containers that are being created. Adding the -a switch gives you a list of /all/ containers.

You can inspect containers for metadata about them, such as IP address:

$ podman inspect -l | grep IPAddress\":
            "SecondaryIPAddresses": null,
            "IPAddress": "",

(Note: If a container is running in rootless mode, an IP address is not assigned.)

If you are familiar with Docker, you will be quite comfortable with Podman's command-line interface, because it is actually based on Docker. Got an image ready to go? Then the podman build command does same as docker build, and you can use the resulting image in a template.

What is a template in Red Hat OpenShift?

Templating is how you get an image or application into the service catalog that shows up in the Red Hat OpenShift Container Platform web console. The following screen capture shows how the service catalog looks in the Red Hat OpenShift web console in IBM Cloud:

Screen capture of the service catalog in the Red Hat OpenShift web console

Each icon in the catalog represents a template. Templates can be as simple as a single image, or they can contain an entire application, consisting of multiple builds, images, and deployments.

Templates typically include the following resources:

Red Hat OpenShift Images: base images for building containers.
Builds: images generated from source code, from applications or Dockerfile.
Images: results of builds.
Deployments: definitions of what images are deployed and how.
Other resources your application might need: storage, networking, and other types.

When you first create a Red Hat OpenShift cluster in IBM Cloud, you notice that there are quite a few Projects that are already created for you. The openshift project is where the existing templates for your cluster are stored. These templates are set up by default to build using a repository that is publicly available on Github. They contain code for the sample application.

For example, the template for nodejs-mongodb-example has its example code hosted at github.com/sclorg/nodejs-ex/. You can see the files used to create the template in the openshift\templates directory of the repository. The beginning of the template file gives some of the general information about the template, including unique, user-friendly names and a description:

  "kind": "Template",
  "apiVersion": "v1",
  "metadata": {
    "name": "nodejs-mongodb-example",
    "annotations": {
      "openshift.io/display-name": "Node.js + MongoDB (Ephemeral)",
      "description": "An example Node.js application with a MongoDB database. For more information about using this template, including OpenShift considerations, see https://github.com/sclorg/nodejs-ex/blob/master/README.md.\n\nWARNING: Any data stored will be lost upon pod destruction. Only use this template for testing.",
      "tags": "quickstart,nodejs",
      "iconClass": "icon-nodejs",
      "openshift.io/long-description": "This template defines resources needed to develop a NodeJS application, including a build configuration, application deployment configuration, and database deployment configuration.  The database is stored in non-persistent storage, so this configuration should be used for experimental purposes only.",
      "openshift.io/provider-display-name": "Red Hat, Inc.",
      "openshift.io/documentation-url": "https://github.com/sclorg/nodejs-ex",
      "openshift.io/support-url": "https://access.redhat.com",
      "template.openshift.io/bindable": "false"
    }
  },
  "message": "The following service(s) have been created in your project: ${NAME}, ${DATABASE_SERVICE_NAME}.\n\nFor more information about using this template, including OpenShift considerations, see https://github.com/sclorg/nodejs-ex/blob/master/README.md.",
  "labels": {
      "template": "nodejs-mongodb-example",
      "app": "nodejs-mongodb-example"
  },
  "objects": [
    {
      "kind": "Secret",
      "apiVersion": "v1",
      "metadata": {
        "name": "${NAME}"
      },
      "stringData": {
        "database-user": "${DATABASE_USER}",
        "database-password": "${DATABASE_PASSWORD}",
        "database-admin-password" : "${DATABASE_ADMIN_PASSWORD}"
}

Further down, you find the other two main sections of the template: objects and parameters. In the parameters section, you set values for your application such as memory use limits and service names. The objects section shows specifics about the images the template uses. In the objects section, you see the following nodejsimage specified:

"strategy": {
  "type": "Source",
  "sourceStrategy": {
    "from": {
      "kind": "ImageStreamTag",
      "namespace": "${NAMESPACE}",
      "name": "nodejs:${NODEJS_VERSION}"
    }

Then mongo:

"type": "ImageChange",
"imageChangeParams": {
  "automatic": true,
  "containerNames": [
    "mongodb"
  ],
  "from": {
    "kind": "ImageStreamTag",
    "namespace": "${NAMESPACE}",
    "name": "mongodb:${MONGODB_VERSION}"
}

Summary

If you want to switch one of these images out with one of your own (for example, to replace the database engine), you can copy the file in the previous section, and replace 'mongodb'. Or, start from scratch and create a completely different application! The Templates documentation provides more details.

You can try templates out for yourself at Red Hat OpenShift on IBM Cloud.

How templating works with Podman, Kubernetes, and Red Hat OpenShift

How templating works with Podman, Kubernetes, and Red Hat OpenShift