在Jenkins Pipeline中升级Docker容器的相关问题咨询

问题1：如何获取待升级的目标运行容器ID #

最稳妥的方式是给你的业务容器固定启动名称，避免通过镜像标签模糊匹配带来的误操作。你可以在首次启动容器时指定--name my-app-container参数，后续要停止旧容器时，直接通过名称过滤获取容器ID即可，优化后的阶段代码示例如下：

stage('Upgrade docker') {
    steps{
        script {
            // 获取指定名称的运行中容器ID，不存在则返回空
            def runningContainerId = sh(
                script: 'docker ps -q --filter "name=^/my-app-container$"',
                returnStdout: true
            ).trim()
            // 如果有运行中的旧容器则停止并删除
            if (runningContainerId) {
                sh "docker stop ${runningContainerId}"
                sh "docker rm ${runningContainerId}"
            }
            // 若部署节点和构建节点为同一机器可省略pull步骤，本地已存在本次构建的镜像
            sh "docker pull ${registry}:${BUILD_NUMBER}"
            // 启动新容器，指定固定名称方便后续升级识别
            sh "docker run -d --name my-app-container -p 8080:80 ${registry}:${BUILD_NUMBER}"
        }
    }
}

如果不想固定名称，也可以通过镜像前缀过滤：docker ps -q --filter "ancestor=${registry}"，但这种方式可能匹配到多个同镜像仓库的容器，误操作风险更高。

问题2：是否需要使用$BUILD_NUMBER + 1作为新版本号 #

• 该思路完全错误，不可使用
• $BUILD_NUMBER是Jenkins当前构建任务的唯一递增编号，你前面Building Docker Image阶段构建、Deploying Docker Image to Dockerhub阶段推送的镜像标签就是${registry}:$BUILD_NUMBER，直接使用当前的$BUILD_NUMBER即可。$BUILD_NUMBER+1对应下一次尚未执行的构建任务，对应的镜像根本不存在。

问题3：Jenkins中执行Docker容器升级是否是行业通用良好实践 #

分场景判断：

• 如果是测试环境、小型单节点业务场景：该做法非常普遍，实现简单、维护成本低，属于可用的常规实践，很多小团队都在使用。你找不到示例是因为很多团队会把这部分逻辑封装到内部脚本或者Ansible剧本里，不会单独公开。
• 如果是生产环境、多节点部署、有高可用要求的场景：该做法不属于最佳实践。存在的问题包括：Jenkins需要持有生产节点的Docker/SSH权限，安全风险高；无法实现滚动发布、灰度发布、自动回滚等高可用能力；排查部署故障时链路长。这类场景一般会把CI（构建、推送镜像）和CD（部署升级）拆分，Jenkins只负责CI部分，CD交给GitOps工具（Argo CD、FluxCD）或者容器编排平台（K8s、Docker Swarm）的原生发布能力实现。

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