■Description Ansible実践ガイド -入門編- http://amzn.asia/ebi7wIz ※上記の書籍内容に基づいて作成を行っています。 ■Target ・これからAnsibleを学びたい方 ・Ansibleとは何かを知りたい方 ・Ansibleと他の構成管理ツールとの違いを知りたい方

1. Ansibleはじめよぉ。
Hewlett Packard Enterprise Japan, Ltd
Shingo.Kitayama
- Infrastructure as Code -

2. 2
自己紹介
元楽天株式会社 所属
国際ECサービスのインフラ部門
好評発売中
http://amzn.asia/ghfpKwi
2016年末「Ansible実践ガイド」執筆
経歴など
shkitayama spchildren
Shingo.Kitayama
日本ヒューレット・パッカード株式会社 所属
テクノロジーコンサルティング事業統括
クロス・インダストリ・ソリューション統括本部
テクノロジーアーキテクト部

3. 3
Agenda
1. Infrastructure as Codeの背景
2. Ansibleとは
3. Ansibleのアーキテクチャ
4. 継続的インテグレーションへの展開
5. HPEにおけるAnsibleの取り組み

4. Infrastructure as Codeの背景
4

5. 従来の構成管理における課題
5
構成管理DB
(CMDB)
InstallInstall
・機器情報
・変更情報
・属性情報
情報更新
手順書
従来の構成管理
従来のオンプレミス環境におけるインフラ構築作業は、エ
ンジニアが複雑なオペレーションを実施し、一度構築した
ものは保守期限が切れるまで長期的に利用し続けていた。
・ミドルウェアのクラスタ構築
・数百台のOS初期設定やインストール
・運用における変更管理
・CMDBの手動更新
など
クラウドが登場し、インフラリソースのライフサイクルが短くなると、
構築/運用コストが肥大化する傾向にある。
仮想化による物理的な制約がなく
なり管理が複雑化

6. 構成管理ツールの必要性
6
Install Install
構成管理ツール
動的機器情報取得
Cloud Platform
状態の管理
API
Code
構成管理ツールによる管理
オペレーション自動化における構成管理ツールの役割りは、
情報を動的に取得して、意図する状態にシステムを収束さ
せること。
・機器の構成情報はクラウドが提供するAPIによって取得
・状態を管理するためには、動的な管理が可能
プログラマブルな構成管理ツール、
Infrastructures as Codeに注目が集まっている。

7. Infrastructure as Codeとは
7
Infrastructure as Code
手作業で行っていたインフラの構築や変更作業をコードで定義し、自動化すること。
ソフトウェア開発で実施されてきた開発プロセスをインフラシステム、アプリケーション、ミ
ドルウェアのデプロイメントやコンフィグレーションの管理に適用。
つまり、インフラリソースをコードで操作するということは、
そのコード自体が「品質管理」「バージョン管理」「テスト」の対象となるということ
継続的インテグレーション
バージョン管理
バージョン管理シ
ステム
CI Server
Build Test
Check
構成管理ツール
Feedback
Commit 自動化(デプロイ/テスト)
Development
CI/Test
Code

8. Infrastructure as Codeのメリット
8
オペレーション工数の削減
従来、手動で行ってきた作業をコード化、自動化することにより、オペレーション工数および納期の短縮
が期待できる。
オペレーション品質の向上
作業をコード化して、自動化することにより、オペレーション品質を均一に保つ効果がある。
システム運用の標準化の促進
自動化やバージョン管理を適切に行うことで、システム運用のポリシーや業務標準化を形成できる。
また、コードを再利用することにより無駄を排除し、継続的インテグレーションやデリバリを実現できる。
作業統制の強化
作業オペレーションを自動化することにより、内部統制やセキュリティ対策面での効果が期待できる。
Infrastructure as Codeを適用することでアジリティの高いサービスを提供

9. Infrastructure as Codeの適用範囲
9
Application Service
Deployment
Configuration
Management
システムの構成管理
Bootstrapping
ブートストラッピング
System
Configuration
Cloud or VM
Image Launch
OS Install
Application Platform
…
Capistrano, Fabric, Serf, Consul etc.
CFEngine, Puppet, Chef, Itamae etc.
Orchestration
アプリケーション
デプロイメント
参照 : velocity-mar2010 「Open Source Provisioning Toolchain」
AWS, Cobbler, Kickstart, VMware, Docker
各ツールは、Provisioning Toolchainによって分類されている。

10. Ansibleとは
10

11. Ansibleとは
11
Ansible
システムオペレーションの自動化を提供する、Python製
の構成管理ツールです。
オンプレミスのシステムから、パブリッククラウドまで
マルチベンダー連携が可能であり、大手金融機関や大規
模製造業を中心とした採用も多く、飛躍的に認知度が上
がっている。
2012 - 開発Project開始
2013 - Ansible.Inc設立
2015 - RedHat.IncがAnsible.Incを買収

12. Ansibleの特徴
12
・YAML形式で読みやすく
書きやすい。
・属人化しにくい
・学習コストが低い
Simple
・エージェント導入コスト
がない
・SSH接続のため安全
Agentless
・多数のベンダー機器に対
応
・マルチレイヤ対応
・同時実行可能
Powerful
Ansibleには、Simple, Agentless, Powerfulの3つの特徴がある。

13. Ansibleの特徴 - Simple -
13
Ansible(YAML)の表記
apache_setup_playbook.yml
---
- name: Install Apache
yum:
name: httpd
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
Chef(Ruby)の表記
apache_setup_recipe.rb
case node[‘platform’]
when “centos”
package ‘httpd’ do
action: install
end
end
template “httpd.conf” do
path “/etc/httpd/conf/httpd.conf”
source “httpd.conf.erb”
end
service “httpd” do
supports :status=>true, :restart=>true, :reload=>true
action [ :enable, :start ]
end
YAML形式は読みやすく書きやすいため、学習コストが低く、属人化しずらい。

14. Ansibleの特徴 - Agentless -
14
処理対象サーバー
管理サーバー
Agent型 Agentless型
Agent
全ての変更対象サーバーにエー
ジェントのインストールが必要
処理対象サーバー
管理サーバー
Agent不要
変更対象サーバーの設定が容易
Agent
Agent
Agentless型のプロダクトは、エージェントの導入コストがない。

15. Ansibleの特徴 - Powerful -
Application Service
Deployment
Configuration
Management
システムの構成管理
Bootstrapping
ブートストラッピング
System
Configuration
Cloud or VM
Image Launch
OS Install
Orchestration
アプリケーション
デプロイメント
Ansible
“Automation for Everyone”
Infrastructure as Codeの対象範囲全てのレイヤに対応している。(マルチレイヤ対応)
商標: それぞれのロゴは、各社/組織団体の登録商標です。

16. Ansibleの特徴 - Powerful -
16
多数のベンダー機器にも対応している。(マルチベンダー対応)

17. (補足) Moduleのサポートに関して
17
コアチームが管理を維持し、常に安全な状態で出荷されるモジュールです。また、すべての要求に対して優先順位が高
くなります。
他の企業によって提出されたり、コミュニティによって維持されるモジュールです。モジュールの管理者は、報告された問題
やモジュールに対して発生した要求を監視する必要があります。
コアチームまたはモジュールに関連付けられた企業/パートナーによってサポートされていないモジュールです。これらはコ
ミュニティによって維持されます。
問題への対応は、全てコミュニティに依存します。ベストエフォートでのサポートは提供されますが、サポート契約の対象と
はなりません。
Core
Curated
Community
Ansibleは数多くのモジュールを提供しますが、各モジュールごとにサポートの内容が異なります。

18. 処理対象サーバー処理対象サーバー
他の構成管理ツールとのアーキテクチャ比較
18
(1)変更内容を定義
(2)変更対象に送信
(3)変更実施
(1)変更内容を定義
(2)定期的に
変更有無を問い合わせ
(3)変更があれば更新
管理サーバー 管理サーバー
Push Architecture Pull Architecture
・シンプルな仕組み
・コントロールの柔軟性
・配布のスケーラビリティ
・完全自動化
「Push Architecture」と「Pull Architecture」があり、AnsibleはPush Architectureを採用している。

19. 他の構成管理ツールとの比較表
19
Puppet Chef Ansible
基本構成 ツールの使用言語 Ruby Ruby Python
ライセンス Apache License Ver2.0 Apache License Ver2.0 GNU Public License Ver3
開発組織 Puppet Labs Chef Software RedHat(旧Ansible.Inc)
開発開始年度 2005年 2009年 2012年
アーキテクチャ 基本構成管理方法 Pull型 (Agent型) Pull型 (Agent型) Push型 (AgentLess型)
実装 コード管理名称 manifest(マニフェスト) recipe(レシピ) playbook(プレイブック)
コード記述言語 独自言語(外部DSL) Ruby(内部DSL)
複雑な処理表記が可能
YAML
書式がとてもシンプル
処理実行順序 コンパイル時に決定される
※記述順通りにはならない
おおよそプログラムの記述順 プログラムの記述順
その他 システム情報の取得 附属ライブラリ(Facter)によって取
得
附属ライブラリ(Ohai)によって取得 附属モジュール(setup)により取
得
GUIツール Puppet Dashboard
Puppet Enterprise（有償）
Chef Server ansible-semaphore
Ansible Tower(有償)

20. Ansibleが注目されている理由
20
Ansibleが最も重視している点は、開発組織の共通言語としての役割りであり、DevOpsの課題を「Simple」
という特徴で補っている。
Sharing Measurement
Culture Automation
コミュニケーションを推進するた
めのイノベーションを引き起こす
こと
互いに学び成長できるよう、経験
を共有すること
フィードバックを得ながら、成果
を計測し、開発サイクルに活用す
ること
各プロセスにおける手作業の処理
をなくしていくこと
Ansible
開発組織の共通言語

21. Ansibleのアーキテクチャ
21

22. Ansible Core Engine
Ansibleのコンポーネント
22
Ansible CLI
Modules
Python API
Playbook
Inventory
PluginInterface
Connection Type Plugin
Callbacks Plugin
Ansibleの各コンポーネントは、インストール時にCore Engineに組み込まれている。
再利用可能な処理ユニット。作業をラッピ
ングしたコンポーネント
Ansibleのコア機能を拡張する
ためのコンポーネント
Ansibleを操作するためのイン
ターフェイス

23. Ansible Core Engine
Ansibleのコンポーネント
Ansible CLI
Modules
Python API
Playbook
Inventory
PluginInterface
Connection Type Plugin
Callbacks Plugin
Ansibleの各コンポーネントは、インストール時にCore Engineに組み込まれている。
再利用可能な処理ユニット。作業を
ラッピングしたコンポーネント
Ansibleのコア機能を拡張
するためのコンポーネント
Ansibleを操作するための
インターフェイス
ユーザーが作成するのは、
「Inventory」と「Playbook」の2つのファイル
23

24. Inventory
24
Inventoryとは、処理対象サーバの接続情報を記載したファイルです。
[web_servers]
web-01 ansible_host=192.168.101.1
web-02 ansible_host=192.168.101.2
web-03 ansible_host=192.168.101.3
[db_servers]
db-01 ansible_host=192.168.201.1
db-01 ansible_host=192.168.201.2
inventory.ini
all
web_servers db_servers
192.168.101.1
192.168.101.2
192.168.101.3
192.168.102.2
192.168.102.1
環境に合わせて処理対象サーバをグループ化することができる。

25. Playbook
25
Playbookとは、一連の作業を順序立てて定義するファイルです。
---
- hosts: web_servers
vars:
apache_conf: /etc/httpd.conf
tasks:
- name: Install Apache
yum:
name: httpd
- name: Configure Apache
template:
src: httpd.conf.j2
dest: “{{ apache_conf }}”
- name: Start Apache process
systemd:
name: httpd
state: started
site.yml
Target Section
web_serversグループに適応
Vars Section
apache_confの変数定義
Tasks Section
(1) Apacheのインストール
- yumモジュールの利用
(2) Apacheの設定
-templateモジュールの利用
(3) Apacheプロセスの開始
-systemdモジュールの利用
上から順に実行される。

26. Ansibleの仕組み
26
Ansibleサーバ 処理対象サーバ
(1)処理対象サーバの選定
(2)Python実行コードに変換
(3)プログラム転送
(sftp)
PlaybookInventory
Ansible
(4)プログラム実行
(5)Python実行コード削除
(1) Inventoryから処理対象を選定
(2) PlaybookをPython実行コードに変換
(3) 実行コードをSFTPで転送
(4) 処理対象サーバ側でコードを実行
(5) 実行コードの削除
Ansibleでは、実行処理をはじめる前にAnsibleサーバ側で実行コードに変換しています。
Python Code
実行処理順序

27. AnsibleのクラウドAPI連携
27
Setup
Install
Public Cloud Platform
各クラウドAPIを操作するためのモ
ジュールが用意されている。
Setup
Install
Public Cloud Platform Private Cloud Platform
Install
Cloud
Modules
Bridge Bridge
Ansibleが各クラウドAPIを統括的にコントロール
Playbook
Ansible
API
APIAPI
AnsibleのクラウドAPI連携により、ハイブリッドクラウドの実現をサポートする。
商標: それぞれのロゴは、各社/組織団体の登録商標です。

28. 継続的インテグレーションへの展開
28

29. 29
継続的インテグレーション
バージョン管理
バージョン管理シ
ステム
CI Server
Build Test
Check
構成管理ツール
Feedback
Commit 自動化(デプロイ/テスト)
Development
CI/Test
Code
コードのコミット
ビルド
単体テスト
開発成果物の管理 デプロイ 機能テスト
AnsibleとCIパイプライン
Playbookをバージョ
ン管理システムに保
存
各Playbookタスクの
単体テストを実施
作成したVMのテンプ
レート化や、コンテナ
のテンプレート化
Ansibleにより、デプロ
イメントを実施
デプロイメントした環
境の機能テストを実
施
CIパイプラインにおいて、Ansibleはデプロイメントを実施する役割りを担っている。

30. デプロイ テスト
30
バージョン
管理システム
開発成果物
管理システム
チェックアウト
アプリケーション
Infrastructure
as code
アプリケーション
エンジニア
インフラ
エンジニア
アプリケーション開発
構成管理の自動化
コードのコミット
ビルド
単体テスト
開発成果物の管理 デプロイ 機能テスト
Continuous
Integration
CIツール
開発成果物の展開 機能/結合テスト
アプリケーション
単体テスト
application
code
ビルド/テスト
自動化ツール
IaaS
CIパイプラインと役割り
イメージ化
VMテンプレートの管理

31. 31
コードレポジトリ
・GitHub Enterprise
・Bitbucket
・GitLab
CIツール
・Jenkins
・Circle CI
・Travis CI
・Concourse CI
成果物レポジトリ
・Jfrog Artifactory
・Github Enterprise
・Docker Trusted
Repository
・GitLab
PaaS
・Cloud Foundry
・Heroku
・Bluemix
Container
Orchestration
・Docker Datacenter
・Mesosphere
・Kubernetes
構成管理の自動化
・Ansible
・Chef
※凡例
手動タスク
自動化タスク
機能テストツール
・UFT
・Selenium
・Appium
・JMeter
コードのコミット
ビルド
単体テスト
開発成果物の管理 デプロイ 機能テスト開発環境
CI環境
ステージング環境
QA環境
本番環境
利用ツール例
デプロイ 機能テスト
コード
反映
コード
反映
デプロイ リリース
Issue Tracking
・JIRA
・Redmine
Promote
Promote
開発成果物の管理
開発成果物の管理
CI/CDのプラットフォーム選択
デプロイメントのプラットフォーム選択がCI/CDのプロセスに大きく影響を及ぼす。
アプリケーションのアーキテクチャおよび
非機能要件/運用要件によって選択

32. HPEにおけるAnsibleの取り組み
32

33. OneViewによるプログラマブルインフラストラクチャ
33
ITインフラの統合管理と自動化を推進「HPE OneView」
HPE OneViewは、サーバーのみならず、ストレージ、ネットワークまでITインフラストラクチャ全体を構成するハードウェアの統合的な管理を実現
します。REST APIを介してOpenStack、Microsoft、System Center、VMware vCenterをはじめとする様々なソフトウェアと連携し、サービス、ソ
フトウェア、ハードウェアまで一気通貫した運用が可能になります。HPE OneViewは、「インフラストラクチャの自動化ハブ」としての機能を強化
し進化し続けています。

34. 34

35. 35

36. 36

37. Ansible教育サービス
37
コース内容
1. Ansibleの概要
2.Ansibleの基礎
3.プレイブックの文法
4.Linux初期セットアップの自動化
5.アプリケーションデプロイメント
6.Ansibleの活用
Ansible実践入門 -Infrastructure as Codeを理解-
http://h50146.www5.hpe.com/services/education/teiki/seihin/H0LT0S.html

38. 38
Enjoy Ansible
Thank you

39. 本資料に関するお問い合わせ
39
Shingo.Kitayama
Mailto: shingo.kitayama@hpe.com
Ansibleは、米国およびその他の国において登録されたRed Hat, Inc.の商標です。
その他、本資料で記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。
本資料に関しては、お気軽にお問い合わせ下さい。
また、内容に関しては個人の意見に基づくものであり、十分考慮の上ですが、所属組織団体の公式見解とは異なる場合
がございます。 何卒、ご了承下さい。
商標