《DevOps 入门与实践》—— DevOps引入指南研究会

[thzt]

《DevOps 入门与实践》

DevOps 是指通过 Dev（开发）和 Ops（运维）的紧密合作来提高商业价值的工作方式和文化。
通过开发和运维之间的协作，DevOps 能够减轻不同团队之间的消耗（overhead），提高开发速度，并通过互相理解来增强变更的灵活性。

基础设施即代码是指将服务器、网络设备等基础设施的设置和架构代码化，把软件开发的开发模式应用到基础设施运维中的方法。
基础设施即代码是在 DevOps 实践中支持开发和运维紧密合作的一个非常有效的方法。

基础设施即代码可以通过将基础设置的配置代码化，从而将基础设施引入软件领域，使软件开发的方法也同样适用于基础设施的构建和配置。
为了进行配置变更，我们可以像写代码一样编写配置信息，并像应用程序开发一样使用测试工具来对配置信息进行测试，并将通过测试的配置信息和代码一样进行版本管理。
像这样，在基础设施的构建和运维中就可以使用开发部门的敏捷开发等持续开发方法。

在通过开发和运维的紧密合作来提高商业价值的 DevOps 中，应用程序的开发工程师能够从软件开发的角度来理解基础设施的运维，或者直接对基础设施的配置进行变更，这种基础设施即代码的思想是非常重要的。

---

以迅速满足商业需求为目标

支持开发和运维紧密合作的工具所具备的要素

• 抽象化：对所有资源进行抽象化，消除不同平台之间的差异，降低专业难度和复杂度
• 自动化：通过自动化的方式使用抽象化的资源，降低专业难度，减小开发、运维人员的工作压力
• 统一管理：通过统一的版本管理系统和沟通工具使信息可视化，构建开发和运维之间的紧密的关系
• 持续集成：通过统一开发部门和运维部门的开发及构建方法，大幅提升系统改善的速度
• 监控：对资源信息进行集中管理和可视化，构建开发和运维的紧密合作关系

支持开发和运维紧密合作的文化所具备的要素

• 目的意识：如果开发和运维有相同的目标，即共同创造服务、迅速满足商业需求，则跟狗容易实现紧密合作
• 同理心：开发和运维团队互相考虑对方的感受，接收对方，建立紧密的关系
• 自主思考：开发部门和运维部门不互相依赖，能自主开展工作，以此不断接近公共目标

PDCA 循环：

• Plan 计划
• Do 执行
• Check 检查
• Act 处理

DevOps 需要通过 PDCA 循环来进行持续改善。
我们可以通过组合使用 网络聊天工具、问题跟踪系统、版本管理工具、持续集成工具、基础设施自动测试工具和监控工具，来实现 PDCA 循环。

DevOps 能解决组织、团队中的什么问题

• 消除对个人的依赖
• 降低团队之间的消耗
• 提高质量

康威定律：设计系统的组织，其产生的设计等同于组织的沟通结构。

---

培育 DevOps 成长的土壤：

• 从个人开始实践 DevOps
• 在团队中普及 DevOps
• 面向 DevOps 的架构变革

系统开发和运维的流程大体来说都包含以下几个阶段：

• 计划和需求分析
• 设计和实现
• 测试
• 发布
• 运维

个人也能够实现 DevOps

• 使用 VirtualBox 构建个人开发环境
• 使用 Vagrant 使基础设施代码化，简化个人开发环境的构建操作
• 使用 Ansible 使构建和配置信息代码化，从而提高开发环境的构建和配置效率
• 使用 ServerSpec 使基础设施代码化，从而提高构建和配置测试的效率
• 使用 Git 高效管理前面编写的各种代码

在团队中实施 DevOps 的意义

• 提高团队开发和沟通的效率：GitHub
• 更简单的进行本地开发环境的创建及共享：Docker
• 使工作程序化（定型化）并进行历史记录管理：Jenkins
• 通过持续工作来提高效率：持续集成（CI）和持续交付（CD）

现代 Web 应用程序具体指以下内容：

• 使用标准化流程自动配置
• 应用程序具有可移植性，可以部署到云计算平台
• 可以不依赖开发环境和生产环境进行持续部署
• 不需要大的修改就能实现纵向扩展和横向扩展

12 个方法论：（实现 Web 应用开发的最佳实践，构建出更省力、自动化程度更高的应用程序）

• 基准代码：应用程序应该基于在一个版本库中管理的一份代码，不管是测试环境还是生产环境，都可以使用这一份代码进行发布。
• 依赖：应在 manifest 文件（定义依赖关系的文件）中对应用程序和各种类库之间的依赖关系进行严格定义，确保应用程序不依赖于某一系统或类库。
• 配置：不要在代码中配置资源信息和环境信息（后端服务的链接信息、认证信息和主机名等），要把应用程序的配置存储于环境变量中。
• 后端服务：后端服务泛指可以跨网络访问的所有服务，包括数据存储、消息队列和缓存等。对于这些服务，我们不需要区分它们是本地服务还是云计算提供商提供的第三方服务，可以在不修改应用程序的情况下进行切换。
• 构建、发布、运行：代码发布之前的过程需要分为构建、发布和运行 3 个阶段。在构建阶段逐步解决依赖关系并在本地实施构建；在发布阶段将构建的结果与实际环境的配置相结合；在运行阶段在选定的资源上启动进程。
• 进程：进行需要设计为无状态，任何需要持久化数据都要存储在后端服务内。进程也必须是无共享（shared nothing）的，各个进程之间相互独立，彼此自律的运行，不能存在任何共享的数据。会话可以放到数据存储中，要尽量避免设计成依赖于粘性会话（sticky session）的形式。
• 端口绑定：应用程序需要设计为自包含（self-contained）的结构，无须使用 Apache 或 Tomcat 等容器，应用程序直接通过端口绑定来对外提供 HTTP 服务
• 并发：使用 UNIX 守护进行模型，把不同类型的工作负载（workload）分配给不同的进程，由此开发人员可以在设计时让应用程序支持多种工作负载。
• 易处理：应将启动时间缩到最短，也就是能够瞬间启动和停止服务，还要使进程在接收到 SIGTERM 信号之后实现优雅停止（grace shutdown）。
• 开发环境与线上环境等价：为了便于实现持续部署，需要尽量保证开发、预发布和生产环境一致。
• 日志：不要将日志写到文件里进行管理，而应将日志作为流（stream）输出，在设计时要保证日志流和输出目标或者存储等无关。
• 管理进程：数据库迁移、记录更新和运行调查用的命令等管理任务需要作为一次性进程运行，管理用的代码和普通的应用程序代码放在同一个版本库中管理，并同时进行部署。