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.

  • Rendering json files and triggering a cli command if the rendered file has changed is basically what you do for every file based service, apache/nginx/smtp/ntp/etc. So I don't get what you're after at all... How YOU choose to version and control your sources is YOUR choice, no one will suggest nor recommend a tool to use...
    – Tensibai
    Jan 26, 2018 at 13:33
  • @Tensibai, sure I can do it myself. But asking for the experience of others is surely appropriate on SE. With that mindset we could get rid of half of DevOps, surely. ;)
    – AnoE
    Jan 28, 2018 at 15:16
  • Opinion based question are a bad fit for StackExchange sites, a good way to do it is highly dependent on your team knowledge, free time to take a learning curve and actual tools used... That's either a too broad question or opinion based one... (so no, asking for experience on a broad subject is not appropriate, focus it by giving background on actual ecosystem used eventually)
    – Tensibai
    Jan 28, 2018 at 16:14
  • 1
    @Tensibai, at no point does the question ask about opinions, nor am I asking you to tell me what to do. It is about whether people who use OpenShift generally do use an external configuration management on top. I'm not sure why you are targetting down on it so, but am very happy to agree to disagree.
    – AnoE
    Jan 28, 2018 at 18:43
  • 1
    Why I am concerned about open ended question has probably to do with the fact site quality is part of moderator duty. I think this question is salvageable and that's why I didn't close it, but as is, it's just a poll and not a good question for this site.
    – Tensibai
    Jan 28, 2018 at 22:41

2 Answers 2


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.


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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.