Now that I can run the TripleO version of Keystone via podman, I want to try running it in OpenShift.Continue reading
My 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 reading
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 reading
Step 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
Computing is three things: calculation, movement, and storage. The rest is commentary.Continue reading
An earlier port hard coded the IP address and port used for MariaDB connections. I want to pull these out so I can pass them in on the command line when I create the client.Continue reading
Kolla has become the primary source of Containers for running OpenStack services. Since if has been a while since I tried deliberately running just the Keystone container, I decided to build the Kolla version from scratch and run it.Continue reading
Red Hat Satellite Server is a key tool in the provisioning process for the systems in our Labs. In one of our labs we have an older deployment running Satellite 6 which maps to the upstream project The Foreman version 1.11. Since I want to be able to perform repeatable operations on this server, I need to make Web API calls.
The easiest way to do this is to use the Hammer CLI. But it turns out the version of Hammer is somewhat tied to the version of Satellite server; the version I have in Fedora 27 Does not talk to this older Satellite instance. So, I want to run an older Hammer.
I decided to use this as an opportunity to walk through running an RPM managed application targetted for RHEL 6/EPEL 6 via Docker.
Edit: actually, this might not be the case, but the rest of the learning process was interesting enough that I kept working at it.
Edit2: This was necessary, see the bottom. Also, the 1.11 in the URL refers to the upstream repo for theforeman. I’d use a different repo for building using supported RH RPMs.
Here is what I learned.