oc new-app

The tools you use should help you grow from newbie to power user. OpenShift’s command line is one such tool. When getting started with Kubernetes development, the new-app option to the oc command line can help movbe you along the spectrum.

To isolate what the new-app command does, I am going to start a new project that has nothing in it. Continuing with usiong the OpenStack Keystone WSGI app as my target application, I am going to call the new projhect keystonedev:

$ oc new-project keystondev
Now using project "keystondev" on server "https://api.demo.redhatfsi.com:6443".
You can add applications to this project with the 'new-app' command. For example, try:
    oc new-app django-psql-example
to build a new example application in Python. Or use kubectl to deploy a simple Kubernetes application:
    kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node
[ayoung@ayoungP40 ~]$ oc get all
No resources found.

Now I run new-app:

$ oc new-app https://github.com/admiyo/keystone-db-init.git#chmodconf
--> Found Docker image 5e35e35 (4 weeks old) from docker.io for "docker.io/centos:7"
    * An image stream tag will be created as "centos:7" that will track the source image
    * A Docker build using source code from https://github.com/admiyo/keystone-db-init.git#chmodconf will be created
      * The resulting image will be pushed to image stream tag "keystone-db-init:latest"
      * Every time "centos:7" changes a new build will be triggered
    * This image will be deployed in deployment config "keystone-db-init"
    * The image does not expose any ports - if you want to load balance or send traffic to this component
      you will need to create a service with 'oc expose dc/keystone-db-init --port=[port]' later
    * WARNING: Image "docker.io/centos:7" runs as the 'root' user which may not be permitted by your cluster administrator
--> Creating resources ...
    imagestream.image.openshift.io "centos" created
    imagestream.image.openshift.io "keystone-db-init" created
    buildconfig.build.openshift.io "keystone-db-init" created
    deploymentconfig.apps.openshift.io "keystone-db-init" created
--> Success
    Build scheduled, use 'oc logs -f bc/keystone-db-init' to track its progress.
    Run 'oc status' to view your app.

Taking the advice to run oc status:

$ oc status
In project keystondev on server https://api.demo.redhatfsi.com:6443
dc/keystone-db-init deploys istag/keystone-db-init:latest <-
  bc/keystone-db-init docker builds https://github.com/admiyo/keystone-db-init.git#chmodconf on istag/centos:7 
    build #1 running for about a minute - ee21636: removed all but db-sync call (Adam Young <ayoung@redhat.com>)
  deployment #1 waiting on image or update
2 infos identified, use 'oc status --suggest' to see details.

But what has that created:

$ oc get all
NAME                           READY   STATUS    RESTARTS   AGE
pod/keystone-db-init-1-build   1/1     Running   0          2m55s
NAME                                                  REVISION   DESIRED   CURRENT   TRIGGERED BY
deploymentconfig.apps.openshift.io/keystone-db-init   0          1         0         config,image(keystone-db-init:latest)
NAME                                              TYPE     FROM            LATEST
buildconfig.build.openshift.io/keystone-db-init   Docker   Git@chmodconf   1
NAME                                          TYPE     FROM          STATUS    STARTED         DURATION
build.build.openshift.io/keystone-db-init-1   Docker   Git@ee21636   Running   2 minutes ago   
NAME                                              IMAGE REPOSITORY                                                                             TAGS   UPDATED
imagestream.image.openshift.io/centos             default-route-openshift-image-registry.apps.demo.redhatfsi.com/keystondev/centos             7      2 minutes ago
imagestream.image.openshift.io/keystone-db-init   default-route-openshift-image-registry.apps.demo.redhatfsi.com/keystondev/keystone-db-init

From top to bottom:

  • 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.

If I wait a little while and run oc get all again, I see a few more pods.

  • pod/keystone-db-init-1-deploy 0/1 Completed 0 6m42s
  • pod/keystone-db-init-1-fq8qv 0/1 CrashLoopBackOff 5 6m32

When you deploy an application in openshift, you run a command like

oc create -f <file>

When the new-app command runs, it needs a place to perform this action as well. The pod that ends with -deploy is the process in which this happens.

The final pod is the product of running the code we just built. It is in crash loop back off state, which means something went wrong. This is not a surprise, considering there is no database associated with this code, but lets see what the error log shows:

$ oc logs pod/keystone-db-init-1-fq8qv
Databasedb-sync+ echo -n Database
+ echo -n db-sync
+ keystone-manage db_sync
IOError: [Errno 13] Permission denied: '/var/log/keystone/keystone.log'
bootstrap + echo ' [COMPLETE]'
+ echo -n 'bootstrap '
+ keystone-manage bootstrap --bootstrap-password=FreeIPA4All
Traceback (most recent call last):
  File "/usr/bin/keystone-manage", line 10, in <module>
IOError: [Errno 13] Permission denied: '/var/log/keystone/keystone.log'
+ echo ' [COMPLETE]'

Some output elided. But it should be clear that my container has permission issues. This parallels what I saw running locally with podman: I need to run the pod as a specific user. More on that in a bit.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.