肥城网站制作,网站建设费用 优帮云,开发商交房需要提供哪些证书,磁力珠语法以及实际案例 平时我们在进行日志收集的时候#xff0c;往往会在每台机器上安装filebeat#xff0c;并且由于每台机器运行服务的不同#xff0c;那么收集日志的配置文件也是不一样的#xff0c;如何快速高效的部署filebeat以及拥有不同的配置文件就是我们要思考的问题往往会在每台机器上安装filebeat并且由于每台机器运行服务的不同那么收集日志的配置文件也是不一样的如何快速高效的部署filebeat以及拥有不同的配置文件就是我们要思考的问题当然不可能一台机器一台机器的修改配置文件。 接下来我将会以一个我自己写的filebeat相关的role举例来分析role模式涉及的一些规范以及如何写一个好的任务编排, 案例中的filebeat的role模式拥有对filebeat的安装更新配置的功能。 role其实是对之前使用playbook的文件目录进行了一些规范(比如必须有roles目录且和playbook入口文件在同一位置roles目录下的各个特定role的目录也是固定命名的)。 代码已经上传github https://github.com/HobbyBear/ansible-role-filebeat.git 整个项目的目录结构如下所示filebeatop.yml到时候是我们执行ansible playbook命令的入口文件我们可以使用这样的命令使用这个role , ansible-playbook -i hosts filebeatop.yml 其中hosts目录就是存放inventory主机清单。 .
├── ReadMe.md
├── filebeatop.yml
├── group_vars
│ └── test.yml
├── hosts
│ ├── prod
│ └── test
└── roles└── filebeat├── handlers│ └── main.yml├── tasks│ ├── install.yml│ ├── main.yml│ ├── rpm.yml│ └── updatecfg.yml└── templates├── debug.conf├── filebeatbox.yml└── log.yml filebeatop.yml 的内容如下,其中roles配置项可以配置多个role不过案例中就只配置了一个filebeat的role这个role的名称就是上述roles目录下的filebeat这个文件夹的名称。同时filebeatop.yml同时设置了变量version和logstashendpoint不同的是version变量是role级别的。 - hosts: test roles: - role: filebeat version : 7.14.2 vars: logstashendpoint: 192.168.0.2:5054 接着了解下roles目录的结构,filebeat 就代表一个role其下有handlerstaskstemplates目录它们存放的内容如下 roles
└── filebeat├── handlers│ └── main.yml├── tasks│ ├── install.yml│ ├── main.yml│ ├── rpm.yml│ └── updatecfg.yml└── templates├── debug.conf├── filebeatbox.yml└── log.yml tasks 里面存放具体的Ansible 的各种模块定义的任务其入口文件是main.yml 它里面可以通过include 引入其他task。就比如这个案例中,我在main.yml 引入了其他配置文件定义的任务。main.yml 代码如下, 可以看到在引入其他配置文件定义的任务时我还用tags为任务打上了标签这个标签可以让我们后续根据特定的标签执行任务。 - include: install.yml tags: - install - include: rpm.yml tags: - rpm - include: updatecfg.yml tags: - updatecfg handlers 目录下存放任务的后续处理逻辑它其实也是ansible的模块定义的各种任务与tasks不同的是它是专门放到tasks执行后执行的。例如在handlers的main.yml文件中我定义了一个名为restart Filebeat service 的handlerhandlers/main.yml代码如下 become 设置为yesbecome_method 设置为sudo 代表在运行这个service的命令时是要以sudo权限运行的。 - name: restart Filebeat service become: yes become_method: sudo service: name: filebeat enabled: yes state: restarted 这个handler在tasks/updatecfg.yml中有被用到如下在更新完filebeat服务配置后通过notify配置定义所需的handler的名称便可以在特定task执行完成后运行对应的handler。 - name: 更新服务配置 shell: sudo systemctl daemon-reload notify: - restart Filebeat service templates 目录存放的是某些需要用到的配置文件模板在模板文件中可以使用{{ 变量名 }} 引用变量的定义可以在前面filebeatop.yml文件中vars或者roles配置中定义也可以放到与hosts目录同级的group_vars 目录中定义Ansible 关于变量的定义方式有很多种这里就不展开了。 拿案例中的group_vars举例其目录下的文件名是inventory主机清单中的机器组的名称比如我这里有个test的机器组所以我在group_vars有个test.yml文件内容如下,定义了两个变量 log_path和log_type。 log_path: - /home/webserver/logs/box-api/box-api.log\r\n - /home/webserver/logs/box-bsk/box-bsk.log\r\n - /home/webserver/logs/box-flow/box-flow.log log_type: box 这两个变量被 templates目录下的log.yml文件所引用。log.yml文件内容如下(是一个典型的filebeat设置日志采集路径的配置) - type: log tail_files: true paths: {{ log_path}} fields: log_type: {{ log_type }} 如何使用这些模板文件呢其实就是通过ansible的template模块拿filebeat role中的updatecfg.yml定义的任务片段举例将filebeat 相关的配置文件上传到主机上对应的目录。 - name: 传送配置文件 become: yes become_method: sudo template: srclog.yml dest/home/webserver/local/filebeat-{{ version }}-linux-x86_64/log.yml ownerroot grouproot - name: 传送配置文件 become: yes become_method: sudo template: srcfilebeatbox.yml dest/home/webserver/local/filebeat-{{ version }}-linux-x86_64/filebeatbox.yml ownerroot grouproot 思考如何利用role模式写好Ansible的任务编排 简单介绍完整个案例的目录和相关的文件后我们从使用角度来分析如何写一个好的部署任务。 像上述案例中我们可以执行下面的命令执行相应的部署更新配置任务。 在filebeatop.yml 中指定要操作的机器组以及filebeat的版本日志输出的logstahsh端点。 在group_vars 中定义每个机器组上需要采集的日志路径 安装filebeat软件包 ansible-playbook -i hosts filebeatop.yml --tags install 安装filebeat service ansible-playbook -i hosts filebeatop.yml --tags rpm 更新filebeat配置文件 ansible-playbook -i hosts filebeatop.yml --tags updatecfg 通过filebeat/tasks 引入其他任务配置文件时的 tags去区分要执行的任务而整个role中则定义对应的组件相关的操作这样能更好的维护对应组件的部署配置任务。 并且让roles相关的文件 只负责部署而针对哪些机器部署的配置则从roles目录中分离出来形成变量。这样的好处在于后续对于其他机器组的配置相同组件的不同版本的配置都可以不用去动roles目录下的文件了只需要新增不同的机器组的变量或者修改filebeatop.yml中的版本号即可。 文章转载自 蓝胖子的编程梦
原文链接https://www.cnblogs.com/hobbybear/p/17824585.html
