自動化大好きエンジニアLT会　第6回発表資料

1. 既存サーバを後からAnsible
で構成管理する
自動化大好きエンジニアLT会 第6回

2. ■今日のポイント
既に手動等で構築しているサーバを新たに
Ansibleの構成管理に加える場合について、どの
様に対応しているかを紹介致します。
Ansibleを使って１から構築する場合とは違った
観点が必要です。

3. ■自己紹介
 [名前]: 上畑圭史（うえはたけいじ)
 [Twitter]: いじけまん(@ijikeman)
 [職業]:株式会社ラクスのインフラエンジニア
 [趣味1]: 自作キーボード大好き
アクリル板(4mm)にキーの穴(60個)を手であけた
自キー(自作キーボード)界隈ではちょっとした有名人
 [趣味2]: ピアノ歴5ヵ月(コロナを契機に) …
 [趣味3]: 野菜作り
 [趣味4]: 自動化大好きエンジニアLT会登壇(第1～6回) 皆勤継続
3

4. ■１. 既存環境へのDry run
--check option
基本的なことですが、ansibleのコードを作成した後は必ず本番環
境に対してDry run[--check]を実行し差分を確認します。
その際、テンプレートやファイルに関しては差分を表示する為、
“--diff”オプションを付けて差分情報を表示しましょう。

5. Dry runモードでチェックで
きないケース

6. Command系のモジュールはDry runモードでは処理をスキップします。
以下例では
shellで確認するバージョンチェック処理がスキップされる為、“register:
app_version”が未定義となります。
次の、アプリのインストールでAnsibleエラーとなり処理がストップします。
その為、Dry runモードではスキップさせるよう
“when: not ansible_check_mode”を実装しています。
■Command系は実行されない
Skipされて未定義
Dry runでも実行エラー
実行エラーの回避

7. ■Command系は実行されない
skipされ未定義
Dry runでも実行エラー
“when: not ansible_check_mode”を実装せずに実行した場合

8. 解決策: check_mode: no
■Command系は実行されない
Dry runでも実行
このオプションはDry runモードであっても実行する為、when:
でエラーにならず実行することができます。

9. この様にDry runモードを使ってあらかじめ既
存環境に対する影響を確認できますので、活用
をお勧めします。

10. ■2. ファイルバックアップ
次にfile等を置き換える場合です。
既存環境に対してファイルの操作を実施する場合には、
“backup: yes”
を追加してバックアップを実施しています。
また、バックアップファイルは
“[FILENAME].PID.YYYY-MM-DD@HH:mm:ss~”
となりカスタマイズはできない様です。

11. □backupが実装されているモジュール
• assemble
• blockinfile
• copy
• cron
• get_url
• lineinfile
• replace
• template
■2. ファイルバックアップ

12. ■3. 部分適用
構成情報を全て実装してから適用すると影響範囲が広くなる為、適
用範囲を絞り徐々に範囲を広げています。
メリット 説明
レビュー者の負担軽減 コード、テスト結果
量が増える事でレビュー品質が下がる
※逆に回数は増える為、範囲設定は要調整
適用時のトラブル影響範囲
を限定
予想外の事態に備え、リカバリ時は範囲が狭い
方がよい
Dry run等テストコストの
低減
コード修正の度にテストを実施する為、テスト
コストを下げる

13. ■3. 部分適用(その他)
1. ファイル等の改変は軽微だがnotifyでサービス再起動が走ってし
まう。(例えばコメント行だけ追加や無駄な改行削除など)
→ handlersにwhen:で条件分岐を一時的記載して再起動を回避
2. tags, skip-tagsを使用し、該当部分のみ処理を行う。
→ 対象台数が増えれば増えるほど全てのAnsibleコードを実行する
と時間がかかる等。
※ただし、部分適用はあくまでも臨時措置であり常用すべきではな
い。
全Ansibleコードを実行して、冪等性の担保に努めることが基本。

14. おわり。