运维

提示：本文要求读者有一定的 Ansible 使用经验 最近一年才有机会在生产环境上使用 Ansible。用的过程中，想把一些小技巧记录下来，避免自己忘记。如果能帮助到其他同学就更好了。如果有同学指出有更好的方法，就更更好了。 技巧1：校验你的模板文件是否正确 通常我们会使用template module 来生成应用的配置，比如生成 Nginx 的配置或者 sudoers 配置。而像 sudoers 文件内的配置错误可能直接导致无法登录。所以，我们希望在生成这些配置文件后能校验一下它的正确性。如果校验失败，直接停止，不生成该配置文件。 而 template module 有一个属性 validate 就是为了实现这一需求的： - template: src: "user-sudoers" dest: "/etc/sudoers.d/abc" validate: visudo -cf %s 校验 Nginx 配置文件的文件： - name: Copy the nginx file template: src: nginx.conf.j2 dest: /etc/nginx/nginx.conf validate: "/usr/sbin/nginx -t -c %s" notify: - restart nginx 校验 Prometheus 配置文件： - name: Copy Prometheus config template: src: prometheus.yml.j2 dest: "/etc/prometheus.yml" validate: "promtool check config %s" notify: reload prometheus config 校验 Logstash 配置文件： ...

注：本文要求读者对Ansible和 Jenkins有一定的认识。 题记: 幸福的家庭都是相似的 不幸的家庭各有各的不幸 行业内各巨头的自动化运维架构都各种功能各种酷炫，如下图，让人可望不可及。现在最终的样子大家都知道了，但问题是如何根据自己团队当前的情况一步步向那个目标演进？ 笔者所在团队，三个半开发，要维护几十台云机器，部署了十来个应用，这些应用90%都是遗留系统。应用系统的编译打包基本在程序员自己的电脑上。分支管理也清一色的 dev 分支开发，测试通过后，再合并到 master 分支。生产环境的应用配置要登录上具体的机器看才知道，更不用说配置中心及配置版本化了。 对了，连基本的机器级别的基础监控都没有。 我平时的工作是 50% 业务开发，50% 运维。面对这么多问题，我就想啊，如何在低成本情况下实现自动化运维。本文就是总结我在这方面一些经验和实践。希望对读者有帮助。 别说话，先上监控和告警 事情有轻重缓急，监控和告警是我觉得一开始就要做的，即使业务开发被拖慢。只有知道了当前的情况，你才好做下一步计划。 现在市面上监控系统很多：Zabbix、Open-Falcon、Prometheus。最终作者选择了 Prometheus。因为： 它是拉模式的 它方便使用文本方式来配置，有利于配置版本化 插件太多了，想要监控什么，基本都会有现成的 以上三者，我基本都要重新学，我为什么不学一个 Google SRE 书上推荐的呢？ 之前我们已经介绍过，人少机器多，所以，安装 Prometheus 的过程也必须要自动化，同时版本化。笔者使用的是 Ansible + Git 实现。最终样子如下： 这里需要简单介绍一下： Prometheus Server 负责监控数据收集和存储 Prometheus Alert manager 负责根据告警规则进行告警，可集成很多告警通道 node-exporter 的作用就是从机器读取指标，然后暴露一个 http 服务，Prometheus 就是从这个服务中收集监控指标。当然 Prometheus 官方还有各种各样的 exporter。 使用 Ansible 作为部署工具的一个好处是太多现成的 role 了，安装Prometheus 时，我使用的是现成的：prometheus-ansble 有了监控数据后，我们就可以对数据进行可视化，Grafana 和 Prometheus 集成得非常好，所以，我们又部署了 Grafana: 在 Grafana 上查看 nodex-exporter 收集的数据的效果图大概如下： 可是，我们不可能24小时盯着屏幕看CPU负载有没有超吧？这时候就要上告警了，Promehtues 默认集成了 N 多告警渠道。可惜没有集成钉钉。但也没有关系，有好心的同学开源了钉钉集成 Prometheus 告警的组件：prometheus-webhook-dingtalk。接着，我们告警也上了： ...

想法 历史原因，我们一直使用的是阿里云经典网络的 ECS，疲于业务的开发及人力不足，一直没有特别大的动力迁移到 VPC 下。 而经典网络下的 ECS 的公网 IP 是收费的，而且没有公网 IP 有时会不方便。 购买公网 IP 时的费用 未购买公网 IP 时的费用 如果是按月购买，每个月将节约：296 - 273 = 23 元。 而我们的大多服务是内网使用的，所以，公网 IP 的申请完全是浪费。 可是，我们有时，还是需要公网下载一些东西的。这时怎么办呢？ 我的方案是：没有公网 IP 的机器，使用 HTTP 代理就可以上网了。 当然，哪些机器需要上网，基于安全上的考虑，需要读者自己决定了。 怎么做？ 我的具体实现方便使用 Squid 搭建 http proxy 服务。其他机器通过配置环境变量配置，笔者是通过 Ansible 初始化机器时配置的： - name: use httpproxy lineinfile: path: "/etc/profile" line: "<<item>>" with_items: - "export http_proxy=http://<< httpproxy.host >>:<< httpproxy.port >>/" - "export https_proxy=http://<< httpproxy.host >>:<< httpproxy.port >>/" when: is_use_httpproxy is defined and is_use_httpproxy == 'True' tag: httpproxy 关于 Squid Http Proxy 服务，笔者同样是使用 Ansible 搭建，具体不细表，看官可以自行看代码：Squid-ansible。 ...

从聊天说起 有一次和朋友聊天，他说他们有一次部署出事了，影响还挺大，那次事故后，他们公司对于部署流程增加了更多的审批。 当朋友说完前半句时，我已经猜到下半句，那是很多公司或个人会做出的反应。至于为什么会做出这样的反应，我也不知道。 我问：为什么那次部署会“出事”？ 他说：当时部署的人忘记了那台机器上有一条 Iptable 规则，导致了事故。 我就在想，如果有人审批，那次事故就不会发生吗？审批的人就知道那台机器上有一条规则导致事故的发生？然后驳回这次部署吗？连一线的开发和运维都忘记了的 Iptable 规则，“高高在上的审批领导”就更不知道了。 题外话：增加审批流程并不能避免这次事故，只不过当出现事故时，可以更好的定责。然而我又好奇了，这种“审批”是为了解决问题，解决什么问题？，还是为了逃避责任？谁逃避了责任？谁又有责任？ 对于这类问题，我心里已经有数了，但想知道这位朋友的回答，就接着问：那么怎么杜绝这类问题呢？ 他说：因为那条 Iptable 规则的设置太久远了，是谁都记不起。如果能把每次部署的步骤记录下来，这样下次部署的时候，过一下以前的部署记录，就会知道那个 Iptable 规则了。（作者：大概原意，已经记不清原话） 这位朋友说的做法，我之前待的一个团队的做法也差不多：会有一个页面专门记录下每次部署的步骤，步骤由开发人员写，然后由运维人员执行。只是我不知道他们会不会回顾之前所有针对这台机器的部署步骤。 这个团队里有某某大型互联网公司来的架构师和某财务软件公司来的运维，所以，我不负责地推测，我们这个行业很多公司对于配置的管理还没有达到足够的重视，也没有正确的看待。 我笑了，接着问朋友：那我要知道当前机器的“最终状态”，是不是要找出所有部署记录，还要过滤出对这次部署有影响的每一个细节？比如那条 Iptable 规则。 接下来的对话细节已经记不清，也不重要了。重要的是找出针对这类运维事故根本原因及解决办法。 我个人认为这类问题的根本原因在于： 配置管理的失控： 已经没有人完整知道线上环境配置是什么了？要了解时，只能一个个查。 测试环境与生产环境的配置不一致： 如果那位倒霉的同学在测试环境部署出现这样的问题，到生产环境部署时，自然就会注意相关配置项了。 以上只是我个人认为的，不一定正确，欢迎各位读者讨论。 那如何杜绝这类问题呢？ 这两个原因可以看作一个，也可以看作两个。但方法都是一样的： 使用声明式的配置管理方法，而不是脚本式 版本化这些声明的配置 所有环境使用同一套装配置管理方法 使用声明式的配置管理方法，而不是脚本式的 脚本式的配置管理是这样的： apt-get install build-essential apt-get install libtool cd /usr/local/src wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.37.tar.gz tar -zxvf pcre-8.37.tar.gz cd pcre-8.34 ./configure make make install 而声明式的配置管理是这样的： # ./ansible-nginx/tasks/install_nginx.yml # 使用这个7-0.el7版本的yum包 - name: NGINX | Installing NGINX repo rpm yum: name: http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm # 当前机器的nginx的状态应该是最新版本 - name: NGINX | Installing NGINX yum: name: nginx state: latest # 当前机器的 nginx service 的状态应该是已经启动的。至于如何确保 nginx 这个 service，当前是什么状态的，又是如何启动的，我们不需要关心。 - name: NGINX | Starting NGINX service: name: nginx state: started 声明式的配置里写的是当前环境的“状态”，语意上，声明式的配置不论你执行多少次，你得到最终的“状态”就是你所声明的，这也就实现了《持续交付》里说的： ...