Ansible Roleの継続的自動Update

542bf1e833425f6ab7bc7bd7238a4792?s=47 chroju
April 25, 2018

Ansible Roleの継続的自動Update

Ansible Night in Tokyo 2018.04

542bf1e833425f6ab7bc7bd7238a4792?s=128

chroju

April 25, 2018
Tweet

Transcript

  1. ANSIBLE ROLE の継 ANSIBLE ROLE の継 続的自動UPDATE 続的自動UPDATE Ansible Night

    in Tokyo 2018.04 chroju
  2. 自己紹介 自己紹介 chroju / / インフラの面倒を見たり運用の改善したりする仕事 Ansible / Terraform /

    in uxDB / Python あたり GitHub Qiita Twitter
  3. INFRASTRUCTURE AS CODE における INFRASTRUCTURE AS CODE における コードの再利用 コードの再利用

    例えば複数のサービスでnginx を使いたい場合 NG → サービスごとにコードを書く OK → 1 回書いたコードを各サービスで再利用 する コード再利用でスノーフレークサーバーを防ぐ
  4. ANSIBLE ROLE での再利用 ANSIBLE ROLE での再利用 Ansible でコードを再利用する仕組みはAnsible Role task,

    handler, 変数, template 等をまとめてモジュ ール化 Role の管理は ansible-galaxy コマンドと requirements.yml で可能 $ ansible-galaxy install bennojoy.nginx - src: https://github.com/bennojoy/nginx version: master name: nginx_role
  5. ROLE を再利用 ROLE を再利用

  6. 再利用 … 再利用 …

  7. ROLE を更新すると? ROLE を更新すると?

  8. Role を使い回すほど管理が大変になる

  9. ROLE の更新をPLAYBOOK にどう ROLE の更新をPLAYBOOK にどう 反映する? 反映する? Role の更新をいかに各Playbook

    側でキャッチする のか? Playbook ごとにRole の更新→テストを全部やるの か? 1000 Playbook あったら? 継続的自動的にやるしかないのでは?
  10. ソフトウェア開発に倣う ソフトウェア開発に倣う Infrastructure as Code は、ソフトウェ ア開発のプラクティスをインフラの オートメーションに活かすアプロー チだ。 (Kief

    Morris 『Infrastructure as Code 』p.5)
  11. ROLE ≒ プログラムのPACKAGE ROLE ≒ プログラムのPACKAGE Ansible Role はRubyGems やJS

    のyarn など、プログ ラムで言うpackage やmodule と似た位置付け ソフトウェアでもimported package の継続的更新は 課題になっている 定期的にyarn update するには - おもしろweb サー ビス開発日記 Jenkins に bundle update した上で Pull Request させる - @kyanny’s blog
  12. JENKINS !! (OR CI) JENKINS !! (OR CI)

  13. ROLE もCI で継続的UPDATE ROLE もCI で継続的UPDATE こんな感じでうまくいきそう? 1. 更新確認用のブランチにcheckout 2.

    install しているrole の更新を確認 3. 更新があればupdate 4. update 後にserverspec 等テストを回す 5. テストが通ったらJenkins からPR 6. 結果をslack に通知
  14. ANSIBLE-GALAXY ANSIBLE-GALAXY での実現 での実現 やりたいのは requirements.yml の記載バージョン から更新があるかの確認 しかし requirements.yml

    にバージョン指定されて いると、install -fr しても最新は入らない 最新を追いかける手段がない
  15. バージョンをLOCK する バージョンをLOCK する requirements.yml を2 種類用意する(Gem le.lock の 発想)

    requirements.lock.yml にバージョン指定を書く 普段の実行時にはこちらを使う requirements.yml はバージョン指定しない 更新確認ではこちらを使い、lock.yml より新しい バージョンが入るか確認する
  16. SAMPLE SAMPLE # まずlockからインストール $ ansible-galaxy install -r requirements.lock.yml $

    ansible-galaxy list -p ./roles > before # 次にrequirements.ymlから $ ansible-galaxy install -fr requirements.yml $ ansible-galaxy list -p ./roles > after $ if [[ $(diff before after | wc -l) -gt 0 ]]; then ... # この後でtestしてpushしてPRして通知
  17. 余談: ROLE の後方互換性 余談: ROLE の後方互換性 Role を更新するとき、Playbook 側でなるべく作業が 必要ないよう配慮する

    Role の破壊的な変更はなるべくしない Role 名や変数名は変えない 変数をdeprecated にするなら、debug module で その旨を実行時に出力するなど、気付かせてあげ るべき 変数追加時は必ず defaults/ で初期値を設定する
  18. まとめ まとめ Ansible でも依存モジュールを継続的自動更新をす るべき ansible-galaxy obsolete コマンドがほしい 何かいい方法があったら教えてほしいです