CI/CD

为什么要优化 Docker 镜像 Docker 镜像并不是一个简单的压缩包，而是由多个只读 Layer 组成的文件系统。 例如： Dockerfile │ ├── FROM ├── RUN ├── COPY └── RUN │ ▼ Image Layers │ ▼ Container 镜像体积会直接影响： 构建时间。 镜像 Push 时间。 镜像 Pull 时间。 CI/CD 执行时间。 磁盘占用。 容器启动速度。 镜像攻击面。 因此，镜像优化并不只是为了“让镜像变小”。 更准确地说： 镜像优化 │ ├── 减少无用文件 ├── 减少无用依赖 ├── 提高构建缓存命中率 ├── 缩短构建时间 ├── 减少网络传输 └── 降低攻击面 Docker 官方也将“小而聚焦”的镜像作为生产镜像构建的重要目标，并强调镜像大小和安全性之间存在直接关系。 因此，一份生产级 Dockerfile 通常应该同时考虑： 体积 性能 缓存 安全 可维护性 而不是只关注其中一个指标。 选择合适的基础镜像 基础镜像是整个 Docker 镜像的起点。 例如：...

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 其中每个命令负责不同的事情：...

GitHub Actions 是什么 GitHub Actions 是 GitHub 提供的 CI/CD 自动化平台，可以根据代码仓库中的事件自动执行构建、测试、发布和部署任务。 例如，一个 PHP 项目可以设计成： 开发者 │ │ git push ▼ GitHub Repository │ │ push event ▼ GitHub Actions │ ├── Checkout ├── Install Dependencies ├── Run Tests ├── Docker Build ├── Docker Push └── Deploy │ ▼ Production GitHub 官方将 Actions 的核心组成划分为 Workflow、Job、Step、Runner 和 Action。一个 Workflow 可以包含一个或多个 Job，每个 Job 又由多个 Step 组成。Job 默认可以并行执行，也可以通过依赖关系串联起来。(GitHub Actions 官方文档) GitHub Actions 官方文档 GitHub Actions 最大的价值并不是「帮你执行几个 Shell 命令」，而是把代码仓库、自动化测试、镜像构建、镜像仓库和部署环境连接起来。...