2020年3月27日トレノケートで開催した無料セミナー「OSSを活用したIaCの実現」プレゼンテーション資料

1. OSSを活用した
IaC(Infrastructure as Code)の実現

2. 本日の流れ
1. IaCって何ですか？
2. コードを書くのは難しい？
3. いくつかのサーバーをまとめて管理したい
4. コードの管理に手間がかかりそう
5. コードは手動で実行するのですか？
2

3. IaCって何ですか？

4. ITインフラの環境変化
◼ 仮想化およびクラウドの登場により、ITの利用範囲は拡大
し、ライフサイクルは短期化している
メインフレーム オープンシステム 仮想化/クラウド
利用期間
利用範囲
✓ 長期間（～10年）
✓ 仕様変更はほとんど
ない特定の業務で利
用
✓ 基幹業務、社会的な
インフラ
✓ 中長期間（3～5年） ✓ 短期間（1年未満）
✓ 数分単位での構成変
更が行われることも
ある
✓ 基幹業務、社会的な
インフラ
✓ さまざまな業務シス
テム
✓ さまざまな消費者向
けWeサービス
✓ モバイル、エンタメ
分野のサービス
✓ 基幹業務、社会的な
インフラ
✓ 主に業務効率化を目
的に使用
✓ TCP/IPネットワーク
上で提供されるさま
ざまな業務システム
4

5. インフラ運用における課題
◼ IT活用領域の拡大による管理対象の増加は、以下のよう
な問題を生じさせる
⚫ 人的リソース確保が困難
- 管理対象サーバーの増加に比例し、保守・運用の作業量も増加
⚫ サーバー構成の不一致による再現不能
- 当初は標準構成で構築されたサーバーに、時間が経つにつれてさま
ざまな差異が紛れ込む（構成ドリフト）
- そのサーバー特有の構成情報が失われ、再構築が困難になった
サーバー（スノーフレークサーバー）
5

6. 参考 「鉄の時代」
◼ 「鉄の時代」と「クラウドの時代」
⚫ 鉄の時代
- 物理的なハードウェアの制約のもと設計・構築
- システム変更に必要な作業が膨大で、かつ手動実行
- 厳格な変更管理プロセス
⚫ クラウドの時代
- ハードウェアの制約は基本的に考慮不要
- システム変更・メンテナンスはソフトウェア的に実行可能
- 短時間でシステム変更を実行しつつ、作業の信頼性を向上
Kief Moris著『Infrastracture as Code』(オライリー, 2017年, p.4)
6

7. Infrastructure as Codeとは
◼ Infrastructure as Code(以下、IaC)
⚫ ITインフラの構築・変更作業をコードによって定義し、一連のプロ
セスを自動化するための取り組み
◼ IaCは以下の実現を目指す
従来の運用 IaCによる運用
✓ システムの変更は厳格な変更管
理プロセスの下、検討・評価を
経て実行される
✓ システム変更は日常的なタスク
として実行される
✓ トラブルの発生を予防するため
に綿密な計画を立てる
✓ トラブルが発生しても迅速に復
旧できる
✓ システム変更は大きなリスクを
伴うため、限定的に実行される
✓ 継続的なシステム変更により、
改善を繰り返す
7

8. IaCの原則 (1/2)
◼ 再現可能
⚫ 人の手を介すことなくインフラを構築・再構築できる
⚫ 人の判断を必要とする項目は、スクリプトに定義されている
◼ 使い捨て
⚫ リソースの作成、破棄を自由に行える
⚫ サーバーが増減しても、サービスの継続性が維持される
◼ 統一的なインフラ
⚫ インフラの構成・設定を統一する
⚫ 不統一なインフラにおいては、再現可能性が損なわれることがある
8

9. IaCの原則 (2/2)
◼ 再利用可能
⚫ インフラに対する操作はスクリプトにより実行され、スクリプトは繰り
返し利用可能なものとする
⚫ 属人的な構成の差異は排除し、統一性を維持する
◼ 継続的な変更
⚫ 安全に素早くシステム変更が繰り返される
⚫ 部分的なシステム変更が容易な設計であることが前提となる
再現可能 使い捨て
統一的
インフラ
再利用可能
継続的な
変更
9

10. 参考 「ペット v.s. 家畜」
◼ 従来型のシステムを「ペット」、クラウド型のシステムを「家
畜」に例えて、IaCにおいてはサーバーを「家畜」として扱う
べきと考える
『CloudScaling』
http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/
✓ 愛着を持って名前をつける
✓ 代わりの利かない唯一の存在
✓ 手をかけて世話をする
✓ 体調を崩すとすぐに病院へ
✓ 一頭一頭の個体差はほとんど
ない
✓ 全体の生産量が重視される
✓ 病気になれば、代わりを補充
することができる
10

11. IaCの構成要素
◼ 構成定義ファイル
⚫ インフラの構成・設定方法を記述したファイル
⚫ JSON、YAML、XMLなどの標準形式で記述したテキストファイル
が利用されることが多い
⚫ Ansibleのプレイブック、Chefのレシピ、Puppetのマニフェスト
---
- hosts: TargetServers
tasks:
- name: apacheのインストール
yum: name=httpd state=latest
- name: apacheの起動設定
service: name=httpd state=started enabled=yes
例）YAML形式で記述されたプレイブック(Ansible)
11

12. IaCの構成要素
◼ 自己記述プロセス
⚫ システム構築・変更を行う手順は、定義ファイル・スクリプトの中に
記述されている（システムに対して行った変更は、定義ファイルを
見れば分かる）
⚫ 人の手を介すことなく、システム変更が実行されるため、属人的な
差異を排除できる
⚫ 構成管理ツール（Ansible、Puppet、Chef）によって、一連
のプロセスが実行される
12

13. IaCの構成要素
◼ バージョン管理システム
⚫ VCS（Version Controll System）によって構成定義ファ
イルを管理する
⚫ トレーサビリティ
- 構成定義ファイルに対する変更履歴を管理する
⚫ ロールバック
- 変更が失敗したときに、前の状態に復元する
⚫ アクショナビリティ
- 構成定義ファイルに対する変更がコミットされたときに、システム変更
を自動的にトリガする
13

14. IaCの構成要素
◼ 継続的なシステム変更とテスト
⚫ システム変更は小刻みに（特定機能を短期間で）実装する
⚫ また、システム変更に対して自動的にテストを実施する
⚫ 小さな単位で変更は、変更内容の追跡、問題発生時の原因の
切り分けを容易にする
⚫ CI（Continuous Integration）ツールが変更・テストの
実行を管理する
企画・設計 構築 テスト
設
計
構
築
テ
ス
ト
設
計
構
築
テ
ス
ト
設
計
構
築
テ
ス
ト
機能A 修正
機能B 追加
機能C 追加
機能A 修正
機能B 追加
機能C
追加
従来の開発
複数の変更を
まとめて対応
CIによる開発
１つ１つ変更
を個別に対応
14

15. IaCの全体像
◼ 各構成要素は下図のように連携して、IaCを構成する
VCS CIツール 構成管理
ツールジョブ①
ジョブ②
・・・
</>
①変更を
コミット
②VCSが変更を通知
（CIがポーリング）
③CIが構成管理
ツールを起動
④変更および
テストを実行
15

16. コードを書くのは難しい？

17. ---
- hosts: WebServers
tasks:
- name: apacheのインストール
yum: name=httpd state=latest
- name: apacheの起動設定
service: name=httpd state=started enabled=yes
- name: phpインストール
yum: name=php state=latest
notify:
- Restart apache
handlers:
- name: Restart apache
service: name=httpd state=restarted
例えば、Ansibleでは
17

18. 構成管理ツールの役割
◼ 構成管理ツールの役割
⚫ システムオペレーションの自動化
⚫ 冪等性（べきとうせい）の保証
- 冪等性：ある処理を1回実行しても、複数回実行しても結果が同
じである性質
- 同じスクリプトを実行すれば、何度実行しても同じシステムの状態が
得られることを保証する
◼ IaCにおける構成管理ツールの位置づけ
⚫ 構成定義ファイル、自己記述プロセス
18

19. Ansibleの特徴
◼ Ansibleとは
⚫ システムオペレーションを自動化する構成管理ツール
⚫ システムの設定変更などのタスクをファイルに記述し、変更対象
サーバーに実行させる
◼ 特徴
⚫ YAML形式で記述された可読性の高い設定ファイル
⚫ 変更対象サーバーにエージェントソフトのインストール不要（プッ
シュ型）
⚫ さまざまなOSやクラウド管理基盤に対応したモジュール群
⚫ 冪等性を保証
19

20. Ansibleの基本動作
◼ 以下の流れでターゲットノードにおいてコードが実行される
コントロール
ノード
ターゲット
ノード
④SSHで実行コード
(.py)を送信
①プレイブック、
インベントリを作成
②プレイブックを実行 ③YAML形式のプレイブックを
Pythonコードに変換
⑤コード(.py)を実行
プレイブック
インベントリ
✓ プレイブックを実行すると、コントロールノードからターゲットノードにSSH接続を行い、
実行コードを転送します。また、実行コードはpythonコードです。
POINT!
20

21. モジュール
◼ モジュール：再利用可能な処理ユニット
⚫ 1つ1つの手順を作業単位にラッピングし、プレイブックやコマンドか
ら呼び出して使用する
⚫ モジュールの中で、各処理の冪等性が保証される
◼ 主なモジュール
⚫ Windows Modules
- WindowsOSを管理するためのモジュール
⚫ Network Modules
- Cisco、F5などのネットワーク機器を操作するためのモジュール
⚫ Command Modules
- コマンドライン操作を行うためのモジュール
- このモジュールは冪等性が保証されていないため、プレイブックの中で
適切に制御する必要がある
21

22. ---
- hosts: WebServers
tasks:
- name: apacheのインストール
yum: name=httpd state=latest
- name: apacheの起動設定
service: name=httpd state=started enabled=yes
- name: phpインストール
yum: name=php state=latest
notify:
- Restart apache
handlers:
- name: Restart apache
service: name=httpd state=restarted
プレイブック（サンプル）
Targetsセクション
Tasksセクション
Handlersセクション
22

23. インベントリの書き方
◼ ホスト変数・グループ変数
⚫ ホスト変数：ターゲットノード固有の変数を定義する
- ホスト変数はインベントリファイル内に、ターゲットノード名の後ろに続
けて記述する
⚫ グループ変数：グループ内の全ノードに適用する変数を定義する
- [グループ名:vars]セクション内に記述する
[WebServers]
www.domX.local ansible_ssh_host=10.X.10.80
[DBServers]
DB.domX.local ansible_ssh_host=10.X.10.90
localhost ansible_ssh_host=10.X.30.100
[all:vars]
ansible_ssh_user=root
ansible_ssh_pass=Pa$$w0rd
23

24. プレイブックの実行
◼ Ansible-playbookコマンドで任意のプレイブックを実行で
きる
# ansible-playbook –i <インベントリ> <プレイブック>
24

25. 【デモ】 LAMP構成
172.16.1.0/24
.90.80
.250
Web
CentOS 7.7
Apache
80
DB
CI
インターネット
10.20.N.0/24
.X
.254
.254
MySQL
3306
PHP
Web
サーバー
CGI
スクリプト
データベース
Ansible
25
プレイブック インベントリ

26. いくつかのサーバーをまとめて管理したい

27. 【デモ】 WordPressをデプロイする
172.16.1.0/24
.90.80
.250
Web
CentOS 7.7
PHP-FPM
Nginx WordPress
8080
DB
CentOS 7.7
MariaDB
3306
インターネット
10.20.N.0/24
.X
.254
.254
27
CI
Ansible
プレイブック インベントリ

28. オーケストレーション
◼ 「オーケストレーション」とは
⚫ 各種アプリケーションやミドルウェアの依存関係や複数のサーバー
に跨る処理を制御し、自動構成する機能
- 新規にサーバーを起動して、クラスタに参加させる
◼ Ansibleを用いたオーケストレーション
⚫ 1つのプレイブックの中にたくさん処理を書くと可読性が損なわれ、
属人的なコードになりやすい
⚫ より簡潔なプレイブックとするために適切なサイズにタスクを分割す
るための機能が、Ansibleには用意されている
- ロールを活用する
- 変数ファイルを分割する
28

29. ロールの活用
◼ 「ロール」とは
⚫ プレイブックを分割して管理するための仕組み
⚫ プレイブックの各セクションを別々のファイルとして構成できる
⚫ 所定のディレクトリ構成、命名規則に沿った名前でファイルを配置
する必要がある
Vars
Tasks
Handlers
---
- hosts:
vars:
tasks:
handlers:
- hosts:
vars:
tasks:
handlers:
- hosts:
vars:
tasks:
handlers:
29
Web
DB
roles

30. Ansibleを用いた構成管理 （構築手順書）
# ansible-playbook --list-tasks playbook.yml
playbook: wordpress_deploy.yml
play #1 (db): Deploy Database for WordPress TAGS: []
tasks:
common : configure / SeLinux permissived TAGS: [common]
common : configure / Update yum package TAGS: [common]
common : configure / Import EPEL Repository TAGS: [common]
db : check_install / Allow ports for Firewall TAGS: [db]
db : check_install / Remove current packages TAGS: [db]
db : install / Import repository key TAGS: [db]
play #2 (web): Deploy Application Server TAGS: []
tasks:
common : configure / SeLinux permissived TAGS: [common]
common : configure /Update yum package TAGS: [common]
common : configure / Import EPEL Repository TAGS: [common]
nginx : check_install / Allow ports for firewalld TAGS:
[nginx]
nginx : install / Install required Packages TAGS: [nginx]
nginx : configure / Setup global configuration file TAGS:
[nginx]
30

31. Ansibleを用いた構成管理 （パラメータシート）
◼ 構成情報の管理
⚫ 前述の「ファクト変数」を使用することで、各サーバーの構成情報
の収集できる
⚫ プレイブックによる構築・変更作業の後にファクトを収集すれば、パ
ラメータシートに相当する情報を得られる
# ansible server01 -m setup
server01 | SUCCESS => {
"ansible_facts": {
<省略>
"ansible_distribution": "CentOS",
"ansible_distribution_major_version": "7",
<省略>
"ipv4": {
"address": "172.16.99.93",
"broadcast": "172.16.99.255",
"netmask": "255.255.255.0",
31

32. WordPress
172.16.1.0/24
.90.80
.250
Web
CentOS 7.7
PHP-FPM
Nginx WordPress
8080
DB
CentOS 7.7
MariaDB
3306
インターネット
10.20.N.0/24
.X
.254
.254
32
CI
Ansible
プレイブック インベントリ

33. コードの管理に手間がかかりそう。

34. （再掲）IaCの全体像
◼ 各構成要素は下図のように連携して、IaCを構成する
VCS CIツール 構成管理
ツールジョブ①
ジョブ②
・・・
</>
①変更を
コミット
②VCSが変更を通知
（CIがポーリング）
③CIが構成管理
ツールを起動
④変更および
テストを実行
34

35. （再掲）IaCの構成要素
◼ バージョン管理システム
⚫ VCS（Version Controll System）によって構成定義ファイ
ルを管理する
⚫ トレーサビリティ
- 構成定義ファイルに対する変更履歴を管理する
⚫ ロールバック
- 変更が失敗したときに、前の状態に復元する
⚫ アクショナビリティ
- 構成定義ファイルに対する変更がコミットされたときに、システム変更
を自動的にトリガする
✓ 本章では、「トレーサビリティ」「ロールバック」を中心に扱います。「アクショナビリティ」
については、CIツールと連携する例は後述します。
POINT!
35

36. Gitの概要
◼ Gitとは
⚫ 分散型のバージョン管理を行うためのオープンソースのソフトウェア
⚫ GitHubはGitリポジトリをインターネットで公開するサービス
◼ Gitによるバージョン管理の全体像
Fork
リモート
リポジトリ
ローカル
リポジトリ
Push
✓ 各ユーザーはリモートリポジトリを
ローカルにコピー(Pull)
✓ ローカルリポジトリに対する変更が
完了すると、リモートリポジトリに
反映(Push)
✓ 複数のユーザによって参照されるリポ
ジトリ
✓ ファイルを編集するときは、ユーザご
とにリポジトリをコピー(Fork)して利
用する
✓ 編集した内容はPullRequestにより、
他のリポジトリへ反映を依頼する
PullRequest
Pull Push Pull
36

37. ブランチの操作
◼ ブランチとは
⚫ 複数ユーザーが、同じファイルに、並行して別々の変更を行うた
め、「最新の状態」を枝分かれさせる機能
⚫ デフォルトでmasterブランチが作成されている
⚫ 変更作業はmasterブランチから分岐した個別のブランチ(下図
BranchA)で行い、作業が完了したらmasterブランチにマージす
る
master master
BranchA
①作業用に
BranchAを作成
②BranchAで
ファイルを編集
②’masterブランチの
ファイルはそのまま
③変更をコミット
④masterと
BranchAをマージ
⑤変更が反映された
状態が新たなmaster
37

38. ブランチの操作
◼ 指定した状態を復元する
⚫ コミットログからある時点を指定し、その状態を復元できる
⚫ 各コミットにハッシュが割り当てられているので、「ブランチを分岐す
る前」、「マージした後」などを特定できる
✓ 誤ってコミットしても、git log/git reflogコマンドで各時点のハッシュを確認し、指
定した状態を復元することができます。
POINT!
master
BranchA
②BranchAで変更
Commit
:12345
Commit
:45678
Commit
:abcde
Commit
:12abc
38

39. ブランチの操作
◼ コミットのハッシュを確認する
[root@CI Work]# git log --graph
* commit b11cb75153f2125fa4d41fa548574ce4e097a164
|¥ Merge: 66cae44 3669394
| | Author: root <root@CI.trainocate.lab>
| | Date: Tue Nov 26 15:25:39 2019 +0900
| |
| | Merge branch ‘Branch-A'
| |
| * commit 3669394c60a47f4c77d5d41c43103daaf8cf4d37
|/ Author: root <root@CI.trainocate.lab>
| Date: Tue Nov 26 15:21:18 2019 +0900
|
| Branch-A commit
|
* commit 66cae44db7a9e05bc2b3e0ddd298b6d4c1c14285
| Author: root <root@CI.trainocate.lab>
| Date: Tue Nov 26 15:14:10 2019 +0900
<省略>
39

40. コードは手動で実行するのですか？

41. （再掲）IaCの全体像
◼ 各構成要素は下図のように連携して、IaCを構成する
VCS CIツール 構成管理
ツールジョブ①
ジョブ②
・・・
</>
①変更を
コミット
②VCSが変更を通知
（CIがポーリング）
③CIが構成管理
ツールを起動
④変更および
テストを実行
41

42. 継続的インテグレーション
◼ 継続的インテグレーション(CI)とは
⚫ システムの改善・変更プロセスを短いサイクルで回し続けること
◼ CIのライフサイクル
⚫ バグ修正、新機能追加などによる変更要求（チケット）から、新
しい構成定義ファイルが完成するまでを1サイクルとする
Plan Do Check Action
修正方針の検
討・決定
</></></> </></></>構成定義ファ
イルの修正
変更された構
成定義ファイ
ルをテスト
テスト結果を
レビューし、
最新版確定
チケット
の起票
本番環境
へ適用
構成定義ファイル
Ver.1.0
構成定義ファイル
Ver.1.1
✓ できるだけ小さな単位で変更・統合を行うことで、変更に起因するトラブルを局所
化します。
POINT!
42

43. CIツール
◼ CIツールの役割
⚫ CIサイクルにおけるパイプラインを定義し、そのプロセスの実行を保
証、管理するツール
⚫ VCSや構成管理ツールとの連携機能が提供される
VCS CIツール 構成管理
ツールジョブ①
ジョブ②
・・・
</>
①変更を
コミット
②VCSが変更を通知
（CIがポーリング）
③CIが構成管理
ツールを起動
④変更および
テストを実行
43

44. Jenkinsの基礎
◼ 主なCIツール
⚫ Jenkins
⚫ TravisCI
⚫ Bamboo
◼ Jenkinsの特徴
⚫ オープンソースのCIツール
⚫ Hudsonからフォークしたプロジェクトで開発
⚫ Webベースのインタフェース
⚫ プラグインにより様々なツールとの連携機能が用意されている
44

45. 構成管理ツールとの連携
◼ プラグインのインストール
⚫ [Jenkinsの管理]-[プラグインの管理]から各種プラグインのイン
ストール・アップデートができる
⚫ Ansible プラグインのインストール
- [利用可能]タブから選択
45

46. VCSとの連携
◼ SCMポーリング（Source Code Management）
⚫ VCSへ一定の間隔でポーリングする
- 前回のポーリングから新しいコミットがあればビルドを実行
- ポーリングの頻度を上げるとVCSに負荷がかかり、頻度を下げるとコ
ミットされてからジョブが実行されるまでに遅れが生じる
◼ Webフック
⚫ 新たにコミットされると、VCSがJenkinsへ通知する
- コミット後に即座にジョブが実行されるため、頻繁にコミットされる環
境に適している
- パブリックなリポジトリを使う場合、JenkinsにグローバルIPが必要
VCS CIツール
ジョブ
ジョブ
</>
SCMポーリング
Webフック
46

47. （再掲）IaCの全体像
◼ 各構成要素は下図のように連携して、IaCを構成する
VCS CIツール 構成管理
ツールジョブ①
ジョブ②
・・・
</>
①変更を
コミット
②VCSが変更を通知
（CIがポーリング）
③CIが構成管理
ツールを起動
④変更および
テストを実行
47

48. もっと詳しく、ハンズオンも交えて学習したい方へ

49. 本日、紹介した内容は
◼ 『ITインフラ運用実践2』
2020年4月22日(水) ～ 4月23日(木) 新宿LC
2020年7月9日(木) ～ 7月10日(金) 新宿LC
2020年9月7日(月) ～ 9月8日(火) 新宿LC

50. （参考）インフラ関連コース
◼ ITインフラの全体像をつかむ！
⚫ カバー領域が広がるITインフラは、実務に近い環境で、全体を俯
瞰できる知識とスキルを徹底強化

51. オンラインLiveトレーニング
◼ https://www.trainocate.co.jp/gkservices/onlin
e-training.html