Red Hat OpenShift Developer II: Building and Deploying Cloud-native Applications

This method creates an application in the cluster by deploying an existing container image. You can use any container image that is available in a publicly accessible container registry, such as Quay.io or the Docker Hub.

To deploy an application from a container image, open the Add screen and then click Container Image, which opens the corresponding Deploy Image screen. In the Deploy Image screen, enter the image name. If your container images are private, then you must configure the registry credentials in an Image pull secret. An image pull secret is a Kubernetes Secret object, which Red Hat OpenShift uses to authenticate to private registries.

The Deploy Image form also includes configurable properties for other common aspects of the deployment, such as the application name, the application port, or extra advanced options.

To complete the deployment, click Create at the bottom of the form.

This method creates an application in the cluster by importing the source code from a Git repository, building the container image, and deploying the built image. To deploy an application with this method, open the Add screen and then click Import from Git. In the Import from Git screen, enter the URL of the Git repository.

Optionally, you can set advanced Git options, such as the repository branch, the context directory that contains the application, or a source secret.

In the following example, the application is at the hello branch, in the hello-java/app-src directory of the DO288-apps repository.

Red Hat OpenShift can automatically build a container image from the source code. After you enter the repository details, the cluster analyzes the repository contents, and automatically tries to select the best import strategy. The import strategy dictates how the cluster builds the application container image. For example, in the following screen capture, OpenShift has detected that the context directory of the Git repository contains a Java 17 application.

Based on the contents of the repository, the cluster selects one of the following import strategies.

Similarly to the deployments from a container image, when importing from Git you can configure further aspects of the deployment.

To complete the deployment, click Create at the bottom of the form.

The developer catalog offers a set of curated recipes that you can use to deploy applications and services. As well as providing shortcuts to preconfigured forms for deploying from repositories and images, the catalog also includes services and additional software, such as databases. To access the developer catalog, open the Add screen and then click any of the items under the Developer Catalog card.

If you click All services, then the web console opens the catalog with no filters applied. If you want to refine your search, then you can select the other items under the Developer Catalog card, such as Database. Alternatively, you can apply filters in the developer catalog screen, as the following screen capture shows:

The developer catalog organizes its content based on the software categories and import types. The following options are the available import types:

You can deploy applications by importing JAR files, and YAML and JSON manifests directly into OpenShift.

If you want to import a manifest, then open the Add screen and click Import YAML, which opens a text editor. Use this editor to drag and upload files, or to manually enter YAML or JSON fragments as needed.

If you want to deploy a JAR file from your local computer, then click Upload JAR file from the Add screen.

Most of the methods that have already been described use visual forms to deploy an application. When comparing the form views of each method, the forms differ in the particularities of each method. For example, some methods require a Git repository as the application source, whereas others require an image name.

These forms, however, typically share the fields and sections that are required to configure the deployed application. For example, when you deploy an application, you can define the application name and the name used for associated resources. You can do this by customizing the Application name and Name fields in the General section.

If you need finer control, then you can customize the parameters under the Advanced options section. This section includes properties, such as the application port, or whether the application is publicly accessible.

You can also define additional parameters to further control your deployment, such as environment variables, resource limits, or health checks. To define these parameters, click the corresponding link at the bottom of the form. The following image displays how the web console displays these elements:

When you deploy an application by using the developer perspective, Red Hat OpenShift creates an Application abstraction. Internally, an application is the logical grouping of the cluster objects that include the app.kubernetes.io/part-of label.

When you create an application with the developer perspective, OpenShift uses the Application name field to set the app.kubernetes.io/part-of label in the created cluster resources. The topology screen displays the cluster objects that contain this label under the same application. The graph view depicts the application as a rounded-corner rectangle, which is annotated with the A badge.

Usually, the graph view also displays objects such as Deployment and DeploymentConfig. The graph view displays these objects as circular icons with a badge. The badge is identified with an acronym, which represents the resource type. For example, the acronym for Deployments is D, and the acronym for DeploymentConfigs is DC.

You can organize your applications with the graph view. For example, you can use this view to group multiple deployments into the same application. You can also use the graph view to create visual connections between different elements. This feature is useful to visually represent dependencies between workloads, such as a dependency between a microservice and a database.

If you are an administrator, then installing Operators is a useful way to provide developers with additional software and services. Operators are particularly interesting when a team must add complex software capabilities to their stack, especially if these capabilities require moderate operational effort. For example, an operator such as Red OpenShift Pipelines can enable a team to adopt continuous integration and deployment (CI/CD) techniques, without the need to maintain a dedicated CI/CD server.

The OperatorHub is a way to discover Kubernetes applications that are available to install on Red Hat OpenShift. To open the OperatorHub, from the administrator perspective, click Operators → OperatorHub.

You can use the hub to list and discover operators. To view more details about a particular operator, click the operator card. The pane that opens shows specific instructions and information about the operator. To install the operator, click Install and follow the instructions.

After an administrator installs an operator, developers can use the installed operators to deploy the services that the operator provides. To do this, from the administrator perspective, click Operators → Installed Operators. Then, click the operator that you want to use. Finally, from the operator details page, you can create the custom resources that the operator offers. For example, the Crunchy Postgres for Kubernetes operator introduces the Postgres Cluster custom resource. You can create one of these resources to create a PostgreSQL cluster.