運用のためのPlaybook (Playbook for Operation)
-
Upload
shingo-kitayama -
Category
Technology
-
view
745 -
download
0
Transcript of 運用のためのPlaybook (Playbook for Operation)
Playbook for OperationAnsible Practical Meetup #1Shingo.Kitayama
2
元楽天株式会社 所属国際ECサービスのインフラ部門
日本ヒューレット・パッカード株式会社 所属テクニカルアーキテクトテクノロジーコンサルティング事業統括クロス・インダストリ・ソリューション統括本部テクノロジーアーキテクト部
http://book.impress.co.jp/books/1115101157
2016年末「Ansible実践ガイド」執筆
北山 晋吾 (Shingo.Kitayama)
経歴など
もーど2のかお
shkitayama spchildren
Introduction
3
Agenda
1. Infrastructure as Codeの原理
2. 運用のためのPlaybook
3. まとめ
※本資料に関しては、個人の意見に基づくものであり、十分考慮の上ですが、所属組織団体の公式見解とは異なる場合がございます。ご了承下さい。
Infrastructure as Codeの原理
4
構成管理の変遷Infrastructure as Codeが必要となった背景
5
構成管理DB(CMDB)
Code手順書
InstallInstall
変更履歴
Install Install
API
構成管理ツール
動的機器情報取得
Cloud Platform
・機器情報・変更情報・属性情報
情報更新
状態の管理構成情報全てを管理
仮想化による物理的な制約がなくなり管理が複雑化
クラウド活用の時代オンプレミス主流の時代
・構成管理情報と実態を常に同期・変更管理と変更が必要→ 構成管理範囲が広い
・動的情報収集・管理内容の可視化→ 自動化のために状態管理を行うこと
Infrastructure as Code(IaC)のメリットIaCを適用することでアジリティの高いサービスを提供
6
オペレーション工数の削減従来、手動で行ってきた作業をコード化、自動化することにより、オペレーション工数および納期の短縮が期待できる。
オペレーション品質の向上作業をコード化して、自動化することにより、オペレーション品質を均一に保つ効果がある。
システム運用の標準化の促進自動化やバージョン管理を適切に行うことで、システム運用のポリシーや業務標準化を形成できる。
作業統制の強化作業オペレーションを自動化することにより、内部統制やセキュリティ対策面での効果が期待できます。
Infrastructure as Codeの範囲ソフトウェア開発で実施されてきたプロセスをインフラの管理に適用
7
継続的デリバリー
継続的インテグレーションバージョン管理
バージョン管理システム
CI Server
Build Test
Check構成管理ツール
Feedback
CommitCode
自動化(デプロイ/テスト)
DevelopmentCI/Test
Staging
Production
Deployment
Release
Monitoring
インフラリソースをコードで操作するということは、そのコード自体が「品質管理」「バージョン管理」「テスト」の対象となるということ
8
プレイブックのベストプラクティスプレイブックは設定ファイルではなく、コードである。
---- name: Install Apache
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はインフラリソースをコードで操作するということ
コードの原理The Principles of Programming
9参照: プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則
プログラミングに銀の弾丸はないプログラミングは本質的に複雑なものであるため、課題に直面した場合は、そのコードができた背景や、歴史から追う必要がある。
コードは設計書であるプログラミングとは仕様のコード化だけではなく、仕様を改善する必要がある。
コードは必ず変更されるコードは修正されるものであり、一度書いて終わりということはほぼない。そのため、変更されることを想定してプログラミングする必要がある。
コードを書くことに時間をかけるよりも、読みやすいものを作る方がいい。
AnsibleのSimpleと言う特徴を損ねては
いけない
10
コードの原則The Principles of Programming
変化に強く柔軟なシステムを構築するために重要な考え方。
重複したコードを書かないこと。その考えに基づいて設計すること。
多分必要になるだろうではなく、本当に必要になったときに必要なモノを作成する。
同じメソッドに属するコードの抽象化レベルをすべて統一する。
読む人に意図がきちんと伝わるコードを書く。こざかしい、むずかしい、頭脳をアピールするコードは書かない。
問題解決において、簡潔性こそが本質的価値でありシステムのゴールでありプロセスであるという経験則。
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
YAGNIの一例You Aren't Going to Need It.
11
---
- name: Install the selinux python moduleyum: name=libselinux-python state=presentwhen: ansible_os_family == "RedHat"
- name: Copy the epel packages copy: src=epel.repo dest=/etc/yum.repos.d/epel_ansible.repowhen: ansible_os_family == "RedHat"
- name: Install the nginx packages yum: name={{ item }} state=presentwith_items: redhat_pkgwhen: ansible_os_family == "RedHat"
- name: Install the nginx packages apt: name={{ item }} state=present update_cache=yeswith_items: ubuntu_pkgenvironment: envwhen: ansible_os_family == "Debian"
多分必要になるだろうではなく、本当に必要になったときに必要なモノを作成する。
あらかじめいろいろな事態にそなえて機能を盛り込んでおいても、結局利用されないことが多く、余計に複雑性を盛り込むことになる。
例)Factによる条件分岐は便利だけれども、必要以上に利用する必要はない。
./roles/nginx/tasks/main.yml
PIEの一例Program Intently and Expressively.
12
- name: Create the links to enable site configurationsfile:
path: /etc/nginx/sites-enabled/{{ item['server']['file_name'] }}state: linksrc: /etc/nginx/sites-available/{{ item['server']['file_name'] }}
with_items: nginx_siteswhen: nginx_sites|lower != 'none'
コードを書くときには、書きやすさより読みやすさを重視すべき。
例)動的な値を除き、変数を必要以上に使いすぎない。
./roles/nginx/tasks/main.yml
- name: Create the links to enable site configurationsfile:
path: /etc/nginx/sites-enabled/{{ item }}state: link src=/etc/nginx/sites-available/{{ item }}with_items:- foo- varwhen: nginx_sites|lower != 'none'
運用のためのプレイブック
13
Ansibleの適応範囲デプロイやリリース作業がメイン
14
要件定義 開発 ビルド開発
デプロイテスト
本番
デプロイテスト リリース 運用
(2) 継続的インテグレーション
(3) 継続的デリバリー
(4) 継続的アセスメント
Business Needs Business Apps
手順の一部が、スクリプト化されバージョン管理されている。
手順が完全自動化されており、環境を変更しても、バージョン管理された設定を更新するフローが確立している。
(4) 継続的オペレーション
運用を踏まえた自動化の仕組みが完備されている。
(1) バージョン管理
ビジネス
アジリティ
手順のほとんどが自動化され、プロビジョニングツールで記述されており、即時に開発環境を作成できる。
Ansibleはデプロイの自動化に利用されることがほとんど。
15
Ansibleで運用作業ってできないの??
再掲) Infrastructure as Code(IaC)のメリットIaCを適用することでアジリティの高いサービスを提供
16
オペレーション工数の削減従来、手動で行ってきた作業をコード化、自動化することにより、オペレーション工数および納期の短縮が期待できる。
オペレーション品質の向上作業をコード化して、自動化することにより、オペレーション品質を均一に保つ効果がある。
システム運用の標準化の促進自動化やバージョン管理を適切に行うことで、システム運用のポリシーや業務標準化を形成できる。
作業統制の強化作業オペレーションを自動化することにより、内部統制やセキュリティ対策面での効果が期待できます。
再掲) Infrastructure as Code(IaC)のメリットIaCを適用することでアジリティの高いサービスを提供
17
オペレーション工数の削減従来、手動で行ってきた作業をコード化、自動化することにより、オペレーション工数および納期の短縮が期待できる。
オペレーション品質の向上作業をコード化して、自動化することにより、オペレーション品質を均一に保つ効果がある。
システム運用の標準化の促進自動化やバージョン管理を適切に行うことで、システム運用のポリシーや業務標準化を形成できる。
作業統制の強化作業オペレーションを自動化することにより、内部統制やセキュリティ対策面での効果が期待できます。
標準化、再利用性がある運用をターゲットとすべき
再利用性のある運用Playbook再利用性を持たせるための切替ポイント
18
タスクファイルroleの
mainタスクPlaybook
ロールのtasksファイル配下に個別のタスクを配置する。
tasks/{{ TASK }}.yml
ロールのmain.ymlを利用する。
tasks/main.yml
Playbookを運用ごとに作成する。
ロール内のタスクファイルをどれだけ再利用化できるかが運用Playbookを作成するメリット
ロールで作成する範囲
タスクファイル(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
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: startwhen: operation == "update_config"
block:- include: ./stop_process.yml- include: ./start_process.yml- include: ./check_process.yml
vars: check_status: startwhen: operation == "restart_process"
./roles/nginx/tasks/main.yml
メインタスクでは、各タスクファイルを業務作業にあわせた形で並べる。
この際に、特定の変数で業務作業単位で呼び出せるように設定しておく。
タスクファイルroleの
mainタスクPlaybook
21
Playbookの役割りロールと、行いたい定常業務作業を制御
---- hosts: web_serversserial: 1vars:operation: update_config
pre_tasks:…
roles:- role: nginx
./nginx_update_config.yml
Playbookは各定常業務の呼び出し、ホストの切替、ロールの切替などを制御する。
1つのPlaybookで全ての運用業務(TESTを含め)を行うことはできない。
タスクファイルroleの
mainタスクPlaybook
まとめ
22
運用Playbookのまとめ
23
Ansibleはコードのため、コードの原理原則を守るコードの原理原則が分かれば、 チーム運用に適したAnsibleのベストプラクティスできる。
運用Playbookは定常業務を対象とすべきすべての運用を自動化することはできない。(Ansibleの役割りを超えている)
運用Playbookを作成しても、再利用性のあるプレイブックを心掛ける再利用性がないのであれば、運用Playbookを作る必要はない
Ansibleはコードです。。。
24
Enjoy Ansible!!
Thank you