运维自动化基础建设|系统环境初始化
运维自动化基础建设|系统环境初始化
网上可以看到不少使用
shell编写的系统初始化脚本，在本篇文档里，我们选择了Ansible作为我们操作的入口工具来进行系统的初始化工作
手动维护场景复现
小B，给我10台安装php7.3环境的机器
小B拿到需求之后，开始编写Shell脚本，一顿操作猛如虎，总算在其中一台机器上安装好了php环境，这个时候小A又过来说，不好意思啊，小B，我刚才少说了一点，我们需要的这批机器Opcache的大小设置需要定为xxx, 另外就是需要mongo的插件，小B一听就来说了，你是猴子派来逗我的么，没办法，活还是要干的，然后就汇过去咔咔一顿敲，等到下班的时候机器交付了，小B愉快的下班了
第二天小A又来了，说小B你给的什么破机器，我跑应用单个进程可以打开1024个文件就不行了，我自己本机可以跑多少的吧啦吧啦说了一大堆，这时候小B不淡定了，我一直都是这么操作的啊，咋了，在这个紧急关头，大B挺身而出，说我来排查下是什么问题，作为高级扛服务器的大B登录到机器上也是咔咔一顿猛如虎的操作，发现了一些端倪,原来是是/etc/security/limits.conf按照默认配置，并没有修改。大B改完之后让小A回去再测试下，果然没问题了，此事告一段落~
其他场景
小C过来跟大B说，大B哥，我们需要一套ES集群，审批已经通过，你这边加急帮我们处理下呗，大B看着小C满带歉意的表情，大手一挥说没问题，我这就去写脚本，然后开始坐下来写python + shell来进行即将接下来的工作的操作，写好之后大B简单的测试了下就把这事甩给小B了，让小B把脚本跑一遍，小B拿到脚本之后再新开的几台机器上运行，哎呀，卧槽，无情，居然没有运行，但是报错的信息只有一句话install es cluster faild, 这可如何是好，小B如何，只好去找大B，大B心中也是万分恼火，让你跑个脚本都跑不好，还是我来吧，大B登录到机器上自己去跑脚本，也是不能正常运行，然后开始针对关键的地方进行print来排错，经过了N久的紧张排查，发现原来是某处依赖有问题，替换之后再来一次，小B和大B愉快的去吃饭去了~
疼点
如上所述，很多时候团队协作过程中常常会发生几个比较常见的疼:
•各自维护一套自己写的shell脚本，但是没有严格按照规范去走，导致别人拿到脚本看的是一辆懵逼， 这就是不统一，没有标准•针对可持续性发展的规划较弱，比如大B擅长python+shell, 但是小B对python不是很了解，这个时候让小B去跑脚本，除了问题肯定不能第一时间解决
系统初始化都要做些什么
操作如下所示，但不局限于下面的描述
•创建应用账号，密码固定（或者nologin），避免使用root账号启动服务，配套的是相关的目录以及目录权限的修改•批量修改root密码•管理iptables和selinux•时间同步定时任务，周期缩短，5分钟同步一次•禁用ipv6•添加第三方yum源•初始化工具安装，常见的开发包和工具安装•swap设定•系统连接数设定•history添加特定的显示方式•ssh dns设定•禁止maildrop的增长•添加了inodes命令，可以快速检索inodes占用情况•添加maybe指令，执行rm -rf *的时候会弹出提醒•大量实用命令别名实现
注意事项
•结合前两篇文档所描述，如果你是使用kvm的模板创建机器的场景的话，按照标准化的操作去走，主机名和IP地址的操作同样可以放在系统初始化里面去做
操作步骤
ansible-galaxy 闪亮登场
$ ansible-galaxy init init-system
[WARNING]: log file at /var/log/ansible.log is not writeable and we cannot create it, aborting
- init-system was created successfully
$ cd init-system
$ tree .
.
├── README.md
├── defaults
│ └── main.yml
├── files
├── handlers
│ └── main.yml
├── meta
│ └── main.yml
├── tasks
│ └── main.yml
├── templates
├── tests
│ ├── inventory
│ └── test.yml
└── vars
└── main.yml
8 directories, 8 files然后开始编写自己的tasks
建议每个任务一个单独的yaml文件，然后再main.yaml里整合
举个栗子
•修改root密码
---
- name: change root password
shell: echo "root:zhuima" | chpasswd
ignore_errors: True
tags: changpass•定时任务添加
---
- name: create ntpdate sync infomation log floder if path=/var/log/ntpdate not exists
file: path=/var/log/ntpdate state=directory
register: result
ignore_errors: True
tags: cfloder
- name: show message
debug:
var: result
ignore_errors: True
tags: cfloder
- name: sync network time every 10 minutes
copy: src={{ ntpfile }} dest=/var/spool/cron/{{ ntpfile }} owner=root group=root mode=0600 backup=yes
ignore_errors: True
when: result.state == "directory"
tags: synctime其他
看到上面的描述，如果你认为系统初始化仅仅是做了这些操作的话，那就错了，每个人做每件事情的本意都是有目标的，前面我们也提到了，我们是要进行系统初始化操作，那么初始化完之后要如何呢？给谁用？怎么用？他们需要什么其他的环境或工具么？
so, 如刚才提出的几个问题，在没有运维平台的前提下，我们可以结合Rundeck或jenkins来作为我们的操作入口，实现自助化按需操作，如下图所示:
如上图所示，配套其他的Ansible的palybook roles， 我们可以随意组合来进行我们需要的环境的初始化操作,
PS：所有的roles执行前默认都会执行init-system这个roles, init-system是最基础的操作。
TiPS
使用Ansible创建账号的时候生成密码注意事项
Ansible的user模块创建账号的时候需要使用密文，所以使用明文的话会不成功，
对password进行密码加密:
openssl passwd -salt -1 "password"总结
•系统初始化能够确保线上线下环境保持一致，减少因为环境差异化而导致的生产故障，•另外就是能够复用之前的工作，不至于每次新来需求就重头撸起shell脚本，可复用性太差•快速交付，减少人为参与和时间的消耗•Ansible并不是万能的，它只能帮助我们解决我们碰到的大部分问题，由于Ansible的约束太过于宽松，在便捷使用的同时也会带来不可控的点，翻看最近几年的新闻不难发现，由Ansible造成的生产故障也屡见不鲜
不得不说的是，这一块的工作和前面的IP规划、主机名规划是相辅相成的， 另外就是安利下Ansible, 自动化不是梦，值得拥有~