Answers: <p>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.</p>
  
  <p>But there is Rancher which in version 2.0 allow us to import external Kubernetes clusters and manage them as Rancher's own environments. </p>
  
  <p>Description of how this could be done with Rancher you can find <a href="https://devops.stackexchange.com/a/3057/2285">here</a>.</p>
  
  <p><strong>FYI:</strong> Rancher 2.0 is slowly moving to Beta so it might take time for you to use it in your activities.</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-01-26T13:16:11.460Z
Answers: 2018-01-26T13:16:11.460Z
Answers: Maksim
Answers: <p>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 <a href="https://blog.openshift.com/getting-started-helm-openshift/" rel="nofollow noreferrer">in the official openshift blogs</a>. <strong>Update</strong>: we are rewriting our configuration management using the mighty <a href="https://github.com/roboll/helmfile" rel="nofollow noreferrer">helmfile</a> which makes it easier to manage multiple helm releases. </p>
  
  <p><a href="https://devops.stackexchange.com/questions/4662/what-is-the-recommended-way-to-monitor-differences-between-multiple-kubernetes-n/5295#5295">This answer</a> 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”. </p>
  
  <p>Also you might be missing an important feature of <code>oc</code> which is <a href="https://docs.openshift.com/online/dev_guide/templates.html" rel="nofollow noreferrer">templates</a>. Yet Helm is newer and has a better template framework built into it. When we used the <code>oc</code> 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. </p>
  
  <p>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 <a href="https://blog.openshift.com/introducing-the-operator-framework/" rel="nofollow noreferrer">Openshift now supports</a>. 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. </p>
  
  <p>The majority of our config can be yaml templated with helm charts. The only thing that seems hard to template are <code>ImageStreamTag</code> 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 <code>oc</code> to pull a particular image stream tag into a project (aka namespace).</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-10-31T18:52:55.063Z
Answers: 2018-12-30T09:06:39.037Z
Answers: 2018-12-30T09:06:39.037Z
Answers: simbo1905
Body: <p>As far as I can tell, reading the OpenShift documentation, including <a href="https://github.com/openshift/training/" rel="noreferrer">https://github.com/openshift/training/</a>, the officially published "standard" way to manage OpenShift configuration (about their objects like services, build config etc.) is to simply use <code>oc</code> 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 <code>oc edit</code> in, say, a git repository.</p>
  
  <p>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?</p>
  
  <p>I noticed that there is a 3rd party OpenShift ansible module on github, but am not quite sure how proven/established that is.</p>
  
Comments: CC BY-SA 3.0
Comments: 2018-01-26T13:33:52.577Z
Comments: 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...
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2018-01-28T15:16:50.527Z
Comments: @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. ;)
Comments: AnoE
Comments: CC BY-SA 3.0
Comments: 2018-01-28T16:14:08.953Z
Comments: 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)
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2018-01-28T18:43:34.723Z
Comments: @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.
Comments: AnoE
Comments: CC BY-SA 3.0
Comments: 2018-01-28T22:41:33.010Z
Comments: 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.
Comments: Tensibai
Tags: <configuration-management><openshift>
Title: OpenShift configuration management
UserDisplayName: AnoE
ThreadText: # OpenShift configuration management
  
  (Asked by: username_0 on 2018-01-26)
  
  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.
  
  **Tags:** configuration-management, openshift
  
  > **Comments:**
  > **username_1**: 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...  
  > **username_0**: @username_1, 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. ;)  
  > **username_1**: 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)  
  > **username_0**: @username_1, 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.  
  > **username_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.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2018-01-26. Score: 3
  
  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](https://devops.stackexchange.com/a/3057/2285).
  
  **FYI:** Rancher 2.0 is slowly moving to Beta so it might take time for you to use it in your activities.
  
  
  ---
  
  ### Answer by username_3 on 2018-10-31. Score: 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](https://blog.openshift.com/getting-started-helm-openshift/). **Update**: we are rewriting our configuration management using the mighty [helmfile](https://github.com/roboll/helmfile) which makes it easier to manage multiple helm releases.
  
  [This answer](https://devops.stackexchange.com/questions/4662/what-is-the-recommended-way-to-monitor-differences-between-multiple-kubernetes-n/5295#5295) 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](https://docs.openshift.com/online/dev_guide/templates.html). 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](https://blog.openshift.com/introducing-the-operator-framework/). 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).
  
  
  ---
  
  