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
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
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
53
Dockerインストール後の設定をしよう/Set up after installing Docker
dayamaguchi1
2
780
ITエンジニアが学ぶ「ティール組織」概要 / IT Engineer learns "Teal organization" summary
dayamaguchi1
2
240
Rancherから始めるCloud Native Journey / Start with Rancher Cloud Native Journey
dayamaguchi1
0
390
Other Decks in Technology
See All in Technology
Claude Codeベストプラクティスまとめ
minorun365
58
32k
レガシー共有バッチ基盤への挑戦 - SREドリブンなリアーキテクチャリングの取り組み
tatsukoni
0
160
Azure Durable Functions で作った NL2SQL Agent の精度向上に取り組んだ話/jat08
thara0402
0
110
DatabricksホストモデルでAIコーディング環境を構築する
databricksjapan
0
220
ブロックテーマでサイトをリニューアルした話 / 2026-01-31 Kansai WordPress Meetup
torounit
0
330
KubeCon + CloudNativeCon NA ‘25 Recap, Extensibility: Gateway API / NRI
ladicle
0
170
名刺メーカーDevグループ 紹介資料
sansan33
PRO
0
1k
サイボウズ 開発本部採用ピッチ / Cybozu Engineer Recruit
cybozuinsideout
PRO
10
73k
AI時代、1年目エンジニアの悩み
jin4
1
140
Introduction to Bill One Development Engineer
sansan33
PRO
0
350
日本語テキストと音楽の対照学習の技術とその応用
lycorptech_jp
PRO
1
400
Embedded SREの終わりを設計する 「なんとなく」から計画的な自立支援へ
sansantech
PRO
2
1.3k
Featured
See All Featured
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
9
1.1k
AI Search: Where Are We & What Can We Do About It?
aleyda
0
6.9k
My Coaching Mixtape
mlcsv
0
45
Marketing to machines
jonoalderson
1
4.6k
Building a Scalable Design System with Sketch
lauravandoore
463
34k
KATA
mclloyd
PRO
34
15k
From π to Pie charts
rasagy
0
120
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
630
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
35
2.4k
Done Done
chrislema
186
16k
Code Review Best Practice
trishagee
74
20k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
2.7k
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 に書けば良い
おわり