当您从底层到顶层检查您的技术堆栈时——硬件、操作系统 (OS)、中间件和应用程序——以及它们各自的配置，很明显，当您在堆栈中向上移动时，更改会更加频繁。您的硬件几乎不会更改，您的操作系统具有较长的生命周期，您的中间件将跟上应用程序的需求，但即使您的发布周期很长（几周或几个月），您的应用程序也将是最不稳定的。
opensource.com
在 系统和网络管理实践 中，作者将 IT 中最大的“时间黑洞”归类为操作系统和应用程序部署的手动/非标准配置。 这些时间黑洞将因重复性任务或计划外工作而吞噬您。
怎么会这样呢？假设您配置了一台没有正确配置网络时间协议 (NTP) 的新服务器，并且您的一小部分请求（在数十台服务器的集群中）开始表现异常，因为应用程序使用某种依赖于正确时间的调度器。当您这样看待它时，这是一个容易解决的问题，但是您的团队需要多长时间才能弄清楚呢？事件或计划外工作会消耗您大量的时间，更糟糕的是，还会消耗您最优秀的人才。您真的应该浪费时间像这样调查生产系统吗？将这台服务器放在一边并从头开始自动配置一台新服务器不是更好吗？
手动部署怎么样？想象一下跨服务器场或节点部署 20 个二进制文件及其各自的配置文件？这有多容易出错？不可避免地，它最终会导致计划外的工作。
2018 年 DevOps 状态报告 介绍了 DevOps 采用的阶段，毫不奇怪，第 0 阶段包括部署自动化和部署模式的重用，而第 1 阶段和第 2 阶段侧重于基础设施堆栈的标准化，以减少环境中的不一致性。
请注意，我不止一次看到运维团队使用这种“标准化”作为限制开发团队交付能力的借口，强迫他们对绝对不是钉子的东西使用锤子。不要这样做；代价极其高昂。
这里要吸取的教训是，缺乏自动化不仅会增加您的交付周期，还会增加流程中问题的发生率和您面临的计划外工作量。如果您读过 凤凰项目，您就会知道这是任何价值流中万恶之源，如果您不摆脱它，它最终会扼杀您的业务。
当试图填补最大的时间黑洞时，为什么不从自动化操作系统安装开始呢？我们可以，但结果需要更长的时间才能显现，因为创建新虚拟机的频率不如部署应用程序的频率高。换句话说，这可能无法释放我们启动计划所需的时间，因此它可能会过早夭折。
仍然不相信？从开发的角度来看，更小、更频繁的发布也非常积极。让我们进一步解释一下……
部署 ≠ 发布
首先要理解的是，尽管部署和发布可以互换使用，但它们不意味着同一件事。发布指的是向用户提供新版本，而部署是部署新版本的技术过程。让我们关注部署的技术过程。
任务、组和 Ansible
我们需要从头到尾理解部署过程，包括中间的一切——任务、过程中涉及的服务器以及执行的步骤——以避免落入 Mattias Geniar 在 自动化未知 中描述的陷阱。
任务
在常规部署过程中通常执行的步骤包括
- 部署应用程序/数据库或数据库更改
- 停止/启动服务和监控
- 从负载均衡器中添加/删除服务器
- 验证应用程序状态——它是否已准备好为请求提供服务？
- 手动批准——有必要吗？
对于某些人来说，自动化部署过程但留下手动批准步骤就像骑着带辅助轮的自行车。正如有人曾经告诉我的那样：“骑着带辅助轮的自行车总比根本不骑好。”
如果某个工具不包含 API 或命令行界面 (CLI) 以启用任务自动化怎么办？好吧，也许是时候考虑更换工具了。有许多开源应用程序服务器、数据库、监控系统和负载均衡器很容易自动化——这在很大程度上归功于 Unix 哲学。当采用新技术时，消除未自动化的选项，并发挥您的创造力来支持您的遗留技术。例如，我见过有人对网络设备配置文件进行版本控制并使用 FTP 更新它们。
您猜怎么着？现在是采用开源工具的好时机。最近的 加速：DevOps 状态 报告发现，开源技术在高绩效组织中得到广泛应用。逻辑很简单：开源项目以“达尔文主义”模式运作，那些不适应和发展的项目将因缺乏用户群或贡献而消亡。反馈对于软件发展至关重要。
组
要确定自动化目标服务器组，请考虑您想要自动化的最多任务，例如
- 部署应用程序/数据库或数据库更改
- 停止/启动服务和监控
- 从负载均衡器中添加/删除服务器
- 验证应用程序状态——它是否已准备好为请求提供服务？
剧本
高级部署流程可能是
- 停止监控（以避免误报）
- 从负载均衡器中删除服务器（以防止用户收到错误代码）
- 停止服务（以实现优雅关机）
- 部署新版本的应用程序
- 等待应用程序准备好接收新请求
- 执行步骤 3、2 和 1。
- 对下一个 N 台服务器执行相同的操作。
拥有流程文档固然很好，但拥有记录部署的可执行文件更好！以下是对于完全开源堆栈，步骤 1-5 在 Ansible 中的样子
- name: Disable alerts
nagios:
action: disable_alerts
host: "{{ inventory_hostname }}"
services: webserver
delegate_to: "{{ item }}"
loop: "{{ groups.monitoring }}"
- name: Disable servers in the LB
haproxy:
host: "{{ inventory_hostname }}"
state: disabled
backend: app
delegate_to: "{{ item }}"
loop: " {{ groups.lbserver }}"
- name: Stop the service
service: name=httpd state=stopped
- name: Deploy a new version
unarchive: src=app.tar.gz dest=/var/www/app
- name: Verify application state
uri:
url: "http://{{ inventory_hostname }}/app/healthz"
status_code: 200
retries: 5为什么选择 Ansible？
还有其他应用程序部署的替代方案，但使 Ansible 成为绝佳选择的原因包括
- 多层编排（即 delegate_to）允许您有序地定位不同的服务器组：监控、负载均衡器、应用程序服务器、数据库等。
- 滚动升级（即 serial）来控制更改的进行方式（例如，一次 1 个，一次 N 个，一次 X% 等）
- 错误控制，max_fail_percentage 和 any_errors_fatal，我的流程是全有还是会容忍失败？
- 大量的模块库，用于
- 监控（例如，Nagios、Zabbix 等）
- 负载均衡器（例如，HAProxy、F5、Netscaler、Cisco 等）
- 服务（例如，service、command、file）
- 部署（例如，copy、unarchive）
- 程序化验证（例如，command、Uniform Resource Identifier）
2 条评论