Upgrade to Pro — share decks privately, control downloads, hide ads and more …

AnsibleNight_2021-02-10

hito58
February 14, 2021

 AnsibleNight_2021-02-10

Ansible Night Online 2021.02.10

hito58

February 14, 2021
Tweet

Other Decks in Technology

Transcript

  1. Ansible Towerをみんなで使うためにやったこと
    @hito58
    Ansible Night 2021.02

    View Slide

  2. 自己紹介
    氏名: 木場 仁美(こば ひとみ, @hito58)
    仕事:
    - 通信キャリアで音声系システム開発担当
    - 入社5年目
    - 運用を楽にするためにがんばってます

    View Slide

  3. 今日お話しすること

    View Slide

  4. 今日お話しすること
    音声系システムの運用でAnsible Towerを使うにあたり
    やったこと
    ①インベントリを共通化する
    ②Playbookを1つのリポジトリで管理する
    この2つについて紹介
    (本内容は所属団体とは無関係な個人の感想であり、正しいからやるべきというものではありません!)

    View Slide

  5. ①インベントリの共通化
    そもそもの利用背景:
    Ansible Towerをつかって運用コマンドをうちたい

    View Slide

  6. ①インベントリの共通化
    そもそもの利用背景:
    Ansible Towerをつかって運用コマンドをうちたい
    アンシブル
    タワー
    worker11
    worker10
    worker21
    worker20
    controller

    View Slide

  7. ①インベントリの共通化
    そもそもの利用背景:
    Ansible Towerをつかって運用コマンドをうちたい
    (障害対応、計画的な保守業務)
    アンシブル
    タワー
    Playbook実行
    worker11
    worker10
    worker21
    worker20
    controller

    View Slide

  8. ①インベントリの共通化
    なぜ共通化が必要か:
    操作内容によってインベントリにおけるhostsの定義が違う

    View Slide

  9. ①インベントリの共通化
    なぜ共通化が必要か:
    操作内容によってインベントリにおけるhostsの定義が違う
    MWが提供する保守用コマンドは
    controllerに入ってクラスタ単位でうつ
    view stats --cluster 1
    worker11
    worker10
    worker21
    worker20
    controller
    hosts:
    で指定される単位

    View Slide

  10. ①インベントリの共通化
    ---
    - name: 状態確認
    hosts: all
    tasks:
    - shell: view stats --cluster {{ cl_no }}
    register: result_status
    ・・・
    # inventory
    worker1 cl_no=1 ansible_host=192.168.0.1
    worker2 cl_no=2 ansible_host=192.168.0.1
    全部同じアドレス(controllerのアドレス)

    View Slide

  11. ①インベントリの共通化
    なぜ共通化が必要か:
    操作内容によってインベントリにおけるhostsの定義が違う
    df -h
    リソース確認などLinuxコマンドは
    サーバ指定でうつ
    worker11
    worker10
    worker21
    worker20
    controller
    hosts:で
    指定される単位

    View Slide

  12. ①インベントリの共通化
    ---
    - name: 状態確認
    hosts: all
    tasks:
    - shell: {{ command }}
    register: result_status
    ・・・
    # inventory
    controller ansible_host=192.168.0.1
    worker10 ansible_host=192.168.0.2
    worker11 ansible_host=192.168.0.3
    worker20 ansible_host=192.168.0.4
    worker21 ansible_host=192.168.0.5

    View Slide

  13. ①インベントリの共通化
    これらをTowerから実行するために:
    ①それぞれのインベントリをTowerに登録
    • 登録するhosts数がサーバ台数より多くなる
    →Towerは登録するhosts数に応じてライセンス費用決まる
    ②インベントリを正規化して共通のインベントリとして登録
    • 既存Playbookを書き換えないといけない

    View Slide

  14. ①インベントリの共通化
    これらをTowerから実行するために:
    ①それぞれのインベントリをTowerに登録
    • 登録するhosts数がサーバ台数より多くなる
    →Towerは登録するhosts数に応じてライセンス費用決まる
    ②インベントリを正規化して共通のインベントリとして登録
    • 既存Playbookを書き換えないといけない

    View Slide

  15. ①インベントリの共通化
    方針:
    ・hostsは最小単位を採用、その他の概念はgroupsで表現
    (groupはいくら登録してもノーカウント!)
    ・インベントリに合わせてplaybookを作りかえ
    (delegate_to節やhosts:にワイルドカード/正規表現つかうと楽!)

    View Slide

  16. ①インベントリの共通化
    書き換え例:
    MW提供のコマンド利用するばあい
    ---
    - name: 状態確認
    hosts: *0
    tasks:
    - delegate_to: controller
    shell: {{ command }}
    register: result_status
    ・・・

    # inventory
    controller ansible_host=192.168.0.1
    worker10 ansible_host=192.168.0.2
    worker11 ansible_host=192.168.0.3
    worker20 ansible_host=192.168.0.4
    worker21 ansible_host=192.168.0.5
    [worker1]
    worker10
    Worker11
    [worker2]
    worker20
    worker21

    View Slide

  17. 今日お話しすること
    音声系システムの運用でAnsible Towerを使うにあたり
    やったほうがいいこと
    ①インベントリを共通化する
    ②Playbookを1つのリポジトリで管理する
    この2つについて紹介

    View Slide

  18. ②Playbookを1つのリポジトリで管理する
    Ansible TowerはPlaybookをGitから呼び出して実行する
    Playbookを保管するリモートリポジトリが必要
    アンシブル
    タワー
    サーバー①
    サーバー②
    Playbook実行
    Playbooks
    repository
    Playbook読み込み
    Git

    View Slide

  19. ②Playbookを1つのリポジトリで管理する
    • インベントリが全Playbook共通にできたからその流れで
    Playbookもまとめて1つのGitリポジトリで管理
    • 共通処理はRoles/カスタムモジュールにし、別のリポジトリで
    管理、submoduleとして紐づける
    アンシブル
    タワー
    Playbook/インベントリ読み込み
    Playbooks
    repository
    Git
    Role①repository
    Role②repository
    Lib①repository
    submodule

    View Slide

  20. ②Playbookを1つのリポジトリで管理する
    リポジトリ内構成例:
    [email protected]/
    [email protected]/
    library/
    ../output_perser/library/output_perser.py
    ../run_mw_command/library/run_mw_command.py
    pb_config_update/
    main.yml
    pb_get_log/
    main.yml
    roles/
    [email protected]/
    [email protected]/
    ansible.cfg
    hosts.yml

    View Slide

  21. ②Playbookを1つのリポジトリで管理する
    リポジトリ内構成例:
    [email protected]/
    [email protected]/
    library/
    ../output_perser/library/output_perser.py
    ../run_mw_command/library/run_mw_command.py
    pb_config_update/
    main.yml
    pb_get_log/
    main.yml
    roles/
    [email protected]/
    [email protected]/
    ansible.cfg
    hosts.yml
    inventoryファイルも同一リポジトリ内
    インベントリソースとしてTowerに登録
    Jobテンプレートで使うPlaybookたち
    カスタムモジュールたち(Submodule)
    Roleたち(Submodule)

    View Slide

  22. ②Playbookを1つのリポジトリで管理する
    よかったこと:
    - このリポジトリだけプロジェクトとしてTowerに登録すればよい
    (Towerにプロジェクトが乱立されない)
    - cloneしたらTowerとほぼ同じ環境でPlaybookの実行確認ができる

    View Slide

  23. まとめ
    • インベントリを正規化/共通化してメンテしやすくなった
    • リポジトリを1つにしてPlaybookを開発、試験しやすくなった
    • Towerを使わなかったとしても、わかりやすい構成で使えるかも

    View Slide

  24. ____________________________
    < Thank you for listening! >
    ----------------------------
    ¥ ^__^
    ¥ (oo)¥_______
    (__) A )¥/¥
    ||----w |
    || ||

    View Slide