「Ansible on Azure入門」でのAnsible概要説明資料です。

1. Ansible on Azure概要説明
廣川英寿（株式会社リアルグローブ）

2. 自己紹介
 廣川英寿 @h-hirokawa
 株式会社リアルグローブ 主幹技師
 Python + SPA によるWebアプリ開発
 コンテナ型PaaS開発/運用
 AI系開発（自然言語処理、機械学習、Prolog…）
 DevOps導入支援業務
 主著書: Ansible徹底入門（翔泳社）

3. 最初に歴史の話を少し

4. IaaS伝来以前
~家内制手工業の時代~
各社が自前で物理マシンを購入したり、
ホスティング・サービスを介してサーバー
を運用
インフラ(サーバー、ネットワーク)の構築
サーバー内のセットアップ作業は、
基本的に手作業が中心
構成の自由度は低く、作業時間もかかり、
全体的にコストがかさみがち

5. IaaS時代の到来
~工場制手工業の時代~
ユーザーはインフラ・レイヤーの物理面
を気にせずに、サーバーとネットワーク
環境を手に入れられるように
マシンの追加・削除、ネットワーク構成
変更などもリアルタイムで実施可能
自由度は格段に向上、コストは大幅減
IaaS自体の操作やサーバー内設定は、
まだまだ手作業が支配的

6. PaaS, SaaSの普及
~工場制機械工業の時代~
ユーザーはインフラ環境だけではなく、
その上で動くシステム環境一式や、
必要となる特定の機能をサービスとして
調達可能になった
もはやバックエンドの設定は不要！
いきなり目的を達成できてしまう
システム構築 ≒
「必要なサービスの選択と組み合わせ」
と言う新たな世界観

7. これで充分？

8. 残されている課題
 必要なものが全て予めサービス化されている訳ではない
 効率的で自由度の高いシステム構築のためには既成のPaaS/SaaSだけでは不十分
 ネットワークやミドルウェアの世話が完全に不要になる事は（当分）ない
 物理マシンの復権
 パフォーマンスを追求すると仮想マシンによる完全仮想化はオーバーヘッド大
 物理マシン上でのコンテナ・クラスタが大規模サービスで採用されている
 Eg. Google, Facebook…
 複数サービス/レイヤーの繋ぎこみが必要
 インフラ・レイヤーの構築（IaaS、オンプレミス）
 マシン内の設定（OS、ミドルウェア、アプリケーション）
 外部サービスの設定と連携（PaaS、SaaS）

9. 運用業務を真に効率化するには
各層を網羅する
柔軟な自動化の手段が必要

10. そのための方法論が

11. Infrastructure as Code

12. Infrastructure as Code とは
 インフラの設定を自動実行可能なコードとして記述すること
 メリット
 効率アップ → 並列化による時間削減、無人化/省人化による作業コスト削減
 安全 → 作業ミス・ゼロ化、状態の完全再現による厳密な検証
 ソフトウェア開発プラクティスの導入: DevOps
 バージョン管理（Eg. git, svn）
 自動テスト
 継続的インテグレーション（CI）
• ここで言うインフラは、物理レイヤーからミドルウェア、
アプリ・デプロイまでを含んだシステム稼働の為に必要な環境全体のこと

13. Infrastructure as Code 実現の2レイヤー
1. オーケストレーション
 サーバー、ネットワークといった実インフラ層の制御を行う
 OSSツール例:
 Terraform: 各種IaaSを中心としたインフラ構成を統合的に記述可能
 オーケストレーション機能が提供されているIaaS基盤もある
 例) Azure ARM Template
 Azure上の各種リソース構成をまとめてJSONで記述しデプロイできる
 通常のVM + ネットワーク構成はもちろん、オートスケール設定なども可能
 https://github.com/Azure/azure-quickstart-templates に各種サンプルあり
 AWS CloudFormation なども同系統のサービス
 特化した物の方が機能は豊富だが個々に学習が必要（餅屋 vs 何でも屋）

14. Infrastructure as Code 実現の2レイヤー
2. コンフィギュレーション
 サーバー内でのコマンド実行やファイル操作を通じて、
OS, ミドルウェア, アプリケーション層の設定管理を行う
 要は「シェルでやるような操作の自動化」をしてくれるもの
 OSSツール例:
 Puppet: 2005年〜。Infrastructure as Code 潮流の原点。
 Chef: 2009年〜。Rubyでコードを書ける事から
Web系開発者中心に普及。
 Ansible: 2012年〜。新興故の使いやすや。
2014年 Red Hatが開発元を買収。
 タイトルにも入っている『構成管理ツール』という言葉は、
この層を取り扱うツールを指していることが多い。

15. Infrastructure as Code 実現の2レイヤー
2. コンフィギュレーション
 サーバー内でのコマンド実行やファイル操作を通じて、
OS, ミドルウェア, アプリケーション層の設定管理を行う
 要は「シェルでやるような操作の自動化」をしてくれるもの
 OSSツール例:
 Puppet: 2005年〜。Infrastructure as Code 潮流の原点。
 Chef: 2009年〜。Rubyでコードを書ける事から
Web系開発者中心に普及。
 Ansible: 2012年〜。新興故の使いやすや。
2014年 Red Hatが開発元を買収。
 タイトルにも入っている『構成管理ツール』という言葉は、
この層を取り扱うツールを指していることが多い。
ここから
Ansibleの話

16. Ansibleの何が良いのか？
 設計上の特徴
 エージェントレス
 プログラミング言語習得不要
 冪等性
 柔軟なホスト定義
 再利用性とメンテナンス性
 使いやすいワケ
 充実したモジュール
 スモールスタート可能
 Web GUI
 フロー統合ツールとしての有用性

17. 設計上の特徴

18. 特徴1. エージェントレス
SSH/WinRM
サーバー内への
事前準備が不要。
余計なものも入らない。
Ansibleは操作対象サーバー内へのエージェント配置が不要
（Puppet, Chefは専用エージェントの起動が必須）
ネットワーク経由でログイン出来るようになってさえいれば、
いきなり対象を操作することができる！！

19. 特徴2. プログラミング言語習得不要
Ansibleのコード(Playbook)は左図の様に
YAMLという一般的なデータ記述形式で書かれるため、
非プログラマー層でも習得負荷が低く
「誰にとっても」書きやすく読みやすいコードになる。
左では yum モジュールと service モジュールを使って、
Apache のインストールと起動処理を実行している。
（モジュールはAnsibleから実行するコマンドの様なもの）
一方、他のツールではChefならばRuby、Puppetなら
Puppet Languageという独自言語が採用されており、
非プログラマーにとっては敷居が高いと言える。

20. 特徴2. プログラミング言語習得不要
この部分がChef(Ruby)だとこうなる

21. 特徴3. 冪等性
 冪等性: ある操作を「何度実行しても結果が同じになる」性質
 Ansibleのモジュールは冪等性を持つ様に作られているため、
同じPlaybookを何度実行しても最終的な結果は同じになる。
→ 構築と更新で同じコードを使った差分更新が可能
 実行する手順を定義する（手続き的）のではなく、
最終的な結果を定義する（宣言的）と言うのがポイント
→ AnsibleのPlaybookは手順書というより要件定義

22. 特徴4. 柔軟なホスト定義
 Ansibleから操作するホスト定義を Inventory と言います
 Inventoryは
 Host: 具体的な接続先を持ったホスト（サーバー, VMなど）
 Group: Host を役割でまとめた集合
 web-server, db-server の様な機能別
 staging, production の様な段階別
 Host, Group に上限はありませんので、巨大・複雑なシステム
もAnsibleから一括で取り扱うことが可能
 静的に定義することも、外部システムからの動的取得も可能

23. 特徴5. 再利用性とメンテナンス性
 変数を使って環境毎に異なる値を柔軟に取り扱い可能
 使い回したい単位で Role というセットを作って再利用可能
 Role化する単位の目安は「1 ミドルウェア 1 Role」
 Ansible Galaxy という Role公開/共有の為のプラットフォームもある
 再利用の単位はあくまでRole毎やPlaybook全体
 ×「あるRoleから10番目のタスクだけを持ってきて実行する」
 Puppet, Chefであれば上記の様な自由度の高い使い回しも可能
 自由度とのトレードオフとしての高いメンテナンス性
 大規模に使い続けても「スパゲッティ化」「ブラックボックス化」しにくい
 Ansibleは「チーム全体でシンプルに使い続けられる」事に重点を置いている

24. 特徴まとめ
~Puppet, Chefとの比較を交えて~
- Ansible Puppet Chef
エージェントレス ◯ × ×
コード形式 YAML 独自言語 Ruby
冪等性 ◯ ◯ ◯
変数 ◯ ◯ ◯
自由度 ◯ ◎ ◎
メンテナンス性 ◯ △ △

25. Ansibleが
使いやすいワケ

26. 使いやすさ 1. 充実したモジュール
 Ansible 2.3.1 現在、組み込みモジュールは約1000種類
 サーバー内の各種コマンド操作系モジュールの充実度は当然として、
 IaaS 操作（Azure, AWS, OpenStack…）
 ネットワーク・ハードウェア操作
 監視システム連携
 コンテナ操作
のような幅広いモジュールがデフォルト状態で使える
 独自モジュールも好きなスクリプト言語で実装可能！
 …とは言え実質的には組み込みモジュールで十分な場合が多い

27. 使いやすさ 2. スモールスタート可能
 エージェントレス、冪等性といった特徴から
「とりあえず小さな範囲で使ってみる」ことがとても簡単
 一般的に新手法導入時の大きな障壁となりがちな、
 大規模な導入作業
 ワークフローの大幅刷新
 チーム全体の教育
といった重たい工程を経ずに使い始めることが可能
 とりあえず使えるところから使ってみるのが良い

28. 使いやすさ 3. Web GUI
 Ansible公式が展開している『Ansible Tower』や
などの Web GUIサービスがある
 どちらもAnsible Playbook開発用の物ではなく、
実運用フェーズの為のサービス
 『Deplow』はPlaybook作成・編集機能搭載予定あり！
詳しくはお問い合わせください
 単純にAnsibleをブラウザから実行できる他、
細かい権限管理やAPI経由のサービス連携が可能

29. フロー統合ツールとしての有用性

30. ここ大事！

31. フロー統合ツールとしての有用性
Ansibleの活用範囲はコンフィギュレーションに留まらず
 外部システム上で管理しているホストへのデプロイ
 「インフラ→サーバー→外部サービス(監視など)」
まで含んだシステム全体のワンストップ設定
の様な、システム運用上必要となるフロー全体を統合的に
自動化するための「フロー統合ツール」としても活用できる
Chef も 最近では Chef Provisioning から同様の事が出来る
ただ、依然としてエージェントレスなAnsibleの方がシンプルな印象

32. 外部システムからのホスト情報取得
 Ansible の Dynamic Inventory という機能を使うと
 各種 IaaS、データベース、CSVファイル …
からホスト情報を動的に取得し、Ansibleからデプロイ可能
* IaaSからはパスワードやSSH秘密鍵情報は取得できない点に注意
 「Azureの東日本リージョンにあるRHEL系OS全て」
の様な指定も可能
 管理下のサーバー全てにセキュリティパッチを当てる場合などに便利

33. システム全体のワンストップ設定
Infrastructure
Orchestration
Server
Configuration
Service
Integration
で一気通貫

34. Ansibleのまとめ
 Ansibleは単体で使ってもサーバー内設定のみならず、
インフラのオーケストレーション層まで含んだ
構成を簡単便利に構築可能！
 Ansibleは各種レイヤー間の繋ぎこみにも使える
 各レイヤー毎の自動化の手段としては
Ansible より適したものがあったりする。
そんな時でもAnsibleでまとめあげることで、
フロー全体の全自動運用が可能になる！

35. Azureと組み合わせるには？

36. 連携1. 組込モジュールを使う
 最もシンプルで簡潔、かつAnsible的な方法
 Ansibleには組み込みでAzure用モジュールが17種類
 VMやネットワークのIaaS的な基本操作は十分できる
 可用性セットやスケールセットは取り扱えない
 Managed Diskなどの新機能への対応は間に合っていない
 IaaS以外の機能（SaaS, PaaS）には未対応
 Azureをがっつり使い込むのには不十分
 ただし、Azure固有の問題ではない。
他のクラウドベンダー（AWS, Google）も同傾向

37. 連携2. Azure CLIと組み合わせる
 Azure上で使える機能のほぼ全てを操作できる
 公式CLIなので新機能対応も問題なし
 Ansibleからも問題なく叩ける
 command モジュールから簡単に呼び出せる
 実行結果がJSONで返るのでAnsibleからのパースが楽
 Playbookが複雑になりがち
 冪等性を守るにはチェック系と実行系のタスクがペアで必要
 コマンドの羅列になるのでPlaybookの見栄えが悪い

38. 連携2. Azure CLIと組み合わせる
 今回のハンズオンはこの方式を採用
 シェルスクリプトで書くよりはかなりマシ
 手続き的な記述で直感的なPlaybook実装が可能

39. その他の連携方法
 自前Ansibleモジュール実装
 Azure公式のPython SDKを使って組むことができる
 オープンにしてコミュニティへのコントリビュートが可能
 実装コストはかなり高い
 Azure Resource Manager Template利用
 azure_rm_deployment を使ってAnsibleから直接呼び出し可能
 複雑な構成でもテンプレート化することでポータブルな構成になる
 サンプルテンプレートが豊富
 仕様やファイルがやや複雑でテンプレートの手動メンテナンスはしたくない

40. 現状、Azure CLI + Ansibleが
柔軟性とシンプルさのバランスが
良い選択肢