24
Playbook for Operation Ansible Practical Meetup #1 Shingo.Kitayama

運用のためのPlaybook (Playbook for Operation)

Embed Size (px)

Citation preview

Page 1: 運用のためのPlaybook (Playbook for Operation)

Playbook for OperationAnsible Practical Meetup #1Shingo.Kitayama

Page 2: 運用のためのPlaybook (Playbook for Operation)

2

元楽天株式会社 所属国際ECサービスのインフラ部門

日本ヒューレット・パッカード株式会社 所属テクニカルアーキテクトテクノロジーコンサルティング事業統括クロス・インダストリ・ソリューション統括本部テクノロジーアーキテクト部

http://book.impress.co.jp/books/1115101157

2016年末「Ansible実践ガイド」執筆

北山 晋吾 (Shingo.Kitayama)

経歴など

もーど2のかお

shkitayama spchildren

Introduction

Page 3: 運用のためのPlaybook (Playbook for Operation)

3

Agenda

1. Infrastructure as Codeの原理

2. 運用のためのPlaybook

3. まとめ

※本資料に関しては、個人の意見に基づくものであり、十分考慮の上ですが、所属組織団体の公式見解とは異なる場合がございます。ご了承下さい。

Page 4: 運用のためのPlaybook (Playbook for Operation)

Infrastructure as Codeの原理

4

Page 5: 運用のためのPlaybook (Playbook for Operation)

構成管理の変遷Infrastructure as Codeが必要となった背景

5

構成管理DB(CMDB)

Code手順書

InstallInstall

変更履歴

Install Install

API

構成管理ツール

動的機器情報取得

Cloud Platform

・機器情報・変更情報・属性情報

情報更新

状態の管理構成情報全てを管理

仮想化による物理的な制約がなくなり管理が複雑化

クラウド活用の時代オンプレミス主流の時代

・構成管理情報と実態を常に同期・変更管理と変更が必要→ 構成管理範囲が広い

・動的情報収集・管理内容の可視化→ 自動化のために状態管理を行うこと

Page 6: 運用のためのPlaybook (Playbook for Operation)

Infrastructure as Code(IaC)のメリットIaCを適用することでアジリティの高いサービスを提供

6

オペレーション工数の削減従来、手動で行ってきた作業をコード化、自動化することにより、オペレーション工数および納期の短縮が期待できる。

オペレーション品質の向上作業をコード化して、自動化することにより、オペレーション品質を均一に保つ効果がある。

システム運用の標準化の促進自動化やバージョン管理を適切に行うことで、システム運用のポリシーや業務標準化を形成できる。

作業統制の強化作業オペレーションを自動化することにより、内部統制やセキュリティ対策面での効果が期待できます。

Page 7: 運用のためのPlaybook (Playbook for Operation)

Infrastructure as Codeの範囲ソフトウェア開発で実施されてきたプロセスをインフラの管理に適用

7

継続的デリバリー

継続的インテグレーションバージョン管理

バージョン管理システム

CI Server

Build Test

Check構成管理ツール

Feedback

CommitCode

自動化(デプロイ/テスト)

DevelopmentCI/Test

Staging

Production

Deployment

Release

Monitoring

インフラリソースをコードで操作するということは、そのコード自体が「品質管理」「バージョン管理」「テスト」の対象となるということ

Page 8: 運用のためのPlaybook (Playbook for Operation)

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はインフラリソースをコードで操作するということ

Page 9: 運用のためのPlaybook (Playbook for Operation)

コードの原理The Principles of Programming

9参照: プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則

プログラミングに銀の弾丸はないプログラミングは本質的に複雑なものであるため、課題に直面した場合は、そのコードができた背景や、歴史から追う必要がある。

コードは設計書であるプログラミングとは仕様のコード化だけではなく、仕様を改善する必要がある。

コードは必ず変更されるコードは修正されるものであり、一度書いて終わりということはほぼない。そのため、変更されることを想定してプログラミングする必要がある。

コードを書くことに時間をかけるよりも、読みやすいものを作る方がいい。

AnsibleのSimpleと言う特徴を損ねては

いけない

Page 10: 運用のためのPlaybook (Playbook for Operation)

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

Page 11: 運用のためのPlaybook (Playbook for Operation)

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

Page 12: 運用のためのPlaybook (Playbook for Operation)

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'

Page 13: 運用のためのPlaybook (Playbook for Operation)

運用のためのプレイブック

13

Page 14: 運用のためのPlaybook (Playbook for Operation)

Ansibleの適応範囲デプロイやリリース作業がメイン

14

要件定義 開発 ビルド開発

デプロイテスト

本番

デプロイテスト リリース 運用

(2) 継続的インテグレーション

(3) 継続的デリバリー

(4) 継続的アセスメント

Business Needs Business Apps

手順の一部が、スクリプト化されバージョン管理されている。

手順が完全自動化されており、環境を変更しても、バージョン管理された設定を更新するフローが確立している。

(4) 継続的オペレーション

運用を踏まえた自動化の仕組みが完備されている。

(1) バージョン管理

ビジネス

アジリティ

手順のほとんどが自動化され、プロビジョニングツールで記述されており、即時に開発環境を作成できる。

Ansibleはデプロイの自動化に利用されることがほとんど。

Page 15: 運用のためのPlaybook (Playbook for Operation)

15

Ansibleで運用作業ってできないの??

Page 16: 運用のためのPlaybook (Playbook for Operation)

再掲) Infrastructure as Code(IaC)のメリットIaCを適用することでアジリティの高いサービスを提供

16

オペレーション工数の削減従来、手動で行ってきた作業をコード化、自動化することにより、オペレーション工数および納期の短縮が期待できる。

オペレーション品質の向上作業をコード化して、自動化することにより、オペレーション品質を均一に保つ効果がある。

システム運用の標準化の促進自動化やバージョン管理を適切に行うことで、システム運用のポリシーや業務標準化を形成できる。

作業統制の強化作業オペレーションを自動化することにより、内部統制やセキュリティ対策面での効果が期待できます。

Page 17: 運用のためのPlaybook (Playbook for Operation)

再掲) Infrastructure as Code(IaC)のメリットIaCを適用することでアジリティの高いサービスを提供

17

オペレーション工数の削減従来、手動で行ってきた作業をコード化、自動化することにより、オペレーション工数および納期の短縮が期待できる。

オペレーション品質の向上作業をコード化して、自動化することにより、オペレーション品質を均一に保つ効果がある。

システム運用の標準化の促進自動化やバージョン管理を適切に行うことで、システム運用のポリシーや業務標準化を形成できる。

作業統制の強化作業オペレーションを自動化することにより、内部統制やセキュリティ対策面での効果が期待できます。

標準化、再利用性がある運用をターゲットとすべき

Page 18: 運用のためのPlaybook (Playbook for Operation)

再利用性のある運用Playbook再利用性を持たせるための切替ポイント

18

タスクファイルroleの

mainタスクPlaybook

ロールのtasksファイル配下に個別のタスクを配置する。

tasks/{{ TASK }}.yml

ロールのmain.ymlを利用する。

tasks/main.yml

Playbookを運用ごとに作成する。

ロール内のタスクファイルをどれだけ再利用化できるかが運用Playbookを作成するメリット

ロールで作成する範囲

Page 19: 運用のためのPlaybook (Playbook for Operation)

タスクファイル(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

Page 20: 運用のためのPlaybook (Playbook for Operation)

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

Page 21: 運用のためのPlaybook (Playbook for Operation)

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

Page 22: 運用のためのPlaybook (Playbook for Operation)

まとめ

22

Page 23: 運用のためのPlaybook (Playbook for Operation)

運用Playbookのまとめ

23

Ansibleはコードのため、コードの原理原則を守るコードの原理原則が分かれば、 チーム運用に適したAnsibleのベストプラクティスできる。

運用Playbookは定常業務を対象とすべきすべての運用を自動化することはできない。(Ansibleの役割りを超えている)

運用Playbookを作成しても、再利用性のあるプレイブックを心掛ける再利用性がないのであれば、運用Playbookを作る必要はない

Ansibleはコードです。。。

Page 24: 運用のためのPlaybook (Playbook for Operation)

24

Enjoy Ansible!!

Thank you