Docker Build

Docker CI/CD 要解决什么问题 前面的 Docker 系列已经介绍了 Dockerfile、Docker Compose、镜像构建、镜像 Push 以及 Harbor 私有镜像仓库。 如果每次发布都手动执行： git pull docker build -t registry.example.com/backend/api:v1.0.0 . docker push registry.example.com/backend/api:v1.0.0 ssh server docker pull registry.example.com/backend/api:v1.0.0 docker compose up -d 项目规模较小时问题不大，但随着服务数量增加，手工发布会逐渐暴露出几个问题： 容易漏执行步骤。 镜像 Tag 容易写错。 测试和生产环境操作不一致。 发布过程缺少统一记录。 无法方便地回滚。 开发人员需要直接登录生产服务器。 发布效率随着项目数量增加而下降。 CI/CD 的核心目标，就是把这些重复操作交给自动化系统完成。 一个典型的 Docker CI/CD 流程如下： Git Push │ ▼ CI Pipeline │ ├── Checkout ├── Test ├── Build Image ├── Tag Image └── Push Image │ ▼ Harbor │ ▼ Deploy │ ▼ Production 最终开发人员只需要：...

在前面的文章中，我们已经介绍了 Dockerfile 和 Docker Compose。 Dockerfile 解决的是「如何定义一个镜像」，Compose 解决的是「如何运行和管理多个容器」。 但一个完整的 Docker 应用交付流程还缺少一个重要环节： Dockerfile ↓ docker build ↓ Docker Image ↓ docker tag ↓ docker push ↓ Container Registry ↓ docker pull ↓ 服务器 ↓ docker run / docker compose 这就是 Docker 镜像从「构建」到「发布」再到「部署」的完整链路。 本文重点介绍 docker build、docker tag、docker login、docker push、docker pull 以及 docker buildx build，并结合一个 PHP 应用说明实际项目中的镜像发布流程。 1. Docker 镜像发布的完整流程 一个 Docker 镜像从代码进入服务器，通常经历以下几个阶段： 开发环境 │ ▼ Dockerfile │ │ docker build ▼ Docker Image │ │ docker tag ▼ Registry Image │ │ docker push ▼ Container Registry │ │ docker pull ▼ 部署服务器 │ │ docker run │ 或 docker compose ▼ Container 其中每个命令负责不同的事情：...