英文:
Can `oc create` behave in a "transactional"/"atomic" manner when asked to create _multiple_ objects on the cluster?
问题
我已经编写了一些相关的 OKD 对象定义，每个对象定义都在自己的 YAML 文件中。这些对象定义基本上组成了一个应用程序部署。当集群上没有任何对象已经存在时，我正在执行类似以下的操作来在 OKD 集群上安装我的应用程序，这在我看来是满意的：
oc create -f deploymentconfig.yaml,service.yaml,route.yaml,configmap.yaml,secret.yaml
然而，如果 oc create 被要求创建的某些对象已经存在于集群中，那么 oc create 将拒绝重新创建它们（这是自然的），但它将已经创建了所有其他之前不存在的对象。
这不是理想的情况，当我在集群上创建的对象是为了“协同工作”，并且是一个相互依赖的应用程序的一部分时。例如，配置映射几乎是一个硬性要求，因为如果没有它，容器将无法通过挂载卷获取配置数据而无法正常启动。
我想知道，是否可以让 oc create 表现得像要么安装命令行上指定的所有对象，要么如果其中一些已经存在或存在错误，则不安装任何对象？
我知道 OKD 有模板功能和其他功能，这些功能可能会在应用程序部署中提供很大帮助，因此，如果 oc create 按设计不执行“事务”，我将采取替代方案。目前我只是试图根据我当前的了解尝试看起来简单的方法，因为我不是 OKD 专家。
英文:
I have written a number of related OKD object definitions, each in its own YAML file. These together essentially make up an application deployment. I am doing something like the following to install my application on an OKD cluster, which works to my satisfaction when none of the objects already exist [on the cluster]:
oc create -f deploymentconfig.yaml,service.yaml,route.yaml,configmap.yaml,secret.yaml
However, if some of the objects oc create is asked to create, already exist on the cluster, then oc create refuses to re-create them (naturally) but it will have created all the other ones that did not exist.
This isn't ideal when the objects I am creating on the cluster were made to behave "in tandem", and are parts of an application where they depend on one another -- the configuration map, for instance, is pretty much a hard requirement as without it the container will fail to start properly (lacking configuration data through a mounted volume).
I'd like to know, can oc create be made to behave like either all of the objects specified on the command line, are installed, or none if some of them already exist or if there were errors?
I am aware OKD has template faculties and other features that may greatly help with application deployment, so if I am putting too much (misplaced) faith on oc create here, I'll take an alternative solution if oc create by design does not do "transactions". This is just me trying what seems simple from where I currently stand -- not being much of an OKD expert.
答案1
得分: 1
很遗憾，这种情况是不存在的。
在 Kubernetes（以及因此在 Openshift 中），清单文件在大多数情况下是声明性的，并且具有幂等性。每个 kind 可以以原子方式进行修改，但不能同时修改一组资源。
您可以使用 oc apply 或 oc replace 以原子方式创建或修改某些资源，但不能对许多资源执行相同操作，因为 Kubernetes 不会将它们视为一个整体。
即使您有一个 Template 或 List，某些资源可能会出现问题，您最终可能只能得到部分结果。
对于这种情况，helm 更为灵活，并且可以使用 --atomic 标志按您所需工作。
如果您的所有清单文件都是分开的，您可以通过以下方式实现类似的效果：
oc apply -f dirwithmanifests/
英文:
Unfortunately, there is no such thing.
In Kubernetes (and so in Openshift), manifests are declarative and idempotent in the most of scenarios. Each kind can be modified in atomic way, but not a group of resources all together.
You can oc apply or oc replace to create or modify some resource in a atomic way, but the same cannot be done with a lot of resources because Kubernetes don't see them as a unity.
Even if you have a Template or a List, some resources may have problems and you will end with a part of the whole.
For this kind of thing helm is much more versatile and works as you want with --atomic flag.
If you have all your manifests separated, you can achieve a similar effect with:
oc apply -f dirwithmanifests/
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论