かゆいところに手が届く感じのAnsibleモジュールなど

好きなモジュールというか便利だなと思うやついくつか失礼します。
今年度前半けっこうAnsibleまみれだった思い出の記録。
1個選ぶの無理でした。ぜんぶべんりですきです。

1.set_fact

後続のタスクでつかう変数をタスクの途中で定義できるモジュール
debugと一緒に何の値が入ってるか確認しながらつくる

以下はレプリケーションするためのマスタのIPをとってきて変数に入れている様子。

- name: マスタのIPアドレスを取得
  set_fact:
    play_fact_primary: "{{ item }}"
    play_fact_primary_replication_ip: "{{ hostvars[item]['ansible_%s'|format(mysql_replication_network_device)].ipv4.address }}"

途中で変わる値を定義したりなどが可能なので、設定した後にその値を元になにかできる
変数を俯瞰したいときに探すのが若干面倒かもしれない（findすればいいけど）

2.stat

ファイルの属性などで処理を分岐するときによくつかいます。

以下はstatでpathに指定したファイルをregisterに入れて、そのステータス（存在するか）を用いてもし、存在しなかったらget_urlでダウンロードしてdestに配置します。

- name: check gsuite
  stat:
    path: "{{ gsuite_dir }}/google-cloud-sdk/bin/gcloud"
  register: chk_gs
  check_mode: no

- name: download gsuite
  get_url:
    url: "{{ gsuite_arc_uri }}/{{ gsuite_arc_file }}"
    dest: "{{ gsuite_dir }}/{{ gsuite_arc_file }}"
    mode: 0755
  when: not chk_gs.stat.exists

冪統性を保証したい、このファイルが存在してたら実行権限があったらまたはなかったら、whenで条件を指定するかんじ。
モジュールなので、ansibleのバージョンが上がって書き方が変わったというめんどくさい修正をしなくてはならなくなる機会が少ないと思われるところがだいぶ気に入ってる次第です（2.4向けに書いたら2.0.0.3の環境に合わせて書き直さないといけなくなったりしたけどstatはさわらないでも大丈夫だったぞーありがとうございまーす）

check_mode: noと書くと、-Cつけてるときも動いてくれるので後続タスクが失敗しないです。

3.template

変数を埋め込んだファイルを配布できるモジュール
factで取れるOSスペックにあわせて設定値を自動計算でいれたり、
factで取れるNICのネットワーク情報に合わせて設定したり、
場合によって変えたい値を変数にして配ったりなど色々べんり。

以下はバックアップスクリプトを配置してcron登録してるのですが、その中身のクレデンシャルやキー的な情報を変数として扱い配布しています。

- block:
  - name: copy backup script for azureblob
    template:
      src: backup.sh-gitlab-azureblob 
      dest: /opt/bin/backup.sh
    no_log: True

  - name: set cron job for backup to azureblob
    cron:
      name: "gitlab backup(send to remote storage)"
      user: 'root'
      job: '/opt/bin/backup.sh'
      minute: '0'
      hour: '3'
      weekday: '0'
  when: use_azureblob_bkup_script == 'yes'

CIDRプレフィクス指定したいときはnetaddrでさらに便利
あとはグループのインベントリ情報に合わせてとか、jinja2の機能でforとかif分岐とかいろいろできてだいぶべんり。
複数行とかも別にパイプでやると渡せるのでblockinfileとか要らないのでは派。
fileモジュールはディレクトリつくるとか圧縮ファイル展開して配置とかじゃないとつかわず設定するだけとかなら大体ぜんぶtemplateつかうかんじです

4.lineinfile

ファイルの中身をsedれるやつです。

- name: setting exclude about clustaring packages.
  lineinfile:
    state: present
    dest: "/etc/yum.conf"
    regexp: '^exclude=kernel.*'
    line: 'exclude=kernel* pacemaker pacemaker-libs corosync cluster-glue heartbeat resource-agents'
    backup: yes

バージョンごとにtemplateを用意するのが激しく面倒だが設定することは同じである
というようなときにだいぶべんり。スクリプトそんなに書かない人にも分かりやすいと好評。
しかしちゃんと網羅的にいろいろなパターン動確しないと正規表現まちがってたとかなりやすいかもしれないとこは実はちょっとめんどくさいんじゃないでしょうかー。

5.shell

パイプつかいたいような複数行の処理を好きにかきたいときにべんり

- name: pipコマンド確認
  shell: which pip
  register: check_pip
  when: check_python|succeeded

やっぱshellやcommandモジュールのめんどくさいとこは冪統性を自ら担保するために少なくとも手前にはcheckタスクかかないといけないあたり

6.command

実行ディレクトリ指定して1行でパイプ無しでなにかしたいときにべんり

- name: install gsuite
  become: yes
  become_user: {{ gsuite_user }}
  command: chdir={{ gsuite_dir }} {{ gsuite_dir }}/google-cloud-sdk/install.sh -q --rc-path ~/.bashrc
  when: not chk_gs.stat.exists

7.debug

set_factやregisterやhost_varsの戻り値を見たいときなどにべんり

# hostvarsの確認単体テスト用(以下のように実行）
# ansible-playbook test/debug_hostvars.yaml > test.log --vault-password-file=path-to-file
---
- hosts: all
  gather_facts: yes
  tasks:
   - name: "dump variables hostvars"
     debug: var=hostvars[inventory_hostname] 

   - name: "dump variables vars"
     debug: var=vars

失敗というほどでもないですが確認してたdebugの消し忘れはしたことあるよ
あと変な名前のテスト用タグの消し忘れとかswpファイル混入とかたまにやらかしますね（fix bugとか雑なgitのコメントいれてけします）
(全部流すと時間かかってめんどくさいので変えたとこだけテストするのに一時的にtagつけて指定してそこだけ流すことがあるんですがinclude_varsとか無駄につかうと部分実行では読まれないみたいな動きするみたいなやらかしもしたことあります)

8.get_url

ダウンロードして置くだけのときにべんり
commandでもいいけどモジュールつかうと地味に確認タスクかかなくても冪等になるのでべんり

- name: download repo about network:ha-clustering
  get_url:
    url: '{{ pacemaker_yumrepo_url }}'
    dest: "/etc/yum.repos.d/{{ pacemaker_yumrepo_file }}"

リンク先がなくなると詰むのでgitリポジトリに入れたくないときはオレオレカスタムパッケージレポジトリかマイストレージバケットなどに置いてダウンロードするといいかもしれない

クラウドモジュールもあるようでgcpのバケット管理したいならgc_storage でAWSのS3ならaws_s3でAzureのBlobだとazure_rm_storageblobでいけるようです（試してはいない）

9.meta

いまこのとき設定が反映されてほしい場合にげんざい実行されてないハンドラをまとめて実行してくれる

- name: set unit files(for oom-killer)
  template:
    src: postgresql.service.j2
    dest: /etc/systemd/system/postgresql-9.6.service.d/override.conf
  notify: run-daemon-reload

- meta: flush_handlers  

- name: set configs
  template: 
    src: "{{ item.name }}.j2"
    dest: "{{ item.path }}/{{ item.name }}"
  with_items: "{{ postgresql_confs }}"
  notify: restart-postgresql
  when: ( postgresql_confs != '' and postgresql_confs is defined )
  tags: pgconf

個別に指定して実行はできないとこは多少はふべんかもしれない（とくに困っては無い）

10.import_tasks

処理を分岐したいときに別ファイルにしてよみこませるなどする
長いでかいファイルをみるのがつらいときにもべんり

  pre_tasks:
    - import_tasks: roles/baseimage/tasks/pip.yml
      tags: pip

モジュールじゃないけどdelegate_toとrun_onceもグループ内の指定した1台だけで処理したいときとかに何気にべんり。

  - name: 準マスタ情報取得(master status)
    mysql_replication2:
      mode: getmaster
    delegate_to: "{{ play_fact_secondary }}"
    register: mysql_replication_secondary_stat

- name: load cib.xml
  command: 'pcs cluster cib-push /root/cib.xml'
  when: chk_resource.stdout == '0'
  run_once: true 
## run_onceによりclusterの片側だけがmasterとして稼働

そのた

nmctl

NetworkManager自体がけっこう慣れないとめんどくさくていろいろアレというのと、やりたい処理が全部できるわけではないので改造が要るかんじだった
設定ばらまくならtemplateつかえたほうが楽かもしれないかな（どちらかに寄せないと冪等でない感じになるというか）

- name: set ipv4 address(for change method to manual)
  nmcli:
    conn_name: "System {{ item }}"
    ifname: "{{ item }}"
    type: ethernet
    ip4: "{{ ip_mask|ipv4('host/prefix') }}"
    gw4: "{{ ansible_default_ipv4.gateway }} "
    method: manual
    autoconnect: true
    state: present
  when: ip_mask is defined
  with_items: "{{ ansible_interfaces|reject('search', 'lo')|list }}"
  tags: set-ipv4-addr,nmcli
  notify: reload-network

むかしかいたモジュール関連の記事（よくつかう・目的別逆引きモジュール）
https://qiita.com/smallpalace/items/eb4fc1d13989993d63b9
https://qiita.com/smallpalace/items/113c2a35c7e550bb9045
グループ毎に処理内容分岐するやつ
https://qiita.com/smallpalace/items/dff5f602f6772c04360e
起動スクリプトで搭載スペックに応じ自動設定するやつ（記事のいちぶぶん）
https://qiita.com/smallpalace/items/d331e65d1e4b57e1c973