当您从底层到顶层检查您的技术栈——硬件、操作系统 (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）来控制如何进行更改（例如，一次一个、一次 N 个、一次 X% 等）
- 错误控制，max_fail_percentage 和 any_errors_fatal，我的流程是全有还是全无，还是可以容忍失败？
- 一个庞大的模块库，用于
- 监控（例如，Nagios、Zabbix 等）
- 负载均衡器（例如，HAProxy、F5、Netscaler、Cisco 等）
- 服务（例如，service、command、file）
- 部署（例如，copy、unarchive）
- 程序化验证（例如，command、Uniform Resource Identifier）
2 条评论