OC new App - Build and deploy with oc new-app
When using the source workflow, developers would:
- Clone the project to a local folder, so they can change the code to their liking and maybe test it outside of OpenShift.
- Commit and push any changes to the origin git repository.
- Log in to OpenShift and create a new project.
- Use the
oc new-appcommand to build the container image and create the OpenShift resources that describe the application.- The OpenShift client command creates OpenShift resources to build and deploy the application.
- 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.
- Expose the application service to the outside world.
- 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=sourceWe 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:
- Build source
- Build strategy
- Build output
- Build trigger
- 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-appcommand. The templates in theopenshiftnamespace are a good starting point. - Use OpenShift client commands, such as
oc setandoc editto 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
Post a Comment