OC new App - Build and deploy with oc new-app

 When using the source workflow, developers would:

  1. Clone the project to a local folder, so they can change the code to their liking and maybe test it outside of OpenShift.
  2. Commit and push any changes to the origin git repository.
  3. Log in to OpenShift and create a new project.
  4. Use the oc new-app command to build the container image and create the OpenShift resources that describe the application.
    1. The OpenShift client command creates OpenShift resources to build and deploy the application.
    2. The build configuration resource starts a source build that runs Maven to generate the application package (JAR) and create the application container image containing the application package.
  5. Expose the application service to the outside world.
  6. Use either curl or a web browser to test the application.


The oc new-app command will create all of those objects for you. Just pass it your Git repo URL, and optionally a context-dir (if your code is in a subfolder), and a name:

oc new-app https://github.com/monodot/container-up
  --context-dir=node-hello-world 
  --name=node-app 
  --strategy=source

We used oc new-app to detect the language of our app, and create a BuildConfig. This ran a Source-to-Image (S2I) build, to create a Docker image.

oc new-app also created a Deployment and a Service to run the container in Pods. Finally, we created a Route so we could access the API outside the cluster


The BuildConfig's core is made up of four important parts:

  1. Build source
  2. Build strategy
  3. Build output
  4. Build trigger

OpenShift resources: a service, a deployment configuration, and application pods



  • a pod used to perform the build. This will be relatively short lived. This pod performs git clone and buildah bud and will store the image produced in the local repository.
  • A deploymentconfig. This is an OpenShift pre-cursor to the Kubernetes deployment. See here for a distinction between the two objects.
  • A buildconfig. This will be used to produce the build above as well as additional builds if triggered
  • A build. This is the process performed in the build pod above. This is a common pattern in OpenShift: a pod is used to manage some other resource. The build will live beyond the life of the build pod.
  • An imagestream for our code. This is the set of images produced by the build. The deployment will always attempt to run the latest image in the image stream when triggered.
  • An imagestream for the Centos7 repo, which is the basis for the keystone-db-init image above


Rebuilds with the binary workflow

The fact that the build requires a binary input means that you cannot simply start a new build using the  oc start-build command. You also cannot use OpenShift webhooks to start a new build. If you need to perform a new build of the application, use the mvn command again:



the oc new-app command creates OpenShift resources using hard-coded defaults. If you want to customize them, for example, to specify a readiness probe or resource limits for your pods, you have two options:

  • Find (or create) a suitable OpenShift template, and use this template as input for the oc new-app command. The templates in the openshift namespace are a good starting point.
  • Use OpenShift client commands, such as oc set and oc edit to change the resources in place.

You can peek inside the OpenShift build configuration that the oc new-app command created for you. Note that the strategy is Source and there is a URL input.

Comments

Popular posts from this blog

Read and Navigate XML - Beautiful Soup

difference-between-stream-processing-and-message-processing

WordNet in Python