While it is always tempting to run a program as root, we know we should not do it. When developing, you want to make the process as non-root as possible. Here is what I am doing to write mod_wsgi code and run it as a non root user.
Continue readingHaving used Apache HTTPD for a good portion of my professional career, and being responsible for explaining how OpenShift works, I decided to try and build an Apache HTTPD container from scratch. For follow on work, I want to see the environment, so the container is essentially wrapping a mod_wsgi APP that dumps the environment. I took some trial and error to get it to run. Here is the end result:
Continue readingI finally got a right-sized flavor for an OpenShift deployment: 25 GB Disk, 4 VCPU, 16 GB Ram. With that, I tore down the old cluster and tried to redeploy. Right now, the deploy is failing at the stage of the controller nodes querying the API port. What is going on?
Read moreThe OpenShift installer is fairly specific in what it requires, and will not install into a virtual machine that does not have sufficient resources. These limits are:
Now that I can run the TripleO version of Keystone via podman, I want to try running it in OpenShift.
Continue readingMy recent forays into running containerized Keystone images have been based on a Centos base image with RPMs installed on top of it. But TripleO does not run this way; it runs via containers. Some notes as I look into them.
Continue readingBefore I can run Keystone in a container, I need to initialize the database. This is as true for running in Kubernetes as it was using podman. Here’s how I got keystone-db-init to work.
Continue readingIn order to run the various Keystone containers as the Keystone user, we can use the modification specified here.
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.
Continue readingStep 3 of the 12 Factor app is to store config in the environment. For Keystone, the set of configuration options is controlled by the keystone.conf file. In an earlier attempt at containerizing the scripts used to configure Keystone, I had passed an environment variable in to the script that would then be written to the configuration file. I realize now that I want the whole keystone.conf external to the application. This allow me to set any of the configuration options without changing the code in the container. More importantly, it allows me to make the configuration information immutable inside the container, so that the applications cannot be hacked to change their own configuration options.
Continue reading