Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AnsibleNight_2021-02-10
Search
hito58
February 14, 2021
Technology
1
2.5k
AnsibleNight_2021-02-10
Ansible Night Online 2021.02.10
hito58
February 14, 2021
Tweet
Share
Other Decks in Technology
See All in Technology
BrainPadプログラミングコンテスト記念LT会2025_社内イベント&問題解説
brainpadpr
1
170
なぜ私はいま、ここにいるのか? #もがく中堅デザイナー #プロダクトデザイナー
bengo4com
0
1.1k
Understanding_Thread_Tuning_for_Inference_Servers_of_Deep_Models.pdf
lycorptech_jp
PRO
0
140
Snowflake Summit 2025全体振り返り / Snowflake Summit 2025 Overall Review
mtpooh
2
420
AWS Organizations 新機能!マルチパーティ承認の紹介
yhana
1
170
あなたの声を届けよう! 女性エンジニア登壇の意義とアウトプット実践ガイド #wttjp / Call for Your Voice
kondoyuko
4
480
「Chatwork」の認証基盤の移行とログ活用によるプロダクト改善
kubell_hr
1
210
Geminiとv0による高速プロトタイピング
shinya337
0
110
2025-06-26_Lightning_Talk_for_Lightning_Talks
_hashimo2
2
100
生成AI活用の組織格差を解消する 〜ビジネス職のCursor導入が開発効率に与えた好循環〜 / Closing the Organizational Gap in AI Adoption
upamune
5
4.2k
「良さそう」と「とても良い」の間には 「良さそうだがホンマか」がたくさんある / 2025.07.01 LLM品質Night
smiyawaki0820
1
380
Github Copilot エージェントモードで試してみた
ochtum
0
110
Featured
See All Featured
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.2k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.7k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
Building an army of robots
kneath
306
45k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
Fireside Chat
paigeccino
37
3.5k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.6k
4 Signs Your Business is Dying
shpigford
184
22k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Transcript
Ansible Towerをみんなで使うためにやったこと @hito58 Ansible Night 2021.02
自己紹介 氏名: 木場 仁美(こば ひとみ, @hito58) 仕事: - 通信キャリアで音声系システム開発担当 -
入社5年目 - 運用を楽にするためにがんばってます
今日お話しすること
今日お話しすること 音声系システムの運用でAnsible Towerを使うにあたり やったこと ①インベントリを共通化する ②Playbookを1つのリポジトリで管理する この2つについて紹介 (本内容は所属団体とは無関係な個人の感想であり、正しいからやるべきというものではありません!)
①インベントリの共通化 そもそもの利用背景: Ansible Towerをつかって運用コマンドをうちたい
①インベントリの共通化 そもそもの利用背景: Ansible Towerをつかって運用コマンドをうちたい アンシブル タワー worker11 worker10 worker21 worker20
controller
①インベントリの共通化 そもそもの利用背景: Ansible Towerをつかって運用コマンドをうちたい (障害対応、計画的な保守業務) アンシブル タワー Playbook実行 worker11 worker10
worker21 worker20 controller
①インベントリの共通化 なぜ共通化が必要か: 操作内容によってインベントリにおけるhostsの定義が違う
①インベントリの共通化 なぜ共通化が必要か: 操作内容によってインベントリにおけるhostsの定義が違う MWが提供する保守用コマンドは controllerに入ってクラスタ単位でうつ view stats --cluster 1 worker11
worker10 worker21 worker20 controller hosts: で指定される単位
①インベントリの共通化 --- - 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のアドレス)
①インベントリの共通化 なぜ共通化が必要か: 操作内容によってインベントリにおけるhostsの定義が違う df -h リソース確認などLinuxコマンドは サーバ指定でうつ worker11 worker10 worker21
worker20 controller hosts:で 指定される単位
①インベントリの共通化 --- - 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
①インベントリの共通化 これらをTowerから実行するために: ①それぞれのインベントリをTowerに登録 • 登録するhosts数がサーバ台数より多くなる →Towerは登録するhosts数に応じてライセンス費用決まる ②インベントリを正規化して共通のインベントリとして登録 • 既存Playbookを書き換えないといけない
①インベントリの共通化 これらをTowerから実行するために: ①それぞれのインベントリをTowerに登録 • 登録するhosts数がサーバ台数より多くなる →Towerは登録するhosts数に応じてライセンス費用決まる ②インベントリを正規化して共通のインベントリとして登録 • 既存Playbookを書き換えないといけない
①インベントリの共通化 方針: ・hostsは最小単位を採用、その他の概念はgroupsで表現 (groupはいくら登録してもノーカウント!) ・インベントリに合わせてplaybookを作りかえ (delegate_to節やhosts:にワイルドカード/正規表現つかうと楽!)
①インベントリの共通化 書き換え例: 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
今日お話しすること 音声系システムの運用でAnsible Towerを使うにあたり やったほうがいいこと ①インベントリを共通化する ②Playbookを1つのリポジトリで管理する この2つについて紹介
②Playbookを1つのリポジトリで管理する Ansible TowerはPlaybookをGitから呼び出して実行する Playbookを保管するリモートリポジトリが必要 アンシブル タワー サーバー① サーバー② Playbook実行 Playbooks
repository Playbook読み込み Git
②Playbookを1つのリポジトリで管理する • インベントリが全Playbook共通にできたからその流れで Playbookもまとめて1つのGitリポジトリで管理 • 共通処理はRoles/カスタムモジュールにし、別のリポジトリで 管理、submoduleとして紐づける アンシブル タワー Playbook/インベントリ読み込み
Playbooks repository Git Role①repository Role②repository Lib①repository submodule
②Playbookを1つのリポジトリで管理する リポジトリ内構成例: output_perser@xxxx/ run_mw_command@xxxx/ 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/ vnfm@xxxx/ worker@xxxx/ ansible.cfg hosts.yml
②Playbookを1つのリポジトリで管理する リポジトリ内構成例: output_perser@xxxx/ run_mw_command@xxxx/ 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/ vnfm@xxxx/ worker@xxxx/ ansible.cfg hosts.yml inventoryファイルも同一リポジトリ内 インベントリソースとしてTowerに登録 Jobテンプレートで使うPlaybookたち カスタムモジュールたち(Submodule) Roleたち(Submodule)
②Playbookを1つのリポジトリで管理する よかったこと: - このリポジトリだけプロジェクトとしてTowerに登録すればよい (Towerにプロジェクトが乱立されない) - cloneしたらTowerとほぼ同じ環境でPlaybookの実行確認ができる
まとめ • インベントリを正規化/共通化してメンテしやすくなった • リポジトリを1つにしてPlaybookを開発、試験しやすくなった • Towerを使わなかったとしても、わかりやすい構成で使えるかも
____________________________ < Thank you for listening! > ---------------------------- ¥ ^__^
¥ (oo)¥_______ (__) A )¥/¥ ||----w | || ||