After creating a project in OpenShift, what we need to do to work with OpenShift is deploying an application to it. We can use the web console or client tool oc to create a new application in OpenShift. In this tutorial, I will guide you all how to create a new application with the client tool oc!

First, you need to login to OpenShift then select the project you want to work:

The basic syntax for creating a new application in OpenShift with client tool oc is:

Therein:

• <application_name> is the name of the application you want to set. The name of the application must be in lower case, accepting characters from a to z, 0 to 9 and the “-” character. The length of the name is a maximum of 58 characters, the first character must be a character from a to z. The “-” character cannot be located at the beginning or end of the name.
• <location_to_the_source_code> is the path to the Git repository of application source code.

If your Git repository needs authentication, you can add the parameter –source- secret to point to the authentication information.

If the source code of the application is in a subdirectory of the Git repository, you can add the –context-dir parameter to point the path to this directory.

If the application’s source code located in a branch other than the default master branch of Git repository, you can add #<branch_name> following the path to Git repository.

For example, I want to deploy an application in OpenShift using the example project in the tutorial Deploy Spring Boot application in Docker in Huong Dan Java repository on my Github https://github.com/huongdanjavacom/huongdanjava.com, I will run the following command:

When running the above command, OpenShift will automatically detect which build strategy need to be used. This means, based on the source code in the Git repository that we passed above, OpenShift will automatically deploy accordingly. There are 3 build strategies that OpenShift supports, such as Docker, Pipeline, and Source.

For Pipeline, OpenShift will rely on Jenkinsfile file, if this Jenkinsfile file is in our source code, this strategy will be used. Jenkinsfile is the definition file for that Jenkins Build Pipeline!

If there is no Jenkinsfile file, OpenShift will check the Dockerfile file, similar to Jenkinsfile, if the Dockerfile file exists, this strategy will be used. Dockerfile, you know, it defines Docker Image to run containers. See more here.

The final strategy is also the default strategy if our source code doesn’t have Jenkinsfile or Dockerfile, it’s Source strategy. This strategy uses the framework Source To Image to build Docker Image from the source code of the application.

Because the example project, I intend to use to deploy an application, is containing Dockerfile, you will see the results when running the above command as follows:

As you can see, a Deployment Config has been created for the “spring-boot-docker” application, which means our application has been deployed to a Pod in that Kubernetes system.

Run the command:

to view the log, you will see the following result:

Along with deploying our application to a Pod, a Docker Image has also been built and pushed to OpenShift Docker Registry at 172.30.1.1!

But now, we cannot access our application. We need to expose a Service to the Deployment “spring-boot-docker”:

then expose a Route from this Service:

Check the information of the newly created Route:

As you can see, “http://spring-boot-docker-huongdanjava.127.0.0.1.nip.io/” is the URL that was exposed outside of the spring-boot-docker application we just deployed in OpenShift above.

Request to http://spring-boot-docker-huongdanjava.127.0.0.1.nip.io/hello, you will see the following result:

So we have successfully deployed an application on OpenShift already!