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.8k
他作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
540
CloudNative Nagoya Code of conduct
dayamaguchi1
0
46
Dockerインストール後の設定をしよう/Set up after installing Docker
dayamaguchi1
2
720
ITエンジニアが学ぶ「ティール組織」概要 / IT Engineer learns "Teal organization" summary
dayamaguchi1
2
230
Rancherから始めるCloud Native Journey / Start with Rancher Cloud Native Journey
dayamaguchi1
0
370
Other Decks in Technology
See All in Technology
型システムを知りたい人のための型検査器作成入門
mame
15
3.8k
Devin(Deep) Wiki/Searchの活用で変わる開発の世界観/devin-wiki-search-impact
tomoki10
0
310
Model Mondays S2E01: Advanced Reasoning
nitya
0
360
(非公式) AWS Summit Japan と 海浜幕張 の歩き方 2025年版
coosuke
PRO
1
240
Javalinの紹介
notoh
0
110
堅牢な認証基盤の実現 TypeScriptで代数的データ型を活用する
kakehashi
PRO
2
220
上長や社内ステークホルダーに対する解像度を上げて、より良い補完関係を築く方法 / How-to-increase-resolution-and-build-better-complementary-relationships-with-your-bosses-and-internal-stakeholders
madoxten
13
7.6k
今からでも間に合う! 生成AI「RAG」再入門 / Re-introduction to RAG in Generative AI
hideakiaoyagi
1
170
Introduction to Sansan, inc / Sansan Global Development Center, Inc.
sansan33
PRO
0
2.6k
RubyOnRailsOnDevin+α / DevinMeetupJapan#2
ginkouno
0
390
Amplifyとゼロからはじめた AIコーディング 成果と展望
mkdev10
1
230
活きてなかったデータを活かしてみた話 / Shirokane Kougyou vol 19
sansan_randd
1
290
Featured
See All Featured
Speed Design
sergeychernyshev
31
990
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
BBQ
matthewcrist
89
9.7k
Making the Leap to Tech Lead
cromwellryan
134
9.3k
4 Signs Your Business is Dying
shpigford
184
22k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
20
1.3k
Why You Should Never Use an ORM
jnunemaker
PRO
56
9.4k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
228
22k
Art, The Web, and Tiny UX
lynnandtonic
299
21k
Product Roadmaps are Hard
iamctodd
PRO
53
11k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
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 に書けば良い
おわり