运维 on 翟志军 Jack Zhai

使用Ansible实现自动化运维的一些技巧

Fri, 22 Jun 2018 00:00:00 +0000

提示：本文要求读者有一定的 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 配置文件：

一些小团队的自动化运维实践经验

Thu, 07 Jun 2018 00:00:00 +0000

带团队的日志

阿里云经典网络下如何节约公网 IP 费用

Mon, 14 May 2018 00:00:00 +0000

想法

历史原因，我们一直使用的是阿里云经典网络的 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。

出现运维事故后，你会怎么办？

Fri, 30 Mar 2018 00:00:00 +0000

从聊天说起

有一次和朋友聊天，他说他们有一次部署出事了，影响还挺大，那次事故后，他们公司对于部署流程增加了更多的审批。

当朋友说完前半句时，我已经猜到下半句，那是很多公司或个人会做出的反应。至于为什么会做出这样的反应，我也不知道。

我问：为什么那次部署会“出事”？

他说：当时部署的人忘记了那台机器上有一条 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

声明式的配置里写的是当前环境的“状态”，语意上，声明式的配置不论你执行多少次，你得到最终的“状态”就是你所声明的，这也就实现了《持续交付》里说的：