标签为 Ansible 的文章

编写Ansible模块并自定义Facts

背景介绍:
Ansible自带的Facts有很多,但很多时候并不够用。 比如,Ansible就没有ansible_private_ipv4_address这样一个Facts,用来保存私网IP地址。 而我们恰恰就需要这样的一个Facts,因为我们有很多服务器的默认网卡并非是eth0,有的是bond0,eth1,em0,em1等,而公网IP地址与私网IP地址也并没有固定的绑定在某个网卡上,很多时候还是虚拟网卡。 还好,我们可以通过编写Ansible模块并自定义Facts来实现。

具体步骤:
[root@idc-server2 ~]# ifconfig

[root@idc-server1 ansible]# vim myfacts.yml

[root@idc-server1 ansible]# mkdir -p roles/myfacts/{tasks,templates}
[root@idc-server1 ansible]# vim roles/myfacts/tasks/main.yml

[root@idc-server1 ansible]# vim roles/myfacts/templates/myfacts.txt.j2

[root@idc-server1 ansible]# mkdir -p library/heylinux
[root@idc-server1 ansible]# vim library/heylinux/myfacts

[root@idc-server1 ansible]# ansible-playbook -u root myfacts.yml -i hosts

[root@idc-server1 ansible]# ssh idc1-server2 'cat /tmp/myfacts.txt'

,

1 Comment

拿什么拯救你,我的Ansible

在自动化运维方面,我用过Chef,Puppet,Salt还有Ansible。
其中Chef和Puppet之前在线上用了很长一段时间,效果也都不错。后来,我们希望尝试一些新的工具,而Salt和Ansible都是通过Python实现的,加上我们的团队也很喜欢用Python,所以就对二者进行了一些比较和试用。

就我个人而言,当时是比较推崇Salt的,因为看起来Salt更轻量级,跟Puppet在配置管理方面也非常相似,而且Salt的源码看起来很舒服,结构很简单,很适合学习和做二次开发。
但Ansible看起来则似乎更独特一些,通过SSH通道实现免Agent,同时在配置方面显得更干练,也有丰富的模块,能通过tags对每个配置项来进行灵活的分组。这些特点,得到了另外一些同事的大力肯定和推荐,在经历过几次争论之后,领导决定将线上所有的Puppet配置都迁移到Ansible上去。

在初期,使用Ansible感觉是比较新鲜的,还略微有点嗨,因为不再需要安装Agent了,新服务器上线之后,把主机名加入hosts inventory,利用初始的root用户密码Push一次,整个配置任务就算完成了。
但在运行了半年多之后,在我们将所有的Puppet配置都迁移过来后,在不停的增加新的配置的情况下,我感到了痛苦,是真真正正的痛苦。

因为,我们目前很难确保线上的配置是完整的,上下逻辑是没有问题的,是能够适用于所有环境的。
而这些,不是Ansible的问题,是人的问题。
由于Ansible免Agent,所以每一次配置的更改,都需要主动的Push一次。在之前配置内容不多,服务器较少的情况下,我们每次都直接把整个配置Push一次。但随着配置的增多,服务器数量增加到了一个相对饱和的程度时,我们绝大部分情况下都只需要对现有的服务器配置进行一些调整,例如增加或更新某个软件,修改某个参数等。

在这种情况下,我们每一次的Push基本上都是通过tags来完成的,没有人愿意在每次都将所有的配置都主动Push一次,没有人会有这个耐心,因为使用tags来执行我想要修改的部分,可能只需要10秒,而将整个配置都跑一次,则需要3分钟甚至更长的时间。因此,日积月累,整个配置的完整性没有了保障,大家更新过的地方,通过tags跑都没有问题,但是抛开tags将整个配置Push一次的时候,就会发现,各种冲突和错误都出现了。

我曾经写过一个CDH5的role,在最开始部署集群时没有一点错误,但是在维护了1个月之后,需要新上线一个新的CDH5集群时,这个role根本无法完成一个新集群的部署,我花费了足足2天来修复所有的报错,我发现,在这1个月里,大家更新了很多的地方,通过那些绑定的tags在现有的环境中Push,都不会报错。
但其实有很多地方,是有冲突和逻辑问题的,很多仅需要在初始化的时候执行的配置之后再也没有执行过,因为更新后的配置大家都是通过tags进行Push的,而Ansible在任何一个配置项报错时都会中止。

这的确是人的问题,但这也是符合人性的。我们尝试过不使用tags来Push,但之后所有的人都觉得这样太过愚蠢,因为绝大部分时间都不会发现错误,只会浪费时间。而经过一段时间之后,谁都不敢保证整个配置Push一次是没有问题的,并且,残酷的现实告诉我们,每次都会有错误出现。

为何之前在使用Puppet的时候,没有遇到过这样的困扰呢?因为,Agent的方式,每次都需要Pull所有关联的配置,需要耗费一些时间,但由于不需要手动去Push,所以感受会不同,我们没有觉得浪费了多少时间,也不用担心更新之后其它的配置项会有问题。

这或许不是工具的问题,是我们没有找到一个合适的方法来使用它。
但是,真的很难找到解决的办法,强制所有人Push整个配置,或周期性的检查整个配置,都难以实施下去。
该拿什么拯救你,我的Ansible。

6 Comments

开启ControlPersist来大幅度提升SSH的连接速度

参考资料:
http://www.ptudor.net/linux/openssh/
http://jpmens.net/2012/06/22/ssh-controlmaster/
https://github.com/ClockworkNet/cmc

背景介绍:
目前,项目中服务器的配置管理已经全部从Puppet迁移到了Ansible,而之前一直认为不会带来困扰的SSH通道慢的问题则暴露的很明显了。
因为很多时候需要同时更新几百台服务器,有不少服务器与Ansible主机还不在同一个IDC机房。
无意间发现了一篇文章,提到开启SSH的ControlMaster并持久化socket连接,可以加速Ansible的执行速度,不需要在每次都经历SSH认证,单个服务器可能节约的时间仅在1秒左右,而上百台的服务器就能节省约1分钟左右的时间。

但开启这个功能,必须安装版本较新的openssh,而我们大部分主机都是CentOS6.4 x86_64,默认的版本太旧了并且官方yum仓库中的版本也很旧。
考虑到这个功能仅需要客户端的支持即可,不需要在每台服务器上都安装,我们就下载了最新的openssh源码包并打包成了RPM直接安装到了Ansible操作主机上。

服务器环境:
CentOS 6.4 x86_64 Minimal

1. 编译生成OpenSSH RPM
1.1 安装编译所需工具
$ sudo yum -y groupinstall "Development tools"
$ sudo yum -y install pam-devel rpm-build rpmdevtools zlib-devel krb5-devel tcp_wrappers tcp_wrappers-devel tcp_wrappers-libs

1.2 配置RPM编译环境
$ cd /home/dong.guo
$ mkdir rpmbuild
$ cd rpmbuild
$ mkdir -pv {BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS,TMP}

$ cd /home/dong.guo
$ vim .rpmmacros

%_topdir /home/dong.guo/rpmbuild
%_tmppath /home/dong.guo/TMP

1.3 升级OpenSSL到最新
$ sudo yum update openssl

1.4 编译OpenSSH RPM
1.4.1 下载源码包
$ cd /home/dong.guo/rpmbuild/SOURCES/
$ wget http://mirror.team-cymru.org/pub/OpenBSD/OpenSSH/portable/openssh-6.6p1.tar.gz
$ wget http://mirror.team-cymru.org/pub/OpenBSD/OpenSSH/portable/openssh-6.6p1.tar.gz.asc
$ openssl dgst -sha1 openssh-6.6p1.tar.gz; echo b850fd1af704942d9b3c2eff7ef6b3a59b6a6b6e

1.4.2 配置SPEC文件
$ cd /home/dong.guo/rpmbuild/SPECS
$ tar xfz ../SOURCES/openssh-6.6p1.tar.gz openssh-6.6p1/contrib/redhat/openssh.spec
$ mv openssh-6.6p1/contrib/redhat/openssh.spec openssh-6.6p1.spec
$ rm -rf openssh-6.6p1
$ sudo chown 74:74 openssh-6.6p1.spec
$ sed -i -e "s/%define no_gnome_askpass 0/%define no_gnome_askpass 1/g" openssh-6.6p1.spec
$ sed -i -e "s/%define no_x11_askpass 0/%define no_x11_askpass 1/g" openssh-6.6p1.spec
$ sed -i -e "s/BuildPreReq/BuildRequires/g" openssh-6.6p1.spec

1.4.3 编译生成RPM
$ cd /home/dong.guo/rpmbuild/SPECS
$ rpmbuild -ba openssh-6.6p1.spec

1.4.4 查看生成的RPM
$ cd /home/dong.guo/rpmbuild/RPMS/x86_64
$ ls openssh-*

openssh-6.6p1-1.x86_64.rpm  openssh-clients-6.6p1-1.x86_64.rpm  openssh-debuginfo-6.6p1-1.x86_64.rpm  openssh-server-6.6p1-1.x86_64.rpm

1.4.5 安装生成的RPM
$ cd /home/dong.guo/rpmbuild/RPMS/x86_64
$ sudo rpm -e openssh-askpass
$ sudo rpm -e openssh-ldap
$ sudo rpm -Fvh openssh*6.6p1-1*rpm

Preparing...          ########################################### [100%]
   1:openssh          ########################################### [ 33%]
   2:openssh-clients  ########################################### [ 67%]
   3:openssh-server   warning: /etc/ssh/sshd_config created as /etc/ssh/sshd_config.rpmnew ##################################### [100%]

1.4.6 更新SSH配置文件,避免某些参数变更造成无法远程登录
$ sudo cp /etc/ssh/sshd_config.rpmnew /etc/ssh/sshd_config
$ sudo /etc/init.d/sshd restart

1.4.7 查看已安装的RPM
$ sudo rpm -qa | grep openssh
openssh-clients-6.6p1-1.x86_64
openssh-server-6.6p1-1.x86_64
openssh-6.6p1-1.x86_64

2. 配置ControlMaster
$ cd /home/dong.guo
$ vim .ssh/config

Host *
  Compression yes
  ServerAliveInterval 60
  ServerAliveCountMax 5
  ControlMaster auto
  ControlPath ~/.ssh/sockets/%r@%h-%p
  ControlPersist 4h

3. 下载cmc工具用于管理sockets
$ cd ~
$ sudo yum install http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
$ sudo yum install git
$ cd /home/dong.guo
$ mkdir bin
$ git clone https://github.com/ClockworkNet/cmc.git
$ cp cmc/cmc bin/

4. 使用与测试
4.1 查看当前的sockets
$ cmc -l

No ControlMaster connection sockets found.

4.2 统计第一次的执行时间
$ time ssh rainbow@heylinux.com 'hostname -s'

ec2-tokyo

real	0m9.486s
user	0m0.017s
sys	0m0.015s

耗时9.5秒

4.3 查看当前的sockets
$ cmc -l

heylinux.com
  Master running (pid=32857, cmd=ssh: /home/dong.guo/.ssh/sockets/rainbow@heylinux.com-22 [mux], start=19:19:05)
  Socket: /home/dong.guo/.ssh/sockets/rainbow@heylinux.com-22

4.4 统计有socket情况下的执行时间
$ time ssh rainbow@heylinux.com 'hostname -s'

ec2-tokyo

real	0m0.240s
user	0m0.004s
sys	0m0.005s

耗时0.24秒

4.5 删除当前所有的sockets
$ cmc -X

heylinux.com - Closing ControlMaster connection
  Exit request sent.

4.6 统计没有socket情况下的执行时间
$ time ssh rainbow@heylinux.com 'hostname -s'

ec2-tokyo

real	0m9.468s
user	0m0.016s
sys	0m0.017s

仍然是9.5秒

5. 结论
在开启了ControlMaster的持久化之后,SSH在建立了sockets之后,节省了每次验证和创建连接的时间。
在网络状况不是特别理想,尤其是跨互联网的情况下,所带来的性能提升是非常可观的,在上面的测试中节约了9秒。
而即使在局域网内部使用,每台服务器节省1秒左右的时间,同时操作上百台服务器时,节省的时间也是非常可观的,非常值得拥有。

, , ,

3 Comments

使用Ansible自动安装部署CDH5集群

背景介绍:
之前,就CDH3和CDH4的安装部署,我写过两个系列的文章:
http://heylinux.com/archives/1980.html
http://heylinux.com/archives/2827.html

但随着CDH5的发展,尤其是在Namenode的高可用方面的成熟,项目上决定将现有的Hadoop集群都迁移到CDH5上。
为了方便管理,我采用了Ansible来自动安装部署整个CDH5集群,目前在线上运行状况良好。

相关配置:
所有的配置,我都放到了GitHub中,对应的仓库地址如下:
https://github.com/mcsrainbow/ansible-playbooks-cdh5

,

2 Comments

Ansible实战之 自动安装部署MooseFS 以及 与Salt的相关比较

前段时间,了解并学习了Salt,感觉非常不错,于是有了想法和打算要替换掉线上的Puppet。
可是最近情况不妙,一名新加入的同事,极力推荐Ansible,并列举了很多Ansible比Salt优越的地方。当时我对Ansible还不了解,因此不能与其争论,到底谁好谁坏也无法做出判断。
于是,我就选择了之前在Salt上实现过的同一个案例 “自动安装部署MooseFS”,来将它用Ansible实现一遍。在经历了一段时间的学习和填坑的过程之后,终于完成了,同时也有了一些心得。

我参考的是官方文档,从 Getting Started 开始,接着重点参考了 ModulesPractices ,以及 官方的Hadoop示例

我的相关Ansible代码都放在了GitHub上,具体结构如下:
$ tree

.
|-- group_vars
|   |-- all
|   `-- moosefs_all
|-- moosefs.hosts
|-- moosefs.yml
|-- roles
|   |-- common
|   |   `-- tasks
|   |       `-- main.yml
|   |-- moosefs_chunkserver
|   |   |-- handlers
|   |   |   `-- main.yml
|   |   |-- tasks
|   |   |   `-- main.yml
|   |   `-- templates
|   |       |-- mfschunkserver.cfg.j2
|   |       `-- mfshdd.cfg.j2
|   |-- moosefs_client
|   |   `-- tasks
|   |       `-- main.yml
|   |-- moosefs_common
|   |   `-- tasks
|   |       `-- main.yml
|   |-- moosefs_master
|   |   |-- files
|   |   |   `-- index.html
|   |   |-- handlers
|   |   |   `-- main.yml
|   |   |-- tasks
|   |   |   `-- main.yml
|   |   `-- templates
|   |       |-- httpd.conf.j2
|   |       |-- mfsexports.cfg.j2
|   |       |-- mfsmaster.cfg.j2
|   |       `-- mfsmetalogger.cfg.j2
|   `-- moosefs_metalogger
|       |-- handlers
|       |   `-- main.yml
|       |-- tasks
|       |   `-- main.yml
|       `-- templates
|           `-- mfsmetalogger.cfg.j2
`-- site.yml

阅读全文 »

,

5 Comments