第15天：从“在我的机器上能运行”到自动化：学习 Jenkins 和 Docker

Source: Dev.to

Introduction

今天是我 DevOps 学习之旅的关键一天。我摆脱了手动流程，开始探索自动化的世界。重点是理解 CI/CD 背后的原因，了解 Jenkins 如何编排任务，并重新审视 Docker 的核心概念，以弄清它与虚拟机的根本区别。

以下是我今天学到的内容概览。

Why CI/CD? (Continuous Integration / Continuous Deployment)

在深入工具之前，我先了解了 CI/CD 为什么是现代软件开发的支柱。

• 问题所在： 过去，开发者会孤立地写代码数周。当他们终于尝试合并更改时，就会出现“集成地狱”——冲突遍布，构建失败。
• 解决方案（CI）： 持续集成意味着开发者频繁地将代码更改合并到中央仓库。自动化的构建和测试会立即运行，以便及早捕获错误。
• 交付（CD）： 持续部署/交付确保代码更改会自动准备好发布到生产环境。

关键收获： CI/CD 不仅仅是为了加快速度，更是为了可靠性。它消除了“在我的机器上可以运行”的借口。

How Jenkins Works

Jenkins 是一个开源的自动化服务器——常被称为 DevOps 的“管家”。它帮助自动化软件开发中与构建、测试和部署相关的部分。

Architecture

• Jenkins Master： 大脑。保存配置、调度任务、监控整个过程，并为用户提供 GUI。
• Jenkins Agents (Nodes)： 工作节点。Master 向 Agents 发送指令，Agents 执行实际的构建步骤（例如编译 Java 代码或运行 Python 脚本）。

Jenkins 使用 pipelines（在 Jenkinsfile 中定义）来脚本化部署过程的各个步骤。

Docker Revisited: Images vs. Containers

这两者很容易混淆，下面的类比帮助我理清了概念：

• Docker Image： 可以把它看作配方（或编程中的类）。它是只读的模板，包含运行应用所需的代码、库和依赖。
• Docker Container： 可以把它看作蛋糕（或编程中的对象）。它是镜像的可运行实例。你可以用同一个配方（镜像）烤出许多蛋糕（容器）。

Docker Containers vs. Virtual Machines (VMs)

Virtual Machines

• 笨重。
• 每个 VM 都需要完整的客操作系统（OS）。
• 启动需要几分钟。

Docker Containers

• 轻量。
• 共享宿主机的 OS 内核；不需要为每个应用提供完整的 OS。
• 启动仅需毫秒级。

结论： 容器更高效，因为它们在不模拟整套硬件和操作系统的情况下隔离应用进程。

Conclusion

今天为我的自动化学习奠定了坚实的理论基础。了解 Jenkins 的架构以及 Docker 容器的高效性，使我明白这些工具为何成为行业标准。我期待着动手实践，尽快构建我的第一个 Jenkins pipeline！