python自动化运维：技术与最佳实践

\n"） #输出上一级目录URL链接 f.write（'
• Parent Directory\n' % （pubutil.parent_dir（self.path））） for name in list： #遍历输出目录文件列表 fullname = os.path.join（path， name） displayname = name = cgi.escape（name） #HTML字符转义 if os.path.islink（fullname）： displayname = name + "@" elif os.path.isdir（fullname）： displayname = name + "/" name = name + os.sep f.write（'
• %s\n' % （name， displayname）） f.write（"

"；  function bubble（array $array）{  for（$i=0， $len=count（$array）-1； $i<$len； ++$i）{       for（$j=$len； $j>$i； --$j）{           if（$array[$j] < $array[$j-1]）           {               $temp = $array[$j]；               $array[$j] = $array[$j-1]；               $array[$j-1] = $temp；           }       }  }  return $array；  }  print_r（bubble（array（23，45，67，3，56，82，24，23，5，77，19，33，51，  99）））；  echo "

- m-a。举例说明：重启webservers组的所有 Apache服务。 ansible webservers -m service -a "name=httpd state=restarted" 本节将重点介绍参数的使用方法，详细规则及 含义见表9-2。 表9-2　匹配目标主机规则表 9.5　Ansible常用模块及API Ansible提供了非常丰富的功能模块，包括Cloud（云计算）、 Commands（命令行）、Database（数据库）、Files（文件管理）、 Internal（内置功能）、Inventory（资产管理）、Messaging（消息队 列）、Monitoring（监控管理）、Net Infrastructure（网络基础服务）、 Network（网络管理）、Notification（通知管理）、Packaging（包管 理）、Source Control（版本控制）、System（系统服务）、Utilities（公 共服务）、Web Infrastructure（Web基础服务），等等，更多模块介绍 见官网模块介绍（网址：http://ansibleworks.com/docs/modules.html）。 模块默认存储目录为/usr/share/ansible/，存储结构以模块分类名作为目 录名，模块文件按分类存放在不同类别目录中。命令行调用模块格式： ansible-m- a，其中默认的模块名为command，即“-m command”可省略。获取远程webservers组主机的uptime信息格式如图9-3 所示。 图9-3　获取主机“uptime”信息 以上命令等价于ansible webservers-a"uptime"，获得模块的帮助说 明信息格式：ansible-doc<模块名>，得到ping模块的帮助说明信息如图 9-4所示。 图9-4　ping模块帮助信息 在playbooks中运行远程命令格式如下： - name： reboot the servers action： command /sbin/reboot -t now Ansible 0.8或以上版本支持以下格式： - name： reboot the servers command： /sbin/reboot -t now Ansible提供了非常丰富的模块，涉及日常运维工作的方方面面。 下面介绍Ansible的常用模块，更多模块介绍见官方说明。 1.远程命令模块 （1）功能 模块包括command、script、shell，都可以实现远程shell命令运 行。command作为Ansible的默认模块，可以运行远程权限范围所有的 shell命令；script功能是在远程主机执行主控端存储的shell脚本文件，相 当于scp+shell组合；shell功能是执行远程主机的shell脚本文件。 （2）例子 ansible webservers -m command -a "free -m" ansible webservers -m script -a "/home/test.sh 12 34" ansible webservers -m shell -a "/home/test.sh" 2.copy模块 （1）功能 实现主控端向目标主机拷贝文件，类似于scp的功能。 （2）例子 以下示例实现拷贝/home/test.sh文件至webserver组目标主机/tmp/目 录下，并更新文件属主及权限（可以单独使用file模块实现权限的修 改，格式为：path=/etc/foo.conf owner=foo group=foo mode=0644）。 # ansible webservers -m copy -a "src=/home/test.sh dest=/tmp/ owner=root group=root mode=0755" 3.stat模块 （1）功能 获取远程文件状态信息，包括atime、ctime、mtime、md5、uid、 gid等信息。 （2）例子 ansible webservers -m stat -a "path=/etc/sysctl.conf" 4.get_url模块 （1）功能 实现在远程主机下载指定URL到本地，支持sha256sum文件校验。 （2）例子 ansible webservers -m get_url -a "url=http：//www.baidu.com dest=/tmp/index.html mode=0440 force=yes" 5.yum模块 （1）功能 Linux平台软件包管理操作，常见有yum、apt管理方式。 （2）例子 ansible webservers -m apt -a "pkg=curl state=latest" ansible webservers -m yum -a "name=curl state=latest" 6.cron模块 （1）功能 远程主机crontab配置。 （2）例子 ansible webservers -m cron -a "name='check dirs' hour='5，2' job='ls -alh > /dev/null'" 效果如下： #Ansible： check dirs * 5，2 * * * ls -alh > /dev/nullsalt '*' file.chown /etc/passwd root root 7.mount模块 （1）功能 远程主机分区挂载。 （2）例子 ansible webservers -m mount -a "name=/mnt/data src=/dev/sd0 fstype=ext3 opts=ro state=present" 8.service模块 （1）功能 远程主机系统服务管理。 （2）例子 ansible webservers -m service -a "name=nginx state=stopped" ansible webservers -m service -a "name=nginx state=restarted" ansible webservers -m service -a "name=nginx state=reloaded" 9.sysctl包管理模块 （1）功能 远程Linux主机sysctl配置。 （2）例子 sysctl： name=kernel.panic value=3 sysctl_file=/etc/sysctl.conf checks=before reload=yessalt '*' pkg.upgrade 10.user服务模块 （1）功能 远程主机系统用户管理。 （2）例子 #添加用户johnd； ansible webservers -m user -a "name=johnd comment='John Doe'" #删除用户johnd； ansible webservers -m user -a "name=johnd state=absent remove=yes" 提示　playbooks模块调用格式如下，以command模块为例 （0.8或更新版本格式）： -name：reboot the servers command：/sbin/reboot-t now 9.6　playbook介绍 playbook是一个不同于使用Ansible命令行执行方式的模式，其功 能更强大灵活。简单来说，playbook是一个非常简单的配置管理和多主 机部署系统，不同于任何已经存在的模式，可作为一个适合部署复杂应 用程序的基础。playbook可以定制配置，可以按指定的操作步骤有序执 行，支持同步及异步方式。官方提供了大量的例子，可以在 https://github.com/ansible/ansible-examples找到。playbook是通过YAML格 式来进行描述定义的，可以实现多台主机应用的部署，定义在 webservers及dbservers组上执行特定指令步骤。下面为读者介绍一个基 本的playbook示例： 【/home/test/ansible/playbooks/nginx.yml】 --- - hosts： webservers vars： worker_processes： 4 num_cpus： 4 max_open_file： 65506 root： /data remote_user： root tasks： - name： ensure nginx is at the latest version yum： pkg=nginx state=latest - name： write the nginx config file template： src=/home/test/ansible/nginx/nginx2.conf dest=/etc/nginx/nginx.conf notify： - restart nginx - name： ensure nginx is running service： name=nginx state=started handlers： - name： restart nginx service： name=nginx state=restarted 以上playbook定制了一个简单的Nginx软件包管理，内容包括安 装、配置模板、状态管理等。下面详细对该示例进行说明。 9.6.1　定义主机与用户 在playbook执行时，可以为主机或组定义变量，比如指定远程登录 用户。以下为webservers组定义的相关变量，变量的作用域只限于 webservers组下的主机。 - hosts： webservers vars： worker_processes： 4 num_cpus： 4 max_open_file： 65506 root： /data remote_user： root hosts参数的作用为定义操作的对象，可以是主机或组，具体定义 规则见9.3.1节内容。本示例定义操作主机为webservers组，同时通过vars 参数定义了4个变量（配置模板用到），其中remote_user为指定远程操 作的用户名，默认为root账号，支持sudo方式运行，通过添加sudo：yes 即可。注意，remote_user参数在Ansible 1.4或更高版本才引入。 9.6.2　任务列表 所有定义的任务列表（tasks list），playbook将按定义的配置文件 自上而下的顺序执行，定义的主机都将得到相同的任务，但执行的返回 结果不一定保持一致，取决于主机的环境及程序包状态。建议每个任务 事件都要定义一个name标签，好处是增强可读性，也便于观察结果输出 时了解运行的位置，默认使用action（具体的执行动作）来替换name作 为输出。下面是一个简单的任务定义示例： tasks： - name： make sure nginx is running service： name=nginx state=running 功能是检测Nginx服务是否为运行状态，如没有则启动。其中name 标签对下面的action（动作）进行描述；action（动作）部分可以是 Ansible的任意模块，具体见9.5节，本例为services模块，参数使用 key=value的格式，如“name=httpd”，在定义任务时也可以引用变量，格 式如下： tasks： - name： create a virtual host file for {{ vhost }} template： src=somefile.j2 dest=/etc/httpd/conf.d/{{ vhost }} 在playbook可通过template模块对本地配置模板文件进行渲染并同 步到目标主机。以nginx配置文件为例，定义如下： - name： write the nginx config file template： src=/home/test/ansible/nginx/nginx2.conf dest=/etc/nginx/nginx.conf notify： - restart nginx 其中，“src=/home/test/ansible/nginx/nginx2.conf”为管理端模板文件 存放位置，“dest=/etc/nginx/nginx.conf”为目标主机nginx配置文件位置， 通过下面nginx模板文件可以让大家对模板的定义有个基本的概念。 【/home/test/ansible/nginx/nginx2.conf】 user nginx； worker_processes {{ worker_processes }}； {% if num_cpus == 2 %} worker_cpu_affinity 01 10； {% elif num_cpus == 4 %} worker_cpu_affinity 1000 0100 0010 0001； {% elif num_cpus >= 8 %} worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000； {% else %} worker_cpu_affinity 1000 0100 0010 0001； {% endif %} worker_rlimit_nofile {{ max_open_file }}； … … Ansible会根据定义好的模板渲染成真实的配置文件，模板使用 YAML语法，详细见9.1节，最终生成的nginx.conf配置如下： user nginx； worker_processes 4； worker_cpu_affinity 1000 0100 0010 0001； worker_rlimit_nofile 65506； … … 当目标主机配置文件发生变化后，通知处理程序（Handlers）来触 发后续的动作，比如重启nginx服务。Handlers中定义的处理程序在没有 通知触发时是不会执行的，触发后也只会运行一次。触发是通过 Handlers定义的name标签来识别的，比如下面notify中的“restart nginx”与 handlers中的“name：restart nginx”保持一致。 notify： - restart nginx handlers： - name： restart nginx service： name=nginx state=restarted 9.6.3　执行playbook 执行playbook，可以通过ansible-playbook命令实现，格式：ansible- playbook playbook file（.yml）[参数]，如启用10个并行进程数执行 playbook： #ansible-playbook /home/test/ansible/playbooks/nginx.yml -f 10， 其他常用参数说明： ·-u REMOTE_USER：手工指定远程执行playbook的系统用户； ·--syntax-check：检查playbook的语法； ·--list-hosts playbooks：匹配到的主机列表； ·-T TIMEOUT：定义playbook执行超时时间； ·--step：以单任务分步骤运行，方便做每一步的确认工作。 更多参数说明运行ansible-playbook-help来获得。 9.7　playbook角色与包含声明 当我们写一个非常大的playbook时，想要复用些功能显得有些吃 力，还好Ansible支持写playbook时拆分成多个文件，通过包含 （include）的形式进行引用，我们可以根据多种维度进行“封装”，比如 定义变量、任务、处理程序等。 角色建立在包含文件之上，抽象后更加清晰、可复用。运维人员 可以更专注于整体，只有在需要时才关注具体细节。Ansible官方在 GitHub上提供了大量的示例供大家参考借鉴，访问地址 https://github.com/ansible/ansible-examples即可获相应的学习资料。 9.7.1　包含文件，鼓励复用 当多个playbook涉及复用的任务列表时，可以将复用的内容剥离 出，写到独立的文件当中，最后在需要的地方include进来即可，示例如 下： 【tasks/foo.yml】 --- # possibly saved as tasks/foo.yml - name： placeholder foo command： /bin/foo - name： placeholder bar command： /bin/bar 然后就可以在使用的playbook中include进来，如： tasks： - include： tasks/foo.yml 当然，也可以将变量传递到包含文件当中，这称为“参数包含”。 如在部署多个WordPress的情况下，可以根据不同用户单独部署 WordPress的任务，且引用单个wordpress.yml文件，可以这样写： tasks： - include： wordpress.yml user=timmy - include： wordpress.yml user=alice - include： wordpress.yml user=bob 注意，1.4或更高版本可支持以Python的字典、列表的传递参数形 式，如： tasks： - { include： wordpress.yml， user： timmy， ssh_keys： [ 'keys/one.txt'， 'keys/two.txt' ] } 使用这两种方法都进行变量传递，然后在包含文件中通过使用 {{user}}进行变量引用。 将处理程序（handlers）放到包含文件中是一个好的做法，比如重 启Apache的任务，如下： 【handlers/handlers.yml】 --- # this might be in a file like handlers/handlers.yml - name： restart apache service： name=apache state=restarted 需要时可以进行引用，像这样： handlers： - include： handlers/handlers.yml 9.7.2　角色 现在我们已经了解了变量、任务、处理程序的定义，有什么方法 更好地进行组织或抽象，让其复用性更强、功能更具模块化？答案就是 角色。角色是Ansible定制好的一种标准规范，以不同级别目录层次及文 件对角色、变量、任务、处理程序等进行拆分，为后续功能扩展、可维 护性打下基础。一个典型角色目录结构的示例如下： site.yml webservers.yml fooservers.yml roles/ common/ files/ templates/ tasks/ handlers/ vars/ meta/ webservers/ files/ templates/ tasks/ handlers/ vars/ meta/ 在playbook是这样引用的： 【site.yml】 --- - hosts： webservers roles： - common - webservers 角色定制以下规范，其中x为角色名。 ·如roles/x/tasks/main.yml文件存在，其中列出的任务将被添加到执 行队列； ·如roles/x/handlers/main.yml文件存在，其中所列的处理程序将被添 加到执行队列； ·如roles/x/vars/main.yml文件存在，其中列出的变量将被添加到执 行队列； ·如roles/x/meta/main.yml文件存在，所列任何作用的依赖关系将被 添加到角色的列表（1.3及更高版本）； ·任何副本任务可以引用roles/x/files/无需写路径，默认相对或绝对 引用； ·任何脚本任务可以引用roles/x/files/无需写路径，默认相对或绝对 引用； ·任何模板任务可以引用文件中的roles/x/templates/无需写路径，默 认相对或绝对引用。 为了便于大家更好地理解和使用角色（role），对9.6节中的nginx 软件包管理的playbook（独立文件）修改成角色的形式，同时添加了一 个公共类角色common，从角色全局作用域中抽取出公共的部分，一般 为系统的基础服务，比如ntp、iptables、selinux、sysctl等。本示例是针 对ntp服务的管理。 （1）playbook目录结构 playbook目录包括变量定义目录group_vars、主机组定义文件 hosts、全局配置文件site.yml、角色功能目录，playbook目录结构可参考 图9-5。 【/home/test/ansible/playbooks/nginx】 （2）定义主机组 以下定义了一个业务组webservers，成员为两台主机。 【nginx/hosts】 [webservers] 192.168.1.21 192.168.1.22 非必选配置，默认将引用/etc/ansible/hosts的参数，角色中自定义 组与主机文件将通过“-i file”命令行参数调用，如ansible-playbook-i hosts 来调用。 图9-5　playbook主目录结构 （3）定义主机或组变量 定义规则见9.3节所述，group_vars为定义组变量目录，目录当中的 文件名要与组名保持一致，组变量文件定义的变量作为域只受限于该 组，all代表所有主机。 【nginx/group_vars/all】 --- # Variables listed here are applicable to all host groups ntpserver： ntp.sjtu.edu.cn 【nginx/group_vars/webservers】 --- worker_processes： 4 num_cpus： 4 max_open_file： 65536 root： /data （4）全局配置文件site.yml 下面的全局配置文件引用了两个角色块，角色的应用范围及实现 功能都不一样： 【nginx/site.yml】 --- - name： apply common configuration to all nodes hosts： all roles： - common - name： configure and deploy the webservers and application code hosts： webservers roles： - web 全局配置文件site.yml引用了两个角色，一个为公共类的common， 另一个为web类，分别对应nginx/common、nginx/web目录。以此类推， 可以引用更多的角色，如db、nosql、hadoop等，前提是我们先要进行 定义，通常情况下一个角色对应着一个特定功能服务。通过hosts参数来 绑定角色对应的主机或组。 （5）角色common的定义 角色common定义了handlers、tasks、templates、vars 4个功能类， 分别存放处理程序、任务列表、模板、变量的配置文件main.yml，需要 注意的是，vars/main.yml中定义的变量优先级高 于/nginx/group_vars/all，可以从ansible-playbook的执行结果中得到验 证。各功能块配置文件定义如下： 【handlers/main.yml】 - name： restart ntp service： name=ntpd state=restarted 【tasks/main.yml】 - name： Install ntp yum： name=ntp state=present - name： Configure ntp file template： src=ntp.conf.j2 dest=/etc/ntp.conf notify： restart ntp - name： Start the ntp service service： name=ntpd state=started enabled=true - name： test to see if selinux is running command： getenforce register： sestatus changed_when： false 其中template：src=ntp.conf.j2引用模板时无需写路径，默认在上级 的templates目录中查找。 【templates/ntp.conf.j2】 driftfile /var/lib/ntp/drift restrict 127.0.0.1 restrict -6 ：：1 server {{ ntpserver }} includefile /etc/ntp/crypto/pw keys /etc/ntp/keys 此处{{ntpserver}}将引用vars/main.yml定义的ntpserver变量。 【vars/main.yml】 --- # Variables listed here are applicable to all host groups ntpserver： 210.72.145.44 （6）角色web的定义 角色web定义了handlers、tasks、templates三个功能类，基本上是 9.6节中的nginx管理playbook对应定义功能段打散后的内容。具体功能 块配置文件定义如下： 【handlers/main.yml】 - name： restart nginx service： name=nginx state=restarted 【tasks/main.yml】 - name： ensure nginx is at the latest version yum： pkg=nginx state=latest - name： write the nginx config file template： src=nginx2.conf dest=/etc/nginx/nginx.conf notify： - restart nginx - name： ensure nginx is running service： name=nginx state=started 【templates/nginx2.conf】 user nginx； worker_processes {{ worker_processes }}； {% if num_cpus == 2 %} worker_cpu_affinity 01 10； {% elif num_cpus == 4 %} worker_cpu_affinity 1000 0100 0010 0001； {% elif num_cpus >= 8 %} worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000； {% else %} worker_cpu_affinity 1000 0100 0010 0001； {% endif %} worker_rlimit_nofile {{ max_open_file }}； …… 具体web角色定义细节将不展开描述，可参考9.6节及common角色 的说明。 （7）运行角色 #cd /home/test/ansible/playbooks/nginx #ansible-playbook -i hosts site.yml -f 10 运行结果如图9-6与图9-7所示。 图9-6　ntp部署片段 图9-7　nginx部署片段 9.8　获取远程主机系统信息：Facts Facts是一个非常有用的组件，类似于Saltstack的Grains功能，实现 获取远程主机的系统信息，包括主机名、IP地址、操作系统、分区信 息、硬件信息等，可以配合playbook实现更加个性化、灵活的功能需 求，比如在httpd.conf模板中引用Facts的主机名信息作为ServerName参 数的值。通过运行ansible hostname-m setup可获取Facts信息，例如，获 取192.168.1.21的Facts信息需运行：ansible 192.168.1.21-m setup，结果如 下： 192.168.1.21 | success >> { "ansible_facts"： { "ansible_all_ipv4_addresses"： [ "192.168.1.21" ]， "ansible_all_ipv6_addresses"： [ "fe80：：250：56ff：fe28：632d" ]， "ansible_architecture"： "x86_64"， "ansible_bios_date"： "07/02/2012"， "ansible_bios_version"： "6.00"， "ansible_cmdline"： { "KEYBOARDTYPE"： "pc"， "KEYTABLE"： "us"， "LANG"： "en_US.UTF-8"， "SYSFONT"： "latarcyrheb-sun16"， "quiet"： true， "rd_NO_DM"： true， "rd_NO_LUKS"： true， "rd_NO_LVM"： true， "rd_NO_MD"： true， "rhgb"： true， "ro"： true， "root"： "UUID=b8d29324-57b2-4949-8402-7fd9ad64ac5a" }， …… 在模板文件中这样引用Facts信息： {{ ansible_devices.sda.model }} {{ ansible_hostname }} 9.9　变量 在实际应用场景中，我们希望一些任务、配置根据设备性能的不 同而产生差异，比如使用本机CPU核数动态配置Nginx的 worker_processes参数，可能有一组主机的应用配置文件几乎相同，但略 有不同的配置项可以引用变量。在Ansible中使用变量的目的是方便处理 系统之间的差异。 变量名的命名规则由字母、数字和下划线组合而成，变量必须以 字母开头，如“foo_port”是一个合法的变量，“foo5”也是可以的，“foo- port”、“foo port”、“foo.port”和“12”都是非法的变量命名。在Inventory中 定义变量见9.3.2节和9.3.3节，在playbook定义变量见9.6节，建议回顾一 下，加深记忆。 9.9.1　Jinja2过滤器 Jinja2是Python下一个广泛应用的模板引擎，它的设计思想类似于 Django的模板引擎，并扩展了其语法和一系列强大的功能，官网地址： http://jinja.pocoo.org/。下面介绍一下Ansible使用Jinja2强大的过滤器 （Filters）功能。 使用格式：{{变量名|过滤方法}}。 下面是实现获取一个文件路径变量过滤出文件名的一个示例： {{ path | basename }} 获取文件所处的目录名： {{ path | dirname }} 下面为一个完整的示例，实现从“/etc/profile”中过滤出文件 名“profile”，并输出重定向到/tmp/testshell文件中。 --- - hosts： 192.168.1.21 vars： filename： /etc/profile tasks： - name： "shell1" shell： echo {{ filename | basename }} >> /tmp/testshell 更多的过滤方法见http://jinja.pocoo.org/docs/templates/#builtin- filters。 9.9.2　本地Facts 我们可以通过Facts来获取目标主机的系统信息，当这些信息还不 能满足我们的功能需求时，可以通过编写自定义的Facts模块来实现。当 然，还有一个更简单的实现方法，就是通过本地Facts来实现。只需在目 标设备/etc/ansible/facts.d目录定义JSON、INI或可执行文件的JSON输 出，文件扩展名要求使用“.fact”，这些文件都可以作为Ansible的本地 Facts，例如，在目标设备192.168.1.21定义三个变量，供以后playbook进 行引用。 【/etc/ansible/facts.d/preferences.fact】 [general] max_memory_size=32 max_user_processes=3730 open_files=65535 在主控端运行ansible 192.168.1.21-m setup-a"filter=ansible_local"可看 到定义的结果，返回结果如下： 192.168.1.21 | success >> { "ansible_facts"： { "ansible_local"： { "preferences"： { "general"： { "max_memory_size"： "32"， "max_user_processes"： "3730"， "open_files"： "65535" } } } }， "changed"： false } 注意返回JSON的层次结构，preferences（facts文件名前缀） →general（INI的节名）→key：value（INI的键与值），最后就可以在我 们的模板或playbook中通过以下方式进行调用： {{ ansible_local.preferences.general. open_files }} 9.9.3　注册变量 变量的另一个用途是将一条命令的运行结果保存到变量中，供后 面的playbook使用。下面是一个简单的示例： - hosts： web_servers tasks： - shell： /usr/bin/foo register： foo_result ignore_errors： True - shell： /usr/bin/bar when： foo_result.rc == 5 上述示例注册了一个foo_result变量，变量值为shell：/usr/bin/foo的 运行结果，ignore_errors：True为忽略错误。变量注册完成后，就可以在 后面playbook中使用了，当条件语句when：foo_result.rc==5成立时， shell：/usr/bin/bar命令才会运行，其中foo_result.rc为返回/usr/bin/foo的 resultcode（返回码）。图9-8返回“rc=0”的返回码。 图9-8　命令执行结果 9.10　条件语句 有时候一个playbook的结果取决于一个变量，或者取决于上一个任 务（task）的执行结果值，在某些情况下，一个变量的值可以依赖于其 他变量的值，当然也会影响Ansible的执行过程。 下面主要介绍When声明。 有时候我们想跳过某些主机的执行步骤，比如符合特定版本的操 作系统将不安装某个软件包，或者磁盘空间爆满了将进行清理的步骤。 在Ansible中很容易做到这一点，通过When子句实现，其中将引用Jinja2 表达式。下面是一个简单的示例： tasks： - name： "shutdown Debian flavored systems" command： /sbin/shutdown -t now when： ansible_os_family == "Debian" 通过定义任务的Facts本地变量ansible_os_family（操作系统版本名 称）是否为Debian，结果将返回BOOL类型值，为True时将执行上一条 语句command：/sbin/shutdown-t now，为False时该条语句都不会触发。 我们再看一个示例，通过判断一条命令执行结果做不同分支的二级处 理。 tasks： - command： /bin/false register： result ignore_errors： True - command： /bin/something when： result|failed - command： /bin/something_else when： result|success - command： /bin/still/something_else when： result|skipped “when：result|success”的意思为当变量result执行结果为成功状态 时，将执行/bin/something_else命令，其他同理，其中success为Ansible内 部过滤器方法，返回Ture代表命令运行成功。 9.11　循环 通常一个任务会做很多事情，如创建大量的用户、安装很多包， 或重复轮询特定的步骤，直到某种结果条件为止，Ansible为我们提供了 此支持。下面是一个简单的示例： - name： add several users user： name={{ item }} state=present groups=wheel with_items： - testuser1 - testuser2 这个示例实现了一个批量创建系统用户的功能，with_items会自动 循环执行上面的语句“user：name={{item}}state=present groups=wheel”，循环的次数为with_items的元素个数，这里有2个元素， 分别为testuser1、testuser2，会分别替换{{item}}项。这个示例与下面的 示例是等价的： - name： add user testuser1 user： name=testuser1 state=present groups=wheel - name： add user testuser2 user： name=testuser2 state=present groups=wheel 当然，元素也支持字典的形式，如下： - name： add several users user： name={{ item.name }} state=present groups={{ item.groups }} with_items： - { name： 'testuser1'， groups： 'wheel' } - { name： 'testuser2'， groups： 'root' } 循环也支持列表（List）的形式，不过是通过with_flattened语句来 实现的，例如： ---- # file： roles/foo/vars/main.yml packages_base： - [ 'foo-package'， 'bar-package' ] packages_apps： - [ ['one-package'， 'two-package' ]] - [ ['red-package']， ['blue-package']] 以上定义了两个列表变量，分别是需要安装的软件包名，以便后 面进行如下引用： - name： flattened loop demo yum： name={{ item }} state=installed with_flattened： - packages_base - packages_apps 通过使用with_flattened语句循环引用定义好的列表变量。 9.12　示例讲解 官网提供的Haproxy+LAMP+Nagios经典示例，也是目前国内最常 用的技术架构，此案例访问地址为：https://github.com/ansible/ansible- examples/tree/master/lamp_haproxy。下面将对该示例进行详细说明，内 容覆盖前面涉及的几乎所有知识点，起到温故的作用，同时作为对 Ansible的总结内容。 下面介绍playbook的基本信息。 1.目录结构 示例playbook目录结构见图9-9。 图9-9　示例目录结构 2.设备环境说明 两台Web主机、1台数据库主机、1台负载均衡器主机、1台监控主 机，hosts配置如下： 【hosts】 [webservers] web1 web2 [dbservers] db1 [lbservers] lb1 [monitoring] nagios 3.palybook入口文件site.yml 需要注意的是base-apache角色，由于webservers及monitoring都需 要部署Apache环境，为提高复用性，将部署Apache独立成base-apache角 色。 【Site.yml】 --- - hosts： all roles： - common - hosts： dbservers user： root roles： - db - hosts： webservers user： root roles： - base-apache - web - hosts： lbservers user： root roles： - haproxy - hosts： monitoring user： root roles： - base-apache - nagios 4.定义组变量 下面定义playbook全局变量，变量作用域为所有主机。 【group_vars/all】 --- # Variables here are applicable to all host groups httpd_port： 80 ntpserver： 192.168.1.2 all文件定义了匹配所有主机作用域的变量，一般为系统公共类基 础配置，如ntpserver地址、sysctl变量、iptables配置等。 下面为定义webservers组的变量，变量作用域为webservers组主 机。 【group_vars/webservers】 --- # Variables for the web server configuration # Ethernet interface on which the web server should listen. # Defaults to the first interface. Change this to： # # iface： eth1 # # ...to override. # iface： '{{ ansible_default_ipv4.interface }}' # this is the repository that holds our sample webapp repository： https：//github.com/bennojoy/mywebapp.git # this is the sha1sum of V5 of the test webapp. webapp_version： 351e47276cc66b018f4890a04709d4cc3d3edb0d webservers文件定义了webservers组作用域的变量。本示例涉及 Apache相关配置，其中“iface：'{{ansible_default_ipv4.interface}}'”引用了 Facts获取的本地网卡接口名信息，另外定义了一个GitHub的repository， 方便下载Web测试文件，如内部搭建git版本控制环境，此处也可以修改 成本地的服务地址。 下面为定义dbservers组的变量，变量作用域为dbservers组主机。 【group_vars/dbservers】 --- # The variables file used by the playbooks in the dbservers group. # These don't have to be explicitly imported by vars_files： they are autopopulated. mysqlservice： mysqld mysql_port： 3306 dbuser： root dbname： foodb upassword： abc dbservers文件定义了dbservers组作用域变量，本示例涉及MySQL 数据库的基本应用信息。 下面为定义lbservers组作用域变量文件，本示例主要涉及haproxy 环境涉及的配置参数值。 【group_vars/lbservers】 --- # Variables for the HAproxy configuration # HAProxy supports "http" and "tcp". For SSL， SMTP， etc， use "tcp". mode： http # Port on which HAProxy should listen listenport： 8888 # A name for the proxy daemon， this wil be the suffix in the logs. daemonname： myapplb # Balancing Algorithm. Available options： # roundrobin， source， leastconn， source， uri # （if persistance is required use， "source"） balance： roundrobin # Ethernet interface on which the load balancer should listen # Defaults to the first interface. Change this to： # # iface： eth1 # # ...to override. # iface： '{{ ansible_default_ipv4.interface }}' 5.playbook角色详解 本示例划分了6个角色，包括base-apache、common、db、 haproxy、nagios、web，分别对应6个功能环境部署，根据不同业务场景 的需求，可以随意加、减角色，如将base-apache更换成nginx，然后在 site.yml中引用。 （1）common角色 common的主要功能是部署、配置系统基础服务，包括yum源、安 装nagios插件、NTP服务、iptables、SELinux等，任务（tasks）的定义如 下： 【roles/common/tasks/main.yml】 --- # This role contains common plays that will run on all nodes. - name： Create the repository for EPEL copy： src=epel.repo dest=/etc/yum.repos.d/epel.repo - name： Create the GPG key for EPEL copy： src=RPM-GPG-KEY-EPEL-6 dest=/etc/pki/rpm-gpg - name： install some useful nagios plugins yum： name={{ item }} state=present with_items： - nagios-nrpe - nagios-plugins-swap - nagios-plugins-users - nagios-plugins-procs - nagios-plugins-load - nagios-plugins-disk - name： Install ntp yum： name=ntp state=present tags： ntp - name： Configure ntp file template： src=ntp.conf.j2 dest=/etc/ntp.conf tags： ntp notify： restart ntp - name： Start the ntp service service： name=ntpd state=started enabled=true tags： ntp - name： insert iptables template template： src=iptables.j2 dest=/etc/sysconfig/iptables notify： restart iptables - name： test to see if selinux is running command： getenforce register： sestatus changed_when： false 上述代码定义了两个远程文件复制copy，其中src（源文件）的默 认位置在roles/common/files，使用with_item标签实现循环安装nagios插 件，同时安装ntp服务，引用模块文件 roles/common/templatesntp.conf.j2，且同步到目标主机/etc/ntp.conf位 置。配置系统iptables，引用roles/common/templates/iptables.j2模 板，“notify：restart iptables”，状态或模板发生变化时将通知处理程序 （handlers）来处理。“command：getenforce”运行getenforce来检测 selinux是否在运行状态，“changed_when：false”作用为不记录命令运行 结果的changed状态，即changed为False。 下面定义common角色的处理程序。 【roles/common/handlers/main.yml】 --- # Handlers for common notifications - name： restart ntp service： name=ntpd state=restarted - name： restart iptables service： name=iptables state=restarted 上述代码定义了两个处理程序，功能分别为重启ntp、iptables服 务，其中“name：restart ntp”与任务（tasks）定义中的“notify：restart ntp”是一一对应的，“name：restart iptables”同理。 下面定义了common角色iptables的配置模板： 【roles/common/templates/iptables.j2】 {% if （inventory_hostname in groups['webservers']） or （inventory_hostname in groups['monitoring']） %} -A INPUT -p tcp --dport 80 -j ACCEPT {% endif %} … … {% for host in groups['monitoring'] %} -A INPUT -p tcp -s {{ hostvars[host].ansible_default_ipv4.address }} -- dport 5666 -j ACCEPT {% endfor %} “inventory_hostname”作为存放在Ansible的inventory文件中的主机 名或IP，好处是可以不依靠Facts的主机名参数ansible_hostname或其他 原因，一般情况下inventory_hostname等于ansible_hostname，但有时候 我们习惯在Ansible的inventory中使用IP地址，而ansible_hostname则返回 主机名。模板使用了jinja2的语法，本例if...endif语句判断当前的 inventory_hostname是否在webservers及monitoring组中（定义具体在 hosts文件中），条件成立则添加80端口访问权限（-A INPUT-p tcp--dport 80-j ACCEPT）。For...endfor语句实现了循环开通允许monitoring组主机 访问5666端口，使用hostvars[host]得到主机对象，可以获得主机的Facts 信息，如hostvars[host].ansible_default_ipv4.address获取主机IP。 （2）haproxy角色 haproxy角色主要实现了haproxy平台的部署、配置功能，任务 （tasks）的定义： 【roles/haproxy/tasks】 --- # This role installs HAProxy and configures it. - name： Download and install haproxy and socat yum： name={{ item }} state=present with_items： - haproxy - socat - name： Configure the haproxy cnf file with hosts template： src=haproxy.cfg.j2 dest=/etc/haproxy/haproxy.cfg notify： restart haproxy 任务（tasks）定义了两个功能，一为安装，二为同步配置文件， 安装使用了yum模块，循环安装haproxy、socat两个工具，同时根据配 置参数渲染roles/haproxy/templates/haproxy.cfg.j2模板文件，完成后同步 到目标主机/etc/haproxy/haproxy.cfg位置，状态发生变化时重启haproxy 服务，使之生效。 下面定义了haproxy角色haproxy.cfg的配置模板： 【roles/haproxy/templates/haproxy.cfg.j2】 … … backend app {% for host in groups['lbservers'] %} listen {{ daemonname }} {{ hostvars[host]['ansible_' + iface].ipv4. address }}：{{ listenport }} {% endfor %} balance {{ balance }} {% for host in groups['webservers'] %} server {{ hostvars[host].ansible_hostname }} {{ hostvars[host] ['ansible_' + iface].ipv4.address }}：{{ httpd_port }} {% endfor %} {{hostvars[host]['ansible_'+iface].ipv4.address}}实现了获取网卡名变 量iface（group_vars/lbservers中定义）的IPv4 IP地址。 （3）web角色 web角色主要实现了php、php-mysql、git平台部署及SELinux的配 置功能，任务（tasks）的定义如下： 【roles/web/tasks/main.yml】 --- # httpd is handled by the base-apache role upstream - name： Install php and git yum： name={{ item }} state=present with_items： - php - php-mysql - git - name： Configure SELinux to allow httpd to connect to remote database seboolean： name=httpd_can_network_connect_db state=true persistent=yes when： sestatus.rc ！= 0 - name： Copy the code from repository git： repo={{ repository }} version={{ webapp_version }} dest=/var/www/html/ 判断sestatus变量（roles/common/tasks/main.yml中定义）返回的 rc（运行代码）不等于0（失败）则配置selinux httpd访问远程数据库的 权限，使用的是Ansible的seboolean模块，该条语句等价于命令 行“setsebool httpd_can_network_connect_db 1”，其中“persistent=yes”表 示开机自启动。 （4）nagios角色 nagios角色主要实现了nagios监控平台的部署，重点介绍任务 （tasks）的定义： 【roles/nagios/tasks/main.yml】 … … - name： create the nagios object files template： src={{ item + ".j2" }} dest=/etc/nagios/ansible-managed/{{ item }} with_items： - webservers.cfg - dbservers.cfg - lbservers.cfg notify： restart nagios template分发多个模板文件时可以使用with_items来循环同步，变 量与字符使用“+”号连接（具体见jinja2语法）。 理解以上4个角色的定义后，再理解ansible-examples其他playbook 的内容已经没有太大的困难，本书将不一一说明。 参考提示 ·9.1节YAML语法介绍参考http://zh.wikipedia.org/zh-cn/YAML。 ·9.2节~9.11节Ansible介绍及示例参考http://docs.ansible.com官网文 档。 第10章　集中化管理平台Saltstack详解 Saltstack（http://www.saltstack.com/）是一个服务器基础架构集中 化管理平台，开始于2011年的一个项目，具备配置管理、远程执行、监 控等功能，一般可以理解成简化版的puppet（http://puppetlabs.com/）和 加强版的func（https://fedorahosted.org/func/）。Saltstack基于Python语言 实现，结合轻量级消息队列（ZeroMQ）与Python第三方模块（Pyzmq、 PyCrypto、Pyjinja2、python-msgpack和PyYAML等）构建。Saltstack具 备如下特点。 ·部署简单、方便。 ·支持大部分UNIX/Linux及Windows环境。 ·主从集中化管理。 ·配置简单、功能强大、扩展性强。 ·主控端（master）和被控制端（minion）基于证书认证，安全可 靠。 ·支持API及自定义模块，可通过Python轻松扩展。 通过部署Saltstack环境，我们可以在成千上万台服务器上做到批量 执行命令，根据不同业务特性进行配置集中化管理、分发文件、采集服 务器数据、操作系统基础及软件包管理等，因此，Saltstack是运维人员 提高工作效率、规范业务配置与操作的利器。目前Saltstack已经趋向成 熟，用户群及社区活跃度都不错，同时官方也开放了不少子项目，具体 可访问https://github.com/saltstack获得。 为了方便读者更系统化地了解Saltstack的技术点，本章将针对相关 技术点详细展开介绍。 10.1　Saltstack的安装 Saltstack的不同角色服务安装非常简单，建议读者采用yum源方式 来实现部署，下面介绍具体步骤。 10.1.1　业务环境说明 为了方便读者理解，笔者通过虚拟化环境部署了两组业务功能服 务器来进行演示，操作系统版本为CentOS release 6.4，自带Python 2.6.6。相关服务器信息如表10-1所示（CPU核数及Nginx根目录的差异化 是为方便演示生成动态配置的需要）。 表10-1　环境说明表 10.1.2　安装EPEL 由于目前RHEL官网yum源还没有Saltstack的安装包支持，因此先 安装EPEL作为部署Saltstack的默认yum源。 ·RHEL（CentOS）5版本：rpm-Uvh下载地址： http://mirror.pnl.gov/epel/5/i386/epel-release-5-4.noarch.rpm ·RHEL（CentOS）6版本：rpm-Uvh下载地址： http://ftp.linux.ncsu.edu/pub/epel/6/i386/epel-release-6-8.noarch.rpm 10.1.3　安装Saltstack （1）主服务器安装（主控端） #yum install salt-master -y #chkconfig salt-master on #service salt-master start （2）从服务器安装（被控端） #yum install salt-minion -y #chkconfig salt-minion on #service salt-minion start 10.1.4　Saltstack防火墙配置 在主控端添加TCP 4505、TCP 4506的规则，而在被控端无须配置 防火墙，原理是被控端直接与主控端的zeromq建立长链接，接收广播到 的任务信息并执行，具体操作是添加两条iptables规则： iptables -I INPUT -m state --state new -m tcp -p tcp --dport 4505 -j ACCEPT iptables -I INPUT -m state --state new -m tcp -p tcp --dport 4506 -j ACCEPT 10.1.5　更新Saltstack配置及安装校验 Saltstack分两种角色，一种为master（主控端），另一种为 minion（被控端），安装完毕后需要对两种角色的配置文件进行修改， 下面具体说明。 （1）master主控端配置 1）更新主控端关键项配置： 【/etc/salt/master】 #绑定Master通信IP； interface： 192.168.1.20 #自动认证，避免手动运行salt-key来确认证书信任； auto_accept： True #指定Saltstack文件根目录位置 file_roots： base： - /srv/salt 2）重启saltstack salt-master服务使新配置生效，具体执行以下命 令： #service salt-master restart （2）minion被控端配置 1）更新被控端关键项配置： 【/etc/salt/minion】 #指定master主机IP地址 master： 192.168.1.20 #修改被控端主机识别id，建议使用操作系统主机名来配置 id： SN2013-08-021 2）重启saltstack salt-minion服务使新配置生效，具体执行以下命 令： service salt-minion restart （3）校验安装结果 通过test模块的ping方法，可以确认指定被控端设备与主控端是否 建立信任关系及连通性是否正常，探测所有被控端采用'*'来代 替'SN2013-08-021'即可，具体如图10-1所示。 图10-1　测试安装主机的连通性 提示　当/etc/salt/master没有配置auto_accept：True时，需 要通过salt-key命令来进行证书认证操作，具体操作如下： ·salt-key–L，显示已经或未认证的被控端id，Accepted Keys为已认 证清单，Unaccepted Keys为未认证清单； ·salt-key–D，删除所有认证主机id证书； ·salt-key-d id，删除单个id证书； ·salt-key–A，接受所有id证书请求； ·salt-key-a id，接受单个id证书请求。 10.2　利用Saltstack远程执行命令 Saltstack的一个比较突出优势是具备执行远程命令的功能，操作及 方法与func（https://fedorahosted.org/func/）相似，可以帮助运维人员完 成集中化的操作平台。 命令格式：salt'<操作目标>'<方法>[参数] 示例：查看被控主机的内存使用情况，如图10-2所示。 图10-2　查看“SN2013-08-021”主机内存使用 其中针对<操作目标>，Saltstack提供了多种方法对被控端主机 （id）进行过滤。下面列举常用的具体参数。 1）-E，--pcre，通过正则表达式进行匹配。示例：控测SN2013字 符开头的主机id名是否连通，命令：salt-E'^SN2013.*'test.ping，运行结果 如图10-3所示。 图10-3　正则匹配主机的连通性 2）-L，--list，以主机id名列表的形式进行过滤，格式与Python的 列表相似，即不同主机id名称使用逗号分隔。示例：获取主机id名为 SN2013-08-021、SN2013-08-022；获取完整操作系统发行版名称，命 令：salt-L'SN2013-08-021，SN2013-08-022'grains.item osfullname，运行结 果如图10-4所示。 图10-4　列表形式匹配主机的操作系统类型 3）-G，--grain，根据被控主机的grains（10.4节详解）信息进行匹 配过滤，格式为'：'，例如，过滤内核为 Linux的主机可以写成'kernel：Linux'，如果同时需要正则表达式的支持 可切换成--grain-pcre参数来执行。示例：获取主机发行版本号为6.4的 Python版本号，命令：salt-G'osrelease：6.4'cmd.run'python-V'，运行结果 如图10-5所示。 图10-5　grain形式匹配主机的Python版本 4）-I，--pillar，根据被控主机的pillar（10.5节详解）信息进行匹配 过滤，格式为“对象名称：对象值”，例如，过滤所有具备'apache： httpd'pillar值的主机。示例：探测具有“nginx：root：/data”信息的主机连 通性，命令：salt-I'nginx：root：/data'test.ping，运行结果如图10-6所 示。 图10-6　pillar形式匹配主机的连通性 其中pillar属性配置文件如下（关于pillar后面10.5单独进行说明）： nginx： root： /data 5）-N，--nodegroup，根据主控端master配置文件中的分组名称进 行过滤。以笔者定义的组为例（主机信息支持正则表达式、grain、条件 运算符等），通常根据业务类型划分，不同业务具备相同的特点，包括 部署环境、应用平台、配置文件等。举例分组配置信息如下： 【/etc/salt/master】 nodegroups： web1group： 'L@SN2012-07-010，SN2012-07-011，SN2012-07-012' web2group： 'L@SN2013-08-021，SN2013-08-022' 其中，L@表示后面的主机id格式为列表，即主机id以逗号分隔； G@表示以grain格式描述；S@表示以IP子网或地址格式描述。 示例：探测web2group被控主机的连通性，其命令为：salt-N web2group test.ping，运行结果如图10-7所示。 图10-7　分组形式（nodegroup）匹配主机的连通性 6）-C，--compound，根据条件运算符not、and、or去匹配不同规 则的主机信息。示例：探测SN2013开头并且操作系统版本为CentOS的 主机连通性，命令如下： salt -C 'E@^SN2013.* and G@os：Centos' test.ping 其中，not语句不能作为第一个条件执行，不过可以通过以下方法 来规避，示例：探测非SN2013开头的主机连通性，其命令为：salt- C'*and not E@^SN2013.*'test.ping。 7）-S，--ipcidr，根据被控主机的IP地址或IP子网进行匹配，示例 如下： salt -S 192.168.0.0/16 test.ping salt -S 192.168.1.10 test.ping 10.3　Saltstack常用模块及API Saltstack提供了非常丰富的功能模块，涉及操作系统的基础功能、 常用工具支持等，更多模块信息见官网模块介绍： http://docs.saltstack.com/ref/modules/all/index.html。当然，也可以通过sys 模块列出当前版本支持的模块，如图10-8所示。 图10-8　所有主机Saltstack支持的模块清单（部分截图） 接下来抽取出常见的模块进行介绍，同时也会列举模块API使用方 法。API的原理是通过调用master client模块，实例化一个LocalClient对 象，再调用cmd（）方法来实现的。以下是API实现test.ping的示例： import salt.client client = salt.client.LocalClient（） ret = client.cmd（'*'， 'test.ping'） print ret 结果以一个标准的Python字典形式的字符串返回，可以通过 eval（）函数转换成Python的字典类型，方便后续的业务逻辑处理，程 序运行结果如下： {'SN2013-08-022'： True， 'SN2013-08-021'： True} 提示　将字符字典转换成Python的字典类型，推荐使用ast 模块的literal_eval（）方法，可以过滤表达式中的恶意函数。 （1）Archive模块 1）功能：实现系统层面的压缩包调用，支持gunzip、gzip、rar、 tar、unrar、unzip等。 2）示例： #采用gzunzip解压/tmp/sourcefile.txt.gz包 salt '*' archive.gunzip /tmp/sourcefile.txt.gz #采用gzip压缩/tmp/sourcefile.txt文件 salt '*' archive.gzip /tmp/sourcefile.txt 3）API调用： client.cmd（'*'， ' archive.gunzip'，['/tmp/sourcefile.txt.gz ']） （2）cmd模块 1）功能：实现远程的命令行调用执行（默认具备root操作权限， 使用时需评估风险）。 2）示例： #获取所有被控主机的内存使用情况 salt '*' cmd.run "free -m" #在SN2013-08-021主机运行test.sh脚本，其中script/test.sh存放在file_roots指定的目 录， #该命令会做两个动作：首先同步test.sh到minion的cache目录（如同步到/var/cache/salt/ #minion/files/base/script/test.sh）；其次运行该脚本 'SN2013-08-021' cmd.script salt：//script/test.sh 3）API调用： client.cmd（'SN2013-08-021'， 'cmd.run'，['free -m']） （3）cp模块 1）功能：实现远程文件、目录的复制，以及下载URL文件等操 作。 2）示例： #将指定被控主机的/etc/hosts文件复制到被控主机本地的salt cache目录 （/var/cache/salt/minion/localfiles/）； salt '*' cp.cache_local_file /etc/hosts #将主服务器file_roots指定位置下的目录复制到被控主机 salt '*' cp.get_dir salt：//path/to/dir/ /minion/dest #将主服务器file_roots指定位置下的文件复制到被控主机 salt '*' cp.get_file salt：//path/to/file /minion/dest #下载URL内容到被控主机指定位置 salt '*' cp.get_url http：//www.slashdot.org /tmp/index.html 3）API调用： client.cmd（'SN2013-08-021'， 'cp.get_file'，[' salt：//path/to/file '，' /minion/dest']） （4）cron模块 1）功能：实现被控主机的crontab操作。 2）示例： #查看指定被控主机、root用户的crontab清单 salt 'SN2013-08-022' cron.raw_cron root #为指定的被控主机、root用户添加/usr/local/weekly任务作业 salt 'SN2013-08-022' cron.set_job root '*' '*' '*' '*' 1 /usr/local/weekly #删除指定的被控主机、root用户crontab的/usr/local/weekly任务作业 salt 'SN2013-08-022' cron.rm_job root /usr/local/weekly 3）API调用： client.cmd（'SN2013-08-021'， 'cron.set_job'， ['root'，'*'，'*'，'*'，'*'，'*'，'/usr/echo']） （5）dnsutil模块 1）功能：实现被控主机通用DNS相关操作。 2）示例： #添加指定被控主机hosts的主机配置项 salt '*' dnsutil.hosts_append /etc/hosts 127.0.0.1 ad1.yuk.com， ad2.yuk.com #删除指定被控主机hosts的主机配置项 salt '*' dnsutil.hosts_remove /etc/hosts ad1.yuk.com 3）API调用： client.cmd（'*'， 'dnsutil.hosts_append'， ['/etc/hosts'，'127.0.0.1'，'ad1.yuk.co']） （6）file模块 1）功能：被控主机文件常见操作，包括文件读写、权限、查找、 校验等。 2）示例： #校验所有被控主机/etc/fstab文件的md5是否为6254e84e2f6ffa54e0c8d9cb230f5505，一致 则返回True salt '*' file.check_hash /etc/fstab md5=6254e84e2f6ffa54e0c8d9cb230f5505 #校验所有被控主机文件的加密信息、支持md5、sha1、sha224、sha256、sha384、sha512加密算 法 salt '*' file.get_sum /etc/passwd md5 #修改所有被控主机/etc/passwd文件的属组、用户权限，等价于chown root：root /etc/passwd salt '*' file.chown /etc/passwd root root #复制所有被控主机本地/path/to/src文件到本地的/path/to/dst文件 salt '*' file.copy /path/to/src /path/to/dst #检查所有被控主机/etc目录是否存在，存在则返回True，检查文件是否存在使用 file.file_exists方法 salt '*' file.directory_exists /etc #获取所有被控主机/etc/passwd的stats信息 salt '*' file.stats /etc/passwd #获取所有被控主机/etc/passwd的权限mode，如755、644 salt '*' file.get_mode /etc/passwd #修改所有被控主机/etc/passwd的权限mode为0644 salt '*' file.set_mode /etc/passwd 0644 #在所有被控主机创建/opt/test目录 salt '*' file.mkdir /opt/test #将所有被控主机/etc/httpd/httpd.conf文件的LogLevel参数的warn值修改成info salt '*' file.sed /etc/httpd/httpd.conf 'LogLevel warn' 'LogLevel info' #给所有被控主机的/tmp/test/test.conf文件追加内容"maxclient 100" salt '*' file.append /tmp/test/test.conf "maxclient 100" #删除所有被控主机的/tmp/foo文件 salt '*' file.remove /tmp/foo 3）API调用： client.cmd（'*'， ' file.remove '，['/tmp/foo']） （7）iptables模块 1）功能：被控主机iptables支持。 2）示例： #在所有被控端主机追加（append）、插入（insert）iptables规则，其中INPUT为输入链 salt '*' iptables.append filter INPUT rule='-m state --state RELATED， ESTABLISHED -j ACCEPT' salt '*' iptables.insert filter INPUT position=3 rule='-m state --state RELATED，ESTABLISHED -j ACCEPT' #在所有被控端主机删除指定链编号为3（position=3）或指定存在的规则 salt '*' iptables.delete filter INPUT position=3 salt '*' iptables.delete filter INPUT rule='-m state --state RELATED， ESTABLISHED -j ACCEPT' #保存所有被控端主机规则到本地硬盘（/etc/sysconfig/iptables） salt '*' iptables.save /etc/sysconfig/iptables 3）API调用： client.cmd（'SN2013-08-022'， 'iptables.append'， ['filter'，'INPUT'，'rule=\'-p tcp --sport 80 -j ACCEPT\'']） （8）netwrok模块 1）功能：返回被控主机网络信息。 2）示例： #在指定被控主机'SN2013-08-022'获取dig、ping、traceroute目录域名信息 salt 'SN2013-08-022' network.dig www.qq.com salt 'SN2013-08-022' network.ping www.qq.com salt 'SN2013-08-022' network.traceroute www.qq.com #获取指定被控主机'SN2013-08-022'的MAC地址 salt 'SN2013-08-022' network.hwaddr eth0 #检测指定被控主机'SN2013-08-022'是否属于10.0.0.0/16子网范围，属于则返回True salt 'SN2013-08-022' network.in_subnet 10.0.0.0/16 #获取指定被控主机'SN2013-08-022'的网卡配置信息 salt 'SN2013-08-022' network.interfaces #获取指定被控主机'SN2013-08-022'的IP地址配置信息 salt 'SN2013-08-022' network.ip_addrs #获取指定被控主机'SN2013-08-022'的子网信息 salt 'SN2013-08-022' network.subnets 3）API调用： client.cmd（'SN2013-08-022'， 'network.ip_addrs'） （9）pkg包管理模块 1）功能：被控主机程序包管理，如yum、apt-get等。 2）示例： #为所有被控主机安装PHP环境，根据不同系统发行版调用不同安装工具进行部署，如redhat平台的 yum，等价于yum -y install php salt '*' pkg.install php #卸载所有被控主机的PHP环境 salt '*' pkg.remove php #升级所有被控主机的软件包 salt '*' pkg.upgrade 3）API调用： client.cmd（'SN2013-08-022'， 'pkg.remove'，['php']） （10）Service服务模块 1）功能：被控主机程序包服务管理。 2）示例： #开启（enable）、禁用（disable）nginx开机自启动服务 salt '*' service.enable nginx salt '*' service.disable nginx #针对nginx服务的reload、restart、start、stop、status操作 salt '*' service.reload nginx salt '*' service.restart nginx salt '*' service.start nginx salt '*' service.stop nginx salt '*' service.status nginx 3）API调用： client.cmd（'SN2013-08-022'， 'service.stop'，['nginx']） （11）其他模块 通过上面介绍的10个常用模块，基本上已经覆盖日常运维操作。 Saltstack还提供了user（系统用户模块）、group（系统组模块）、 partition（系统分区模块）、puppet（puppet管理模块）、system（系统 重启、关机模块）、timezone（时区管理模块）、nginx（Nginx管理模 块）、mount（文件系统挂载模块），等等，更多内容见官网介绍： http://docs.saltstack.com/ref/modules/all/index.html#all-salt-modules。当 然，我们也可以通过Python扩展功能模块来满足需求。 10.4　grains组件 grains是Saltstack最重要的组件之一，grains的作用是收集被控主机 的基本信息，这些信息通常都是一些静态类的数据，包括CPU、内核、 操作系统、虚拟化等，在服务器端可以根据这些信息进行灵活定制，管 理员可以利用这些信息对不同业务进行个性化配置。官网提供的用来区 分不同操作系统的示例如下（采用jinja模板）： {% if grains['os'] == 'Ubuntu' %} host： {{ grains['host'] }} {% elif grains['os'] == 'CentOS' %} host： {{ grains['fqdn'] }} {% endif %} 示例中CentOS发行版主机将被“host：{{grains['fqdn']}}”匹配，以 主机SN2013-08-022（centOS 6.4）为例，最终得到“host：SN2013-08- 022”。同时，命令行的匹配操作系统发行版本为CentOS的被控端可以通 过-G参数来过滤，如salt-G'os：CentOS'test.ping。 10.4.1　grains常用操作命令 匹配内核版本为2.6.32-358.14.1.el6.x86_64的主机： salt -G 'kernelrelease：2.6.32-358.14.1.el6.x86_64' cmd.run 'uname -a' 获取所有主机的grains项信息： salt '*' grains.ls 当然，也可以获取主机单项grains数据，如获取操作系统发行版 本，执行命令：salt'SN2013-08-022'grains.item os，结果如图10-9所示。 图10-9　根据grains获取主机操作系统发行版本信息 获取主机id为“SN2013-08-022”的所有grains键及值信息，执行命令 如图10-10所示。 10.4.2　定义grains数据 定义grains数据的方法有两种，其中一种为在被控主机定制配置文 件，另一种是通过主控端扩展模块API实现，区别是模块更灵活，可以 通过Python编程动态定义，而配置文件只适合相对固定的键与值。下面 分别举例说明。 图10-10　获取主机所有grains信息（部分截图） 1.被控端主机定制grains数据 SSH登录一台被控主机，如SN2013-08-022，配置文件定制的路径 为/etc/salt/minion，参数为default_include：minion.d/*.conf，具体操作如 下： 【/etc/salt/minion.d/hostinfo.conf】 grains： roles： - webserver - memcache deployment： datacenter4 cabinet： 13 重启被控主机salt-minion服务，使之生效：service salt-minion restart。验证结果在主控端主机运行：salt'SN2013-08-022'grains.item roles deployment cabinet，观察配置的键与值，如图10-11所示。 图10-11　定制grains数据信息 2.主控端扩展模块定制grains数据 首先在主控端编写Python代码，然后将该Python文件同步到被控 主机，最后刷新生效（即编译Python源码文件成字节码pyc）。在主控 端bash目录（见/etc/salt/master配置文件的file_roots项，默认的base配置 在/srv/salt）下生成_grains目录，执行install-d/srv/salt/_grains开始编写代 码，实现获取被控主机系统允许最大打开文件数（ulimit-n）的grains数 据。 【/srv/salt/_grains/sysprocess.py】 import os，sys，commands def Grains_openfile（）： ''' return os max open file of grains value ''' grains = {} #init default value _open_file=65536 try： getulimit=commands.getstatusoutput（'source /etc/profile；ulimit - n'） except Exception，e： pass if getulimit[0]==0： _open_file=int（getulimit[1]） grains['max_open_file'] = _open_file return grains 上面代码的说明如下。 ·grains_openfile（）定义一个获取最大打开文件数的函数，函数名 称没有要求，符合Python的函数命名规则即可； ·grains={}初始化一个grains字典，变量名一定要用grains，以便 Saltstack识别； ·grains['max_open_file']=_open_file将获取的Linux ulimit-n的结果值 赋予grains['max_open_file']，其中“max_open_file”就是grains的项， _open_file就是grains的值。 最后同步模块到指定被控端主机并刷新生效，因为grains比较适合 采集静态类的数据，比如硬件、内核信息等。当有动态类的功能需求 时，需要提行刷新，具体操作如下： 同步模块salt'SN2013-08-022'saltutil.sync_all，看看“SN2013-08- 022”主机上发生了什么？文件已经同步到minion cache目录中，如下： /var/cache/salt/minion/extmods/grains/grains_openfile.py /var/cache/salt/minion/files/base/_grains/grains_openfile.py /var/cache/salt/minion/extmods/grains/为扩展模块文件最终存放位 置，刷新模块后将在同路径下生成字节码 pyc；/var/cache/salt/minion/files/base/_grains/为临时存放位置。 刷新模块salt'SN2013-08-022'sys.reload_modules，再看看主机发生 了什么变化？在/var/cache/salt/minion/extmods/grains/位置多了一个编译 后的字节码文件grains_openfile.pyc文件，为Python可执行的格式。 /var/cache/salt/minion/extmods/grains/grains_openfile.py /var/cache/salt/minion/extmods/grains/grains_openfile.pyc /var/cache/salt/minion/files/base/_grains/grains_openfile.py 校验结果为可以在主控端查看grains信息，执行salt'SN2013-08- 022'grains.item max_open_file，结果显示“max_open_file：65535”，这就 是前面定制的主机grains信息。 SN2013-08-022： max_open_file： 65535 10.5　pillar组件 pillar也是Saltstack最重要的组件之一，其作用是定义与被控主机相 关的任何数据，定义好的数据可以被其他组件使用，如模板、state、 API等。在pillar中定义的数据与不同业务特性的被控主机相关联，这样 不同被控主机只能看到自己匹配的数据，因此pillar安全性很高，适用于 一些比较敏感的数据，这也是区别于grains最关键的一点，如定义不同 业务组主机的用户id、组id、读写权限、程序包等信息，定义的规范是 采用Python字典形式，即键/值，最上层的键一般为主机的id或组名称。 下面详细描述如何进行pillar的定义和使用。 10.5.1　pillar的定义 1.主配置文件定义 Saltstack默认将主控端配置文件中的所有数据都定义到pillar中，而 且对所有被控主机开放，可通过修改/etc/salt/master配置中的 pillar_opts：Ture或False来定义是否开启或禁用这项功能，修改后执行 salt'*'pillar.data来观察效果。图10-12为pillar_opts：Ture的返回结果，以 主机“SN2013-08-022”为例，执行salt'SN2013-08-022'pillar.data。 图10-12　主机所有pillar信息（部分截图） 2.SLS文件定义 pillar支持在sls文件中定义数据，格式须符合YAML规范，与 Saltstack的state组件十分相似，新人容易将两者混淆，两者文件的配置 格式、入口文件top.sls都是一致的。下面详细介绍pillar使用sls定义的配 置过程。 （1）定义pillar的主目录 修改主配置文件/etc/salt/master的pillar_roots参数，定义pillar的主目 录，格式如下： pillar_roots： base： - /srv/pillar 同时创建pillar目录，执行命令：install-d/srv/pillar。 （2）定义入口文件top.sls 入口文件的作用一般是定义pillar的数据覆盖被控主机的有效域范 围，“*”代表任意主机，其中包括了一个data.sls文件，具体内容如下： 【/srv/pillar/top.sls】 base： '*'： - data 【/srv/pillar/data.sls】 appname： website flow： maxconn： 30000 maxmem： 6G （3）校验pillar 通过查看“N2013-08-022”主机的pillar数据，可以看到多出了data.sls 数据项，原因是我们定义top.sls时使用“*”覆盖了所有主机，这样当查 看“SN2013-08-022”的pillar数据时可以看到我们定义的数据，如图10-13 所示，如果结果不符合预期，可以尝试刷新被控主机pillar数据，运行 salt'*'saltutil.refresh_pillar即可。 图10-13　返回主机pillar的信息 10.5.2　pillar的使用 完成pillar配置后，接下来介绍使用方法。我们可以在state、模板 文件中引用，模板格式为“{{pillar变量}}”，例如： {{ pillar['appname'] }}（一级字典） {{ pillar['flow']['maxconn'] }}（二级字典）或{{ salt['pillar.get']（'flow： 'maxconn'， {}） }} Python API格式如下： pillar['flow']['maxconn'] pillar.get（' flow：appname'， {}） 1.操作目标主机 见10.5.1节，通过-I选项来使用pillar来匹配被控主机： # salt -I 'appname：website' test.ping SN2013-08-021： True SN2013-08-022： True 2.结合grains处理数据的差异性 首先通过结合grains的id信息来区分不同id的maxcpu的值，其次进 行引用观察匹配的信息，延伸“10.5.1 pillar的定义”的例子，将data.sls修 改成如下形式，其中，“if…else…endfi”为jinja2的模板语法，更多信息 请访问jinja2官网语法介绍，网址为 http://jinja.pocoo.org/docs/templates/。 appname： website flow： maxconn： 30000 maxmem： 6G {% if grains['id'] == 'SN2013-08-022' %} maxcpu： 8 {% else %} maxcpu： 4 {% endif %} 通过查看被控主机的pillar数据，可以看到maxcpu的差异，如图10- 14所示。 图10-14　不同主机产生的pillar数据差异 10.6　state介绍 state是Saltstack最核心的功能，通过预先定制好的sls（salt state file）文件对被控主机进行状态管理，支持包括程序包（pkg）、文件 （file）、网络配置（network）、系统服务（service）、系统用户 （user）等，更多状态对象见 http://docs.saltstack.com/ref/states/all/index.html。 10.6.1　state的定义 state的定义是通过sls文件进行描述的，支持YAML语法，定义的规 则如下： $ID： $State： - $state： states 其中： ·$ID，定义state的名称，通常采用与描述的对象保持一致的方法， 如apache、nginx等； ·$State，须管理对象的类型，详见 http://docs.saltstack.com/ref/states/all/index.html； ·$state：states，定制对象的状态。 官网提供的示例如下： 1 apache： 2 pkg： 3 - installed 4 service： 5 - running 6 - require： 7 - pkg： apache 上述代码检查apache软件包是否已安装状态，如果未安装，将通过 yum或apt进行安装；检查服务apache进程是否处于运行状态。下面详细 进行说明： 第1行用于定义state的名称，此示例为apache，当然也可以取其他 相关的名称。 第2行和第4行表示state声明开始，使用了pkg和service这两个状态 对象。pkg使用系统本地的软件包管理器（yum或apt）管理将要安装的 软件，service管理系统守护进程。 第3行和第5行是要执行的方法。这些方法定义了apache软件包和服 务目标状态，此示例要求软件包应当处于已安装状态，服务必须运行， 如未安装将会被安装并启动。 第6行是关键字require，它确保了apache服务只有在成功安装软件 包后才会启动。 注意　require：在运行此state前，先运行依赖的state关系 检查，可配置多个state依赖对象；watch：在检查某个state发生变化时运 行此模块。 10.6.2　state的使用 state的入口文件与pillar一样，文件名称都是top.sls，但state要求sls 文件必须存放在saltstack base定义的目录下，默认为/srv/salt。state描述 配置.sls支持jinjia模板、grains及pillar引用等，在state的逻辑层次定义完 成后，再通过salt'*'state.highstate执行生效。下面扩展10.5.1节定义的范 例，结合grains与pillar，实现一个根据不同操作系统类型部署apache环境 的任务。 1.定义pillar 【/srv/pillar/top.sls】 base： '*'： - apache 在top.sls中引用二级配置有两种方式：一种是直接引用，如本示例 中直接引用apache.sls；另一种是创建apache目录，再引用目录中的 init.sls文件，两者效果是一样的。为了规范起见，笔者建议采用二级配 置形式，同理，state的top.sls也采用如此方式。 #mkidr /srv/pillar/apache #创建apache目录 【/srv/pillar/apache/init.sls】 pkgs： {% if grains['os_family'] == 'Debian' %} apache： apache2 {% elif grains['os_family'] == 'RedHat' %} apache： httpd {% elif grains['os'] == 'Arch' %} apache： apache {% endif %} 测试pillar数据，执行salt'*'pillar.data pkgs，结果返回以下信息，说 明配置已生效。 SN2013-08-021： ---------- pkgs： ---------- apache： httpd 2.定义state 【/srv/salt/top.sls】 base： '*'： - apache 【/srv/salt/apache/init.sls】 apache： pkg： - installed - name： {{ pillar['pkgs']['apache'] }} service.running： - name： {{ pillar['pkgs']['apache'] }} - require： - pkg： {{ pillar['pkgs']['apache'] }} 在配置中，{{pillar['pkgs']['apache']}}将引用匹配到操作系统发行版 对应的pillar数据，笔者的环境为CentOS，故将匹配为httpd，检查目标 主机是否已经安装，没有则进行安装（yum–y install httpd），同时检查 apache服务是否已经启动，没有则启动（/etc/init.d/httpd start）。 3.执行state 执行state及返回结果信息见图10-15。 图10-15　执行state的结果信息 从图10-15中可以看出，结果返回两种对象类型结果，分别为pkg与 service，执行的结果是自动部署apache 2.2.15环境并启动服务。 10.7　示例：基于Saltstack实现的配置集中化管理 本示例实现一个集中化的Nginx配置管理，根据业务不同设备型 号、分区、内核参数的差异化，动态产生适合本机环境的Nginx配置文 件。本示例结合了Saltstack的grains、grains_module、pillar、state、 jinja（template）等组件。 10.7.1　环境说明 具体对照表10-1环境说明表，此处省略。 10.7.2　主控端配置说明 master主配置文件的关键配置项如下： 【/etc/salt/master】（配置片段） nodegroups： web1group： 'L@SN2012-07-010，SN2012-07-011，SN2012-07-012' web2group： 'L@SN2013-08-021，SN2013-08-022' file_roots： base： - /srv/salt pillar_roots： base： - /srv/pillar 定义的pillar、module api、state目录结构，如图10-16所示。 图10-16　示例目录结构 使用Python编写grains_module，实现动态配置被控主机grains的 max_open_file键，值为ulimit–n的结果，以便动态生成Nginx.conf中的 worker_rlimit_nofile、worker_connections参数的值，具体代码如下： import os，sys，commands def NginxGrains（）： ''' return Nginx config grains value ''' grains = {} max_open_file=65536 try： getulimit=commands.getstatusoutput（'source /etc/profile；ulimit - n'） except Exception，e： pass if getulimit[0]==0： max_open_file=int（getulimit[1]） grains['max_open_file'] = max_open_file return grains 代码说明见“10.4.2定义Grains数据”得“主控端扩展模块定制Grains 数据” 同步grains模块，运行： # salt '*' saltutil.sync_all 刷新模块（让minion编译模块），运行： # salt '*' sys.reload_modules 验证max_open_file key的key操作命令见图10-17。 图10-17　校验max_open_file key的key信息 10.7.3　配置pillar 本示例使用分组规则定义pillar，即不同分组引用各自的sls属性， 使用match属性值进行区分，除了属性值为nodegroup外，还支持grain、 pillar等形式。以下是使用grain作为区分条件例子： dev： 'os：Debian'： - match： grain - servers 本示例通过/etc/salt/master中定义好的组信息，如web1group与 web2group与业务组，分别引用web1server.sls与web1server.sls，详 见/srv/pillar/top.sls中的内容： 【/srv/pillar/top.sls】 base： web1group： - match： nodegroup - web1server web2group： - match： nodegroup - web2server 定义私有配置。本示例通过pillar来配置web_root的数据，当然， 也可以根据不同需求进行定制，格式为python字典形式，即"key： value"。 【/srv/pillar/web1server.sls】 nginx： root： /www 【/srv/pillar/web2server.sls】 nginx： root： /data 通过查看不同分组主机的pillar信息来验证配置结果，如图10-18所 示。 图10-18　不同分组的pillar差异信息 10.7.4　配置state 定义入口top.sls： 【/srv/salt/top.sls】 base： '*'： - nginx 下面定义nginx包、服务状态管理配置sls，其中， salt：//nginx/nginx.conf为配置模板文件位置，-enable：True检查服务是 否在开机自启动服务队列中，如果不在则加上，等价于chkconfig nginx on命令“reload：True”，表示服务支持reload操作，不加则会默认执行 restart操作。watch一则检测/etc/nginx/nginx.conf是否发生变化，二则确 保nginx已安装成功。 【/srv/salt/nginx.sls】 nginx： pkg： - installed file.managed： - source： salt：//nginx/nginx.conf - name： /etc/nginx/nginx.conf - user： root - group： root - mode： 644 - template： jinja service.running： - enable： True - reload： True - watch： - file： /etc/nginx/nginx.conf - pkg： nginx 定制Nginx配置文件jinja模板，各参数的引用规则如下： ·worker_processes参数采用grains['num_cpus']上报值（与设备CPU 核数一致）； ·worker_cpu_affinity分配多核CPU，根据当前设备核数进行匹配， 分别为2、4、8、核或其他； ·worker_rlimit_nofile、worker_connections参数理论上为 grains['max_open_file']； ·root参数为定制的pillar['nginx']['root']值。 【/srv/salt/nginx/nginx.conf】 # For more information on configuration， see： user nginx； worker_processes {{ grains['num_cpus'] }}； {% if grains['num_cpus'] == 2 %} worker_cpu_affinity 01 10； {% elif grains['num_cpus'] == 4 %} worker_cpu_affinity 1000 0100 0010 0001； {% elif grains['num_cpus'] >= 8 %} worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000； {% else %} worker_cpu_affinity 1000 0100 0010 0001； {% endif %} worker_rlimit_nofile {{ grains['max_open_file'] }}； error_log /var/log/nginx/error.log； #error_log /var/log/nginx/error.log notice； #error_log /var/log/nginx/error.log info； pid /var/run/nginx.pid； events { worker_connections {{ grains['max_open_file'] }}； } http { include /etc/nginx/mime.types； default_type application/octet-stream； log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'； access_log /var/log/nginx/access.log main； sendfile on； #tcp_nopush on； #keepalive_timeout 0； keepalive_timeout 65； #gzip on； # Load config files from the /etc/nginx/conf.d directory # The default server is in conf.d/default.conf #include /etc/nginx/conf.d/*.conf； server { listen 80 default_server； server_name _； #charset koi8-r； #access_log logs/host.access.log main； location / { root {{ pillar['nginx']['root'] }}； index index.html index.htm； } error_page 404 /404.html； location = /404.html { root /usr/share/nginx/html； } # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html； location = /50x.html { root /usr/share/nginx/html； } } } 执行刷新state配置，结果如图10-19所示。 图10-19　刷新state返回结果（部分截图） 10.7.5　校验结果 登录web1group组的一台服务器，检查Nginx的配置，尤其是变量 部分的参数值，配置片段如下： 【/etc/nginx/nginx.conf】 user nginx； worker_processes 2； worker_cpu_affinity 01 10； worker_rlimit_nofile 65535； error_log /var/log/nginx/error.log； #error_log /var/log/nginx/error.log notice； #error_log /var/log/nginx/error.log info； pid /var/run/nginx.pid； events { worker_connections 65535； } …… location / { root /www； index index.html index.htm； } 再登录web2group组的一台服务器，检查Nginx的配置，对比 web1group组的服务器差异化，包括不同硬件配置、内核参数等，配置 片段如下： 【/etc/nginx/nginx.conf】 user nginx； worker_processes 4； worker_cpu_affinity 1000 0100 0010 0001； worker_rlimit_nofile 65535； error_log /var/log/nginx/error.log； #error_log /var/log/nginx/error.log notice； #error_log /var/log/nginx/error.log info； pid /var/run/nginx.pid； events { worker_connections 65535； } …… location / { root /data； index index.html index.htm； } 至此，一个模拟生产环境Web服务集群的配置集中化管理平台已 经搭建完成，大家可以利用这个思路扩展到其他功能平台。 参考提示　10.1至10.6节的Saltstack介绍可参考官网文档 http://docs.saltstack.com/en/latest/。 第11章　统一网络控制器Func详解 Func（Fedora Unified Network Controller）是由红帽子公司以 Fedora平台构建的统一网络控制器，是为解决集群管理、监控问题而设 计开发的系统管理基础框架，官网地址为https://fedorahosted.org/func。 它是一个能有效简化多服务器系统管理工作的工具，它易于学习、使用 和扩展，功能强大，只需要极少的配置和维护操作。Func分为master和 slave两部分，master为主控端，slave为被控端。Func具有以下特点。 ·支持在主控机上管理任意多台服务器，或任意多个服务器组。 ·支持命令行方式发送远程命令或者远程获取数据。 ·Func通信基于XMLRPC和SSL标准协议，具有模块化的可扩展的 特点。与Saltstack认证方式一致。 ·可以通过Kickstart预安装Func到系统中，自动注册到主控服务器 端。 ·任何人都可以通过Func提供的Python API轻松编写自己的模块， 以实现具体功能扩展。而且任何Func命令行能完成的工作，都能通过 API编程实现。 ·提供封装大量通用的服务器管理命令模块。 ·Func平台没有与数据库关联，不需要复杂的安装与配置，服务器 间安全证书的分发都是自动完成的。 Func与Saltstack在主、被控端建立信任机制是一样的，都采用了证 书+签名的方式。相比Saltstack或Ansible，Func在文件配置、状态管理 方面还是空白，但在远程命令执行、API支持、配置简单等方面还是能 体现出其优势，适合中小型服务集群的远程命令执行、文件分发的工 作，同时API支持跨语言，可以与现有运营平台打通，实现交互式更 强、体验更好的自动化运营平台。 11.1　Func的安装 Func需要在主控端、被控端部署环境，建议读者采用yum的方式 实现部署。目前Func最新版本为0.28，由func、certmaster、pyOpenSSL 三个组件组成。下面详细讲解Func的安装步骤。 11.1.1　业务环境说明 为了方便读者理解，笔者通过虚拟化环境部署功能服务器来进行 演示，操作系统版本为CentOS release 6.4，自带Python 2.6.6。相关服务 器信息如表11-1所示。 表11-1　业务环境表说明 11.1.2　安装Func 1.主控端服务器安装 主控端部署在主机名为SN2013-08-020的设备上，通过yum方式安 装，如下： # yum install func –y # /sbin/chkconfig --level 345 certmaster on 在设备通信上Func要求使用主机名来识别，在没有内部域名解析 服务的情况下，可通过配置主机hosts来解决主机名的问题。主控端 hosts配置如下： 【/etc/hosts】 192.168.1.21 SN2013-08-021 192.168.1.22 SN2013-08-022 192.168.1.20 func.master.server.com 修改/etc/certmaster/minion.conf的certmaster参数，指向证书服务 器，即主控端服务器，func命令用到此配置，如： 【/etc/certmaster/minion.conf】 # configuration for minions [main] certmaster = func.master.server.com certmaster_port = 51235 log_level = DEBUG cert_dir = /etc/pki/certmaster 启动证书服务： # /sbin/service certmaster start 配置iptables，开通192.168.1.0/24网段访问证书服务 51235（certmaster服务）端口。 # iptables -I INPUT -s 192.168.1.0/24 -p tcp --dport 51235 -j ACCEPT 至此，主控端配置完毕。 2.被控端服务器安装 被控端部署在主机名为SN2013-08-021、SN2013-08-022的设备上， 同样通过yum方式安装，如下： # yum install func –y # /sbin/chkconfig --level 345 funcd on 配置hosts信息： 192.168.1.20 func.master.server.com 修改/etc/certmaster/minion.conf的certmaster参数，以便指向证书服 务器发出签名请求，建立信任关系，如： 【/etc/certmaster/minion.conf】 # configuration for minions [main] certmaster = func.master.server.com certmaster_port = 51235 log_level = DEBUG cert_dir = /etc/pki/certmaster 修改/etc/func/minion.conf的minion_name参数，作为被控主机的唯 一标识，一般使用主机名，以SN2013-08-021主机为例，配置如下： # configuration for minions [main] log_level = INFO acl_dir = /etc/func/minion-acl.d listen_addr = listen_port = 51234 minion_name = SN2013-08-021 method_log_dir = /var/log/func/methods/ 启动func服务： # /sbin/service funcd start 配置iptables，开通192.168.1.20主控端主机访问本机51234（func服 务）端口。 # iptables -I INPUT -s 192.168.1.20 -p tcp --dport 51234 -j ACCEPT 至此，被控端配置完毕。 3.证书签名 在主控端运行certmaster-ca--list获取当前请求证书签名的主机清 单，如： # certmaster-ca --list sn2013-08-021 sn2013-08-022 证书签名通过certmaster-ca--sign hostname命令来完成，如： # certmaster-ca --sign sn2013-08-021 当然，也可以结合--list、--sign参数实现一键完成所有主机的签名 操作，如： # certmaster-ca --sign `certmaster-ca --list` Func也提供了类似Saltstack自动签名的机制，通过修 改/etc/certmaster/certmaster.conf的参数autosign=no为autosign=yes即可。 使用func"*"list_minions查看已经完成签名的主机名，如： # func '*' list_minions sn2013-08-021 sn2013-08-022 删除（注销）签名主机使用certmaster-ca-c hostname，如： # certmaster-ca -c sn2013-08-021 校验安装、任务签名是否正确，通过func"*"ping命令来测试，如 图11-1所示。 图11-1　测试认证主机的连通性 提示　对已注销的被控服务器，要重新注册，先删除被控 主机端/etc/pki/certmaster/下的证书文件，再运3行certmaster-request进行 证书请求，具体操作步骤如下： # rm -rf /etc/pki/certmaster/主机名.* # /usr/bin/certmaster-request 11.2　Func常用模块及API Func提供了非常丰富的功能模块，包括CommandModule（执行命 令）、CopyFileModule（拷贝文件）、CpuModule（CPU信息）、 DiskModule（磁盘信息）、FileTrackerModule（文件跟踪）、 IPtablesModule（iptables管理）、MountModule（Mount挂载）、 NagiosServerModule（Nagios管理）、NetworkTest（网络测试）、 ProcessModule（进程管理）、SysctlModule（sysctl管理）、 SNMPModule（SNMP信息），等等，更多模块介绍见官网模块介绍： https://fedorahosted.org/func/wiki/ModulesList。命令行调用模块格式： func<目标主机>call 模块命令行执行结果都以Python的元组字符串返回（API以字典形 式返回），这对后续进行结果集的解析工作非常有利，例如，远程运 行“df-m”命令的运行结果如图11-2所示。 图11-2　返回主机内存使用信息 在所有模块中，CommandModule模块最常用，可以在目标被控主 机执行任意命令。笔者建议使用API方式对应用场景的逻辑进行封装， 将权限放到一个预先定制好的方框中，实现收敛操作。下面对Func常用 的模块一一进行讲解。 11.2.1　选择目标主机 Func选择目标主机操作对象支持“*”与“？”方式匹配，其中“*”代 表任意多个字符，“？”代表单个任意字符，例如： # func "SN2013-*-02？" call command run "uptime" “SN2013-*-02？”在本文环境中将匹配到SN2013-08-021、SN2013- 08-022两台主机，可以根据实际应用场景随意组合。例如，我们定义的 多台Web业务服务器主机名分别为：web1、web2、web3、…、 webn.webapp.com，要查看所有Web应用的uptime信息可以运行： # func "web*.webapp.com" call command run "uptime" 多个目标主机名使用分号分隔，如： # func "web.example.org；mailserver.example.org；db.example.org" call command run "df -m" 11.2.2　常用模块详解 1.执行命令模块 （1）功能 CommandModule实现Linux远程命令调用执行。 （2）命令行模式 # func "*" call command run "ulimit -a" # func "SN2013-08-022" call command run "free -m" （3）API模式 import func.overlord.client as func client = func.Client（"SN2013-08-022"） print client.command.run（"free -m"） 2.文件拷贝模块 （1）功能 CopyFileModule实现主控端向目标主机拷贝文件，类似于scp的功 能。 （2）命令行模式 # func "SN2013-08-022" copyfile -f /etc/sysctl.conf --remotepath /etc/sysctl.conf （3）API模式 import func.overlord.client as func client = func.Client（"SN2013-08-022"） client.local.copyfile.send（"/etc/sysctl.conf"，"/tmp/sysctl.conf"） 3.CPU信息模块 （1）功能 CpuModule获取远程主机CPU信息，支持按时间（秒）采样平均 值，如下面示例中的参数“10”。 （2）命令行模式 # func "SN2013-08-022" call cpu usage # func "SN2013-08-022" call cpu usage 10 （3）API模式 import func.overlord.client as func client = func.Client（"SN2013-08-022"） print client.cpu.usage（10） 4.磁盘信息模块 （1）功能 DiskModule实现获取远程主机的磁盘分区信息，参数为分区标 签，如/data分区。 （2）命令行模式 # func "SN2013-08-022" call disk usage # func "SN2013-08-022" call disk usage /data （3）API模式 import func.overlord.client as func client = func.Client（"SN2013-08-022"） print client.disk.usage（"/dev/sda3"） 5.拷贝远程文件模块 （1）功能 GetFileModule实现拉取远程Linux主机指定文件到主控端目录，不 支持命令行模式。 （2）API模式 import func.overlord.client as func client = func.Client（"SN2013-08-022"） client.local.getfile.get（"/etc/sysctl.conf"，"/tmp/"） 6.iptables管理模块 （1）功能 IPtablesModule实现远程主机iptables配置。 （2）命令行模式 # func "SN2013-08-022" call iptables.port drop_to 53 192.168.0.0/24 udp src # func "SN2013-08-022" call iptables drop_from 192.168.0.10 （3）API模式 import func.overlord.client as func client = func.Client（"SN2013-08-022"） client.iptables.port.drop_to（8080， "192.168.0.10"， "tcp"， "dst"） 7.系统硬件信息模块 （1）功能 HardwareModule返回远程主机系统硬件信息。 （2）命令行模式 # func "SN2013-08-022" call hardware info # func "SN2013-08-022" call hardware hal_info （3）API模式 import func.overlord.client as func client = func.Client（"SN2013-08-022"） print client.hardware.info（with_devices=True） print client.hardware.hal_info（） 8.系统Mount管理模块 （1）功能 MountModule实现远程主机Linux系统挂载、卸载分区管理。 （2）命令行模式 # func "SN2013-08-022" call mount list # func "SN2013-08-022" call mount mount /dev/sda3 /data #　func "SN2013-08-022" call mount umount "/data" （3）API模式 import func.overlord.client as func client = func.Client（"SN2013-08-022"） print client.mount.list（） print client.mount.umount（"/data"） print client.mount.mount（"/dev/sda3"，"/data"） 9.系统进程管理模块 （1）功能 ProcessModule实现远程Linux主机进程管理。 （2）命令行模式 # func "SN2013-08-022" call process info "aux" # func "SN2013-08-022" call process pkill nginx -9 # func "SN2013-08-022" call process kill nginx SIGHUP （3）API模式 import func.overlord.client as func client = func.Client（"SN2013-08-022"） print client.process.info（"aux"） print client.process.pkill（"nginx"， "-9"） print client.process.kill（"nginx"， "SIGHUP"） 10.系统服务管理模块 （1）功能 ServiceModule实现远程Linux主机系统服务管理。 （2）命令行模式 # func "SN2013-08-022" call service start nginx （3）API模式 import func.overlord.client as func client = func.Client（"SN2013-08-022"） print client.service.start（"nginx"） 11.系统内核参数管理模块 （1）功能 SysctlModule实现远程Linux主机系统内核参数管理。 （2）命令行模式 # func "SN2013-08-022" call sysctl list # func "SN2013-08-022" call sysctl get net.nf_conntrack_max # func "SN2013-08-022" call sysctl set net.nf_conntrack_max 15449 （3）API模式 import func.overlord.client as func client = func.Client（"SN2013-08-022"） print client.sysctl.list（） print client.sysctl.get（'net.ipv4.icmp_echo_ignore_broadcasts'） print client.sysctl.set（'net.ipv4.tcp_syncookies'， 1） func命令功能参数举例： 1）查看所有主机uptime，开启5个线程异步运行，超时时间为3 秒，命令如下： # func -t 3 "*" call --forks="5" --async command run "/usr/bin/uptime" 2）格式化输出结果，默认格式为Python的元组，分别添加--jsion 或--xml来输出JSON及XML格式，命令如下： # func -t 3 "*" call --forks="5" --json --async command run "/usr/bin/uptime" 11.3　自定义Func模块 Func自带的模块已经非常丰富，但在日常系统运维当中，尤其是 面对大规模的服务器集群、不同类别的业务平台，此时Func自带的模块 或许已经不能满足我们的需求，所以有必要通过自定模块来填补这块的 不足。本节介绍一个简单的Func自定义模块的，通过采用Func自带的建 模块工具func-create-module来现实。 （1）自定义模块步骤 如图11-3所示，自定义模块分为四个步骤进行，第一步生成模块， 即通过fun-create-module命令创建模块初始模板；第二步编写逻辑，即 填充我们的业务功能逻辑，生成模块；第三步分发模块，将编写完成的 模块分发到所有被控主机；第四步执行已经分发完成的模块，调用方法 与Func自带模块无差异。详细过程见图11-3。 图11-3　自定义模块发布流程 （2）生成模块 切换到Func安装包minion模块存储目录。笔者使用的是系统自带 的Python 2.6，具体路径为/usr/lib/python2.6/site- packages/func/minion/modules。 # cd /usr/lib/python2.6/site-packages/func/minion/modules 运行创建模块命令func-create-module，根据图11-14填写相关信 息。 图11-4　创建模块时填写的信息 最终生成了一个初始化的模块代码文件mymodule.py： 【/usr/lib/python2.6/site- packages/func/minion/modules/mymodule.py】 # # Copyright 2014 # liutiansi # # This software may be freely redistributed under the terms of the GNU # general public license. # # You should have received a copy of the GNU General Public License # along with this program； if not， write to the Free Software # Foundation， Inc.， 675 Mass Ave， Cambridge， MA 02139， USA. import func_module class Mymodule（func_module.FuncModule）： # Update these if need be. version = "0.0.1" api_version = "0.0.1" description = "My module for func." def echo（self）： """ TODO： Document me ... """ pass （3）编写逻辑 这一步只需在上述模块基础上做修改即可，如模块实现一个根据 指定的条数返回最新系统日志（/var/log/messages）信息，修改后的代码 如下： 【/usr/lib/python2.6/site- packages/func/minion/modules/mymodule.py】 # # Copyright 2010 # liutiansi # # This software may be freely redistributed under the terms of the GNU # general public license. # # You should have received a copy of the GNU General Public License # along with this program； if not， write to the Free Software # Foundation， Inc.， 675 Mass Ave， Cambridge， MA 02139， USA. import func_module from func.minion import sub_process class Mymodule（func_module.FuncModule）： # Update these if need be. version = "0.0.1" api_version = "0.0.1" description = "My module for func." def echo（self，vcount）： """ TODO： response system messages info """ command="/usr/bin/tail -n "+str（vcount）+" /var/log/messages" cmdref = sub_process.Popen（command， stdout=sub_process.PIPE， stderr=sub_process.PIPE， shell=True， close_fds=True） data = cmdref.communicate（） return （cmdref.returncode， data[0]， data[1]） （4）分发模块 首先编写分发模块的功能，使用Func的copyfile模块来实现，原理 比较简单，即读取主控端func minion包下的模块文件（参数传入），通 过Func的copyfile模块同步到目标主机的同路径下。一次编写可持续使 用，源码如下： 【/home/test/func/RsyncModule.py】 #！/usr/bin/python import sys import func.overlord.client as fc import xmlrpclib module = sys.argv[1] pythonmodulepath="/usr/lib/python2.6/site-packages/func/minion/modules/" client = fc.Client（"*"） fb = file（pythonmodulepath+module， "r"）.read（） data = xmlrpclib.Binary（fb） #分发模块 print client.copyfile.copyfile（pythonmodulepath+ module，data） #重启Func服务 print client.command.run（"/etc/init.d/funcd restart"） 分发模块的运行结果如图11-5所示。 图11-5　模块分发结果 检查被控主机/usr/lib/python2.6/site-packages/func/minion/modules目 录是否多了一个mymodule.py文件，是则说明模块已经成功分发。 （5）执行模块 最后，执行模块及返回结果见图11-6。 图11-6　执行模块结果 正常返回了5条/var/log/messages信息，完成了自定义模块的全过 程。 11.4　非Python API接口支持 Func通过非Python API实现远程调用，目的是为第三方工具提供调 用及返回接口。Func使用func-transmit命令来实现，支持YAML与JSON 格式，实现了跨应用平台、语言、工具等，比如通过Java或C生成JSON 格式的接口定义，通过fun-transmit命令进行调用，使用上非常简单，扩 展性也非常强。 定义一个command模块的远程执行，分别采用YAML及JSON格式 进行定义，如下： 【/home/test/func/run.yaml】 clients： "*" async： False nforks： 1 module： command method： run parameters： "/bin/echo Hello World" 【/home/test/func/run.json】 { "clients"： "*"， "async"： "False"， "nforks"： 1， "module"： "command"， "method"： "run"， "parameters"： "/bin/echo Hello World" } 各参数详细说明如下。 ·clients，目标主机，"*"代表所有被控主机； ·async，是否异步，是一个布尔值，True为使用异步，False则不使 用； ·nforks，启用的线程数，用数字表示； ·module，模块名称，如command、copyfile、process等； ·method，方法名称，如command模块下的run方法； ·parameters，参数，如"/usr/bin/tail-100/var/log/messages"。 通过func-transmit命令调用不同接口配置，将返回不同的格式串， 如图11-7和图11-8所示。 图11-7　返回标准的YAML格式 图11-8　返回标准的JSON格式 返回的两种格式都可以被绝大部分语言所解析，方便后续处理。 11.5　Func的Facts支持 Facts是一个非常有用的组件，其功能类似于Saltstack的grains、 Ansible的Facts，实现获取远程主机的系统信息，以便在对目标主机操作 时作为条件进行过滤，产生差异。Func的Facts支持通过API来扩展用户 自己的属性。Facts由两部分组成，一为模块（module），另为方法 （method），可通过list_fact_modules、list_fact_methods方法来查看当 前支持的模块与方法的清单，如图11-9所示。 图11-9　查看主机支持模块及方法 在使用Facts时，我们关注它的方法（func"*"call fact list_fact_methods显示的清单）即可，可通过命令行调用Facts的call_fact 方法查看所有主机的操作系统信息，具体见图11-10。 图11-10　查看主机操作系统信息 Fact支持and与or作为条件表达式连接操作符，下面详细介绍。 （1）and表达式--filter 语法： --filter "keyword[operator]value，keyword2[operator]value2" --filter "value in keyword，value ini keyword" 示例：所有满足内核（kernel）版本大于或等于2.6，并且操作系统 信息包含CentOS的目标主机运行uptime命令，如图11-11所示。 图11-11　根据fact条件（and）过滤主机 （2）or表达式--filteror 语法： --filteror "keyword[operator]value，keyword2[operator]value2" --filteror "value in keyword，value ini keyword" 示例：所有满足内核（kernel）版本大于或等于2.6，或者运行级别 等于5的目标主机运行df-m命令，如图11-12所示。 图11-12　根据fact条件（or）过滤主机 参考提示　11.1节~11.5节关于Func的介绍参考官网文档 https://fedorahosted.org/func/。 第12章　Python大数据应用详解 随着云时代的到来，大数据（big data）也越来越受大家的关注， 比如互联网行业日常生成的运营、用户行为数据，随着时间及访问量的 增长这一规模日益庞大，单位可达到日TB或PB级别。如何在如此庞大 的数据中挖掘出对我们有用的信息？目前业界主流存储与分析平台是以 Hadoop为主的开源生态圈，MapReduce作为Hadoop的数据集的并行运 算模型，除了提供Java编写MapReduce任务外，还兼容了Streaming方 式，我们可以使用任意脚本语言来编写MapReduce任务，优点是开发简 单且灵活。本章详细介绍如何使用Python语言来实现大数据应用，将分 别通过原生Python与框架（Framework）方式进行说明。 提示　因为Hadoop不作为本章的主体内容，所以将不对其 架构、子项目、优化等进行说明。 12.1　环境说明 为了方便读者理解，笔者通过虚拟化环境部署了Hadoop平台来进 行演示，操作系统版本为CentOS release 6.4，以及Python 2.6.6、hadoop- 1.2.1、jdk1.6.0_45、mrjob-0.4.2等。相关服务器信息如表12-1所示。 表12-1　环境说明表 12.2　Hadoop部署 由于部署Hadoop需要Master访问所有Salve主机实现无密码登录， 即配置账号公钥认证，具体参考9.2.5节关于配置Linux主机SSH无密码访 问的介绍，本节将不再陈述。 （1）安装 SSH登录Master主机，这里使用root账号进行相关演示。安装JDK 环境： # mkdir –p /usr/java/ && cd /usr/java # wget http：//uni-smr.ac.ru/archive/dev/java/SDKs/sun/j2se/6/jdk-6u45- linux-x64.bin # chmod +x jdk-6u45-linux-x64.bin # ./jdk-6u45-linux-x64.bin # vi /etc/profile （配置Java环境变量，追加以下内容） export JAVA_HOME=/usr/java/jdk1.6.0_45 export PATH=$PATH：$JAVA_HOME/bin export CLASSPATH=.：$JAVA_HOME/jre/lib：$JAVA_HOME/lib： $JAVA_HOME/lib/tools.jar # cd /etc （使环境变量生效） # . profile 安装Hadoop，版本为1.2.1，安装路径为/usr/local。 # cd /usr/local # wget http：//mirrors.cnnic.cn/apache/hadoop/common/hadoop-1.2.1/hadoop- 1.2.1.tar.gz # tar –zxvf hadoop-1.2.1.tar.gz # cd /usr/local/hadoop-1.2.1/conf 修改目录（/usr/local/hadoop-1.2.1/conf）中的四个Hadoop核心配置 文件hadoop-env.sh、core-site.xml、hdfs-site.xml、mapred-site.xml，具体 内容如下： ·hadoop-env.sh，Hadoop环境变量配置文件，指定JAVA_HOME。 export JAVA_HOME=/usr/java/jdk1.6.0_45 ·core-site.xml，Hadoop core的配置项，主要针对Common组件的属 性配置。由于默认的hadoop.tmp.dir的路径为/tmp/hadoop-${user.name}， 笔者的Linux系统的/tmp文件系统的类型是Hadoop不支持的，会 报“File/tmp//input/conf/slaves could only be replicated to 0 nodes，instead of 1”异常，因此手工修改hadoop.tmp.dir指向/data/tmp/hadoop- ${user.name}，作为Hadoop用户的临时存储目录，配置如下： hadoop.tmp.dir /data/tmp/hadoop-${user.name} fs.default.name hdfs：//192.168.1.20：9000 //master主机IP：9000端口 ·hdfs-site.xml，Hadoop的HDFS组件的配置项，包括Namenode、 Secondarynamenode和Datanode等，配置如下： dfs.name.dir /data/hdfs/name //Namenode持久存储名字空间、事务日志路径 dfs.data.dir /data/hdfs/data //Datanode数据存储路径 dfs.datanode.max.xcievers 4096 //Datanode所允许同时执行的发送和接受任务数量，默认为256 dfs.replication 2 //数据备份的个数，默认为3 ·mapred-site.xml，配置map-reduce组件的属性，包括jobtracker和 tasktracker，配置如下： mapred.job.tracker 192.168.1.20：9001 ·masters，配置Secondarynamenode项，环境使用主设备 192.168.1.20同时承担Secondarynamenode的角色，生产环境要求使用独 立服务器，起到HDFS文件系统元数据（metadata）信息的备份作用，当 NameNode发生故障后可以快速还原数据，配置内容如下： 192.168.1.20 ·slaves，配置所有Slave主机信息，填写IP地址即可。本示例中 Slave的信息如下： 192.168.1.21 192.168.1.22 接下来，从主节点（Master）复制jdk及Hadoop环境到所有Slave， 目标路径要与Master保持一致，切记！执行以下命令进行复制： # ssh root@192.168.1.21 '[ -d /usr/java ] || mkdir -p /usr/java ]' # ssh root@192.168.1.22 '[ -d /usr/java ] || mkdir -p /usr/java ]' # scp -r /usr/java/jdk1.6.0_45 root@192.168.1.21：/usr/java # scp -r /usr/java/jdk1.6.0_45 root@192.168.1.22：/usr/java # scp -r /usr/local/hadoop-1.2.1 root@192.168.1.21：/usr/local # scp -r /usr/local/hadoop-1.2.1 root@192.168.1.22：/usr/local Hadoop部分功能是通过主机名来寻址的，因此需要配置主机名 hosts信息（生产环境建议直接搭建内网DNS服务），保证Hadooop环境 所有主机的/etc/hosts文件配置如下： 192.168.1.20 SN2013-08-020 192.168.1.21 SN2013-08-021 192.168.1.22 SN2013-08-022 管理员通过浏览器查看datanode信息，需要配置本地hosts，如 Windows 7系统hosts文件路径为C:\Windows\System32\drivers\etc，添加 所有datanode主机信息，如下： 192.168.1.21 SN2013-08-021 192.168.1.22 SN2013-08-022 如设备启用了iptables防火墙，需要对主节点（Master）及Slave主 机添加以下规则： Master： iptables -I INPUT -s 192.168.1.0/24 -p tcp --dport 50030 -j ACCEPT iptables -I INPUT -s 192.168.1.0/24 -p tcp --dport 50070 -j ACCEPT iptables -I INPUT -s 192.168.1.0/24 -p tcp --dport 9000 -j ACCEPT iptables -I INPUT -s 192.168.1.0/24 -p tcp --dport 9001 -j ACCEPT Slaves： iptables -I INPUT -s 192.168.1.0/24 -p tcp --dport 50075 -j ACCEPT iptables -I INPUT -s 192.168.1.0/24 -p tcp --dport 50060 -j ACCEPT iptables -I INPUT -s 192.168.1.20 -p tcp --dport 50010 -j ACCEPT 配置完成后在主节点（Master）上格式化文件系统的namenode， 执行： # cd /usr/local/hadoop-1.2.1 # bin/hadoop namenode -format 最后，在主节点（Master）上执行启动命令，如下： # bin/start-all.sh （2）检验安装结果 Hadoop官方提供的一个测试MapReduce的示例，执行： # bin/hadoop jar hadoop-examples-1.2.1.jar pi 10 100 如果返回如图12-1所示结果，则说明配置成功。 图12-1　计算pi的测试结果（部分截图） 访问Hadoop提供的管理页面，Map/Reduce管理地址： http://192.168.1.20：50030/，如图12-2所示。 图12-2　Map/Reduce管理界面（部分截图） HDFS存储管理地址：http://192.168.1.20：50070/，如图12-3所示。 图12-3　HDFS管理界面（部分截图） 12.3　使用Python编写MapReduce Map与Reduce为两个独立函数，为了加快各节点的处理速度，使 用并行的计算方式，map运算的结果再由reduce继续进行合并。例如， 要统计图书馆有多少本书籍，首先一人一排进行统计（map），其次将 每个人的统计结果进行汇总（reduce），最终得出总数。Hadoop除了提 供原生态的Java来编写MapReduce任务，还提供了其他语言操作的API ——Hadoop Streaming，它通过使用标准的输入与输出来实现map与 reduce之前传递数据，映射到Python中便是sys.stdin输入数据、sys.stdout 输出数据。其他业务逻辑也直接在Python中编写。 下面实现一个统计文本文件（/home/test/hadoop/input.txt）中所有 单词出现的词频功能，分别使用原生Python与框架方式来编写 mapreduce。文本文件内容如下： 【/home/test/hadoop/input.txt】 foo foo quux labs foo bar quux abc bar see you by test welcome test abc labs foo me python hadoop ab ac bc bec python 12.3.1　用原生Python编写MapReduce详解 （1）编写Map代码 见下面的mapper.py代码，它会从标准输入（stdin）读取数据，默 认以空格分割单词，然后按行输出单词及其词频到标准输出 （stdout），不过整个Map处理过程并不会统计每个单词出现的总次 数，而是直接输出“word 1”，以便作为Reduce的输入进行统计，要求 mapper.py具备可执行权限，执行chmod+x/home/test/hadoop/mapper.py。 【/home/test/hadoop/mapper.py】 #！/usr/bin/env python import sys #输入为标准输入stdin； for line in sys.stdin： #删除开头和结尾的空格； line = line.strip（） #以默认空格分隔行单词到words列表； words = line.split（） for word in words： #输出所有单词，格式为“单词，1”以便作为Reduce的输入； print '%s\t%s' % （word， 1） （2）编写Reduce代码 见下面的reducer.py代码，它会从标准输入（stdin）读取mapper.py 的结果，然后统计每个单词出现的总次数并输出到标准输出 （stdout），要求reducer.py同样具备可执行权限，执行 chmod+x/home/test/hadoop/reducer.py。 【/home/test/hadoop/reducer.py】 #！/usr/bin/env python from operator import itemgetter import sys current_word = None current_count = 0 word = None # 获取标准输入，即mapper.py的输出； for line in sys.stdin： #删除开头和结尾的空格； line = line.strip（） # 解析mapper.py输出作为程序的输入，以tab作为分隔符； word， count = line.split（'\t'， 1） # 转换count从字符型成整型； try： count = int（count） except ValueError： # count非数字时，忽略此行； continue # 要求mapper.py的输出做排序（sort）操作，以便对连续的word做判断； if current_word == word： current_count += count else： if current_word： # 输出当前word统计结果到标准输出 print '%s\t%s' % （current_word， current_count） current_count = count current_word = word # 输出最后一个word统计 if current_word == word： print '%s\t%s' % （current_word， current_count） （3）测试代码 我们可以在Hadoop平台运行之前在本地进行测试，校验mapper.py 与reducer.py运行的结果是否正确，测试结果如图12-4所示。 测试reducer.py时需要对mapper.py的输出做排序（sort）操作，当 然，Hadoop环境会自动实现排序，如图12-5所示。 （4）在Hadoop平台运行代码 首先在HDFS上创建文本文件存储目录，本示例中 为/user/root/word，运行命令： # /usr/local/hadoop-1.2.1/bin/hadoop dfs -mkdir /user/root/word 上传文件至HDFS，本示例中为/home/test/hadoop/input.txt，如果有 多个文件，可采用以下方法进行操作，因为Hadoop分析目标默认针对 目录，目录下的文件都在运算范围中。 # /usr/local/hadoop-1.2.1/bin/hadoop fs –put /home/test/hadoop/input.txt /user/root/word/ # /usr/local/hadoop-1.2.1/bin/hadoop dfs -ls /user/root/word/ Found 1 items -rw-r--r-- 2 root supergroup 118 2014-02-10 09：49 /user/root/word/input.txt 图12-4　mapper执行结果（部分截图） 图12-5　reducer执行结果 下一步便是关键的执行MapReduce任务了，输出结果文件指 定/output/word，执行以下命令： # /usr/local/hadoop-1.2.1/bin/hadoop jar /usr/local/hadoop- 1.2.1/contrib/streaming/hadoop-streaming-1.2.1.jar -file ./mapper.py - mapper ./mapper.py -file ./reducer.py -reducer ./reducer.py -input /user/root/word -output /output/word 图12-6为返回的执行结果，可以看到map及reduce计算的百分比进 度。 图12-6　执行MapReduce任务结果 访问http://192.168.1.20：50030/jobtracker.jsp，点击生成的Jobid，查 看mapreduce job信息，如图12-7所示。 图12-7　Web查看mapreduce job信息（部分截图） 查看生成的分析结果文件清单，其中/output/word/part-00000为分 析结果文件，如图12-8所示。 图12-8　任务输出文件清单 最后查看结果数据，图12-9显示了单词个数统计的结果，整个分析 过程结束。 图12-9　查看结果文件part-00000内容 提示　HDFS常用操作命令有： 1）创建目录，示例：bin/hadoop dfs-mkdir/data/root/test。 2）列出目录清单，示例：bin/hadoop dfs-ls/data/root。 3）删除文件或目录，示例：bin/hadoop fs-rmr/data/root/test。 4）上传文件，示例：bin/hadoop fs- put/home/test/hadoop/*.txt/data/root/test。 5）查看文件内容，示例：bin/hadoop dfs-cat/output/word/part- 00000。 12.3.2　用Mrjob框架编写MapReduce详解 Mrjob（http://pythonhosted.org/mrjob/index.html）是一个编写 MapReduce任务的开源Python框架，它实际上对Hadoop Streaming的命 令行进行了封装，因此接触不到Hadoop的数据流命令行，使我们可以 更轻松、快速编写MapReduce任务。Mrjob具有如下特点。 1）代码简洁，map及reduce函数通过一个Python文件就可以搞 定； 2）支持多步骤的MapReduce任务工作流； 3）支持多种运行方式，包括内嵌方式、本地环境、Hadoop、远程 亚马逊； 4）支持亚马逊网络数据分析服务Elastic MapReduce（EMR）； 5）调试方便，无须任何环境支持。 安装Mrjob要求环境为Python 2.5及以上版本，源码下载地址： https://github.com/yelp/mrjob。 # pip install mrjob #PyPI安装方式 # python setup.py install #源码安装方式 回到实现一个统计文本文件（/home/test/hadoop/input.txt）中所有 单词出现的词频功能，Mrjob通过mapper（）与reducer（）方法实现了 MR操作，实现代码如下： 【/home/test/hadoop/word_count.py】 from mrjob.job import MRJob class MRWordCounter（MRJob）： def mapper（self， key， line）： for word in line.split（）： yield word， 1 def reducer（self， word， occurrences）： yield word， sum（occurrences） if __name__ == '__main__'： MRWordCounter.run（） 可以看出代码行数只是原生Python的1/3，逻辑也比较清晰，代码 中包含了mapper、reducer函数。mapper函数接收每一行的输入数据，处 理后返回一对key：value，初始化value为数据1；reducer接收mapper输出 的key-value对进行整合，把相同key的value作累加（sum）操作后输出。 Mrjob利用Python的yield机制将函数变成一个Generators（生成器），通 过不断调用next（）去实现key-value的初始化或运算操作。前面介绍 Mrjob支持四种运行方式，包括内嵌（-r inline）、本地（-r local）、 Hadoop（-r hadoop）、Amazon EMR（-r emr），下面主要介绍前三者 的运行方式。 （1）内嵌（-r inline）方式 特点是调试方便，启动单一进程模拟任务执行状态及结果，默认 （-r inline）可以省略，输出文件使用“>output-file”或“-o output-file”。下 面两条命令是等价的： # python word_count.py -r inline input.txt >output.txt # python word_count.py input.txt –o output.txt 输出文件output.txt内容见图12-10。 图12-10　查看输出output.txt文件内容 （2）本地（-r local）方式 用于本地模拟Hadoop调试，与内嵌（inline）方式的区别是启动了 多进程执行每一个任务，如： # python word_count.py -r local input.txt >output.txt 执行的结果与inline一样，只是运行过程存在差异。 （3）Hadoop（-r hadoop）方式 用于Hadoop环境，支持Hadoop运行调度控制参数，如： ·指定Hadoop任务调度优先级（VERY_HIGH|HIGH），如，-- jobconf mapreduce.job.priority=VERY_HIGH。 ·Map及Reduce任务个数限制，如，--jobconf mapred.map.tasks=10-- jobconf mapred.reduce.tasks=5。 注意，执行之前需要指定Hadoop环境变量，执行结果见图12-11。 访问http://192.168.1.20：50030/jobtracker.jsp，显示的最后一行便是 任务执行的信息，从中可以看到任务的优先级、map及reduce的总数， 如图12-12所示。 查看Hadoop分析结果文件，内容见图12-13。 Mrjob框架的介绍告一段落，下一节重点以实际案例进行说明。 图12-11　任务执行结果（部分截图） 图12-12　已完成任务清单（部分截图） 图12-13　查看任务结果文件内容 12.4　实战分析 在互联网企业中，随着业务量、访问量的不断增长，用户产生的 数据也越来越大，如何处理大数据的存储与分析问题呢？比如Web服务 器的访问log，当日志只有GB单位大小时，我们还可以勉强通过shell、 awk进行分析，当达到上百GB，甚至上PB级别时，通过脚本的方式已经 力不从心了。另外一个待解决的问题就是数据存储。Hadoop很好地解 决了这两个问题，即分布式存储与计算。下面将通过示例介绍如何从 Web日志中快速获取访问流量、HTTP状态信息、用户IP信息、连接数/ 分钟统计等。 12.4.1　示例场景 站点www.website.com共有5台Web设备，日志文件存放位 置：/data/logs/日期（20140215）/access.log，日志为默认的Apache定义 格式，如： 125.26.28.8 - - [01/Aug/2010：09：56：53 +0700] "GET /teacher/jitra/image/pen.gif HTTP/1.1" 200 12014 "http：//www.kpsw.ac.th/teacher/jitra/page4.htm" "Mozilla/4.0 （compatible； MSIE 8.0； Windows NT 5.1； Trident/4.0； GTB6.5； InfoPath.1； .NET CLR 2.0.50727； yie8）" 125.26.28.8 - - [01/Aug/2010：09：56：53 +0700] "GET /favicon.ico HTTP/1.1" 200 1187 "-" "Mozilla/4.0 （compatible； MSIE 8.0； Windows NT 5.1； Trident/4.0； GTB6.5； InfoPath.1； .NETCLR 2.0.50727； yie8）" 66.249.65.37 - - [01/Aug/2010：09：57：59 +0700] "GET /picture/49- 02/DSC02630.jpg HTTP/1.1" 200 79220 "-" "Googlebot-Image/1.0" 66.249.65.37 - - [01/Aug/2010：09：59：19 +0700] "GET /elearning/index.php？cal_m=2&cal_y=2011 HTTP/1.1" 200 9232 "-" "Mozilla/5.0 （compatible； Googlebot/2.1； +http：//www.google.com/bot.html）" 共有12列数据（空格分隔），分别为：①客户端IP；②空白（远 程登录名称）；③空白（认证的远程用户）；④请求时间；⑤UTC时 差；⑥方法；⑦资源；⑧协议；⑨状态码；⑩发送字节数； 访问 来源； 客户浏览器信息（不具体拆分）。 接下来在5台Web服务器部署HDFS的客户端，以便定期上传Web日 志到HDFS存储平台，最终实现分布式计算。需要安装（JDK配置环境 变量）、Hadoop（原版tar包解析即可），详细见12.2相关内容。添加上 传日志功能作业到crontab，内容如下： 55 23 * * * /usr/bin/python /home/test/hadoop/hdfsput.py >> /dev/null 2>&1 通过subprocess.Popen（）方法调用Hadoop HDFS相关外部命令， 实现创建HDFS目录及客户端文件上传，详细代码如下： 【/home/test/hadoop/hdfsput.py】 import subprocess import sys import datetime webid="web1" #HDFS存储日志标志，其他Web服务器分别为web2、web3、web4、web5 currdate=datetime.datetime.now（）.strftime（'%Y%m%d'） logspath="/data/logs/"+currdate+"/access.log" #日志本地路径 logname="access.log."+webid #HDFS存储日志名 try： subprocess.Popen（["/usr/local/hadoop-1.2.1/bin/hadoop"， "dfs"， "- mkdir"， "hdfs：//192.168.1.20：9000/user/root/website.com/"+currdate]， stdout=subprocess.PIPE） #创建HDFS目录，目录格式：website.com/20140205 except Exception，e： pass putinfo=subprocess.Popen（["/usr/local/hadoop-1.2.1/bin/hadoop"， "dfs"， "-put"， logspath， "hdfs：//192.168.1.20： 9000/user/root/website.com/"+currdate+"/"+logname]， stdout=subprocess.PIPE） #上传本地日志到HDFS for line in putinfo.stdout： print line 在crontab定时作业运行后，5台Web服务器的日志在HDFS上的信 息如下： # /usr/local/hadoop-1.2.1/bin/hadoop dfs -ls /user/root/website.com/20140215 Found 5 items -rw-r--r-- 3 root supergroup 156541746 2014-02-15 23：55 /user/root/website.com/20140215/access.log.web1 -rw-r--r-- 3 root supergroup 251245315 2014-02-15 23：53 /user/root/website.com/20140215/access.log.web2 -rw-r--r-- 3 root supergroup 134256412 2014-02-15 23：55 /user/root/website.com/20140215/access.log.web3 -rw-r--r-- 3 root supergroup 192314554 2014-02-15 23：54 /user/root/website.com/20140215/access.log.web4 -rw-r--r-- 3 root supergroup 183267834 2014-02-15 23：55 /user/root/website.com/20140215/access.log.web5 截至目前，数据的分析源已经准备就绪，接下来的工作便是分析 了。 12.4.2　网站访问流量统计 网站访问流量作为衡量一个站点的价值、热度的重要标准，另外 在CDN服务中流量会涉及计费，如何快速准确分析当前站点的流量数据 至关重要，当然，使用Mrjob可以很轻松实现此类需求。下面实现精确 到分钟统计网站访问流量，原理是在mapper操作时将Web日志中小时的 每分钟作为key，将对应的行发送字节数作为value，在reducer操作时对 相同key作累加（sum）统计，详细源码如下： 【/home/test/hadoop/httpflow.py】 from mrjob.job import MRJob import re class MRCounter（MRJob）： def mapper（self， key， line）： i=0 for flow in line.split（）： if i==3： #获取时间字段，位于日志的第4列，内容如“[06/Aug/2010：03： 19：44” timerow= flow.split（"："） hm=timerow[1]+"："+timerow[2] #获取“小时：分钟”，作为key if i==9 and re.match（r"\d{1，}"， flow）： #获取日志第10列-发送的 字节数， 作为value yield hm， int（flow） #初始化key：value i+=1 def reducer（self， key， occurrences）： yield key， sum（occurrences） #相同key“小时：分钟”的value作累加操作 if __name__ == '__main__'： MRCounter.run（） 生成Hadoop任务，运行： # python /home/test/hadoop/httpflow.py -r hadoop --jobconf mapreduce.job.priority=VERY_HIGH -o hdfs：///output/httpflow hdfs：///user/root/website.com/20140215 分析结果见图12-14。 图12-14　任务分析结果（部分截图） 建议将分析结果数据定期入库MySQL，利用MySQL灵活、丰富的 SQL支持，可以很方便地对数据进行加工，轻松输出比较美观的数据报 表。图12-15为网站一天的流量趋势图。 图12-15　业务流量趋势图 12.4.3　网站HTTP状态码统计 统计一个网站的HTTP状态码比例数据，可以帮助我们了解网站的 可用度及健康状态，比如我们关注的200、404、5xx状态等。在此示例 中我们利用Mrjob的多步调用的形式来实现，除了基本的mapper、 reducer方法外，还可以添加自定义处理方法，在steps中添加调用即可， 详细源码如下： 【/home/test/hadoop/httpstatus.py】 from mrjob.job import MRJob import re class MRCounter（MRJob）： def mapper（self， key， line）： i=0 for httpcode in line.split（）： if i==8 and re.match（r"\d{1，3}"， httpcode）：#获取日志中HTTP状 态码段，作为key yield httpcode， 1 #初始化key：value，value计数为1，方便 reducer作累加 i+=1 def reducer（self， httpcode， occurrences）： yield httpcode， sum（occurrences） #对排序后的key对应的value作sum累加 def steps（self）： return [self.mr（mapper=self.mapper）， #在steps方法中添加调用队列 self.mr（reducer=self.reducer）] if __name__ == '__main__'： MRCounter.run（） 生成hadoop任务，分析数据源保持不变，输出目录改 成/output/httpstatus，执行： # python /home/test/hadoop/httpstatus.py -r hadoop --jobconf mapreduce.job.priority=VERY_HIGH -o hdfs：///output/httpstatus hdfs：///user/root/website.com/20140215 分析结果见图12-16。 图12-16　任务分析结果 我们可以根据结果数据输出比例饼图，如图12-17所示。 图12-17　生成HTTP状态码饼图 12.4.4　网站分钟级请求数统计 一个网站的请求量大小，直接关系到网站的访问质量，非常有必 要对该数据进行分析且关注。本示例以分钟为单位对网站的访问数进行 统计，原理与12.4.2类似，区别是value初始为1，以便作累加统计，详细 源码如下： 【/home/test/hadoop/http_minute_conn.py】 from mrjob.job import MRJob import re class MRCounter（MRJob）： def mapper（self， key， line）： i=0 for dt in line.split（）： if i==3： #获取时间字段，位于日志的第4列，内容如“[06/Aug/2010：03： 19：44” timerow= dt.split（"："） hm=timerow[1]+"："+timerow[2] #获取“小时：分钟”，作为key yield hm， 1 #初始化key：value，value计数为1，方便reducer作累加 i+=1 def reducer（self， key， occurrences）： yield key， sum（occurrences） if __name__ == '__main__'： MRCounter.run（） 生成Hadoop任务，输出目录/output/http_minute_conn，执行： # python /home/test/hadoop/http_minute_conn.py -r hadoop --jobconf mapreduce.job.priority=VERY_HIGH -o hdfs：///output/http_minute_conn hdfs：///user/root/website.com/20140215 分析结果见图12-18。 图12-18　任务分析结果（部分截图） 12.4.5　网站访问来源IP统计 统计用户的访问来源IP可以更好地了解网站的用户分布，同时也 可以帮助安全人员捕捉攻击来源。实现原理是定义匹配IP正则字符串作 为key，将value初始化为1，执行reducer操作时作累加（sum）统计，详 细源码如下： 【/home/test/hadoop/ipstat.py】 from mrjob.job import MRJob import re IP_RE = re.compile（r"\d{1，3}\.\d{1，3}\.\d{1，3}\.\d{1，3}"） #定义IP正则匹 配 class MRCounter（MRJob）： def mapper（self， key， line）： #匹配IP正则后生成key：value，其中key为IP地址，value初始值为1 for ip in IP_RE.findall（line）： yield ip， 1 def reducer（self， ip， occurrences）： yield ip， sum（occurrences） if __name__ == '__main__'： MRCounter.run（） 生成Hadoop任务，输出目录/output/ipstat，执行： # python /home/test/hadoop/ipstat.py -r hadoop --jobconf mapreduce.job.priority=VERY_HIGH -o hdfs：///output/ipstat hdfs：///user/root/website.com/20140215 分析结果见图12-19。 图12-19　任务分析结果（部分截图） 12.4.6　网站文件访问统计 通过统计网站文件的访问次数可以帮助运维人员了解访问最集中 的文件，以便进行有针对性的优化，比如调整静态文件过期策略、优化 动态cgi的执行速度、拆分业务逻辑等。实现原理是将访问文件作为 key，初始化value为1，执行reducer时作累加（sum）统计，详细源码如 下： 【/home/test/hadoop/httpfile.py】 from mrjob.job import MRJob import re class MRCounter（MRJob）： def mapper（self， key， line）： i=0 for url in line.split（）： if i==6： #获取日志中URL文件资源字段，作为key yield url， 1 i+=1 def reducer（self， url， occurrences）： yield url， sum（occurrences） if __name__ == '__main__'： MRCounter.run（） 执行结果如图12-20所示。 图12-20　任务分析结果（部分截图） 同理，我们可以使用以上方法对User-Agent域进行分析，包括浏览 器类型及版本、操作系统及版本、浏览器内核等信息，为更好地提升用 户体验提供数据支持。 参考提示　12.2.1小节原生Python编写mapreduce示例参考 http://www.michael-noll.com/tutorials/writing-an-hadoop-mapreduce- program-in-python/。 第三部分　案例篇 ·第13章　从零开始打造B/S自动化运维平台 ·第14章　打造Linux系统安全审计功能 ·第15章　构建分布式质量监控平台 ·第16章　构建桌面版C/S自动化运维平台 第13章　从零开始打造B/S自动化运维平台 随着企业业务的不断发展，在运营方面，如何保障业务的高可用 及服务质量，系统管理员将面临越来越多的挑战。目前，很多企业还处 在传统的“半自动化”状态，一旦出现运维事故，技术部的每个人都会加 入“救火”行列，最后弄得疲惫不堪。因此，构建高效的运营模式已迫在 眉睫，可以从以下几个方面入手，包括定制符合企业特点的IT制度、流 程规范、质量与成本管理、运营效率建设等。本章将介绍如何使用 Python从零开始打造一个易用、扩展性强、安全、高效的自动化运维平 台，从而提高运营人员的工作效率。 13.1　平台功能介绍 作为ITIL体系当中的一部分，本平台同样遵循ITIL标准设计规范。 OMServer是本平台的名称，后面的内容将使用它作为平台的称号。 OMServer实现了一个集中式的Linux集群管理基础平台，提供了模块扩 展的支持，可以随意添加集群操作任务模块，服务器端模块支持前端 HTML表单参数动态定制，可灵活实现日常运维远程操作、文件分发等 任务；在安全方面，采用加密（RC4算法）指令传输、操作日志记录、 分离Web Server与主控设备等；在效率方面，管理员只需选择操作目标 对象及操作模块即可完成一个现网变更任务。另外，在用户体验方面， 采用前端异步请求，模拟Linux终端效果接收返回串。任何人都可以根 据自身的业务特点对OMServer平台进行扩展，比如与现有资产平台进行 对接，或整合到现有的运营平台当中。平台首页如图13-1所示。 图13-1　平台首页界面 13.2　系统构架设计 OMServer平台采用了三层设计模式，第一层为Web交互层，采用 了Django+prototype.js+MySQL实现，服务器端采用了Nginx+uwsgi构建 高效的Web服务；第二层为分布式计算层，采用rpyc分布式计算框架实 现，作为第一层与第三层的数据交互及实现主控端物理分离，提高整体 安全性，同时具备第三层的多机服务的能力；第三层为集群主控端服务 层，支持Saltstack、Ansible、Func等平台。具体见如图13-2所示的系统 架构图。 图13-2　系统架构图 从图13-2可以看出系统的三个层次，首先管理员向OMServer平台 所在Web服务器发起HTTP请求，OMServer接收HTTP POST的数据并采 用“RC4+b64encode+密钥key”进行加密，再作为rpyc客户端向rpyc服务 器发送加密指令串，rpyc服务器端同时也是Saltstack、Ansible、Func等 的主控端，主控端将接收到的数据通过“RC4+b64decode+密钥key”进行 解密，解析成OMServer调用的任务模块，结合Saltstack、Ansible或Func 向目标业务服务器集群发送执行任务，执行完毕后，将返回的执行结果 加解密处理，最后逐级返回给系统管理员，整个任务模块分发执行流程 结束。 13.3　数据库结构设计 13.3.1　数据库分析 OMServer平台采用了开源数据库MySQL作为数据存储，将数据库 命名为OMServer，该数据库总共有4张表，表信息说明如下。 ·server_fun_categ：服务功能分类表。 ·server_app_categ：服务应用分类表。 ·server_list：服务器列表。 ·module_list：模块列表。 13.3.2　数据字典 server_fun_categ服务功能分类表。 server_app_categ服务应用分类表。 server_list服务器列表。 module_list模块列表。 13.3.3　数据库模型 在ITIL体系中有一种比较典型的资产定义方法，即采用“功能分 类”作为根类，其子类为“应用分类”，在最小单位的“服务器”中指定“应 用分类”进行关联，完成其层次关系的定义，例如，Linux.Web（一级功 能类别），bbs.domain.com（二级应用类别），10.11.100.10（服务器归 bbs.domain.com类别），详见图13-3所示的数据库模型图。 图13-3　数据库模型 从模型关系图中可以看出，server_list表中的server_app_id字段被设 置为外键，与server_app_categ表中的ID字段进行关联；server_app_categ 表中的server_categ_id字段被设置为外键，与server_fun_categ表中的ID字 段进行关联。 13.4　系统环境部署 13.4.1　系统环境说明 OMServer采用Django-1.4.9、nginx-1.5.9、uwsgi-2.0.4、rpyc-3.2.3等 开源组件来构建。为了便于读者理解，下面对平台的运行环境、安装部 署、开发环境优化等进行详细说明。环境设备角色表如表13-1所示。 表13-1　系统环境说明表 13.4.2　系统平台搭建 OMServer平台涉及两个角色，其中一个为Web服务端，运行 Django及rpyc环境，另一角色为主控端，需要部署Saltstack、Ansible或 Func主控端环境，可参与本书第9~11章内容，本节不予详细介绍。另外 同样需要部署rpyc环境。 （1）Django环境部署 本示例部署主机为192.168.1.10（SN2012-07-010）。 # cd /home # mkdir -p /home/install/Django && cd /home/install/Django #创建安装包目 录 # mkdir –p /data/logs/ #创建uwsgi日志目录 1）安装pcre。pcre是一个轻量级的正则表达式函数库，Nginx的 HTTP Rewrite模块会用到，最新版本为8.34（对于OMServer平台环境来 说非必选项）。 # wget ftp：//ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre- 8.34.tar.gz # tar -zxvf pcre-8.34.tar.gz # cd pcre-8.34 #./configure # make && make install # cd .. 2）安装Nginx。Nginx是最流行的高性能HTTP服务器，最新版本 为1.5.9。 # wget http：//nginx.org/download/nginx-1.5.9.tar.gz # tar -zxvf nginx-1.5.9.tar.gz # cd nginx-1.5.9 #./configure --user=nobody --group=nobody --prefix=/usr/local/nginx -- with-http_stub_status_module --with-cc-opt='-O3' --with-cpu-opt=opteron # make && make install # cd .. 3）安装MySQL-python。MySQL-python是Python访问MySQL数据 库的第三方模块库，最新版本为1.2.3c1。 # yum install -y MySQL-python #yum安装方式 # wget http：//nchc.dl.sourceforge.net/project/mysql-python/mysql- python/1.2.2/ # tar -zxvf MySQL-python-1.2.2.tar.gz #源码安装方式 # cd MySQL-python-1.2.2 # python setup.py install # cd .. 4）安装uwsgi。uwsgi是一个快速的、纯C语言开发的、自维护、 对开发者友好的WSGI服务器，旨在提供专业的Python Web应用发布和 开发功能，最新版本为2.0.4。 # wget http：//projects.unbit.it/downloads/uwsgi-2.0.4.tar.gz # tar -zxvf uwsgi-2.0.4.tar.gz # cd uwsgi-2.0.4 # make # cp uwsgi /usr/bin # cd .. 5）安装Django。Django是一个Python最流行的开源Web开发框 架，最新版本为1.6.5。考虑到兼容与稳定性，本示例使用1.4.9版本进行 开发。 # wget https：//www.djangoproject.com/m/releases/1.4/Django-1.4.9.tar.gz # tar -zxvf Django-1.4.9.tar.gz # cd Django-1.4.9 # python setup.py install 6）配置Nginx。修改/usr/local/nginx/conf/nginx.conf，添加以下 server域配置： server { listen 80； server_name omserver.domain.com； location / { uwsgi_pass 192.168.1.10：9000； include uwsgi_params； uwsgi_param UWSGI_CHDIR /data/www/OMserverweb； uwsgi_param UWSGI_SCRIPT django_wsgi； access_log off； } location ^~ /static { root /data/www/OMserverweb； } location ~* ^.+\. （mpg|avi|mp3|swf|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|txt |tar|mid|midi|wav|rtf|mpeg）$ { root /data/www/OMserverweb/static； access_log off； } } 其中“omserver.domain.com”为平台访问域 名，“/data/www/OMserverweb”为项目根目录，可以根据具体环境进行 修改。 7）配置uwsgi。创建uwsgi配置文件/usr/local/nginx/conf/uwsgi.ini， 详细内容如下： [uwsgi] socket = 0.0.0.0：9000 #监听的地址及端口 master = true #启动主进程 pidfile = /usr/local/nginx/uwsgi.pid processes = 8 #uwsgi开启的进程数 chdir = /data/www/OMserverweb #项目主目录 pythonpath = /data/www profiler=true memory-report=true enable-threads = true logdate=true limit-as=6048 daemonize=/data/logs/django.log 启动uwsgi与nginx服务，建议配置成服务自启动脚本，便于后续的 日常维护。详细启动脚本这里不展开说明，有兴趣的读者可参阅互联网 上已经存在的相关资源。 # /usr/bin/uwsgi --ini /usr/local/nginx/conf/uwsgi.ini # /usr/local/nginx/sbin/nginx 访问http://omserver.domain.com，出现如图4-4所示的页面说明 Django+uwsgi环境部署成功！ 图13-4　Django默认首页 （2）rpyc模块安装。 rpyc（Remote Python Call）是Python提供分布式计算的基础服务 平台，可以理解成封装程度更高的Socket编程，最新版本为3.3。本示例 需要部署rpyc模块的主机为192.168.1.20（SN2013-08-020）、 192.168.1.10（SN2012-07-010）。 # wget https：//pypi.python.org/packages/source/r/rpyc/rpyc-3.2.3.tar.gz - -no-check-certificate # tar -zxvf rpyc-3.2.3.tar.gz # cd rpyc-3.2.3 # python setup.py install 13.4.3　开发环境优化 开发环境相对于生产环境更注重调试便捷性，好的调试工具对软 件开发将起到事半功倍的作用，方便高效地定位问题。本节介绍Django 必备调试工具django-debug-toolbar的安装与配置，同时介绍如何实现一 种Django代码自动刷新生效的方法。 （1）django-debug-toolbar的安装 # wget https：//github.com/robhudson/django-debug- toolbar/archive/master.zip # unzip master # cd django-debug-toolbar-master/ # python setup.py install 修改Django的setting.py配置，关键参数如下： INTERNAL_IPS = （'127.0.0.1'，'192.168.1.101'，） #添加启动调试器的来源IP MIDDLEWARE_CLASSES = （ # MIDDLEWARE_CLASSES添加以下行 … … 'debug_toolbar.middleware.DebugToolbarMiddleware'， ） INSTALLED_APPS = （ # INSTALLED_APPS添加以下行 … … 'debug_toolbar'， } TEMPLATE_DIRS = （ #TEMPLATE_DIRS添加以下行，注意与python的安装路径保持一致 … … '/usr/lib/python2.6/site-packages/django_debug_toolbar-0.8.5- py2.6.egg/debug_toolbar/templates/'， ） 务必要渲染一个模板，这样debug_toolbar才会自动附加调试信息 到当前的页面，否则看不到debug_tool的界面。debug_toolbar在业务前 端页面设计成可伸缩展示，展开后的调试界面如图13-5所示。 图13-5　debug_toolbar界面 （2）Django源码自动重载（reload）方案 本方案结合uwsgi的“--touch-reload”参数来实现，参数格式：-- touch-reload"文件"，即当该参数值指定的文件发生变化（修改或touch操 作）时，uwsgi进程将自动重载（reload），从而使我们的项目代码刷新 生效。另外，如何保证一旦更新项目源码立即触发变更--touch-reload指 定的文件？Linux系统下的inotify可以做到这点，具体操作如下。 1）在项目目录中创建一个监视文件： # mkdir /data/www/OMserverweb/shell #在项目目录中创建一个存放监视文件的目录 shell # touch reload.set #创建一个监视文件reload.set # yum -y install inotify-tools #安装inotify程序包 # uwsgi启动脚本添加“--touch-reload”项 # /usr/bin/uwsgi --ini "/usr/local/nginx/conf/*.ini" --touch-reload "/data/www/OMserverweb/shell/reload.set" 2）编写监视脚本： # vi /data/www/OMserverweb/shell/autoreload.sh #！/bin/sh objectdir="/data/www/OMserverweb" # 启动inotify监视项目目录，参数“--exclude”为忽略的文件或目录正则 /usr/bin/inotifywait -mrq --exclude "（static|logs|shell|\.swp|\.swx|\.pyc|\.py\~）" --timefmt '%d/%m/%y %H： %M' --format '%T %w%f' --event modify，delete，move，create，attrib ${objectdir} | while read files do #项目源码发生变化后，触发touch reload.net的操作，最终使uwsgi进程重载，达到刷新项目源码 的目的 /bin/touch /data/www/OMserverweb/shell/reload.set continue done & 3）启动脚本开启项目目录监视： # /data/www/OMserverweb/shell/autoreload.sh 13.5　系统功能模块设计 13.5.1　前端数据加载模块 OMServer平台的Web前端采用prototype.js作为默认Ajax框架，通过 get方式向定义好的Django视图发起请求，功能视图通过 HttpResponse（）方法直接输出结果，前端会将输出的结果做页面渲 染。图13-6为应用ID（app_categId）等于1的HttpResponse（）输出结 果，前端会将这个结果串进行分割，然后填充页面元素，后端返回主机 信息。 图13-6　后端返回主机信息 前端各区域对应的数据库表及视图方法见图13-7。 图13-7　前端各区域对应后台方法及数据库表 局部方法代码如下： 【/data/www/OMserverweb/autoadmin/views.py】 """ =Return server IP list =返回服务器列表方法 """ def server_list（request）： ip="" ip_hostname="" if not 'app_categId' in request.GET： app_categId="" else： app_categId=request.GET['app_categId'] #获取用户选择的应用分类ID #ServerList为server_list表模型对象，实现过滤获取的应用分类ID相匹配的主机列表 ServerListObj = ServerList.objects.filter（server_app_id=app_categId） for e in ServerListObj： ip+="，"+e.server_lip ip_hostname+="，"+e.server_lip+"*"+e.server_name server_list_string=ip[1：]+"|"+ip_hostname[1：] # 输出格式：192.168.1.10，192.168.1.20|192.168.1.10*sn2012-07-010，\ #192.168.1.20*sn2013-08-020，其中“|”分隔符前部分为IP地址，作为HTML 下拉框显示项， #分隔符后部分为的value，以“*”号作为分隔符，目的是为后端提供主机名及IP两种 目标地址支持 return HttpResponse（server_list_string） """ =Return module list =返回功能模块列表方法 """ def module_list（request）： module_id="-1" module_name=u"请选择功能模块..." # ModuleList为module_list表模型对象，实现读取所有模块列表，以模块id做排序 ModuleObj = ModuleList.objects.order_by（'id'） for e in ModuleObj： module_id+="，"+str（e.id） module_name+="，"+e.module_name module_list_string=module_name+"|"+module_id #输出格式：“请选择功能模块...，查看系统日志，查看最新登录，查看系统版本|-1，1001， 1002，1003” #其中“|”号分隔模块名称与模块ID，Web前端获取数据后通过JavaScript做拆分与组装 return HttpResponse（module_list_string） 13.5.2　数据传输模块设计 传输模块采用rpyc分布式计算框架，利用分布式特点可以实现多台 主控设备的支持，具备一定横向扩展及容灾能力。rpyc分为两种角色， 一种为Server端，另一种为Client端，与传统的Socket工作方式一样，区 别是rpyc实现了更高级的封装，支持同步与异步操作、回调和远程服务 以及透明的对象代理，可以轻松在Server与Client之间传递Python的任意 对象，在性能方面也非常高效。下面介绍的是Django的module_run（） 视图方法，实现接收功能模块的提交参数、加密、发送、接收功能模块 运行结果等，局部方法代码如下： 【/data/www/OMserverweb/autoadmin/views.py】 """ = Run module = 运行模块视图方法（向rpyc服务器端发起任何请求） """ def module_run（request）： import rpyc put_string="" if not 'ModuleID' in request.GET： #接收模块ID、操作主机、模块扩展参数等 （更多源码已省略） Module_Id="" else： Module_Id=request.GET['ModuleID'] put_string+=Module_Id+"@@" …… try： conn=rpyc.connect（'192.168.1.20'，11511） #连接rpyc主控端主机，端 口：11511 #调用rpyc Server的login方法实现账号、密码校验，屏蔽恶意的连接 conn.root.login（'OMuser'，'KJS23o4ij09gHF734iuhsdfhkGYSihoiwhj38u4h'） except Exception，e： logger.error（'connect rpyc server error：'+str（e）） return HttpResponse（'connect rpyc server error：'+str（e）） #对请求数据串使用tencode方法进行加密，密钥使用Django 中settings.SECRET_KEY的值 put_string=tencode（put_string，settings.SECRET_KEY） #调用rpyc Server的Runcommands方法实现功能模块的任务下发，返回的结果使用tdecode进 行解密 OPresult=tdecode（conn.root.Runcommands（put_string）， settings.SECRET_KEY） return HttpResponse（OPresult） #输出结果供前端渲染 关于rpyc服务器端的实现原理，首先接收rpyc客户端传递过来的信 息，通过解密方法还原出模块ID、操作对象、模块扩展参数等信息，再 通过exec方法导入相应的功能模块（要事先完成编写，否则会提示找不 到指定功能模块），调用功能模块的相关方法，实现操作任务向业务集 群服务器下发与执行，最后将任务执行结果串进行格式化、加密后返回 给Web层。完整实现代码如下： 【/home/test/OMServer/OMservermain.py】 # -*- coding： utf-8 -*- import time import os，sys import re from cPickle import dumps from rpyc import Service from rpyc.utils.server import ThreadedServer import logging from libraries import * from config import * #定义服务器端模块存放路径 sysdir=os.path.abspath（os.path.dirname（__file__）） sys.path.append（os.sep.join（（sysdir，'modules/'+AUTO_PLATFORM））） class ManagerService（Service）： #定义login认证方法，对外开放调用的方法，rpyc要求加上“ exposed_”前缀，调用时使用 # login（）即可 def exposed_login（self，user，passwd）： if user=="OMuser" and passwd=="KJS23o4ij09gHF734iuhsdfhkGYSihoiwhj38u4h"： self.Checkout_pass=True #认证结果标记变量，值为“True”则认证通过， 反之 #认证失败 else： self.Checkout_pass=False def exposed_Runcommands（self，get_string）： logging.basicConfig（level=logging.DEBUG， #启用系统日志记录 format='%（asctime）s [%（levelname）s] %（message）s'， filename=sys.path[0]+'/logs/omsys.log'， filemode='a'） #判断是否通过认证 try： if self.Checkout_pass！=True： return tencode（"User verify failed！"，SECRET_KEY） except： return tencode（"Invalid Login！"，SECRET_KEY） #获取rpyc Client的请求串get_string，通过tdecode方法解密后再进行分隔，分隔符 为“@@” self.get_string_array=tdecode（get_string， SECRET_KEY）.split（'@@'） self.ModuleId=self.get_string_array[0] #获取功能模块ID self.Hosts=self.get_string_array[1] #获取操作目标主机 sys_param_array=[] #获取功能模块的扩展参数并追加到列表 for i in range（2，len（self.get_string_array）-1）： sys_param_array.append（self.get_string_array[i]） #加载模块ID应对的模块名，格式为“Mid_”+模块ID，如“Mid_1001.py” mid="Mid_"+self.ModuleId importstring = "from "+mid+" import Modulehandle" try： exec importstring except： return tencode（u"module\""+mid+u"\"does not exist， Please add it"，SECRET_KEY） #调用模块相关方法，下发执行任务 Runobj=Modulehandle（self.ModuleId，self.Hosts，sys_param_array） Runmessages=Runobj.run（） #根据不同主控端组件格式化输出，支持Func、Ansible、Saltstack if AUTO_PLATFORM=="func"： if type（Runmessages） == dict： returnString = func_transform（Runmessages，self.Hosts） else： returnString = str（Runmessages）.strip（） elif AUTO_PLATFORM=="ansible"： if type（Runmessages） == dict： returnString = ansible_transform（Runmessages，self.Hosts） else： returnString = str（Runmessages）.strip（） elif AUTO_PLATFORM=="saltstack"： if type（Runmessages） == dict： returnString = saltstack_transform（Runmessages， self.Hosts） else： returnString = str（Runmessages）.strip（） #对返回给rpyc Client的数据串进行加密 return tencode（returnString，SECRET_KEY） s=ThreadedServer（ManagerService，port=11511，auto_register=False） s.start（） #启动rpyc服务监听、接收、响应请求 数据传输的安全性关系到整个运营平台的生命线，因此严格做好 入侵安全防范至关重要。OMServer平台采用base64.b64encode（）、 base64.b64decode（）加上密钥混淆算法（RC4）实现数据的加密与解 密。OMServer平台遵循一个原则，数据在传输之前调用tencode（）方 法进行加密，在数据接收完毕后调用dencode（）方法进行解密。解密 的密钥采用项目settings.py中的SECRET_KEY变量值。同时在rpyc服务 器端添加login（）方法，实现逻辑层的安全防护。 【/home/test/OMServer/libraries.py】 # -*- coding： utf-8 -*- #！/usr/bin/env python import random， base64 from hashlib import sha1 #RC4加密算法 def crypt（data， key）： x = 0 box = range（256） for i in range（256）： x = （x + box[i] + ord（key[i % len（key）]）） % 256 box[i]， box[x] = box[x]， box[i] x = y = 0 out = [] for char in data： x = （x + 1） % 256 y = （y + box[x]） % 256 box[x]， box[y] = box[y]， box[x] out.append（chr（ord（char） ^ box[（box[x] + box[y]） % 256]）） return ''.join（out） #使用RC4算法加密编码后的数据，data为加密的数据，key为密钥 def tencode（data， key， encode=base64.b64encode， salt_length=16）： """RC4 encryption with random salt and final encoding""" salt = '' for n in range（salt_length）： salt += chr（random.randrange（256）） data = salt + crypt（data， sha1（key + salt）.digest（）） if encode： data = encode（data） return data #使用RC4算法解密编码后的数据，data为加密的数据，key为密钥 def tdecode（data， key， decode=base64.b64decode， salt_length=16）： if decode： data = decode（data） salt = data[：salt_length] return crypt（data[salt_length：]， sha1（key + salt）.digest（）） 13.5.3　平台功能模块扩展 OMServer平台模块的扩展需要完成两件事情，一是在前端添加模 块基本信息，二是在服务器端编写对应的任务模块，下面对具体内容进 行详细说明。 （1）添加前端模块 添加前端模块包括指定模块名称、功能说明、模块扩展（HTML表 单作为模块参数）等，具体操作是点击首页的【添加模块】按钮，跳转 到“添加模块”表单页面，其中最关键的是“模块扩展”输入框，支持所有 HTML表单元素，后台通过name属性引用其值（value）。OMServer目 前支持最多两个扩展参数，name属性要求使 用“sys_param_1”、“sys_param_2”作为其定义值，当然，扩展更多参数 的改造成本也非常低。在本示例中添加“重启进程服务”模块，具体操作 如图13-8所示。 提交后将返回新增模块的ID，该模块ID同时会作为服务器端任务 模块的后缀名，如图13-9所示，记下模块ID“1007”，前端模块添加完 毕。 图13-8　添加前端模块 图13-9　提交前端模块添加 （2）添加服务器端任务模块 服务器端模块的作用是负责具体远程操作任务的功能封装，支持3 种Python自动化操作组件，包括Saltstack、Ansible、Func。不同组件的 API语法及返回数据结构都不一样，因此OMServer在设计时就将不同组 件的模块进行隔离，具体模块目录结构如图13-10所示，在模块目录 （modules）下组件名作为二级目录名，二级目录下为具体的任务模 块，文件名称由“Mid_”+模块ID组成，与前端生成的模块ID进行关联。 图13-10　服务器端模块目录结构 关于任务模块的编写，不同组件的实现规范和方法都不一样，在 编写任务模块之前需要更新配置文件config.py的两个选项，其 中“AUTO_PLATFORM”为指定组件环境，可选项 为“ansible”、“saltstack”、“func”，“SECRET_KEY”为指定加密、解密的 密钥，与项目settings.py中的SECRET_KEY变量保持一致。另外 modules/（ansible|saltstack|func）/Public_lib.py文件的作用是导入、定义 各组件的API模块包及全局参数，同时也增加代码的复用性。 【/home/test/OMServer/config.py】 # -*- coding： utf-8 -*- #！/usr/bin/env python AUTO_PLATFORM = "saltstack" #指定组件环境，支持Saltstack、Ansible、Func #密钥，与项目中setting.py的SECRET_KEY变量保持一致 SECRET_KEY = "ctmj#&；8hrgow_^sj$ejt@9fzsmh_o）-=（byt5jmg=e3#foya6u" 服务器端任务模块由Modulehandle类及其两个方法组成，其中 __init__（）方法作用为初始化模块基本信息，包括操作主机列表、模 块ID、模块扩展参数等；run（）方法实现组件API的调用以及返回执行 结果。针对“重启进程服务”这个任务模块，下面分别介绍3个组件的不 同实现方法。 1）编写Ansible组件ID为“1007”模块。 根据Ansible组件模块的开发原理，通过调用command模块实现远 程命令执行，使用copy模块实现文件远程同步，详细源码如下： 【/home/test/OMServer/modules/ansible/Mid_1007.py】 # -*- coding： utf-8 -*- from Public_lib import * #重启应用模块进程服务# class Modulehandle（）： def __init__（self，moduleid，hosts，sys_param_row）： #初始化方法无须改 动 self.hosts = "" self.Runresult = "" self.moduleid = moduleid #模块ID self.sys_param_array= sys_param_row #模块扩展参数列表 self.hosts=target_host（hosts，"IP"） #格式化主机信息，参数“IP”为IP地 址，“SN”为主机名 #任务下发、执行方法 def run（self）： try： #根据模块扩展参数定义执行的不同命令集 commonname=str（self.sys_param_array[0]） if commonname=="resin"： self.command="/etc/init.d/resin restart" elif commonname=="nginx"： self.command="/etc/init.d/nginx restart" elif commonname=="haproxy"： self.command="/etc/init.d/haproxy restart" elif commonname=="apache"： self.command="/etc/init.d/httpd restart" elif commonname=="mysql"： self.command="/etc/init.d/mysql restart" elif commonname=="lighttpd"： self.command="/etc/init.d/lighttpd restart" #调用Ansible提供的API（command模块），执行远程命令 self.Runresult = ansible.runner.Runner（ pattern=self.hosts， forks=forks， module_name="command"， module_args=self.command，）.run（） if len（self.Runresult['dark']） == 0 and len（self.Runresult['contacted']） == 0： return "No hosts found，请确认主机已经添加ansible环境！" except Exception，e： return str（e） return self.Runresult #返回执行结果 2）编写Saltstack组件ID为“1007”模块。 根据Saltstack组件模块的开发原理，通过调用cmd（）方法配 置“cmd.run”与“cp.get_file”参数实现远程命令执行及文件远程同步，详 细源码（部分）如下： 【/home/test/OMServer/modules/saltstack/Mid_1007.py】 def run（self）： try： client = salt.client.LocalClient（） …… #调用Saltstack提供的API（cmd.run模块），执行远程命令 self.Runresult = client.cmd（self.hosts，'cmd.run'， [self.command]，\ expr_form='list'） if len（self.Runresult） == 0： return "No hosts found，请确认主机已经添加saltstack环境！" except Exception，e： return str（e） return self.Runresult #返回执行结果 3）编写Func组件ID为“1007”模块。 根据Func组件模块的开发原理，通过调用client.command.run（） 方法实现远程命令执行，使用client.copyfile.copyfile（）方法实现文件远 程同步，详细源码（部分）如下： 【/home/test/OMServer/modules/func/Mid_1007.py】 def run（self）： try： client = fc.Overlord（self.hosts） …… #调用Func提供的API（command.run模块），执行远程命令 commonname=str（self.sys_param_array[0]） self.Runresult=client.command.run（self.command） except Exception，e： return str（e） return self.Runresult #返回执行结果 任务模块编写完成后，启动服务端服务，运行以下命令： # cd /home/test/OMServer # python OMservermain.py & 最后，打开浏览器访问http://omserver.domain.com，效果见图13- 11。 图13-11　远程操作功能截图 参考提示　RC4加密算法参考文章 http://www.snip2code.com/Snippet/27937/Blockout-encryption-decryption- methods-p。 第14章　打造Linux系统安全审计功能 随着互联网逐渐深入我们日常生活的方方面面，网络安全威胁也 随之严重，比如服务器渗透、数据窃取、恶意攻击等。为了解决网络安 全的问题，人们采取了各式各样的防护措施来保证网络或服务的正常运 行，其中系统安全审计是记录入侵攻击主机的一个重要凭证：实时跟踪 黑客的操作记录，可在第一时间监测到攻击者的行为，并让管理员采取 相应的应对措施；同时也可作为日后攻击者的犯罪证据，为后续的审计 工作提供数据依据，具有可靠性、完整性、不可抵赖等特点。本章将介 绍在OMServer平台扩展Linux系统安全审计功能。 14.1　平台功能介绍 安全审计功能作为OMServer平台的一部分，扩展了Linux系统安全 审计的功能，实现实时跟踪所有Linux服务器系统登录账号的操作记 录，由于操作记录异地集中式存储，即使攻击者做了事后的操作痕迹清 理也无济于事。该功能结合Linux系统的history（命令行历史记录）工作 机制实现，同时设置用户全局环境/etc/profile的history属性变量，实现定 制系统用户实时触发事件，在该事件中加入Python编写的上报脚本，实 现数据的实时跟踪，最后利用OMServer的前端作为实时输出展示，平台 首页截图见图14-1。 图14-1　平台首页截图 14.2　系统构架设计 OMServer平台安全审计的功能同样基于B/S结构，服务端的数据来 源于业务集群Agent实时上报，使用MySQL数据库作为数据存储，客户 端采用prototype.js前端架构实现数据同步展示，系统架构图见图14-2。 图14-2　系统架构图 从图14-2中可以看出系统的整体架构，首先管理员在业务服务器集 群部署Python数据上报脚本，通过OMServer提供的cgi接口实现数据接 收、入库，最后通过访问前端页面来查看、跟踪服务器上报的审计信 息，整个流程结束。 14.3　数据库结构设计 14.3.1　数据库分析 安全审计服务器端功能是在OMServer平台上进行扩展，追加一张 server_history表，用于操作事件信息的存储，且与server_list的IP字段配 置外键关联。表信息说明如下。 ·server_history：操作事件表。 ·server_list：服务器列表。 14.3.2　数据字典 server_list服务器列表。 server_history操作事件表。 数据库模型功能沿用了OMServer系统中主机表（server_list）的层 次结构，且追加了操作事件表（server_history），其中，将表 server_history的history_ip字段设置成外键，与server_list表中的server_lip 字段进行关联，详细见图14-3的数据库模型。 图14-3　平台数据库模型 14.4　系统环境部署 14.4.1　系统环境说明 系统安全审计功能的服务器端作为OMServer项目的App存在，关 于服务器端Web Server的环境搭建本节将不再说明。为了便于读者理 解，下面对上报主机系统环境配置、Agent与服务器端Python实现方法 进行详细说明，环境设备角色如表14-1所示。 表14-1　系统环境说明表 14.4.2　上报主机配置 系统安全审计功能主机上报需要完成两个任务，一为配置用户 profile，二为编写上报Python脚本，下面一一进行说明。 （1）系统用户环境配置 通过配置Linux profile的history相关变量来实现与安全审计功能的 对接，包括指定系统账号history存放路径、存储长度、扩展信息、 PROMPT_COMMAND事件等，更多见以下配置及含义说明。 # vi /etc/profile # 追加以下配置 #add by OMAudit export HISTFILE=$HOME/.bash_history #指定用户history日志存放路径 export HISTSIZE=1200 #指定history 命令输出的记录数 export HISTFILESIZE=1200 #指定历史记录文件.bash_history的最大存储行数 export HISTCONTROL=ignoredups #不记录连续重复的命令 export HISTTIMEFORMAT="`whoami` %F %T " # history命令显示当前记录的用户与时间， 例如： # “root 2014-06-05 23：32：16 free –m” # PROMPT_COMMAND变量最为核心，实现了指定内容在出现bash提示符前执行的功能； # “history –a” 将目前新增的history命令写入histfiles中；“history -c”刪除记录的所有 命令（仅内存）； # “history -r” 将histfiles 的內容读到内存中，即可以通过history查看； # “/home/test/OMAudit/OMAudit_agent.py $（history 1）” 通过$（history 1）获取 最后一条 # 命令，且作为参数传递给OMAuditmain.py脚本，做后续的命令数据信息上报 export PROMPT_COMMAND="history -a； history -c； history - r；"'/home/test/OMAudit/ OMAudit_agent.py $（history 1）' shopt -s histappend #历史清单将以添加形式加入HISTFILE变量指定的文件，而不是覆盖 typeset -r PROMPT_COMMAND #设置关键变量只读，提高安全性 typeset -r HISTTIMEFORMAT 保存配置后使其生效，运行“source/etc/profile”命令，profile环境配 置完成。 （2）客户端上报脚本 客户端上报脚本的作用是将接收的最新Linux命令“$（history 1）”及服务器相关信息提交到OMServer主机，其中config.py为上报agent 的配置文件，涉及三个选项，详细说明如下： 【/home/test/OMAudit/config.py】 # -*- coding： utf-8 -*- #！/usr/bin/env python Net_driver = "eth0" #为便于记录上报来源主机，获取指定网卡驱动的IP地址 OMServer_address = "omserver.domain.com" #OMServer服务器端地址，作为上报的目 的 Connect_TimeOut = 3 #指定上报超时时间，单位为秒 OMAudit_agent.py作为主上报agent程序，负责信息的上报，采用 了httplib模块作为HTTP客户端，详细源码及说明如下： 【/home/test/OMAudit/OMAudit_agent.py】 #！/usr/bin/env python #coding：utf-8 import sys import socket import fcntl import struct import logging from config import * import urllib，httplib socket.setdefaulttimeout（Connect_TimeOut） #设置全局Socket超时时间（覆盖 HTTP连接超时） logging.basicConfig（level=logging.DEBUG， #启用日志记录 format='%（asctime）s [%（levelname）s] %（message）s'， filename=sys.path[0]+'/omsys.log'， filemode='a'） #对$（history 1）信息进行合法校验，少于6个参数则报错，正确的格式为“173 root 2014- 06-07 22：05：56 ls” if len（sys.argv）<6： logging.error（'History not configured in /etc/profile！'） sys.exit（） def get_local_ip（ethname）： #获取本地IP地址函数，用来确认数据来源 try： sock = socket.socket（socket.AF_INET， socket.SOCK_DGRAM） addr = fcntl.ioctl（sock.fileno（）， 0x8915， struct.pack（'256s'， ethname）） return socket.inet_ntoa（ addr[20：24] ） except Exception，e： logging.error（'get localhost IP address error：'+str（e）） return "127.0.0.1" def pull_history（http_get_param=""）： #数据上报函数 try： #与OMServer服务器建立HTTP连接，指定超时时间 http_client =httplib.HTTPConnection（OMServer_address， 80， timeout= Connect_TimeOut） http_client.request（"GET"， http_get_param） #发起GET请求 response =http_client.getresponse（） #获取HTTP返回对象 if response.status ！= 200： #非HTTP 200状态则退出 logging.error（'response http status error：'+str（response.status）） sys.exit（） http_content=response.read（）.strip（） #返回字符串非“OK”则退出 if http_content ！= "OK"： logging.error（'response http content error：'+str（http_content）） sys.exit（） except Exception， e： logging.error（'connection django-cgi server error：'+str（e）） sys.exit（） finally： if http_client： http_client.close（） else： logging.error（'connection django-cgi server unknown error.'） sys.exit（） Sysip = get_local_ip（Net_driver） #调用获取本地IP函数 SysUser = sys.argv[2] #获取history信息中的系统用户 History_Id = sys.argv[1] #获取history ID信息 History_date = sys.argv[3] #获取history 日期信息 History_time = sys.argv[4] #获取history 时间信息 History_command = "" for i in range（5， len（sys.argv））： #获取history的系统命令信息 History_command+= sys.argv[i]+" " #合并所有信息的HTTP GET参数格式，部分信息使用urllib.quote进行URL编码 s= "/omaudit/omaudit_pull/？ history_id="+History_Id+"&history_ip="+Sysip+"&history_user="+SysUser+ \ "&history_datetime="+History_date+urllib.quote（" "） +History_time+"&history_com mand="+urllib.quote（History_command.strip（）） pull_history（s） #调用数据上报函数 添加“/home/test/OMAudit/OMAudit_agent.py”可执行权限，执行以 下chmod命令，客户端上报agent部署完毕。接下来使用SSH工具登录 Linux服务器，输入的任何shell命令都会即时同步到服务器端，见图14- 4。 # chmod +x/home/test/OMAudit/OMAudit_agent.py 图14-4　系统命令即时上报并展示 14.5　服务器端功能设计 14.5.1　Django配置 安全审计功能作为OMServer的一个功能扩展，需要Web服务器端 开发框架（Django）同样做些变更来支持新增的功能。由于该功能作为 项目的一个App，因此，第一步需要创建一个App，操作如下： # cd /data/www/OMserverweb # python manage.py startapp omaudit 在创建的omaudit目录中修改urls.py，添加App的URL映射规则，内 容如下： from django.conf.urls.defaults import * urlpatterns = patterns（'omaudit.views'， （r'^$'，'index'）， （r'omaudit_pull/$'，'omaudit_pull'）， #映射到omaudit_pull方法，实现客户 端数据接收 （r'omaudit_run/$'，'omaudit_run'）， #映射到omaudit_run方法，实现前端实 时查询 ） 修改App的models.py，实现与数据库的关系映射，内容如下： from django.db import models # Create your models here. class ServerHistory（models.Model）： id = models.IntegerField（primary_key=True， db_column='ID'） # Field name made lowercase. history_id = models.IntegerField（） history_ip = models.CharField（max_length=45） history_user = models.CharField（max_length=45） history_datetime = models.DateTimeField（） db_datetime = models.DateTimeField（） history_command = models.CharField（max_length=765） class Meta： db_table = u'server_history' 如果数据库结构已经存在，可以通过python manage.py inspectdb命 令来生成models代码。 最后修改项目settings.py，注册该App名称，内容如下： INSTALLED_APPS = （ … … # 'django.contrib.admindocs'， 'public'， 'autoadmin'， 'omaudit'， #添加此行，注册该App ） 14.5.2　功能实现方法 服务器端提供了两个关键视图方法，分别实现前端实时展示 （omaudit_run）及数据接收（omaudit_pull），下面针对两个方法进行 说明。 （1）前端实时展示（omaudit_run）方法 关于前端数据实时展示的实现原理，通过前端JavaScript的 setInterval（）方法实现定时函数调用，首次请求默认返回ID倒序最新5 条记录，并记录下LastID（最新记录ID），后面的定时调用将传递 LastID参数，数据库查询条件是“ID>LastID”，从而达到实时获取最新记 录的目的，同时也支持选择主机来作为过滤条件，功能实现流程图见图 14-5。 图14-5　前端数据展示流程图 omaudit_run（）方法实现源码如下： """ =事件任务前端展示方法 """ def omaudit_run（request）： if not 'LastID' in request.GET： #获取上次查询到的最新记录ID LastID="" else： LastID=request.GET['LastID'] if not 'hosts' in request.GET： #获取选择的主机地址信息 Hosts="" else： Hosts=request.GET['hosts'] ServerHistory_string="" host_array=target_host（Hosts，"IP"）.split（'；'） #调用target_host方 法过滤出IP地址 if LastID=="0"： #符合第一次提交条件，查询不加“id>LastID”条件，反之 if Hosts==""： #符合没有选择主机条件，查询不加“history_ip in host_array” #条件，反之 ServerHistoryObj = ServerHistory.objects \ .order_by（'-id'）[：5] else： ServerHistoryObj = ServerHistory.objects \ .filter（history_ip__in=host_array）.order_by（'-id'）[：5] else： if Hosts==""： ServerHistoryObj = ServerHistory.objects \ .filter（id__gt=LastID）.order_by（'-id'） else： ServerHistoryObj = ServerHistory.objects \ .filter（id__gt=LastID， history_ip__in=host_array）.order_by（'-id'） lastid="" i=0 for e in ServerHistoryObj： #遍历查询结果，返回给前端 if i==0： lastid=e.id ServerHistory_string+=""+e.history_ip+ \ " ； ；\t"+ e.history_user+" ； ；\t"+ \ str（e.db_datetime）+"\t # "+e.history_command+"*" i+=1 ServerHistory_string+="@@"+str（lastid） #通过“@@”字符分隔事件记录与 lastid， #前端拆分 return HttpResponse（ServerHistory_string） （2）数据接收（omaudit_pull）方法 数据接收方法相对比较简单，即将接收到的信息直接入库，实现 的源码如下： """ =事件任务pull方法 """ def omaudit_pull（request）： if request.method == 'GET'： #校验HTTP（GET）请求参数合法性 if not request.GET.get（'history_id'， ''）： return HttpResponse（"history_id null"） if not request.GET.get（'history_ip'， ''）： return HttpResponse（"history_ip null"） if not request.GET.get（'history_user'， ''）： return HttpResponse（"history_user null"） if not request.GET.get（'history_datetime'， ''）： return HttpResponse（"history_datetime null"） if not request.GET.get（'history_command'， ''）： return HttpResponse（"history_command null"） history_id=request.GET['history_id'] #获取HTTP请求参数值 history_ip=request.GET['history_ip'] history_user=request.GET['history_user'] history_datetime=request.GET['history_datetime'] history_command=request.GET['history_command'] historyobj = ServerHistory（history_id=history_id， \ #数据入库 （insert） history_ip=history_ip， \ history_user=history_user， \ history_datetime=history_datetime， \ history_command=history_command） try： historyobj.save（） except Exception，e： return HttpResponse（"入库失败，请与管理员联系！"+str（e）） Response_result="OK" #输出“OK”字符作为成功标志 return HttpResponse（Response_result） else： return HttpResponse（"非法提交！"） 当然，如接入的集群过于庞大，服务器端数据库会逐步形成瓶 颈，主机审计信息入库会出现一定延时，影响Linux用户操作体验，一 个可行的方案是采用信息异步入库，即先将信息写入本地，再通过上报 程序后台提交信息，用户将无感知。 第15章　构建分布式质量监控平台 中国互联网呈多运营商并存的发展格局，一个注重用户体验的业 务平台，在上线前就必须解决多运营商互联互通的问题，例如电信、联 通、移动等网络的接入。目前有两个常见方案，一是将服务器资源放置 不同运营商的IDC，二是直接接入支持BGP协议的IDC。在此之后，我 们还要考虑监控不同运营网络访问业务平台的质量问题，例如骨干网络 路由延时或调度不合理甚至网络故障，导致访问业务网络出现延时、丢 包等现象，影响用户体验。因此，必须提供一种分布式（多运营商支 持）的业务服务质量监控机制。本章通过实现一套分布式的质量监控平 台整体进行说明。 15.1　平台功能介绍 分布式质量监控平台实现了多个数据采集点（不同运营商链路） 对Web业务平台进行探测，采集的信息包括DNS解析时间、建立连接时 间、准备传输时间、开始传输时间、传输总时间、HTTP状态、下载数 据包大小、下载速度等，覆盖了HTTP请求的整个生命周期。分析这些 数据，可以帮助我们快速发现（异常告警）、定位访问业务延时过大问 题。通过RRDTOOL做数据报表展示，报表类型包括请求响应时间、下 载速度、可用性的自定义、日、月、年等，可以让管理员了解业务服务 质量的整体趋势，平台截图见图15-1。 图15-1　平台首页截图 15.2　系统构架设计 分布式质量监控平台由三种不同功能角色组成，第一种为数据采 集探测功能，采用Python+pycurl模块实现数据的采集并入库MySQL； 第二种为后台定时rrdtool作业，实现MySQL数据导出并更新 RRDTOOL，采用了Python+rrdtool模块实现；第三种为Web报表展示， 采用Django+MySQL+rrdtool模块实现，服务器端采用了Nginx+uwsgi构 建高效的Web服务，根据管理员发起的请求条件输出不同类型的报表。 系统架构图见图15-2。 从图15-2中可以看出系统的整体架构，首先通过不同采集点向业务 服务集群发起定时探测任务，将获取的响应数据入库MySQL，异常返 回信息将触发告警。功能模块定时从MySQL数据库拉取数据做rrdtool update操作，为后续的报表输出提供数据支持。最后管理员通过前端 Web页面查询、定制输出报表，整个流程结束。 图15-2　系统架构图 15.3　数据库结构设计 15.3.1　数据库分析 分布式质量监控平台有两张数据库表，分别为webmonitor_hostinfo 及webmonitor_monitordata表，其中webmonitor_monitordata的FID字段配 置外键关联，表信息说明如下： ·webmonitor_hostinfo：业务信息表 ·webmonitor_monitordata：采集数据信息表 15.3.2　数据字典 webmonitor_hostinfo业务信息表。 webmonitor_monitordata采集数据信息表。 15.3.3　数据库模型 从图15-3的数据库EER图可以看出，表webmonitor_monitordata的 FID字段被设置为外键，与webmonitor_hostinfo表中的ID字段进行关 联，作为采集信息数据与业务信息表的唯一关联。 图15-3　系统数据库模型 15.4　系统环境部署 15.4.1　系统环境说明 前面介绍了分布式质量监控平台的三种角色，为了便于读者理 解，下面对不同角色的环境、实现方法进行详细说明，环境设备角色表 如表15-1所示。 表15-1　系统环境说明表 15.4.2　数据采集角色 数据采集功能角色需要完成两个任务：一为采集远程业务服务集 群HTTP响应数据，并将数据写入远程MySQL数据库；二为提供异常 HTTP响应告警支持。本示例部署192.168.1.20、192.168.1.21主机，分别 模拟电信与联通网络。下面详细说明。 数据采集端只有两个Python文件，一个为config.py，其定义了数据 库信息、运营商网络代码、连接超时时间等，内容如下： 【/data/detector/config.py】 # -*- coding： utf-8 -*- #定义MySQL数据信息 DBNAME='WebMonitor' DBUSER='webmonitor_user' DBPASSWORD='SKJDH3745tgDTS' DBHOST='192.168.1.10' # 修改成探测运营商网络代码（重要） # settings.py 中定义IDC={'ct'：'电信'，'cnc'：'联通'，'cmcc'：'移动'} # “ct”代表电信探测点网络，联通网络修改成“cnc”，移动网络修改成“cmcc”，其他类似 IDC="ct" #连接的等待时间 CONNECTTIMEOUT = 5 #请求超时时间 TIMEOUT = 10 #告警邮件地址 MAILTO="user1@domain.com，user2@domain.com" #告警手机号 MOBILETO="136****3463" 另一个为提供业务服务质量采集功能的runmonitor.py，采用了 pycurl模块实现，通过定义setopt（）方法定量参数，模拟一个HTTP请 求器（request），也可以理解成一个简单的浏览器。再通过getinfo（） 定义的定量获取HTTP返回结果（response），采集的数据将即时入库， 异常响应将触发告警，关键代码如下： 【/data/detector/runmonitor.py】 …… Curlobj = pycurl.Curl（） #创建Curl对象 Curlobj.setopt（Curlobj.URL， url） #定义请求的URL #定义setopt请求器常量，各参数详细说明见2.4节 Curlobj.setopt（Curlobj.CONNECTTIMEOUT， CONNECTTIMEOUT） Curlobj.setopt（Curlobj.TIMEOUT， TIMEOUT） Curlobj.setopt（Curlobj.NOPROGRESS， 0） Curlobj.setopt（Curlobj.FOLLOWLOCATION， 1） Curlobj.setopt（Curlobj.MAXREDIRS， 5） Curlobj.setopt（Curlobj.OPT_FILETIME， 1） Curlobj.setopt（Curlobj.NOPROGRESS， 1） bodyfile = open（os.path.dirname（os.path.realpath（__file__））+"/_body"， "wb"） Curlobj.setopt（Curlobj.WRITEDATA， bodyfile） Curlobj.perform（） bodyfile.close（） #定义getinfo响应返回常量，各参数详细说明见2.4节 self.NAMELOOKUP_TIME=Decimal（str（round（Curlobj.getinfo（Curlobj.NAMELOOKUP_TIME）， 2））） self.CONNECT_TIME=Decimal（str（round（Curlobj.getinfo（Curlobj.CONNECT_TIME）， 2））） self.PRETRANSFER_TIME=Decimal（str（round（Curlobj.getinfo（Curlobj.PRETRANSFER_TIME）， 2））） self.STARTTRANSFER_TIME=Decimal（str（round（Curlobj.getinfo（Curlobj.STARTTRANSFER_TIME）， 2））） self.TOTAL_TIME = Decimal（str（round（Curlobj.getinfo（Curlobj.TOTAL_TIME），2））） self.HTTP_CODE = Curlobj.getinfo（Curlobj.HTTP_CODE） …… 最后，配置系统crontab，5分钟作一次数据采集，内容如下： */5 * * * * /usr/bin/python /data/detector/runmonitor.py > /dev/null 2>&1 15.4.3　rrdtool作业 rrdtool作业实现从MySQL导出数据并更新到rrdtool中，以便为后面 的rrdtool报表功能提供数据支持。具体方法是通过查询 webmonitor_monitordata表字段MARK为'0'的记录，再将数据通过 rrdtool.updatev（）方法做rrdtool更新，最后更新数据库标志MARK 为'1'。rrdtool作业部署在任一台安装rrdtool模块的主机上即可，本示例 的rrdtool作业与Web Server部署在同一台主机上。部分关键源码如下： 【/data/www/Servermonitor/webmonitor/updaterrd.py】 def updateRRD（self，rowobj）： #更新rrd文件方法 if str（rowobj["HTTP_CODE"]）=="200"： #非HTTP200状态标志“1” unavailablevalue=0 else： unavailablevalue=1 FID=rowobj["FID"] time_rrdpath=RRDPATH+'/'+str（self.getURL（FID））+'/'+str（FID） +'_'+\ str（self.rrdfiletype[0]）+'.rrd' #指定三个特性数据rrdtool文件位置 download_rrdpath=RRDPATH+'/'+str（self.getURL（FID）） +'/'+str（FID）+'_'+\ str（self.rrdfiletype[1]）+'.rrd' unavailable_rrdpath=RRDPATH+'/'+str（self.getURL（FID）） +'/'+str（FID）+'_'+\ str（self.rrdfiletype[2]）+'.rrd' try： #将查询的MySQL记录更新到rrd文件 rrdtool.updatev（time_rrdpath，'%s：%s：%s：%s：%s：%s' % （str（rowobj["DATETIME"]）\ ，str（rowobj["NAMELOOKUP_TIME"]），str（rowobj["CONNECT_TIME"]）， str（rowobj["PRETRANSFER_TIME"]），str（rowobj["STARTTRANSFER_TIME"]）， str（rowobj["TOTAL_TIME"]））） rrdtool.updatev（download_rrdpath，'%s：%s' %（str（rowobj ["DATETIME"]），\ str（rowobj["SPEED_DOWNLOAD"]））） rrdtool.updatev（unavailable_rrdpath，'%s：%s' % （str（rowobj ["DATETIME"]）\ ，str（unavailablevalue））） self.setMARK（rowobj["ID"]） #更新数据库标志 except Exception，e： logging.error（'Update rrd error：'+str（e）） def setMARK（self，_id）： #更新已标志记录方法 try： self.cursor.execute（"update webmonitor_monitordata set \ MARK='1' where ID='%s'"%（_id）） self.conn.commit（） except Exception，e： logging.error（'SetMark datebase error：'+str（e）） def getNewdata（self）： #获取未标志的新记录方法 try： self.cursor.execute（"select ID，FID，NAMELOOKUP_TIME，CONNECT_ TIME，PRETRANSFER_TIME，STARTTRANSFER_TIME，TOTAL_TIME，HTTP_CODE， SPEED_DOWNLOAD，DATETIME from webmonitor_monitordata where MARK='0'"） for row in self.cursor.fetchall（）： self.updateRRD（row） except Exception，e： logging.error（'Get new database error：'+str（e）） 同目录下的config.py为rrdtool作业配置文件，定义了数据库连接信 息及项目路径等信息，可根据实际情况相应修改，最后配置系统 crontab，建议与采集同一执行频率，如每5分钟，内容如下： */5 * * * * /usr/bin/python /data/www/Servermonitor/webmonitor/updaterrd.py > /dev/null 2>&1 15.5　服务器端功能设计 服务器端以Web的形式作为服务平台，以Django作为开发框架，结 合rrdtool模块实现了业务添加（rrdtool create）、报表绘图（rrdtool graph）等功能。另外，项目改用直接操作SQL方式来代替Django的 ORM，为熟悉SQL的人员提供另一种选择。下面详细介绍项目配置及功 能实现方法。 15.5.1　Django配置 作为一个新Django项目，第一步需要创建一个项目，操作如下： # cd /data/www # django-admin.py startproject Servermonitor 在创建的omaudit目录中修改urls.py，添加App的URL映射规则，内 容如下： from django.conf.urls.defaults import * urlpatterns = patterns（'webmonitor.views'， （r'^$'，'index'）， #映射到index方法，实现前端首页渲染 （r'add_do/'，'adddo'）， #映射到adddo方法，实现新增业务提交服务器端处理 （r'add/'，'add'）， #映射到add方法，实现新增业务页面渲染 （r'monitorlist/'，'monitorlist'）， #映射到monitorlist方法，实现前端扫描 记录列表展示 ） 修改项目settings.py，关键配置项如下： import os BASE_DIR = os.path.dirname（os.path.abspath（__file__）） SYSTEM_NAME="分布式质量监控平台 V1.0" #定义系统名称 IDC={'ct'：'电信'，'cnc'：'联通'，'cmcc'：'移动'} #定义采集IDC RRDPATH=BASE_DIR+"/rrd" #rrdtool rrd文件存储路径 PNGPATH=BASE_DIR+"/site_media/rrdtool" #rrdtool 生成png存储路径 #定义webmonitor app路径，调用graphrrd.sh用rrd绘图相关参数 MAINAPPPATH=BASE_DIR+"/webmonitor" # TIME_ALARM=1 #定义“业务请求响应时间统计”图表告警线阈值（HRULE），单位为秒 TIME_YMAX=1 #定义“业务请求响应时间统计”图表Y轴最大值，单位为秒 DOWN_APEED_YMAX=8388608 #定义“业务下载速度统计”图表Y轴最大值，单位为字节 项目包括两个App，其中，webmonitor为功能应用，publicclass用 于提供公共方法调用。以下结合具体功能对两个App进行介绍。 15.5.2　业务增加功能 业务增加模块后台实现了两个功能点：一为将业务信息写入 MySQL数据库，包括业务名称、监控URL、告警通知方式、探测点及 规则等；二为创建所选择的探测点三个图表对应的rrdtool文件，图表包 括业务请求响应时间统计、业务下载速度、业务可用性统计。前端功能 截图如图15-4所示。 图15-4　前端功能截图 创建rrd文件功能利用了rrdtool模块的create（）方法实现，实现源 码如下： """ =创建rrd -create_rrd（url） """ def create_rrd（url）： URL=url domain=GetURLdomain（url） #调用GetURLdomain（）方法获取URL域名部分 HID=[] cur_time=str（int（time.time（））） #获取当前Linux时间戳，作为 rrdool.create方法的start参数值 HID=getID（URL） #调用getID（）方法获取URL对应的所有采集点ID for id in HID： #遍历采集点ID try： #参数指定rrd文件路径，如“项目根目录/rrd/www.baidu.com/17_time.rrd”； # step指定步长，设置为300秒，即每隔5分钟收到一个值；start指定第一条记录的 起 #始时间，使用cur_time变量指定 rrd_time=rrdtool.create（settings.RRDPATH+'/'+str（domain） +'/'+str（id）+ \ '_time.rrd'，'--step'，'300'，'--start'，cur_time， 'DS：NAMELOOKUP_TIME：GAUGE：600：0：U'， #定义数据5个 数据源（DS） 'DS：CONNECT_TIME：GAUGE：600：0：U'， #GAUGE计量类型， 收到数据后 #直接存入RRD； 'DS：PRETRANSFER_TIME：GAUGE：600：0：U'， #‘600’为心 跳值，即两 #个刻度无效时，使 用 'DS：STARTTRANSFER_TIME：GAUGE：600：0：U'， #UNKNOWN 填充；0：U #输入数据的界 限 'DS：TOTAL_TIME：GAUGE：600：0：U'， 'RRA：AVERAGE：0.5：1：600'， #定义数据存放格式（RRA）， 分别为平均、 #最大、最小合并数据 'RRA：AVERAGE：0.5：6：700'， #方式，其他参数说明可参考 3.2节案例 #源码说明 'RRA：AVERAGE：0.5：24：775'， 'RRA：AVERAGE：0.5：288：797'， 'RRA：MAX：0.5：1：600'， 'RRA：MAX：0.5：6：700'， 'RRA：MAX：0.5：24：775'， 'RRA：MAX：0.5：444：797'， 'RRA：MIN：0.5：1：600'， 'RRA：MIN：0.5：6：700'， 'RRA：MIN：0.5：24：775'， 'RRA：MIN：0.5：444：797'） if rrd_time： logging.error（rrdtool.error（）） （其他两张图表rrdtool.create方法类似，此处省略） except Exception，e： logging.error（'create rrd error！'+str（e）） 针对“www.baidu.com”业务增加成功后，执行“#ll rrd/www.baidu.com”，输出已生成的rrd文件清单，见图15-5。前 缀“17_、18_”代表不同运营商探测点ID。对采集端而言，一个运营商被 视为一个独立业务，产生的数据也是独立的。比如，在增加业务时选择 了电信、联通两个运营商探测点，对该业务做数据采集时，将产生两份 数据。 图15-5　生成不同运营商的rrd数据文件 15.5.3　业务报表功能 分布式质量监控平台提供了非常丰富的报表功能，常规报表包括 最近3小时、当天、当前月、当前年；自定义报表根据选择的时间范围 定制。在页面中提交前保持起始时间与结束时间为空则为常规报表，最 新3小时报表具体见图15-6。 图15-6　输出业务“当前（最新3小时）”报表 自定义报表根据选择的时间范围进行rrdtool查询，结果如图15-7所 示。 图15-7　输出自定义时间报表 两种报表实现原理是通过定制graph方法的“--start”参数来实现，如 常规报表中当前、日、月、年图表对应分别 为“-3h、-1day、-1month、-1year”，参数“--end”为当前时间；自定义报 表采用提交的起始时间与结束时间来对应“--start”与“--end”参数。平台 rrdtool graph生成图表时要求有中文支持，但Python的rrdtool模块没有封 装“--font”参数，为了解决此问题，最终采用原生rrdtool命令行方案，在 Django中视图中通过os.system（）方法来调用，实现关键代码如下： 【/data/www/Servermonitor/webmonitor/graphrrd.sh】 #！/bin/sh rrdfile=$1 #接收rrdtool文件路径 pngfile=$2 #接收生成png图片路径 rrdtype=$3 #接收rrd类别，区分定义的三种图表 appname=$4 #接收业务名称 GraphStart=$5 #接收rrdtool起始时间 GraphEnd=$6 #接收rrdtool结束时间 ymax=$7 #接收Y轴最大值 Alarm=$8 #接收告警红线值 #定义两种字体 rrdtool_font_msyhbd="/data/www/Servermonitor/site_media/font/msyhbd.ttf" rrdtool_font_msyh="/data/www/Servermonitor/site_media/font/msyh.ttf" if [ "$rrdtype" == "time" ]； then /usr/local/rrdtool/bin/rrdtool graph ${pngfile} -w 500 -h 207 \ -n TITLE：9：${rrdtool_font_msyhbd} \ #定义标题字体 -n UNIT：8：${rrdtool_font_msyh} \ #定义Y轴单位字体 -n LEGEND：8：${rrdtool_font_msyh} \ #定义图例字体 -n AXIS：8：${rrdtool_font_msyh} \ #定义坐标轴字体 -c SHADEA#808080 \ #左上边框颜色 -c SHADEB#808080 \ #右上边框颜色 -c FRAME#006600 \ #数据标记说明边框颜色 -c ARROW#FF0000 \ #X、Y轴箭头颜色 -c AXIS#000000 \ #X、Y轴线颜色 -c FONT#000000 \ #图形所有字体颜色 -c CANVAS#eeffff \ #图形数据区域背景颜色 -c BACK#ffffff \ #图形背景（不含数据区域） 颜色 --title "业务请求响应时间统计-${appname}" -v "速度 （秒）" \ #图表标题 --start ${GraphStart} \ #图表起始时间 --end ${GraphEnd} \ #图表结束时间 --lower-limit=0 \ #限制 Y 轴的下限 --base=1024 \ #修改1k对应的刻度，默认为1000 -u ${ymax} -r \ #定义Y轴最大值 DEF：NAMELOOKUP_TIME=${rrdfile}：NAMELOOKUP_TIME：AVERAGE \ #定义数据源及合 并统计 #类型为AVERAGE DEF：CONNECT_TIME=${rrdfile}：CONNECT_TIME：AVERAGE \ DEF：PRETRANSFER_TIME=${rrdfile}：PRETRANSFER_TIME：AVERAGE \ DEF：STARTTRANSFER_TIME=${rrdfile}：STARTTRANSFER_TIME：AVERAGE \ DEF：TOTAL_TIME=${rrdfile}：TOTAL_TIME：AVERAGE \ COMMENT：" \n" \ AREA：TOTAL_TIME#0011ff：总共时间 \ #用“方块”的形式来绘制“总共时间”数据 #GPRINT定义图表下方的文字说明，参数TOTAL_TIME定义数据来源变量；LAST定义合并（统计）类 型， #指显示当前值； #其他部分为输出的文字及数值格式 GPRINT：TOTAL_TIME：LAST："当前\：%0.2lf %Ss" \ GPRINT：TOTAL_TIME：AVERAGE："平均\：%0.2lf %Ss" \ GPRINT：TOTAL_TIME：MAX："最大\：%0.2lf %Ss" \ GPRINT：TOTAL_TIME：MIN："最小\：%0.2lf %Ss" \ COMMENT：" \n" \ LINE1：NAMELOOKUP_TIME#eeee00：域名解析 \ #用“线条”的形式来绘制“域名解析”数据 GPRINT：NAMELOOKUP_TIME：LAST："当前\：%0.2lf %Ss" \ GPRINT：NAMELOOKUP_TIME：AVERAGE："平均\：%0.2lf %Ss" \ GPRINT：NAMELOOKUP_TIME：MAX："最大\：%0.2lf %Ss" \ GPRINT：NAMELOOKUP_TIME：MIN："最小\：%0.2lf %Ss" \ COMMENT：" \n" \ （“连接时间”、“开始传输”、“第一字节”定义与“域名解析”，此处省略） HRULE：${Alarm}#ff0000："（告警值）" \ #输出告警红线值 COMMENT：" \n" \ COMMENT：" \n" \ COMMENT："\t\t\t\t\t\t\t\t\t\t最后更新 \：$（date '+%Y-%m-%d %H\：%M'）\n" （其他两张图表rrdtool graph参数类似，此处省略） 生成的图表png文件在前端页面中进行引用： #下面为渲染后的HTML标签 第16章　构建桌面版C/S自动化运维平台 OManager与OMServer平台实现了相同的功能，最大的区别是 OManager是基于C/S结构（桌面版本）的，OMServer是B/S结构（Web 版本）的。C/S结构相对于B/S结构，具有交互性更强、存取模式更加安 全、网络通信量低、响应速度更快、利于处理大量数据、可调用操作系 统API等特点。当然，它也有局限性，比如要求相对统一的硬件、操作 系统（版本、类型）等，由于在公司内部局域网使用且使用人群比较固 定，这些条件基本都可以满足。OManager是基于Python的wxpython GUI（图形用户界面）开发，具备跨平台的能力，比如在Linux桌面环 境，源码无须做任何改动即可直接兼容，平台支持的系统有Windows XP、Windows 2000或Windows 2003、Windows 7等；支持Linux 2.6或以 上内核，如Redhat、Ubuntu等发行版。下面对平台进行全面介绍。 16.1　平台功能介绍 与OMServer一样，OManager同样实现了一个集中式的Linux集群管 理基础平台，支持模块扩展功能，管理员可以在OManager平台添加集 群任务模块，其中客户端模块采用XRC（XML Resource）方式动态定 制，服务器端则与OMServer共享一套主控服务器端。OManager实现日 常运维远程操作、文件分发、在线升级等功能；安全方面，采用加密 （RC4算法）指令传输、操作日志记录、个性化配置等；效率方面，管 理员只需选择操作目标对象及操作模块即可完成一个现网变更任务。另 外在用户体验方面，模拟Linux终端效果，接收返回串，并使用Psyco模 块对Python运行程序进行加速。任何人都可以根据自身的业务特点对 OManager平台进行扩展，现已支持XML与现有资产平台进行对接。平 台登录、管理界面见图16-1和图16-2。 图16-1　平台登录页面 图16-2　平台主界面 16.2　系统构架设计 OManager平台采用了两层设计模式。 第一层为客户端交互层，采用了wxpython+xrc+rpyc+MySQL等技 术，实现了客户端与主控服务器端直连通信，rpyc分布式计算框架负责 传输与计算，传输采用加密（RC4算法）方式，保证平台整体安全性； 第二层为集群主控端服务层，支持Saltstack、Ansible、Func等平 台，且具备多机服务的能力。系统架构图见图16-3。 图16-3　系统架构图 从图16-3中可以看出系统两个层次的结构，首先管理员在办公电脑 安装OManager客户端软件包，作为rpyc客户端向rpyc服务器发送加密指 令串，指令串通过“RC4+b64encode+密钥key”进行加密，rpyc服务器端 同时也是Saltstack、Ansible、Func等的主控端，主控端将接收的数据通 过“RC4+b64decode+密钥key”进行解密，解析成OManager调用的任务模 块，结合Saltstack、Ansible或Func向目标业务服务器集群发送执行任 务，执行完毕后，对返回的执行结果做加密/解密处理，最后返回给客 户端，整个任务模块分发执行流程结束。 16.3　数据库结构设计 16.3.1　数据库分析 OManager平台采用了开源数据库MySQL以存储数据，数据库名为 OManager，数据库总共有3张表，表信息说明如下。 ·upgrade：系统升级表； ·users：用户表； ·user_logs：操作日志表。 16.3.2　数据字典 1）upgrade系统升级表。 2）user_logs操作日志表。 3）users用户表。 16.3.3　数据库模型 考虑到平台的通用性，OManager的数据库结构设计得非常简单， 只涉及账号及操作日志等基础表，平台中服务器分类及清单来源于企业 资产库生成的XML文件。数据库中users表存储了管理员的账号信息； user_logs表存储了管理员的操作日志，表中字段“user”配置外键，与 users表中的“admin”字段进行关联，upgrade表存储OManager的版本号， 系统数据库模型见图16-4。 图16-4　系统数据库模型 16.4　系统环境部署 16.4.1　系统环境说明 OManager由wxPython2.8、rpyc-3.2.3、psyco-1.6等开源组件构建。 为了便于读者理解，下面对平台的运行环境、安装部署、开发环境优化 等进行详细说明，环境设备角色表如表16-1所示。 表16-1　系统环境说明表 16.4.2　系统环境搭建 OManager平台基于多种Python第三方模块实现，包括wxpython、 rpyc、MySQL-python、psyco、pywin32等，这些开源组件无论是在开发 效率还是运行速度方面都赢得了很好的口碑，尤其容易上手，可以做到 快速开发、快速实现。wxPython官网提供了非常丰富的demo代码，可 以帮助开发人员做到边学边用，下面介绍平台所需模块及功能说明。 ·MySQL-python-1.2.4b4.win32-py2.7.exe：Python访问MySQL的API 模块。 ·psyco-1.6.win32-py25.exe：Python程序提速模块。 ·pyinstaller-2.0.zip：Python程序打包工具，安装包制作推荐使用 Smart Install Maker。 ·pywin32-218.win32-py2.7.exe：Windows系统API访问库。 ·rpyc-3.2.3.win32.exe：分布式计算框架。 ·wxPython2.8-win32-docs-demos-2.8.12.1.exe：wxPython Demo（可 选项）。 ·wxPython2.8-win32-unicode-2.8.12.1-py27.exe：Python GUI图形 库。 平台重点文件及目录说明见图16-5。 图16-5　系统目录结构及说明 16.5　系统功能模块设计 16.5.1　用户登录模块 OManager平台的登录采用了双重安全校验机制：一种为传统的用 户名与密码匹配，另一种为密钥文件校验方式，实现的原理是在密钥文 件中输入任意随机字符串，通过平台自带的md5sum.exe工具计算出该文 件的md5，将生成的md5字符串更新到users（用户表）管理员账号对应 的Privatekey字段，以root用户的密钥numbers/root.pem为例，使用方法 见图16-6和图16-7。 图16-6　查看密钥文件md5 图16-7　数据库存储的密钥文件md5数据 管理员登录时首先获得选择密钥文件的md5，再与数据库中的 Privatekey字段进行匹配，建议由超级管理员提前开设好所有用户的账号 信息，包括用户名、密码及密钥。再统一将密钥文件以人为单位进行发 放。验证的实现方法源码如下： def Check（self，name， password，Privatekey）： import md5 m = md5.new（password） #使用md5模块计算密码的md5串 md5pass=m.hexdigest（） myrow=DBclass（） #创建数据库连接对象（自定义类） sql = "select admin，privileges from users where admin='%s' and passwd='%s' \ and Privatekey='%s'"% （name， md5pass，Privatekey） #参照MySQL中 的用户名、 #密码、密钥进行校 验 result = myrow.fetchallq（sql） return result #返回结果集 下面是计算密钥文件md5的实现方法，主要用到了hashlib模块： #计算文件md5值，参数fileName为实体文件路径；参数excludeLine为排除的文本行； #参数includeLine为额外包含的行 def md5（fileName， excludeLine=""， includeLine=""）： m = hashlib.md5（） #使用hashlib模块生成一个md5 hash对象 try： fd = open（fileName，"rb"） #打开密钥文件 except IOError： print "Unable to open the file in readmode："， filename return eachLine = fd.readline（） while eachLine： #遍历密钥文件 if excludeLine and eachLine.startswith（excludeLine）： #排除指定 的行 continue m.update（eachLine） #用update方法对行字符串进行md5加密且不断做更新处理 eachLine = fd.readline（） m.update（includeLine） #对额外包含的行做更新和加密处理 fd.close（） return m.hexdigest（） #返回十六进制结果 调用计算文件密钥md5方法： md5（self.Privatekey.GetValue（）） #self.Privatekey.GetValue（）为用户选择 的密钥文件路径 16.5.2　系统配置功能 OManager平台将常用的参数配置化，包括连接数据库、主控端、 传输密钥等信息，当外部环境发生变化时无须做代码变更，简单更新配 置即可，提高了平台的易用性，降低使用门槛，具体是通过 ConfigParser模块操作ini文件实现，效果见图16-8。 图16-8　系统配置功能 手工修改ini文件与界面操作达到的效果是一样的，平台ini文件格 式如下： 【data/config.ini】 [system] height = 765 width = 1024 version = v2014 upversion = 10026 ip = 192.168.1.20 port = 11511 timeout = 10 max_servers = 10 secret_key = ctmj#&；8hrgow_^sj$ejt@9fzsmh_o）-=（byt5jmg=e3#foya6u upgrade_url = http：//update.domain.com/upgrade [db] db_ip = 192.168.1.10 db_user = servmanageruser db_pass = 123456#abc db_name = OManager 使用ConfigParser模块操作ini配置文件非常方便，通过get（）、 set（）方法来读取与更新配置文件。读配置源码如下： self.cf = ConfigParser.ConfigParser（） #创建ConfigParser对象 self.cf.read（sys.path[0]+'/data/config.ini'，encoding='utf8'） #读取配 置文件 #读取“system”节中所有键值到指定的变量 self.cf = ConfigParser.ConfigParser（） self.cf.read（sys.path[0]+'/data/config.ini'） self._syswidth= self.cf.get（"system"，"Width"） self._sysheight= self.cf.get（"system"，"Height"） self._timeout=self.cf.get（"system"，"Timeout"） self._ip=self.cf.get（"system"，"IP"） self._port=self.cf.get（"system"，"Port"） self._max_servers=self.cf.get（"system"，"max_servers"） self._secret_key=self.cf.get（"system"，"secret_key"） self._sysversion= self.cf.get（"system"，"Version"） self._sysUpversion= self.cf.get（"system"，"Upversion"） self._upgrade_url= self.cf.get（"system"，"upgrade_url"） #读取“db”节中所有键值到指定的变量 self._db_ip= self.cf.get（"db"，"db_ip"） self._db_user= self.cf.get（"db"，"db_user"） self._db_pass= self.cf.get（"db"，"db_pass"） self._db_name= self.cf.get（"db"，"db_name"） 更新配置也非常简单，将get（）方法更换成set（），再指定ini的 节、键、值三个元素即可。下面是更新数据库IP参数的代码，其中 self.DB_ip.GetValue（）为输入框的内容。 self.cf.set（"db"， "db_ip"， self.DB_ip.GetValue（）） 16.5.3　服务器分类模块 为了让OManager更具通用性，平台的服务器信息依赖企业现有资 产库数据，通过平台规范好的格式生成XML文件，结合Tree与ListBox控 件实现功能分类与服务器联动，效果见图16-9。 图16-9　服务器分类选择 服务器分类的组织形式与OMserver保持一致，即功能分类→业务 分类→服务器。图16-10为服务器类别的XML数据文件，用来描述服务 器类别信息。 【data/ServerOptioninfo.xml】 图16-10　服务器分类的XML文件 其中，“”标签id属性值为功能分类ID 号，“应用服务器”使用子元素描述功 能分类名称。服务器信息的XML数据文件用来描述服务器的详细属性， 详细内容见图16-11，属性与子元素说明见表16-2。 【data/Serverinfo.xml】（部分内容） 图16-11　服务器信息的XML文件 表16-2　属性与子元素说明 每个管理员所负责的服务器资源通常都不一样，一般以服务器功 能分类的维度划分。OManager可为这种权限要求提供支持，实现的思 路是在users表的privileges（权限角色）字段定义服务器分类ID，其 中“root”为特殊权限，代表超级管理员，所有服务器资源都可见。账 号“demo”的权限配置，以及在平台中展示的效果见图16-12。 图16-12　用户权限配置及展示效果 当窗体（wx.Frame）初始化时，“服务器类别”控件会自动加载数 据，实现的方法是通过遍历以上提到的两个XML数据，将当前账号的权 限ID列表与服务器类别ID进行关联，获取所具备的权限，即拥有的服务 器类别ID。“应用名称”则通过服务器信息的“”元素与服务器类 别ID进行匹配，实现源码如下： import xml.etree.ElementTree as ET import os import sys root_tree = ET.parse（sys.path[0]+'/data/ServerOptioninfo.xml'） #打开服务器 类别XML文档 class_tree = ET.parse（sys.path[0]+'/data/Serverinfo.xml'） #打开服务器信 息XML文档 root_doc = root_tree.getroot（） #获得服务器类别XML文档root节点 class_doc = class_tree.getroot（） #获得服务器信息XML文档root节点 class ServerClassList（）： def Resurn_list（self，UserPrivileges）： #返回服务器类别、应用方法 ServerList_KEY=[] #定义返回的服务器类别、应用信息列表对象 serverclass=[] #定义服务器类别列表对象 serverapp=[] #定义业务应用列表对象 for root_child in root_doc： #遍历服务器类别节点 if not root_child.get（'id'） in UserPrivileges and not UserPrivileges[0]=="root"： continue #没有权限的服务器类别将被忽略 serverclass.append（root_child[0].text.encode（'gbk'）） #追加服 务器类 #别名称 serverapp=[] for class_child in class_doc： #遍历服务器信息节点 #如与功能分类ID相匹配，则追加到serverapp #通过index（）方法产生的异常判断当前是否已经存在于serverapp中 if class_child[6].text==root_child.get（'id'）： try： serverapp.index（class_child[4].text.encode（'gbk'）） except： serverapp.append（class_child[4].text.encode（'gbk'）） serverclass.append（serverapp） ServerList_KEY.append（serverclass） serverclass=[] #返回结果串格式：[['应用服务器'，['www.a.com'，'www.b.com']]，['数据库服务器'， ['www.c.com']]...] return ServerList_KEY 16.5.4　系统升级功能 相比B/S结构程序，C/S结构的另一缺点是不方便升级，部分软件 甚至要求重新安装、重启计算机等操作。为了解决此问题，OManager 在系统升级方面结合了B/S的模式，将升级包放在远端，由管理员触发 升级操作，同时不影响当前的其他操作，重启OManager程序后即可完 成升级。OManager系统升级流程图见图16-13。 图16-13　系统升级流程图 OManager系统升级的原理：首先将升级描述文件 （updateMS.xml）、升级包上传至版本服务器，由管理员触发升级操 作，再通过urllib模块实现HTTP方式下载updateMS.xml文件并进行分 析，获取所有需要升级的程序包，包括远程URL及下载本地存储地址， 最后遍历下载所有升级包到指定的位置，完成整个升级过程。下面是升 级描述文件updateMS.xml的示例： 【tmp/updateMS.xml】 <？xml version="1.0" encoding="UTF-8"？> data/Serverinfo.xml /data/Serverinfo.xml data/ServerOptioninfo.xml /data/ServerOptioninfo.xml OManager.10026.exe /OManager.exe 在此XML文件中，localsrc与remotesrc分别表示本地存储地址及远 程URL路径，远程URL文件与本地路径建议保持一致，可以提高系统的 可维护性，如本地的“data/Serverinfo.xml”与远程 的“/data/Serverinfo.xml”，远程升级包目录结构见图16-14。 图16-14　远程升级包存储路径 在此配置中，需要升级的程序包为OManager.exe、Serverinfo.xml、 ServerOptioninfo.xml三个，变更项包括了添加主机信息、主程序优化 等，下面介绍升级步骤。 1）上传升级相关文件到版本服务器指定位置，具体见图16-14。 2）更新数据库中平台最新版本号，即更新upgrade表的version字 段，如更新版本号为“10026”；用户会根据data/config.ini中的upversion键 值与最新版本号进行匹配，当小于最新版本号时将触发升级。 3）点击“系统升级”工具栏图标进行升级，升级成功后如图16-15所 示。 升级结束后，平台根目录下多了一个“OManager.10026.exe”最新版 本的程序包，见图16-16。 运行“OManager.10026.exe”，在主程序左侧的服务器列表框中多了 一台“218.31.20.11”主机，见图16-17。再查看data/config.ini中的upversion 键值，已经改为“10026”，说明系统已成功升级。 图16-15　系统升级成功 图16-16　升级后的文件列表 图16-17　更新后的主机列表 介绍完系统升级的操作过程，下面介绍OManager实现升级功能的 源码分析，使用模块urllib.urlopen（url）.read（）方法实现HTTP协议文 件下载，使用xml.etree.ElementTree模块实现XML文件的分析。 def load_data（self，event）： #系统升级方法 try： if self.button.GetLabel（）==u"关闭"： self.Destroy（） url=self.updateURL+"/updateMS.xml" #指定升级描述文件远程及本地路 径 localfile=sys.path[0]+'/tmp/updateMS.xml' if not self.download（url，localfile）： #下载升级描述文件 return except Exception，e： wx.MessageBox（u"更新描述文件下载失败"+str（e），u"OManager："， style=wx. OK|wx.ICON_ERROR） self.Destroy（） return try： #打开升级描述文件，为下面的分析做好准备 import xml.etree.ElementTree as ET update_tree = ET.parse（sys.path[0]+'/tmp/updateMS.xml'） up_doc = update_tree.getroot（） except Exception，e： wx.MessageBox（u"导入更新包出错"，u"OManager："， style=wx.OK|wx.ICON_ERROR） self.Destroy（） return try： #遍历描述文件，获取升级描述文件中所有程序包的远程及本地路径，调用 #download（）方法实现下载 upgrade_count=0 for cur_child in up_doc： upgrade_count+=1 url=self.updateURL+cur_child[1].text localfile=sys.path[0]+'/'+cur_child[0].text if self.download（url，localfile）==False： break self.cf.set（"system"， "Upversion"， self.lastversion） #更新 config.ini #最新版本号 self.cf.write（open（sys.path[0]+'/data/config.ini'， "w"）） self.ConnStaticText.SetLabel（u"成功更新"+str（upgrade_count） +"个数据包..."） self.button.SetLabel（u"关闭"） except Exception，e： wx.MessageBox（u"系统文件下载失败"，"OManager"， style=wx.OK|wx.ICON_ERROR） self.Destroy（） return finally： pass event.Skip（） 16.5.5　客户端模块编写 OManager提供客户端模块开发支持，与OMserver的实现思想一 样，区别是OMserver基于HTML表单来定义，而OManager基于XRC。 XRC（XML Resource）的设计来源于wxWidgets，原理是将界面设计的 工作从程序中独立出来，类似于Django开发框架中模板系统的角色，目 的是将业务逻辑与界面进行分离，好处是代码的结构会更加清晰，可读 性也会大大提高。具体做法是通过XML格式定义系统界面，当程序运行 时再载入。XRC的使用手册见 http://wiki.wxwidgets.org/Using_XML_Resources_with_XRC。OManager 平台将功能模块采用XRC设计，在主程序中按功能分类导入，效果见图 16-18和图16-19。 图16-18　功能模块菜单 OManager平台提供了最多2个控件参数的定义，控件类别支持 wxSpinCtrl（微调控制器）、wxListBox（列表控件）、wxTextCtrl（文 本输入控件）等，当然，扩展更多的控件类型也非常简单，前提是需要 了解各控件的属性及方法，其中控件值会被当成模块参数通过rpyc传输 到服务器端。下面为“bas_1001_系统日志.xrc”功能模块的设计，包括一 个容量控件wxPanel对象，wxPanel对象包含了两个对象，一个文字标签 控件wxStaticText对象，通过元素定义该模块的功能文字说明；另 一个对象为微调控制器wxSpinCtrl，通过元素定义默认值， 与定义控件的最小值及最大值。更多的控件介绍请参考： http://wiki.wxwidgets.org/Using_XML_Resources_with_XRC。该功能模块 的XRC定义内容如下： 图16-19　功能模块窗口 【Module/bas_1001_系统日志.xrc】 <？xml version="1.0" encoding="utf-8"？> 在主程序中，通过xrc.XmlResource（）方法加载XRC模块文件， 使用xrc.XRCCTRL（）方法获取控件对象，使用对象的GetValue（）或 GetStringSelection（）方法得到控件输入值，其中wxSpinCtrl、 wxTextCtrl控件使用GetValue（）方法，wxListBox控件使用 GetStringSelection（）方法。在主程序中调用XRC的方法，源码（部 分）如下： from wx import xrc self.res = xrc.XmlResource（sys.path[0]+'/Module/bas_1001_系统日志.xrc'） #加载模块资源文件 panel = self.res.LoadPanel（self， "panel"） #加载panel面板控件 try： self.Parameter1 = xrc.XRCCTRL（panel， 'Parameter1_object_id'） #加载控 件1对象名 except Exception，e： pass #获取不同控件的返回值，GetClassName（）方法返回控件类别名，用于定位不同控件获取value的方 法 try： if self.Parameter1.GetClassName（）=="wxSpinCtrl"： self.Parameter1_value=self.Parameter1.GetValue（） elif self.Parameter1.GetClassName（）=="wxListBox"： self.Parameter1_value=self.Parameter1.GetStringSelection（） except Exception，e： pass … 平台功能模块XRC文件命名遵循一定的标准规范，即“模块功能类 别_模块ID_功能中文名称.xrc”，文件名将会以“_”作为分隔符，拆分的 数据将应用到系统功能中，比如文件名前缀“模块功能类别”会根据不同 类别代号加载到不同功能菜单，实现源码（部分）如下： bashmenu = wx.Menu（） #定义"基本功能"二级菜单 appmenu = wx.Menu（） #定义"应用功能"二级菜单 dbmenu = wx.Menu（） #定义"数据库功能"二级菜单 servicemenu = wx.Menu（） #定义"后台服务功能"二级菜单 middlemenu = wx.Menu（） #定义"中间件功能"二级菜单 #根据不同XRC文件前缀，将三级菜单追加到对应的二级菜单中 for file_info in self.Moduledetail： file_array=string.split（file_info，'_'） if file_info[0：3]=="bas"： bashmenu.Append（int（file_array[1]），file_array[2]， file_array[2]） elif file_info[0：3]=="app"： appmenu.Append（int（file_array[1]），file_array[2]，file_array[2]） elif file_info[0：3]=="dba"： dbmenu.Append（int（file_array[1]），file_array[2]，file_array[2]） elif file_info[0：3]=="ser"： servicemenu.Append（int（file_array[1]），file_array[2]， file_array[2]） elif file_info[0：3]=="mid"： middlemenu.Append（int（file_array[1]），file_array[2]， file_array[2]） 文件“模块ID”段将作为该模块的唯一标识，与服务器端模块进行 匹配。另外，要求模块XRC文件必须存放于平台Module目录。以下为客 户端的所有模块清单，其中ID为“100*”的模块，服务器端已完成对接， 其他部分读者可以根据自身的需求自行开发或扩展，平台功能模块XRC 文件列表见图16-20。 图16-20　功能模块XRC文件列表 16.5.6　执行功能模块 由于OManager只有两层结构，与服务器端的通信就是一个交互过 程，由客户端发起任务请求，服务器执行任务并返回操作结果，操作步 骤见图16-21。 图16-21　功能模块执行步骤 为提高平台的通用性及兼容度，OManager的数据封装、传输、加 密方式及服务器端与OMserver一致，即传输采用了rpyc框架、RC4加密 算法、服务器端同一监听服务。服务器端的实现本节不再做介绍，具体 可参考13.5.3节。下面介绍基于wxPython实现的客户端提交任务的几个 方法。 try： conn=rpyc.connect（self._ip，int（self._port）） #连接rpyc服务器 #调用login（）方法实现通信账号、密码校验 conn.root.login（'OMuser'，'KJS23o4ij09gHF734iuhsdfhkGYSihoiwhj38u4h'） except Exception，e： message=u"系统提示：连接远程服务器超时。"+str（e） wx.MessageBox（message，u"OManager服务器管理平台："， style=wx.OK|wx.ICON_ERROR） return #调用OnGetSelectServerinfo方法获取计算机名、字符串、服务器数量 _server_list=self.OnGetSelectServerinfo（'serverserial_ip'，1， int（self._max_servers）） #判断用户是否选择了至少一台服务器，不选择则直接返回 if not _server_list： return #操作记录调用了Addsyslogs（）方法写入user_logs表，用于操作记录追溯 Intologs.Addsyslogs（self.CurrentAdmin，u"操作对象："+\ self.OnGetSelectServerinfo（'lip'，1，20）+u"-操作MID："+GetModelestrrow[0]） #合并提交串，格式：“模块ID@@主机IP*主机名，N@@参数1@@参数2@@” 例如：“1001@@192.168.1.21*SN2013-08-021@@30@@” put_string+=str（GetModelestrrow[0]） +"@@"+_server_list+"@@"+Parameter_string #调用tencode（）方法对提交串进行加密 put_string=FunApp.tencode（put_string，self._secret_key） # #调用rpyc的Runcommands（）方法执行任务，返回的结果通过tdecode（）方法解密OPresult= FunApp.tdecode（conn.root.Runcommands（put_string）， self._secret_key）.decode（'utf8'） #在“输出消息”框输出返回结果 self.OnWriteMessageBox（FunApp.format_str（OPresult）） conn.close（） 下面为“输出消息”框输出消息方法，使用SetInsertionPoint（0）获 取消息插入点，通过WriteText（）方法写入消息，代码如下： def OnWriteMessageBox（self，message）： t = time.localtime（time.time（）） st = time.strftime（"%Y-%m-%d %H：%M：%S"， t） #获取当前系统时间 self.SysMessaegText.SetInsertionPoint（0） #设置消息框插入点，参数0为开 始位置 #将方法参数message（消息内容）写入消息框 self.SysMessaegText.WriteText（"++++++++++++"+str（st） +"++++++++++++++++\n"+message+"\n"） self.SysMessaegText.SetInsertionPoint（0） 执行任务返回的结果见图16-22。另外OManager的窗体元素支持任 意角度的组合、分离、拖动等，管理员可以根据不同喜好进行调整。 16.5.7　平台程序发布 为了让平台在没有Python以及第三方模块包的环境中正常运行， 对源程序进行打包发布是项目最后一个环节，对此 pyinstaller（http://www.pyinstaller.org）提供了很好的解决方案，其支持 Linux与Windows平台可执行程序的制作，简单易用。Pyinstaller 2.0无须 安装，解压即可使用，下面为平台打包的bat批处理脚本。 图16-22　功能模块执行结果 【install.bat】 cd D：\python\OManager\OManager d： rd /S /Q dist rd /S /Q build del logdict2.7.3.final.0-1.log python d：/soft/pyinstaller-2.0/pyinstaller.py --onedir -w -- icon=img/imac.ico OManager.py copy MD5sum.exe dist\OManager xcopy /s data dist\OManager\data\ xcopy /s img dist\OManager\img\ xcopy /s Module dist\OManager\Module\ xcopy /s numbers dist\OManager\numbers\ xcopy /s tmp dist\OManager\tmp\ rd /S /Q build rd /S /Q build del logdict2.7.3.final.0-1.log 假设项目目录为“D:\python\OManager\OManager”，参数“-- onedir”为创建的一个目录，包含exe文件以及相关依赖类包；“-w”表示 制作视窗界面，无控制台（命令行）；“--icon”指定执行程序图 标；“OManager.py”为平台入口源程序。通过xcopy复制平台相关目录到 打包路径（如dist\OManager）。打包后的目录结构见图16-23。 图16-23　打包后生成的文件列表 最后一步就是制作安装包，我们可以简单对目录制作压缩包发 布，也可以使用更加专业的安装包制作工具，如Advanced Installer、 Inno Setup、Smart Install Maker等，最终将生成一个安装包文 件“Setup.exe”，单击安装后的效果见图16-24。 图16-24　系统安装界面 参考提示　RC4加密算法参考文章 http://www.snip2code.com/Snippet/27937/Blockout-encryption-decryption- methods-p。 Table of Contents 本书赞誉 前言 第一部分 基础篇 第1章 系统基础信息模块详解 1.1 系统性能信息模块psutil 1.2 实用的IP地址处理模块IPy 1.3 DNS处理模块dnspython 第2章 业务服务监控详解 2.1 文件内容差异对比方法 2.2 文件与目录差异对比方法 2.3 发送电子邮件模块smtplib 2.4 探测Web服务质量方法 第3章 定制业务质量报表详解 3.1 数据报表之Excel操作模块 3.2 Python与rrdtool的结合模块 3.3 生成动态路由轨迹图 第4章 Python与系统安全 4.1 构建集中式的病毒扫描机制 4.2 实现高效的端口扫描器 第二部分 高级篇 第5章 系统批量运维管理器pexpect详解 5.1 pexpect的安装 5.2 pexpect的核心组件 5.3 pexpect应用示例 第6章 系统批量运维管理器paramiko详解 6.1 paramiko的安装 6.2 paramiko的核心组件 6.3 paramiko应用示例 第7章 系统批量运维管理器Fabric详解 7.1 Fabric的安装 7.2 fab的常用参数 7.3 fabfile的编写 7.4 Fabric应用示例 第8章 从“零”开发一个轻量级WebServer 8.1 Yorserver介绍 8.2 功能实现方法 第9章 集中化管理平台Ansible详解 9.1 YAML语言 9.2 Ansible的安装 9.3 定义主机与组规则 9.4 匹配目标 9.5 Ansible常用模块及API 9.6 playbook介绍 9.7 playbook角色与包含声明 9.8 获取远程主机系统信息：Facts 9.9 变量 9.10 条件语句 9.11 循环 9.12 示例讲解 第10章 集中化管理平台Saltstack详解 10.1 Saltstack的安装 10.2 利用Saltstack远程执行命令 10.3 Saltstack常用模块及API 10.4 grains组件 10.5 pillar组件 10.6 state介绍 10.7 示例：基于Saltstack实现的配置集中化管理 第11章 统一网络控制器Func详解 11.1 Func的安装 11.2 Func常用模块及API 11.3 自定义Func模块 11.4 非Python API接口支持 11.5 Func的Facts支持 第12章 Python大数据应用详解 12.1 环境说明 12.2 Hadoop部署 12.3 使用Python编写MapReduce 12.4 实战分析 第三部分 案例篇 第13章 从零开始打造B/S自动化运维平台 13.1 平台功能介绍 13.2 系统构架设计 13.3 数据库结构设计 13.4 系统环境部署 13.5 系统功能模块设计 第14章 打造Linux系统安全审计功能 14.1 平台功能介绍 14.2 系统构架设计 14.3 数据库结构设计 14.4 系统环境部署 14.5 服务器端功能设计 第15章 构建分布式质量监控平台 15.1 平台功能介绍 15.2 系统构架设计 15.3 数据库结构设计 15.4 系统环境部署 15.5 服务器端功能设计 第16章 构建桌面版C/S自动化运维平台 16.1 平台功能介绍 16.2 系统构架设计 16.3 数据库结构设计 16.4 系统环境部署 16.5 系统功能模块设计