使用Werf和现有的Dockerfiles改善你的CI/CD体验

迟到总比不到好。该故事讲关于我们因不支持使用常规的Dockerfile来构建镜像导致我们差点犯了一个重大错误。

Werf[1]是一个GitOps工具，可以很好地集成到任何CI/CD系统中，并提供完整的应用程序生命周期管理，允许你：

• 构建和推送镜像

• 部署应用程序到Kubernetes中

• 根据策略清理未使用镜像

我们工具的理念是：将低级手段组合到一个统一的系统中让DevOps工程师控制应用程序。尽可能使用现有的即用型工具（如Helm和Docker）。但是如果没有合适的任务解决方案呢？答案很简单，我们自己编写并维护工具来完成工作。

背景：自定义镜像构建器

Werf镜像构建器也发生了同样的故事。Dockerfile是描述构建镜像过程的事实标准，但我们的需求受到很大限制。这个问题在我们项目的早期阶段变得至关重要。在开发用于容器化应用的工具时，我们很快意识到Dockerfile不适合以下特定任务：

1. 遵循构建典型小型Web应用程序的标准工作流程：a）安装系统范围的应用程序依赖项，b）安装特定于应用程序的库，c）构建资产（assets），d）最重要的部分，快速高效地更新镜像中的代码。

2. 构建器在发生更改时应通过提交修补应用于修改的文件来创建新的镜像层。

3. 如果某些文件已被修改，则必须重建依赖阶段。

这是我们一开始的需求列表，在今天我们的构建器有着许多额外的功能。

总而言之，我们没花多长时间就开始使用首选编程语言开发自定义DSL（见下文）。它必须满足既定目标，根据文件描述分阶段的构建过程并确定不同阶段间的依赖。它由相应的那些可将DSL转变成最终目标的构建器，即即用型Docker镜像补充。一开始我们使用Ruby实现了DSL，在切换到Golang之后我们用YAML文件形式重写了它。

Werf的Ruby的配置，这是旧的版本（此时项目被称为dapp）

Werf的YAML形式配置ÿ