OpenShift 4.8如何避免oc apply触发重复rollout部署问题

方案1：临时暂停DC自动触发，直接适配现有脚本逻辑 #

不想调整现有部署流程的话，直接在执行oc apply前暂停DeploymentConfig（简称DC）的自动触发能力，就能拦住ConfigChange触发器在apply阶段自动拉起rollout，全程只会触发一次更新：

# 暂停DC，暂停期间ConfigChange、ImageChange等所有自动触发器全部失效
oc rollout pause dc/my-application
# 应用最新部署配置，这一步不会触发自动rollout
oc apply -f deployment-config.yaml
# 手动触发一次rollout，会按照imagePullPolicy: Always规则拉取最新snapshot镜像
oc rollout latest dc/my-application
# 等rollout正常启动后恢复DC的自动触发能力，不影响后续配置变更的正常触发
oc rollout resume dc/my-application

如果不想用pause命令，也可以临时移除ConfigChange触发器，apply完成后再加回，效果完全一致：

# 执行前先通过oc get dc/my-application -o jsonpath='{.spec.triggers}' 确认ConfigChange触发器的索引位置，替换下方路径里的数字
oc patch dc/my-application --type=json -p '[{"op":"remove", "path":"/spec/triggers/0"}]'
oc apply -f deployment-config.yaml
oc rollout latest dc/my-application
# 重新加回ConfigChange触发器
oc patch dc/my-application --type=json -p '[{"op":"add", "path":"/spec/triggers/-", "value":{"type":"ConfigChange"}}]'

方案2：用原生ImageChange触发器替代手动强制rollout（更推荐） #

你额外加oc rollout latest的核心需求是snapshot标签镜像更新后，即便部署配置没改也能拉到最新版本部署，这个场景OpenShift原生的ImageChange触发器就能直接满足，不需要加手动强制命令，从根源避免重复rollout问题：

1. 调整DC的触发器配置，保留原有ConfigChange触发器，新增ImageChange触发器关联对应镜像流：

spec:
  triggers:
  - type: ConfigChange
  - type: ImageChange
    imageChangeParams:
      automatic: true
      containerNames:
      - my-application # 替换为DC里实际的业务容器名
      from:
        kind: ImageStreamTag
        name: my-application:snapshot
        namespace: <你的镜像流所在项目命名空间>

2. 如果snapshot镜像存放在外部第三方仓库，只需要在每次镜像构建推送完成后，执行一次镜像导入命令同步元数据即可：

oc import-image my-application:snapshot --confirm

这套配置下的触发逻辑完全匹配需求：

• 修改部署配置（环境变量、资源限制、端口等）执行oc apply时，ConfigChange触发器自动触发一次rollout，默认拉取当时最新的snapshot镜像
• 部署配置无修改，仅snapshot镜像重新构建推送时，ImageChange触发器会检测到镜像digest变化，自动触发rollout拉取最新镜像
• 全程不需要执行oc rollout latest，不存在重复触发的可能，稳定性比手写脚本高很多

注：ImageChange触发器触发部署时，会自动把容器镜像地址替换为对应镜像的sha256摘要值，比单纯用浮动snapshot标签+imagePullPolicy: Always的可靠性更高，不会因为节点镜像缓存、仓库标签覆盖导致拉取的镜像版本不符合预期。

内容的提问来源于stack exchange，提问作者user1766169