DevOps世界中的“环境管理”如何工作

64次阅读

问题描述

在遵循DevOps实践的团队中，关于环境管理的角色和责任有一些有趣的讨论。传统上，一个“环境经理”的角色是：

协调软件开发生命周期（SDLC）的各个阶段，以确保在适时提供已知版本的软件，并保持可用性。

在跨职能的敏捷团队中，遵循DevOps实践，我认为这些职责应该由整个团队承担，最终向产品负责人作为业务代表负责。

简而言之，我的问题是：在不拥有外部“环境管理”职能的团队中，谁负责环境管理？

解决方案

在DevOps模型中，环境管理的角色不再是一个独立的“环境经理”，而是通过Dev和Ops两方面的元素支持的过程。高度“DevOps成熟度”的组织不再拥有一个独立的“发布管理事件” – 发布的行为已经融入了持续交付流程中（参考“推送绿灯” 什么是“推送绿灯”？）。

方案1

Configuration Management（配置管理）是另一个可能被混淆的概念。在这种管理中，特定于环境的配置可以手动管理，或者使用工具如Puppet或Chef来管理。这项工作通常是由运维团队负责的，高成熟度的组织则通过代码来处理配置管理。责任可以在Dev和Ops之间共享，也可以有一个专门的SRE团队来处理配置管理。

方案2

另一种方法是编写脚本或使用工具来控制容器的运行顺序。你可以使用docker run命令来手动控制容器的启动顺序，或者使用一些第三方工具来管理容器的依赖关系。以下是一个简单的bash脚本示例，可以在容器A启动后启动容器B：

#!/bin/bash
# 启动容器A
docker run -d --name container_a your_image_a
# 等待容器A完全启动
while ! docker exec container_a echo "Container A is ready"; do
  sleep 1
done
# 启动容器B
docker run -d --name container_b your_image_b

在这个示例中，我们首先使用docker run命令启动容器A，并将其命名为container_a。然后，使用一个循环来等待容器A完全启动（这里是通过在容器内运行echo命令来测试）。一旦容器A就绪，我们再使用docker run命令启动容器B，并将其命名为container_b。