Downloaded 44 times
![PIEの一例
Program Intently and Expressively.
12
- name: Create the links to enable site configurations
file:
path: /etc/nginx/sites-enabled/{{ item['server']['file_name'] }}
state: link
src: /etc/nginx/sites-available/{{ item['server']['file_name'] }}
with_items: nginx_sites
when: nginx_sites|lower != 'none'
コードを書くときには、書きやすさより読み
やすさを重視すべき。
例）
動的な値を除き、変数を必要以上に使いすぎ
ない。
./roles/nginx/tasks/main.yml
- name: Create the links to enable site configurations
file:
path: /etc/nginx/sites-enabled/{{ item }}
state: link src=/etc/nginx/sites-available/{{ item }}
with_items:
- foo
- var
when: nginx_sites|lower != 'none'](https://image.slidesharecdn.com/principleofplaybook-170223115017/85/Playbook-Playbook-for-Operation-12-320.jpg)
Uploaded byShingo Kitayama
運用のためのPlaybook (Playbook for Operation)
Ansible Practice Meetup 「Ansible実践ガイド」出版記念イベント 発表資料 https://thinkit.connpass.com/event/47283/
More Related Content
![[B11] 基礎から知るSSD（いまさら聞けないSSDの基本） by Hironobu Asano](https://cdn.slidesharecdn.com/ss_thumbnails/b11-140623022028-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to 運用のためのPlaybook (Playbook for Operation)
![[Red Hat Forum 2017] Ansible Towerの実践!!エンタープライズのInfrastructure as Codeの現在(イマ)](https://cdn.slidesharecdn.com/ss_thumbnails/redhatforumv04-171020081056-thumbnail.jpg?width=640&height=640&fit=bounds)
運用のためのPlaybook (Playbook for Operation)
- 1. Playbook for Operation AnsiblePractical Meetup #1 Shingo.Kitayama
- 2. 2 元楽天株式会社 所属 国際ECサービスのインフラ部門 日本ヒューレット・パッカード株式会社 所属 テクニカルアーキテクト テクノロジーコンサルティング事業統括 クロス・インダストリ・ソリューション統括本部 テクノロジーアーキテクト部 http://book.impress.co.jp/books/1115101157 2016年末「Ansible実践ガイド」執筆 北山晋吾 (Shingo.Kitayama) 経歴など もーど２のかお shkitayama spchildren Introduction
- 3. 3 Agenda 1. Infrastructure asCodeの原理 2. 運用のためのPlaybook 3. まとめ ※本資料に関しては、個人の意見に基づくものであり、十分考慮の上ですが、所属組織団体の公式見解とは異なる場 合がございます。 ご了承下さい。
- 4.
- 5. 構成管理の変遷 Infrastructure as Codeが必要となった背景 5 構成管理DB (CMDB) Code手順書 InstallInstall 変更履歴 InstallInstall API 構成管理ツール 動的機器情報取得 Cloud Platform ・機器情報 ・変更情報 ・属性情報 情報更新 状態の管理 構成情報全てを管理 仮想化による物理的な制約 がなくなり管理が複雑化 クラウド活用の時代オンプレミス主流の時代 ・構成管理情報と実態を常に同期 ・変更管理と変更が必要 → 構成管理範囲が広い ・動的情報収集 ・管理内容の可視化 → 自動化のために状態管理を行うこと
- 6.
- 7. Infrastructure as Codeの範囲 ソフトウェア開発で実施されてきたプロセスをインフラの管理に適用 7 継続的デリバリー 継続的インテグレーション バージョン管理 バージョン管理 システム CIServer Build Test Check 構成管理ツール Feedback Commit Code 自動化(デプロイ/テスト) Development CI/Test Staging Production Deployment Release Monitoring インフラリソースをコードで操作するということは、そのコード自体が 「品質管理」「バージョン管理」「テスト」の対象となるということ
- 8. 8 プレイブックのベストプラクティス プレイブックは設定ファイルではなく、コードである。 --- - name: InstallApache yum: name=http when: ansible_distribution == 'CentOS' - name: Configure Apache template: src: httpd.conf dest: /etc/httpd/conf/httpd.conf - name: Start Apache service: name: httpd state: started enabled: yes Ansibleのプレイブックを上手く構成、管理したければ、 コードの原理原則を知るべきである。 プレイブックの ベストプラクティスとは?? ? ? ? Infrastructure as Codeは インフラリソースをコードで操作するということ
- 9. コードの原理 The Principles ofProgramming 9参照: プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則 プログラミングに銀の弾丸はない プログラミングは本質的に複雑なものであるため、課題に直面した場合は、そのコードができた背景や、 歴史から追う必要がある。 コードは設計書である プログラミングとは仕様のコード化だけではなく、仕様を改善する必要がある。 コードは必ず変更される コードは修正されるものであり、一度書いて終わりということはほぼない。そのため、変更されることを想定 してプログラミングする必要がある。 コードを書くことに時間をかけるよりも、読みやすいものを作る方がいい。 AnsibleのSimpleと 言う特徴を損ねては いけない
- 10. 10 コードの原則 The Principles ofProgramming 変化に強く柔軟なシス テムを構築するために 重要な考え方。 重複したコードを書か ないこと。 その考えに基づいて設 計すること。 多分必要になるだろう ではなく、本当に必要 になったときに必要な モノを作成する。 同じメソッドに属する コードの抽象化レベル をすべて統一する。 読む人に意図がきちん と伝わるコードを書く。 こざかしい、むずかし い、頭脳をアピールす るコードは書かない。 問題解決において、簡 潔性こそが本質的価値 でありシステムのゴー ルでありプロセスであ るという経験則。 DRY YAGNI PIE SLAPKISS Don't Repeat Yourself. You Aren't Going to Need It. Program Intently and Expressively. Single Level of Abstraction Principle Keep it short and simple. 参照: http://d.hatena.ne.jp/asakichy/20100203/1265158263
- 11. YAGNIの一例 You Aren't Goingto Need It. 11 --- - name: Install the selinux python module yum: name=libselinux-python state=present when: ansible_os_family == "RedHat" - name: Copy the epel packages copy: src=epel.repo dest=/etc/yum.repos.d/epel_ansible.repo when: ansible_os_family == "RedHat" - name: Install the nginx packages yum: name={{ item }} state=present with_items: redhat_pkg when: ansible_os_family == "RedHat" - name: Install the nginx packages apt: name={{ item }} state=present update_cache=yes with_items: ubuntu_pkg environment: env when: ansible_os_family == "Debian" 多分必要になるだろうではなく、本当に必要 になったときに必要なモノを作成する。 あらかじめいろいろな事態にそなえて機能を 盛り込んでおいても、結局利用されないこと が多く、余計に複雑性を盛り込むことになる。 例） Factによる条件分岐は便利だけれども、必要以 上に利用する必要はない。 ./roles/nginx/tasks/main.yml
- 12. PIEの一例 Program Intently andExpressively. 12 - name: Create the links to enable site configurations file: path: /etc/nginx/sites-enabled/{{ item['server']['file_name'] }} state: link src: /etc/nginx/sites-available/{{ item['server']['file_name'] }} with_items: nginx_sites when: nginx_sites|lower != 'none' コードを書くときには、書きやすさより読み やすさを重視すべき。 例） 動的な値を除き、変数を必要以上に使いすぎ ない。 ./roles/nginx/tasks/main.yml - name: Create the links to enable site configurations file: path: /etc/nginx/sites-enabled/{{ item }} state: link src=/etc/nginx/sites-available/{{ item }} with_items: - foo - var when: nginx_sites|lower != 'none'
- 13.
- 14. Ansibleの適応範囲 デプロイやリリース作業がメイン 14 要件定義 開発 ビルド 開発 デプロイ テスト 本番 デプロイ テストリリース 運用 (2) 継続的インテグレーション (3) 継続的デリバリー (4) 継続的アセスメント Business Needs Business Apps 手順の一部が、スクリプト化されバージョン管理されている。 手順が完全自動化されており、環境を変更しても、バージョン管理された設定を更新するフローが確立している。 (4) 継続的オペレーション 運用を踏まえた自動化の仕組みが完備されている。 (1) バージョン管理 ビジネス アジリティ 手順のほとんどが自動化され、プロビジョニングツールで記述されており、即時に開発環境を作成できる。 Ansibleはデプロイの自動化に利 用されることがほとんど。
- 15.
- 16. 再掲) Infrastructure asCode(IaC)のメリット IaCを適用することでアジリティの高いサービスを提供 16 オペレーション工数の削減 従来、手動で行ってきた作業をコード化、自動化することにより、オペレーション工数および納期の短縮 が期待できる。 オペレーション品質の向上 作業をコード化して、自動化することにより、オペレーション品質を均一に保つ効果がある。 システム運用の標準化の促進 自動化やバージョン管理を適切に行うことで、システム運用のポリシーや業務標準化を形成できる。 作業統制の強化 作業オペレーションを自動化することにより、内部統制やセキュリティ対策面での効果が期 待できます。
- 17. 再掲) Infrastructure asCode(IaC)のメリット IaCを適用することでアジリティの高いサービスを提供 17 オペレーション工数の削減 従来、手動で行ってきた作業をコード化、自動化することにより、オペレーション工数および納期の短縮 が期待できる。 オペレーション品質の向上 作業をコード化して、自動化することにより、オペレーション品質を均一に保つ効果がある。 システム運用の標準化の促進 自動化やバージョン管理を適切に行うことで、システム運用のポリシーや業務標準化を形成できる。 作業統制の強化 作業オペレーションを自動化することにより、内部統制やセキュリティ対策面での効果が期 待できます。 標準化、再利用性がある運用をターゲットとすべき
- 18.
- 19. タスクファイル(tasks/{{ TASK }}.yml)の役割り ロールのタスクを定常業務の作業単位で作成 19 ./roles/nginx/tasks/ -start_process.yml (プロセスの起動) - stop_process.yml (プロセスの停止) - check_process.yml (プロセスの確認) - modify_configuration.yml (設定更新) - initial_setup.yml (初期構築) - … - name: 利用ポートの確認 - name: 利用IPアドレスの確認 - name: nginxの起動 - name: nginxのコンテンツ確認 などなど 各タスクファイルは 疎結合で完了するように作成する。 ./roles/nginx/tasks/start_process.yml 起動タスクと言っても、 運用上起動だけを行 うわけではない。 タスクファイル roleの mainタスク Playbook
- 20. 20 roleのメインタスク(tasks/main.yml)の役割り 定常業務の流れをmain.ymlで制御 --- block: - include: ./check_process.yml vars:check_status: start - include: ./stop_process.yml - include: ./modify_configuration.yml - include: ./start_process.yml - include: ./check_process.yml vars: check_status: start when: operation == "update_config" block: - include: ./stop_process.yml - include: ./start_process.yml - include: ./check_process.yml vars: check_status: start when: operation == "restart_process" ./roles/nginx/tasks/main.yml メインタスクでは、各タスクファイ ルを業務作業にあわせた形で並 べる。 この際に、特定の変数で業務作 業単位で呼び出せるように設定 しておく。 タスクファイル roleの mainタスク Playbook
- 21. 21 Playbookの役割り ロールと、行いたい定常業務作業を制御 --- - hosts: web_servers serial:1 vars: operation: update_config pre_tasks: … roles: - role: nginx ./nginx_update_config.yml Playbookは各定常業務の呼び出 し、ホストの切替、ロールの切替 などを制御する。 １つのPlaybookで全ての運用業 務(TESTを含め)を行うことはでき ない。 タスクファイル roleの mainタスク Playbook
- 22.
- 23.
- 24.