Deep Dive into OpenShift’s ‘oc new-app’ Command

OpenShift, Red Hat’s Kubernetes distribution, offers powerful developer-friendly tools. Among them, the oc new-app command stands out, offering a streamlined method to deploy applications from various sources. This post delves deep into its intricacies.

What is oc new-app?

The oc new-app command is OpenShift’s versatile tool that simplifies the process of deploying applications. It introspects the provided input, whether a Git repository or a container image, and automatically creates all the necessary resources to build and deploy application.

How does it work?

Based on the argument you provide, OpenShift determines how to interpret it and whether to kick off a build or deployment process:

1. Git Repository: If you provide a Git URL, OpenShift will inspect the content of the repository. If it finds a Dockerfile, it considers it a Docker build. Otherwise, it’ll try to detect the programming language and choose an appropriate S2I (Source-to-Image) builder image. If multiple languages or ambiguous setups are detected, you can use the --strategy option to clarify.
2. Container Image: If you provide a container image URL, OpenShift will deploy the image directly without any build process.

Resources created by ‘oc new-app’

When you run the oc new-app command, the following resources are created in the project:

1. Build Configuration: This defines how to build the application container image. It could be based on source code or a Dockerfile.
2. Image Stream: This tracks versions of an image and can point to an image in OpenShift’s internal registry or and external one.
3. Deployment Resource: Responsible for creating and managing application pods. Uses the image stream as input.
4. Service: Created for any ports that the application container image exposes. If no ports are declared, no service is created.

+Add in the OpenShift Web Console

The ‘+Add’ option in the OpenShift web console is essentially a graphical representation of the oc new-app command. If provides a user-friendly way to deploy applications without having to remember or understand command-line syntax.

The Essence of the ‘app’ Label

In OpenShift, an ‘application’ is technically a collection of resources that share the same ‘app’ label. This approach helps in:

1. Grouping resources that belong to the same logical application.
2. Simplifying commands to act on related resources. For example, you could delete all resources associated with an application using its app label. oc delete all -l app=<app-name>
3. Visualizing applications holistically in the OpenShift web console.

Both the oc new-app command and the “+Add” section in the web console ensure that all resources created as part of an application deployment have this label.

Input Sources, Strategies, and Options Explored

oc new-app
|
|-- [Build Input Sources]
|   |
|   |-- Git Repository URL
|   |   |-- (Build Phase) Uses source code from Git for builds
|   |
|   |-- Docker/OCI Image
|   |   |-- (Deployment Phase) Directly deploys a container from the specified image
|   |
|   |-- Template
|       |-- (Both Build and Deployment Phases) Uses a predefined template to instantiate resources
|
|-- [Build Strategies]
|   |
|   |-- --strategy=source (or S2I, when inferred)
|   |   |-- (Build Phase) Uses a builder image + source code to create a new application image
|   |
|   |-- --strategy=docker
|   |   |-- (Build Phase) Uses a Dockerfile present in the source repo to build an image
|   |
|   |-- --strategy=pipeline
|   |   |-- (Both Build and Deployment Phases) Uses Jenkins Pipelines for build and deployment tasks
|   |
|   |-- --strategy=custom
|       |-- (Build Phase) Uses a custom builder image for specialized build processes
|
|-- [Additional Options]
|   |
|   |-- --code
|   |   |-- (Build Phase) Explicitly provides a Git repo for source code
|   |
|   |-- --docker-image
|   |   |-- (Deployment Phase) Specifies a container image URL for deployment
|   |
|   |-- --image-stream (-i)
|   |   |-- (Both Build and Deployment Phases) Points to an ImageStream for build/deploy
|   |
|   |-- --context-dir
|   |   |-- (Build Phase) Directs to a sub-directory in the Git repo for build context
|   |
|   |-- --as-deployment-config
|       |-- (Deployment Phase) Instructs to create DeploymentConfig instead of a Deployment

The Process

Depending on the input, the sequence can vary. Here’s a typical flow:

1. The build configuration is established by the oc new-app command.
2. oc new-app triggers the initial build.
3. An image stream is created, which points to the container image constructed by the S2I process.
4. A deployment configuration gets created.
5. A replication controller configuration is created due to the initial deployment. If there are future deployments, deployer pods might also be generated.
6. If the application’s S2I builder image exposes a port, a service is established for it, say port 8080/TCP.
7. Build pods from the latest builds are kept for long inspection. Deployer pods get deleted after successful termination.
8. The application pod is generated by the initial deployment.

Builder image in context

A builder image is an image containing all the necessary tools to compile and run an application. When an S2I build is triggered, the source code is injected into this builder image, built, and the resultant application image is then run.

Conclusion

The oc new-app command in OpenShift illustrates the platform’s approach to streamlining application deployment in a Kubernetes environment. By automatically deciphering various input types and harnessing diverse build strategies, this command manages to simplify a process that could otherwise be daunting. Whether you’re someone who leans towards the visual cues of the OpenShift web console or prefers the granularity of the command line, the underlying goal is clear: to make containerized application deployment as straightforward as possible. The adaptability and utility oc new-app underscore its significance in modern developer toolkits.