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
他作Playbookを実行することになって読みにくかった話
Search
Daichi Yamaguchi
June 23, 2020
Technology
3
1.9k
他作Playbookを実行することになって読みにくかった話
Ansible Night Online 2020.06
Daichi Yamaguchi
June 23, 2020
Tweet
Share
More Decks by Daichi Yamaguchi
See All by Daichi Yamaguchi
CloudNativeをなぜ実践するのか? / Why practive CloudNative
dayamaguchi1
1
550
CloudNative Nagoya Code of conduct
dayamaguchi1
0
52
Dockerインストール後の設定をしよう/Set up after installing Docker
dayamaguchi1
2
750
ITエンジニアが学ぶ「ティール組織」概要 / IT Engineer learns "Teal organization" summary
dayamaguchi1
2
240
Rancherから始めるCloud Native Journey / Start with Rancher Cloud Native Journey
dayamaguchi1
0
380
Other Decks in Technology
See All in Technology
「Verify with Wallet API」を アプリに導入するために
hinakko
1
230
Pure Goで体験するWasmの未来
askua
1
170
「AI駆動PO」を考えてみる - 作る速さから価値のスループットへ:検査・適応で未来を開発 / AI-driven product owner. scrummat2025
yosuke_nagai
4
580
Flaky Testへの現実解をGoのプロポーザルから考える | Go Conference 2025
upamune
1
420
about #74462 go/token#FileSet
tomtwinkle
1
290
生成AIを活用したZennの取り組み事例
ryosukeigarashi
0
200
自作LLM Native GORM Pluginで実現する AI Agentバックテスト基盤構築
po3rin
2
250
AI ReadyなData PlatformとしてのAutonomous Databaseアップデート
oracle4engineer
PRO
0
170
From Prompt to Product @ How to Web 2025, Bucharest, Romania
janwerner
0
120
[2025-09-30] Databricks Genie を利用した分析基盤とデータモデリングの IVRy の現在地
wxyzzz
0
470
GC25 Recap+: Advancing Go Garbage Collection with Green Tea
logica0419
1
400
成長自己責任時代のあるきかた/How to navigate the era of personal responsibility for growth
kwappa
3
270
Featured
See All Featured
Optimizing for Happiness
mojombo
379
70k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
Practical Orchestrator
shlominoach
190
11k
The Cost Of JavaScript in 2023
addyosmani
53
9k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
2.6k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
9.7k
Context Engineering - Making Every Token Count
addyosmani
5
180
Unsuck your backbone
ammeep
671
58k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
The World Runs on Bad Software
bkeepers
PRO
71
11k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
Transcript
他作Playbookを 実行することになって 読みにくかった話 Ansible Night オンライン! 2020.06 山口大地 (@dayamaguchi1)
自己紹介 氏名:山口 大地( @dayamaguchi1 ) 所属会社:株式会社エイチームライフスタイル [業務] AWS インフラ全般(最近は terraform
触ることが多い) [ その他 ] ・ Ansible Night in Nagoya 2019.02 の登壇以来です ・在宅勤務の間にフィットボクシングとスパイスカレーに目覚めました ・土曜日に映画ミッドサマー ディレクターズカット版をみて心が沈んでいます
今日伝えたいこと • Ansible でプログラマブルなコードを書くと複雑性が増してわかりにくい • 想定どおり動かないケースもあるから気をつけよう
業務背景 • 旧い環境を再現する必要があった • 過去に作成された AnsiblePlaybook を利用して、環境を再現させる • 現行環境に追随されていないので、そこの差分は個別で埋めていく(これは本発表 外の話)
問題が起きたコード - name: "Httpd 設定ファイルコピー(staging)" when: web.server_name_staging is defined template:
src: 'vhost.d/staging.conf' dest: '/etc/httpd/conf.d/vhost.d/staging.conf' - name: "Httpd 各種ディレクトリ展開 (staging)" when: web.server_name_staging is defined set_fact: web: env: 'staging' - name: "Httpd 設定ファイルコピー(prod)" when: web.server_name_prod is defined template: src: 'vhost.d/prod.conf' dest: '/etc/httpd/conf.d/vhost.d/prod.conf' - name: "Httpd 各種ディレクトリ展開 (prod)" when: web.server_name_prod is defined set_fact: web: env: 'prod' vars: web: server_name_prod: "{{ inventory_hostname }}" server_name_staging: "{{ inventory_hostname | regex_replace('prod', 'staging') }}"
問題が起きたコード - name: "Httpd 設定ファイルコピー(staging)" when: web.server_name_staging is defined template:
src: 'vhost.d/staging.conf' dest: '/etc/httpd/conf.d/vhost.d/staging.conf' - name: "Httpd 各種ディレクトリ展開 (staging)" when: web.server_name_staging is defined set_fact: web: env: 'staging' - name: "Httpd 設定ファイルコピー(prod)" when: web.server_name_prod is defined template: src: 'vhost.d/prod.conf' dest: '/etc/httpd/conf.d/vhost.d/prod.conf' - name: "Httpd 各種ディレクトリ展開 (prod)" when: web.server_name_prod is defined set_fact: web: env: 'prod' vars: web: server_name_prod: "{{ inventory_hostname }}" server_name_staging: "{{ inventory_hostname | regex_replace('prod', 'staging') }}" この変数(web.server_name_staging)の定 義有無で判定したいようだ stagingかprodか、環境に応じて配置する configを変えたいようだ
問題が起きたコード - name: "Httpd 設定ファイルコピー(staging)" when: web.server_name_staging is defined template:
src: 'vhost.d/staging.conf' dest: '/etc/httpd/conf.d/vhost.d/staging.conf' - name: "Httpd 各種ディレクトリ展開 (staging)" when: web.server_name_staging is defined set_fact: web: env: 'staging' - name: "Httpd 設定ファイルコピー(prod)" when: web.server_name_prod is defined template: src: 'vhost.d/prod.conf' dest: '/etc/httpd/conf.d/vhost.d/prod.conf' - name: "Httpd 各種ディレクトリ展開 (prod)" when: web.server_name_prod is defined set_fact: web: env: 'prod' vars: web: server_name_prod: "{{ inventory_hostname }}" server_name_staging: "{{ inventory_hostname | regex_replace('prod', 'staging') }}" envの変数を定義したいようだ(なんでここで ・・・?) mainのvarsで定義されており、inventory_hostname が登録されるようだ inventory_hostnameをweb.prod.local.testに指定し た場合、以下の通りになるはず server_name_prod:web.prod.local.test server_name_staging: web.staging.local.test
コードを動かす前の私の考え inventory_hostname を web.prod.test.local とした場合、以下の var が有効になる server_name_prod = web.prod.local.test
server_name_staging = web.staging.local.test 定義されたので、 when の条件分岐も true となる web.prod.test.local 上に prod と staging 両方の httpd config が配置されるだろう
実行してみたらそうならなかった TASK [web : Httpd 設定ファイルコピー (staging)] ***************************************************************************************** changed: [web.prod.test.local]
=> ~~~(ry~~~~ TASK [web : Httpd 各種ディレクトリ展開 (staging)] **************************************************************************************** ok: [web.prod.test.local] => {"ansible_facts": {"web": {"env": "staging"}}, "changed": false} TASK [web : Httpd 設定ファイルコピー (prod)] ******************************************************************************************** skipping: [web.prod.test.local] => ~(ry~: "Conditional result was False"} TASK [web : Httpd 各種ディレクトリ展開 (prod)] ******************************************************************************************* skipping: [web.prod.test.local] => {"changed": false, "skip_reason": "Conditional result was False"}
実行してみたらそうならなかった TASK [web : Httpd 設定ファイルコピー (staging)] ***************************************************************************************** changed: [web.prod.test.local]
=> ~~~(ry~~~~ TASK [web : Httpd 各種ディレクトリ展開 (staging)] **************************************************************************************** ok: [web.prod.test.local] => {"ansible_facts": {"web": {"env": "staging"}}, "changed": false} TASK [web : Httpd 設定ファイルコピー (prod)] ******************************************************************************************** skipping: [web.prod.test.local] => ~(ry~: "Conditional result was False"} TASK [web : Httpd 各種ディレクトリ展開 (prod)] ******************************************************************************************* skipping: [web.prod.test.local] => {"changed": false, "skip_reason": "Conditional result was False"} どうでもいい話ですが、 (ry って死語かな?と弊社チャットで話題になったら、 2020 年新卒の方から古文に片足つっこんでますとコメントいただきました
なんでskipされてしまうん? • よくわからん(教えて詳しい人) • 作業的には vars の server_name_staging をコメントアウトすることで、 httpd(prod)
が実 行できた ◦ set_fact で設定した env 変数が、この先の playbook の条件分岐で利用されている ◦ ここが skip されると prod 用の環境構築ができない状態になる • 期待としては変数を上書きして動的に処理させたかったのだと思われる ◦ けど実行できてなかったので、正しい状態とは言えない
まとめ • 変数を上書きしていく、はプログラマブルな発想 • ansible においては条件分岐はミスの元なので、多用しない方が良さそう ◦ ましてや条件分岐の先に条件分岐があると、もはやよくわからん状態に ◦ 複雑性が増していくだけなので、個人的には使いたくない
◦ 変数を指定したい場合は、 playbook 内で set_fact しなくても普通に vars に書けば良い
おわり