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.
- null
- 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' [COMPLETE] 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> sys.exit(main()) ... IOError: [Errno 13] Permission denied: '/var/log/keystone/keystone.log' [COMPLETE] + 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.