playbook中when的简单实用

逻辑漏洞
• 阅读 799

背景

在使用 ansible 编写 playbook 的过程中,我们发现在安装某服务时,例如部署 fastdfs 分布式存储时,有的机器需要启动 tracker 和 storage 两个服务,有的机器只需要启动一个服务即可,它们需要的配置不同,我们要根据不同的机器来做不同的判断,来分发不同的配置文件,这时就会用到 when 来做判断了,并且我们还要使用 jinja2 的循环条件控制语句,还要在 ansible 的清单文件中设置好变量。

一个简单的判断

判断某文件或目录是否存在,存在则直接跳过,否则创建

- name: Check if fdfs_dl_dir is already exists
  stat:
    path: "{{ fdfs_dl_dir }}"   #这里是一个由引号引起的变量,可在vars目录中指定
  register: fdfs_dl

- name: Create download dir
  file:
    path: "{{ fdfs_dl_dir }}"
    state: directory
    mode: 0755
  when: fdfs_dl.stat.exists == False
  become: true

我们在日常的部署中,这种使用方法能帮我们大大的提高 playbook 的执行效率

针对不同的主机来做判断,如果满足条件,则执行任务,不满足直接略过

- name: Copy tracker init file
  template:
    src: "{{ item.src }}"
    dest: "{{ item.dest }}"
    mode: 0755
  with_items:
    - src: fdfs_trackerd.j2
      dest: /etc/init.d/fdfs_trackerd
    - src: fdfs_systemd.j2
      dest: /etc/init.d/fdfs_systemd
  when: fdfs_role == 'tracker'
  become: true

这里我们自定义了一个变量 fdfs_role,该变量是定义在清单文件中的,如下:

[fdfs]
10.0.3.115
10.0.3.116
10.0.3.150

[tracker]
10.0.3.115 tracker_host=tracker1.backend.com
10.0.3.116 tracker_host=tracker2.backend.com

[storage]
10.0.3.115 group_id=1
10.0.3.116 group_id=1
10.0.3.150 group_id=2

[tracker:vars]
fdfs_role=tracker

[storage:vars]
fdfs_role=storage

我们这里对不同的主机进行分组,when 执行的判断是当 fdfs_role 为 tracker 时,才去执行此任务,简而言之就是满足条件才会执行,这对我们非常有用,例如在部署 mysql 集群时,我们需要对数据库执行授权操作,当然,授权操作主库和从库都要进行,但是进行主从关系授权时,则只需要在主库上进行即可,所以,我们需要做一个判断,类似与 fastdfs 的配置,如下:

- name: Grant replication to slave hosts
  mysql_user:
    login_user: "{{ mysql_root_user }}"
    login_port: "{{ mysql_port }}"
    config_file: "{{ ansible_env.HOME }}/my.cnf"
    name: "{{ mysql_dbuser }}"
    host: "{{ mysql_app_dbuser_host }}"
    password: "{{ mysql_dbpwd }}"
    append_privs: yes
    priv: '*.*:REPLICATION SLAVE'
    state: present
  environment:
    PATH: "{{ ansible_env.PATH }}:{{ mysql_install_dir }}/bin"
  when: mysql_db_role == 'master'

- name: Stop replication
  mysql_replication:
    login_user: "{{ mysql_root_user }}"
    login_port: "{{ mysql_port }}"
    config_file: "{{ ansible_env.HOME }}/my.cnf"
    mode: stopslave
  environment:
    PATH: "{{ ansible_env.PATH }}:{{ mysql_install_dir }}/bin"
  become: true
  when: mysql_db_role == 'slave'

- name: Reset replication
  mysql_replication:
    login_user: "{{ mysql_root_user }}"
    login_port: "{{ mysql_port }}"
    config_file: "{{ ansible_env.HOME }}/my.cnf"
    mode: resetslave
  environment:
    PATH: "{{ ansible_env.PATH }}:{{ mysql_install_dir }}/bin"
  become: true
  when: mysql_db_role == 'slave'

- name: get the current master status
  mysql_replication:
    login_user: "{{ mysql_root_user }}"
    login_port: "{{ mysql_port }}"
    config_file: "{{ ansible_env.HOME }}/my.cnf"
    mode: getmaster
  delegate_to: "{{ mysql_host_master }}"
  register: master_info
  environment:
    PATH: "{{ ansible_env.PATH }}:{{ mysql_install_dir }}/bin"
  when: mysql_db_role == 'slave'

- name: Change the master on slave to start the replication
  mysql_replication:
    login_user: "{{ mysql_root_user }}"
    login_port: "{{ mysql_port }}"
    config_file: "{{ ansible_env.HOME }}/my.cnf"
    mode: changemaster
    master_host: "{{ mysql_host_master }}"
    master_port: "{{ mysql_port }}"
    master_log_file: "{{ master_info.File }}"
    master_log_pos: "{{ master_info.Position }}"
    master_user: "{{ mysql_dbuser }}"
    master_password: "{{ mysql_dbpwd }}"
  environment:
    PATH: "{{ ansible_env.PATH }}:{{ mysql_install_dir }}/bin"
  when: mysql_db_role == 'slave'

- name: Start slave
  mysql_replication:
    login_user: "{{ mysql_root_user }}"
    login_port: "{{ mysql_port }}"
    config_file: "{{ ansible_env.HOME }}/my.cnf"
    mode: startslave
  environment:
    PATH: "{{ ansible_env.PATH }}:{{ mysql_install_dir }}/bin"
  when: mysql_db_role == 'slave'

看着很长,但是逻辑非常简单,就是先给从库进行授权,然后防止之前执行失败,所以先 stop slave,再 reset slave(这两个操作顺序随意),然后再获取主库的 binlog 文件和 binlog 位置,最后在从库确立关系。

[mysql]
10.0.3.150
10.0.3.115
10.0.3.116

[slave]
10.0.3.116 server_id=116
10.0.3.115 server_id=115

[master]
10.0.3.150

[master:vars]
mysql_db_role=master

[slave:vars]
mysql_db_role=slave

喜欢的朋友可以关注下我的个人公众号哦

playbook中when的简单实用

点赞
收藏
评论区
推荐文章
Stella981 Stella981
3年前
Flume使用Kafka Sink导致CPU过高的问题
在日志收集服务器上使用Flume(1.6)的KafkaSink将日志数据发送至Kafka,在FlumeAgent启动之后,发现每个Agent的CPU使用率都非常高,而我们需要在每台机器上启动多个FlumeAgent来收集不同类型的日志,如果每个Agent都这样,那肯定会把机器的CPU吃满了,刚开始使用jstack定位到是org.apache.flume
Stella981 Stella981
3年前
Hadoop之Shell脚本自动启动
在用Hadoop进行大数据分析处理时,通常配置的服务器不止一两台。为了减少人工操作的重复性,所以hadoop提供了可以自动启动Hadoop集群的Shell脚本。在使用Shell脚本启动集群之前,需要进行相应的配置。说明:$HADOOP\_HOME/root/project/hadoop(根据自己配置的路径不同而不同)打开$HADOOP\_H
Wesley13 Wesley13
3年前
01.Java数据结构和多线程
数据结构数据结构是计算机存储、组织数据的方式。数据结构是指相互之间存在一种或多种特定关系的数据元素的集合。不同的数据结构的操作性能是不同的:(有的查询性能很快,有的插入速度很快,有的是插入头和尾速度很快,有的做等值判断很快,有的做范围查找很快,有的允许元素重复,有的不允许重复等等),在开发中如何选择,要根据具体的需求来选择.
Stella981 Stella981
3年前
Ansible playbook 使用
playbooks是一种简单的配置管理系统与多机器部署系统的基础。与现有的其他系统有不同之处,且非常适合于复杂应用部署playbook可以定制配置,可以按指定的步骤有序执行,支持同步以及异步方式。官网例子:https://github.com/ansible/ansibleexamplesplaybooks可以用于声明配置,更强大的地方在
Stella981 Stella981
3年前
Linux配置SSH免用户免密码登陆
1\.目的简化SSH登陆过程,实现从机器A登陆机器B只需要运行sshhostname即可,即不需要输入用户名和密码。2\.配置host配置host的作用是ssh登陆机器时用hostname代替IP,在机器很多的集群环境中hostname比IP容易记的多,编辑/etc/hosts文件,配
Stella981 Stella981
3年前
Dubbo链路追踪——生成全局ID(traceId)
全局traceId关于链路追踪,在微服务的趋势下,一次调用的日志信息分布在不同的机器上或目录下,当需要看一条链路调用所有的日志信息时,这是个比较困难的地方,我们虽然有ELK,Sentry等日志异常收集分析工具,但是如何把信息串起来也是一个关键的问题。我们一般的做法是在系统调用开始时生成一个traceId,并且它伴随着一
Easter79 Easter79
3年前
SpringBoot2.0之六 多环境配置
  开发过程中面对不同的环境,例如数据库、redis服务器等的不同,可能会面临一直需要修改配置的麻烦中,在以前的项目中,曾通过Tomcat的配置来实现,有的项目甚至需要手动修改相关配置,这种方式费时费力,出错的概率还极大,SpringBoot为我们提供了更加简单方便的配置方案来解决多环境的配置问题,下面我们看看怎么实现。一、新建一个项目(本文以上篇的代码
Stella981 Stella981
3年前
SpringBoot2.0之六 多环境配置
  开发过程中面对不同的环境,例如数据库、redis服务器等的不同,可能会面临一直需要修改配置的麻烦中,在以前的项目中,曾通过Tomcat的配置来实现,有的项目甚至需要手动修改相关配置,这种方式费时费力,出错的概率还极大,SpringBoot为我们提供了更加简单方便的配置方案来解决多环境的配置问题,下面我们看看怎么实现。一、新建一个项目(本文以上篇的代码
Stella981 Stella981
3年前
Kubernetes 学习1 Devops 核心要点和k8s架构概述
一、概述  1、我们以往在去实现安装部署应用程序时我们要去实现部署实现应用手动去做会非常麻烦,所以我们后来便有了工具,像ansible等等,这个工具其实就是一个应用编排工具。他能够安装,配置,服务启动,甚至能够让你按照所定义的Playbok完成对多种应用程序在实现有依赖关系时将我们手工需要配置的工作反应在ansible配置文件playbox中,让其按照p
Spring配置文件的魔法炼金术:如何制造容器化时代的完美配方 | 京东物流技术团队
基于现代服务的云原生十二要素理论,我们在采用容器化部署时,要保证同一个镜像可以满足不同环境的部署要求,而不是不同环境打包不同的镜像。本文档主要介绍一种基于spring框架的满足不同环境配置的编译打包方案,满足同一个镜像可以在环境分组下通过启动项配置实现不同环境的部署。
逻辑漏洞
逻辑漏洞
Lv1
四海十年兵不解,胡尘直到江城。
文章
3
粉丝
0
获赞
0