OpenShift configuration management

Question

As far as I can tell, reading the OpenShift documentation, including https://github.com/openshift/training/, the officially published "standard" way to manage OpenShift configuration (about their objects like services, build config etc.) is to simply use oc or the web console and "do it". They do not seem to document/suggest a standard way to keep this configuration, i.e. the YAML or JSON representation that you see in the web console or in oc edit in, say, a git repository.

Would you say that most projects (that you witnessed or know about) work this way, i.e., just keeping the config inside OpenShift? Or are there established standards, to have this outside of OpenShift itself?

I noticed that there is a 3rd party OpenShift ansible module on github, but am not quite sure how proven/established that is.

Answer 1

AFAIK neither OpenShift nor Kubernetes itself allow you to externalize services configuration. You should have a bunch of yml/json files somewhere and control their deployment/configuration using CLI tools.

But there is Rancher which in version 2.0 allow us to import external Kubernetes clusters and manage them as Rancher's own environments.

Description of how this could be done with Rancher you can find here.

FYI: Rancher 2.0 is slowly moving to Beta so it might take time for you to use it in your activities.

Answer 2

In my experience Openshift is open in terms of supporting good Kubernetes tools that the community comes up with. You can adopt the Kubernetes tooling that fits your needs. We use Helm to manage the configuration objects (aka yaml) of our applications running in our Openshift cluster. Helm can manages both genetic kubernetes objects as well as openshift specific extensions. Helm is introduced in the official openshift blogs. Update: we are rewriting our configuration management using the mighty helmfile which makes it easier to manage multiple helm releases.

This answer gives an overview of how we store all the Helm (or Helmfile) configuration in git and push what is in git out to openshift to give us “infrastructure as code”.

Also you might be missing an important feature of oc which is templates. Yet Helm is newer and has a better template framework built into it. When we used the oc template system but I had to write my own wrapper logic to deal with conditional logic to add or remove optional features from our application templates. All that custom logic got removed when we upgraded to Helm. Helm also has a rollback to previous release feature.

I believe that the openshift team started adding things like oc templates to fill a gap in the ecosystem at one time. That gap is now filled by Helm which is evolving faster (e.g., Helmfile that also suppers Kustomize). The Kubernetes Operator framework is another example of something from upstream Kubernetes that Openshift now supports. IMHO this isn’t a surprise to RedHat and Openshift they are not competing with any other opensource project they are selling supper for an opensource ecosystem and the strong it is the better it is for them.

The majority of our config can be yaml templated with helm charts. The only thing that seems hard to template are ImageStreamTag objects as they contain a lot of specific information such as the sha256 of each image layer. Since the tags we want to run change all the time it as our software changes it feels natural to define the "shapes" of our environments using yaml managed by Helmfile yet run oc to pull a particular image stream tag into a project (aka namespace).