应用布局与部署的全面指南

### 应用布局与部署的全面指南 #### 1. 应用布局原则与特性开关 应用布局的第二个原则是必须便于审查合并到代表集群真实来源的文件集中的每一项更改。当应用源代码和部署配置文件纳入版本控制后，一个常见问题是这些仓库之间的关系。对于小型项目，可使用同一仓库存放应用源代码和配置；但在大型项目中，分开存放更合理，即便构建和部署应用的是同一批人，构建者和部署者的视角差异也使得这种分离有意义。 特性开关在连接源代码控制中的新特性开发与生产环境部署方面发挥着重要作用。开发新特性时，可在特性标志或开关后进行，示例代码如下： ```javascript if (featureFlags.myFlag) { // Feature implementation goes here } ``` 这种方法有诸多好处： - 团队可在特性准备好发布前就提交到生产分支，使特性开发与仓库的 HEAD 更紧密对齐，避免长期分支的合并冲突。 - 启用特性只需更改配置激活标志，能清晰知晓生产环境的更改内容，若特性引发问题，回滚也很简单。 - 简化调试，禁用特性无需回退到旧版本代码，避免丢失新版本的 bug 修复和改进。 应用布局的第三个原则是代码默认关闭，置于特性标志后存入源代码控制，仅通过对配置文件的代码审查更改来激活。 #### 2. 源代码控制中的应用管理 确定文件系统应代表集群的真实来源后，关键问题是如何在文件系统中布局文件。 ##### 2.1 文件系统布局 为单个集群布局应用实例时，应按语义组件或层（如前端或批处理工作队列）组织。以使用两个服务的前端应用为例，文件系统可能如下： ```plaintext frontend/ service-1/ service-2/ ``` 每个目录中存储应用的配置文件（YAML 文件），通常在同一文件中包含服务名称和对象类型。Kubernetes 虽允许在同一 YAML 文件中创建多个对象，但这通常是反模式，除非对象在概念上相同。扩展后的文件系统示例如下： ```plaintext frontend/ frontend-deployment.yaml frontend-service.yaml frontend-ingress.yaml service-1/ service-1-deployment.yaml service-1-service.yaml service-1-configmap.yaml ... ``` ##### 2.2 管理定期版本 管理应用发布时，存储和维护配置的多个版本很有用。有两种方法： - **使用分支和标签**：目录结构不变，准备发布时，在配置版本控制系统中添加标签（如 `git tag v1.0`），标签代表该版本的配置，HEAD 继续迭代。更新发布配置较复杂，先将更改提交到仓库的 HEAD，然后在 v1.0 标签处创建名为 v1 的新分支，将所需更改挑选到发布分支（`git cherry-pick <edit>`），最后用 v1.1 标签标记该分支。需注意，挑选修复到发布分支时，应挑选到所有活跃版本。 - **使用目录**：每个版本化的部署存在于自己的目录中，例如： ```plaintext frontend/ v1/ frontend-deployment.yaml frontend-service.yaml current/ frontend-deployment.yaml frontend-service.yaml service-1/ v1/ service-1-deployment.yaml service-1-service.yaml v2/ service-1-deployment.yaml service-1-service.yaml current/ service-1-deployment.yaml service-1-service.yaml ... ``` 所有部署从 HEAD 进行，添加新配置到 `current` 目录。创建新发布时，复制 `current` 目录创建新的发布目录。进行 bug 修复时，拉取请求需修改所有相关发布目录中的 YAML 文件，这种方式比分支和标签的方式更清晰。 #### 3. 开发、测试和部署的应用结构 为实现敏捷开发、质量测试和安全部署，应用需满足两个目标： - 开发者能轻松开发新特性，可在自己的环境中使用所有服务。 - 应用便于在部署前进行准确测试，以快速推出特性并保持高可靠性。 发布的阶段包括： | 阶段 | 描述 | | ---- | ---- | | HEAD | 配置的最新更改 | | Development | 基本稳定，但未准备好部署，适合开发者构建特性 | | Staging | 开始测试，除非发现问题，否则不太可能更改 | | Canary | 首次向用户发布，用于测试实际流量问题 | | Release | 当前生产版本 | 引入开发标签是模拟开发阶段的正确方式，通过版本控制标签实现。定期对 HEAD 进行自动化集成测试，若测试通过，将开发标签前移到 HEAD。 为避免配置混乱，应建立版本和阶段之间的映射。在文件系统中，可使用符号链接将阶段名称映射到版本；在版本控制中，可在相应版本处添加额外标签。 #### 4. 参数化应用配置 当有多个环境和阶段时，使用参数化环境可使环境尽可能相似。以 Helm 为例，其模板语言使用 “mustache” 语法，示例如下： ```yaml metadata: name: {{ .Release.Name }}-deployment ``` 通过 `values.yaml` 文件传递参数： ```yaml Release: Name: my-release ``` 参数替换后结果为： ```yaml metadata: name: my-release-deployment ``` 在文件系统布局中，将每个部署生命周期阶段视为参数