Looking to explore Red Hat OpenShift streamlined CI/CD workflows to run your ACE container natively on Red Hat OpenShift? In this post we show how to run a simplistic pipeline on OpenShift. You don’t have an OpenShift cluster? No worries. You can also follow this tutorial on your local workstation using Minishift (for OpenShift 3) or CodeReady (for OpenShift 4) which gives you a local cluster for development purposes.
You can download CodeReady Containers and Minishift from;
Red Hat CodeReady Containers
Key concepts and definitions
Before we start, we suggest you refresh your Kubernetes and OpenShift knowledge. Below we summarized some of the key concepts that are referred to from OpenShift documentation.
An image holds a set of software that is ready to run, while a container is a running instance of a container image.
An image registry is a content server that can store and serve container images. (For example: registry.redhat.io) A registry contains a collection of one or more image repositories, which contain one or more tagged images. Red Hat provides a registry at registry.redhat.io for subscribers. OpenShift Container Platform can also supply its own internal registry for managing custom container images.
An image repository is a collection of related container images and tags identifying them. For example, the OpenShift Jenkins images are in the repository.
An imagestream provides a way of storing different versions of the same basic image. An imagestream and its associated tags provide an abstraction for referencing container images from within OpenShift Container Platform. Imagestreams do not contain actual image data, but present a single virtual view of related images, similar to an image repository.
A project allows a community of users to organize and manage their content in isolation from other communities.
You can deploy an OpenShift application from components that include source or binary code, images, and templates. As a result of application creation OpenShift objects that will build, deploy, and run the application will also be created.
Another concept unique to Openshift is the Template object. An OpenShift Template bundles some number of objects that are related from a functional point of view.
In terms of application promotion, Templates can serve as the starting point for setting up resources in a given staging environment, especially with the parameterisation capabilities. Additional post-instantiation modifications are very conceivable though when applications move through a promotion pipeline.
Deployments and DeploymentConfigs in OpenShift are API objects that provide two similar but different methods for fine-grained management over common user applications. They are composed of the following separate API objects:
- A DeploymentConfig or a Deployment, either of which describes the desired state of a particular component of the application as a Pod template.
- DeploymentConfigs involve one or more ReplicationControllers, which contain a point-in-time record of the state of a DeploymentConfig as a Pod template. Similarly, Deployments involve one or more ReplicaSets, a successor of ReplicationControllers.
- One or more Pods, which represent an instance of a particular version of an application.