oc或网络控制台并“执行”即可。它们似乎没有记录/建议保持该配置的标准方法，即，您在Web控制台或oc edit中看到的YAML或JSON表示形式，例如在git存储库中。您会吗？说大多数项目（您见证或知道的项目）都是以这种方式工作的，即仅将配置保留在OpenShift中？还是在OpenShift本身之外建立了标准？
我注意到github上有一个第三方的OpenShift ansible模块，但是我不确定这是如何证明/建立的。 />
#1 楼
AFAIK OpenShift和Kubernetes本身都不允许您外部化服务配置。您应该在某处放置一堆yml / json文件，并使用CLI工具控制它们的部署/配置。但是Rancher在2.0版中允许我们导入外部Kubernetes集群并将其作为Rancher自己的集群进行管理环境。
此处介绍了如何使用Rancher进行操作。
FYI：Rancher 2.0正在缓慢地升级到Beta版，因此您可能需要花费一些时间才能将其用于您的活动。
#2 楼
根据我的经验，Openshift在支持社区提出的优秀Kubernetes工具方面是开放的。您可以采用适合您需求的Kubernetes工具。我们使用Helm来管理在Openshift集群中运行的应用程序的配置对象（也称为yaml）。 Helm可以管理遗传kubernetes对象以及openshift特定的扩展。在正式的openshift博客中介绍了Helm。更新：我们正在使用强大的helmfile重写我们的配置管理，这使得管理多个helm版本更加容易。此答案概述了我们如何将所有Helm（或Helmfile）配置存储在git中，并将git中的内容推送到openshift，以提供“基础结构即代码”。
此外，您可能还缺少
oc的一个重要功能，即模板。但是，Helm较新，并且内置了更好的模板框架。当我们使用oc模板系统时，我不得不编写自己的包装器逻辑来处理条件逻辑，以便在应用程序模板中添加或删除可选功能。当我们升级到Helm时，所有自定义逻辑都被删除。 Helm还具有回滚到先前发行版功能的功能。 我相信openshift团队开始添加oc模板之类的东西来一次填补生态系统中的空白。现在，Helm填补了这一空白，后者发展得更快（例如，Helmfile也支持Kustomize）。 Kubernetes Operator框架是Openshift现在支持的上游Kubernetes的另一个示例。恕我直言，这对RedHat和Openshift并不感到惊讶，他们没有与其他任何开源项目竞争，他们正在为一个开源生态系统出售晚饭，而且对于他们来说，强者越多越好。
我们的大多数配置都可以使用舵图作为Yaml模板。
ImageStreamTag对象似乎很难模板化，因为它们包含许多特定信息，例如每个图像层的sha256。由于我们要运行的标签随软件的更改而一直在变化，因此使用Helmfile管理的yaml定义环境的“形状”是很自然的，但要运行oc将特定的图像流标签拉入项目（又名命名空间） 。
评论
如果渲染的文件已更改，则渲染json文件并触发cli命令基本上就是您对每个基于文件的服务apache / nginx / smtp / ntp / etc所做的工作。所以我根本不了解您的用意...选择版本和控制源代码是您的选择，没有人会建议也不推荐要使用的工具...@Tensibai，请确保我自己可以做。但是，在SE上寻求他人的经验肯定是合适的。有了这种心态，我们肯定可以摆脱一半的DevOps。 ;）
基于意见的问题非常不适合StackExchange网站，一种很好的方式高度依赖于您的团队知识，空闲时间来学习曲线和使用的实际工具...这可能是一个过于广泛的问题，也可能是基于意见的问题。 ..（因此，不宜在广泛的主题上寻求经验，而应通过提供最终使用的实际生态系统的背景来集中精力）
@Tensibai，问题绝对不会询问意见，我也不是要您告诉我该怎么做。有关使用OpenShift的人员是否通常会在顶部使用外部配置管理。我不确定您为什么要以此为目标，但很高兴同意不同意。
为什么我担心开放式问题可能与网站质量是主持人职责的一部分有关。我认为这个问题是可以解决的，这就是为什么我没有关闭它，但是就目前而言，这只是一个民意调查，而不是该网站的好问题。