AnsibleおよびDockerで始めるInfrastructure as a Code

Copyright 2020 IGUAZU Corporation
イグアステクニカルセミナー第9回
2021年 3月4日
株式会社イグアスソリューション事業部
テクニカル推進部吉田
Ansible およびDockerで始める
Infrastructure as a Code

▶ このセッションでは、インフラの構成を自動化するために必要な
Infrastructure as a Code の考え方を紹介し、実践手法として
Ansible およびコンテナの特徴およびユースケースの概要を解説し
ます。
1
初めに

▶Infrastructure as a Codeとは
▶Ansible によるシステム操作の自動化
▶オートスケーリング
▶学習リソース
2
目次

Infrastructure
as a Codeとは
3

▶ 毎日、毎月、サービス増強時などインフラ構築の作業を自動化
4
Infrastructure as Code
インフラ担当
手作業人的ミス防止
◼ 直接的なメリット
✓ 作業自動化による省人化、効率化
✓ 人的ミスの防止
◼ 派生するメリットについては後述

◼ 物理マシンでの環境を構築
✓ 時間をかけてセットアップ
✓ 数か月以上～数年にわたってメンテナンスしながら使用を継続
✓ 構成は固定的。ほとんど変更しない
◼ セットアップ作業のイメージ
✓ ハードウェアメーカー、OSメーカー、ミドルウェアなどを発注して到着を待つ
✓ ハードの据え付け、ケーブルの配線
✓ CDからソフトをインストール、設定変更作業
✓ アプリケーションの稼働チェック etc…
◼ このほかにも定期的な作業発生（バックアップテープ交換）
◼ 同じ構成のサーバーを一台増やすだけでも一苦労
Infrastructure as Code に至るまでの歴史 (1/3)
5

◼ 仮想マシン登場
✓ セットアップした「仮想マシン」を複製して増やしたり、
テンプレートとして保管することができるようになりまし
た。
6
H/W
VM
Linux
Kernel
Com, Lib
MW
Appl A
仮想マシンの稼働環境
H/W
Linux
Kernel
Command, Library
Middle Ware
Appl
物理マシン
VM
Linux
Kernel
Com, Lib
MW
Appl B
VM
Linux
Kernel
Com, Lib
MW
Appl C
仮想マシン
部分
ホストマシン
部分

◼ IaaS (Infrastructure as a Service)登場
✓ 仮想マシンを稼働させる環境を必要な時に必要な分だけ借りることがで
きるようになりました。
✓ 負荷などに応じてリソースを増減でき。不要になったら削除できます。
✓ 構成は流動的。状況の変化に対応した作業が求められます。
◼ 構成自動化ツール登場
✓ Puppet (2005年)
✓ Chef (2009年)
✓ Ansible (2012年。2015年にRed Hat 社に買収される)
✓ これらのツールの共通点としては、機器ごとの専用ソフトとは異なり、機
器が変わっても同じ管理手法を共有できます。専用ソフトごとの属人化、
部分的最適化を回避できるようになります。
7

◼ _
◼ Ruby 言語で書けるため、Chef は Web アプリケーション開発者に好まれ
ました。
◼ Yaml形式は、プログラム言語ではないため柔軟性の点では劣りますが、
可読性やメンテナンス性の点で優位になります。
◼ エージェント
✓ Puppet および Chef では、操作対象にエージェントをインストールする必要があ
ります。エージェントが管理側のサーバーからデプロイ用のスクリプトを取得し
て、操作対象内を設定します。
✓ Ansible では、管理側のサーバーからそれぞれの操作対象にログインして操作対
象内を設定します。
Puppet、Chef、Ansible の比較
8
名称スクリプト記述方法エージェント※
Puppet Manifest Pappet Language 必要
Chef Recipe (レシピ) Ruby 言語※ 必要
Ansible Playbook Yaml 形式 ※ 不要

Ansibleによる
システム操作の自動化
9

Copyright 2020 IGUAZU Corporation 10
自動化における「Ansible」の位置づけ
システム側のプロセス
人や組織のプロセス
プラットフォームアプリケーション
人が実際に機器にロ
グインして操作する
ような作業が得意
ビジネスプロセス管理、承認・申請ワークフロー、
チケット管理、インシデント管理、リリース管理等
祝祭日と連携した業務バッチ、
システム間のデータ連携、
定型のデータメンテナンス等
定型的な入力処理（RPAなど）

現行の手順を Playbook として置き換え自動化
● Playbook は実行可能なパラメータシート兼手順書として利用できる。
● シンプルな手順から複雑なシナリオまで対応可能な柔軟性を持つ。
11
Ansible による自動化の考え方
設計書パラメータシート手順書
設計書 Playbook
作業者環境
Ansible 環境

• YAML 形式で記述されたパラメータと手順 → わかりやすい
12
自動化を記述する「Playbook」とは
---
- name: install and start apache
hosts: web
become: yes
vars:
http_port: 80
tasks:
- name: httpd package is present
yum:
name: httpd
state: latest
- name: latest index.html file is present
copy:
src: files/index.html
dest: /var/www/html/
- name: httpd is started
service:
name: httpd
state: started
ほぼ
同じ意味
「コード」なので、
コーディング規約の
準拠などをプログラ
ムでチェック可能

• 構築された環境の正しさを検証
– 想定した状態になっているか確認
• インフラの結合テスト
– 複数機器やOSにまたがるテスト
– 人では実現できない網羅的なテスト
– 何度でも繰り返せるため、回帰テスト
と相性が良い
– ※Playbook を何回実行しても結果が同じ
になる（冪等性がある）ことが前提です。
同じ操作を何回繰り返しても結果が同じに
なることを冪等（べきとう）性といいます。
• テストが蓄積されるほど品質が向上
13
テスト自動化での活用
tasks:
- name: 対象サーバーのポートがOpenしているか
local_action:
module: wait_for
host: “{{ inventory_hostname }}“
port: 80
state: started
delay: 3
timeout: 10
- name: ゲートウェイにping送信可能か
shell: |
ping -c 3 {{ ansible_default_ipv4.gateway }}
- name: コンテンツが配布されているか
shell: |
test -f /var/www/html/index.html
- name: コンテンツがHTTP経由で取得できるか
local_action:
module: uri
url: http://{{ inventory_hostname }}/
validate_certs: no
timeout: 5
return_content: yes
register: webpages
- name: TEST check contents
assert:
that:
- (webpages.content | search(query))
vars:
query: "{{ content_msg }}"

◼ 直接的なメリット
✓ 作業自動化による省人化、効率化
✓ 毎月、毎日など定期的に必要なシステム操作
✓ その他、不定期な定型的な作業（仮想マシンの追加など）
✓ 人的ミスの防止
◼ スクリプト化されたことによるメリットの例
✓ Git などでバージョン管理できる
✓ 自動テストツールでテストできる
✓ プログラムとしてキックできる
✓ crontab などからキックして実行
✓ プログラムを修正してコミットしたらJenkins からキックして稼働環境をビルド
✓ システムの負荷を検知して自動的にリソースを増減（後述のオート
スケーリング）
Infrastructure as Code で可能になること
14

オートスケーリング
15

ここにも
Linux
Kernel
ここにも
Linux
Kernel
Linux
Kernel
Com, Lib
MW
16
処理負荷の増減に対応する方法
Appl
用語スケールアウト、インスケールアップ、ダウン
処理負荷の増減に
対応する方法
サーバーの台数を増やす、減らすサーバーの性能 (ＣＰＵ、メモリな
ど)を増やす、減らす
メリット複数のサーバーで処理を分散してい
るので、そのうちの一台が故障して
もサービスを継続可能
コンテンツの更新は一台だけで行
えばよいので運用管理が容易
Com, Lib
MW
Appl
Com, Lib
MW
Appl
Linux
Kernel
Command, Library
Middle Ware
Appl

H/W
17
コンテナによる環境分離
Linux Kernel + コンテナランタイム
Namespace
Com, Lib
MW
Appl
Namespace
Com, Lib
MW
Appl
Namespace
Com, Lib
MW
Appl
コンテナ：アプリケーションを動かすために最小限必要なコマンド、ライブ
ラリなどをアプリケーションと一緒にカプセル化したもの。
Linux kernel 部分は共有するため、コンテナ自体のサイズを小さくすることが
できます。
Kernel を共有。
名前空間で分離
コンテナ

H/W
Linux Kernel + コンテナランタイム
18
コンテナ環境でオートスケーリングするイメージ
▶ 仮想マシンの場合よりも効率的に負荷の増大に対応
低負荷時
コンテナコンテナ
高負荷時
コンテナ
コンテナ
コンテナ
コンテナ
CPU 使用率、メモリ使用
量、秒間リクエスト数な
どの状態監視
Kubernetes, OpenShift,
クラウドベンダーなどの提供機能
目標値と比較してスケー
ルアウト、スケールイン

コンテナの運用実行と管理を行うオーケストレーションツール
▶ コンテナが大量になってくると管理しきれない部分をカバー
✓ スケーリング・オートスケーリング
✓ 負荷分散
✓ 死活監視
✓ 障害時のセルフヒーリング（コンテナのプロセス停止などを監視して、コンテナを再デプロ
イする機能）
✓ スケジューリング（コンテナのデプロイ先のNode決定）etc…
▶ リソース管理
✓ CPU・メモリー
✓ 永続的なストレージ、ネットワーク、クレデンシャル情報etc…
19
Kubernetes

Kubernetes クラスタのイメージ図
Node
Master Node
Node
Pod
ｺﾝﾃﾅA
Node
Pod
Pod
Storage
Pod
• コンテナは Pod という集合体の単位で管理され、下記が行えます。
• Pod 単位での増減
• Pod のリソース割り当ての増減
• Node の追加
コンテナランタイム
Node
ｺﾝﾃﾅB
network

Kubernetes のオートスケーリング機能の名前
▶ Pod 単位での増減 : HorizontalPodAutoScaler
• Pod のレプリカ数を自動的に増減。スケールアウト的な考え方
• 例えば、Node 内の Pod の CPU使用率の平均値と目標値を比較して
• 目標値の110％超であれば Pod を追加し、
• 90％未満であれば Pod を減らすことができます。
▶ Pod のリソース割り当ての増減：VerticalPodAutoScaler
• Pod のCPU・メモリ割り当てを増減。スケールアップ的な考え方
▶ Node 追加：Cluster AutoScaler
• Pod を起動できるノードが存在しない場合、Node を追加

▶ Operatorは、サービス運用者の普段の作業をコード化して、人の代わりに
オペレーションさせることを目指すフレームワーク。
▶ 下記のような、Kubernetes の制約を解決することを目指します。
✓ 静的なコンテンツ、RESTful APIなど、ステートレスなアプリケーションで使
用することが前提。データ欠損の回避、可用性、スケール時の柔軟な設定変更
などはできない
✓ 例えば、Pod を追加するときも、コンテナ・プロセスの停止を検知してコ
ンテナを再デプロイ（セルフヒーリング）するときも、まっさらな状態の
コンテナをデプロイしてしまう。
✓ そのため状態を維持しながら処理する必要のあるストートフル・アプリケー
ションにはコンテナ化は向かないと言われていた。
✓ 例えばデータベースをコンテナ化した場合、直前の状態を維持しながらス
ケーリング、障害からの回復などは Kubernetes だけでは行えない。
22
OpenShift Operator とは？

OpenShift Operator
⚫ OpenShift には下記の機能が追加されています。
⚫ Cluster services
✓ 監視、ロギングなど、クラスタの運用コストを効率化するサービス
⚫ Application services
✓ ミドルウェア、ISV などアプリケーションのサービス
⚫ Developer services
✓ 開発ツール、自動ビルド、CI/CD、IDE など開発の生産性を高めるサービス
⚫ Service mesh
✓ マイクロサービスの運用・開発・テストを簡素化
⚫ 信頼性の高い Kubernetes 管理
✓ Operator による自動化レイヤにより、オートスケーリングなど、運用の自
動化を作りこみできるようになります。（←この部分に該当）
✓ RHCOS (Red Hat Enterprise Linux CoreOS)
✓ コンテナ実行に最適化された Linux。コンテナのエンジンとして CRI-O が組み込
まれています。

▶ OperatorHub.io で IBM社提供の Operator を検索した例
▶ 下記のような、Kubernetes の制約を解決することを目指します。
24
OpenShift Operator の例

▶ テスト・検証状況により Operator は下記の４種類に分類されます。
• そのうち上位3種類が OperatorHub.io に登録されています (2021/2月
末現在 181種類)
25
Operator の分類
分類テストサポート
Certified サポート検証、品質検証済 ISV とのパートナーシップによりサ
ポート (Red Hat 製品の Operator
は、Red Hat 社サポート)
Operator Catalog in
OpenShift
OpenShiftへのインストール可否
テスト済
コミュニテイー
OperatorHub.io 登録済簡単な動的テスト済コミュニテイー
その他、コミュニテイーや
ISV が作成したOperator で、
OperatorHub.io 未登録のもの
があります。
- -

▶ 可能な作業により、5種類のフェーズに分類されます。成熟度ととも言い
ます。(Vが最高、I が最低)
▶ Operator の開発には、Ansible または Go が使用されています。
• フェーズ I の開発のみ Helm も使用されています。
• Ansible と OpenShift Operator の両方を使いこなせるようになると、
さまざまな運用の自動化に役立ちます。
26
Operator の分類
フェーズ可能な作業
V オートスケーリング対応、変化に合わせた設定のチューニング
IV メトリクス取得、アラート対応など
III アプリケーションのライフサイクル対応
データのバックアップ、リカバリ
II パッチ適用、バージョン・アップグレード
I 基本インストール（動的なアプリケーション展開、設定管理）

学習リソース紹介
27

▶ Ansible徹底入門クラウド時代の新しい構成管理の実現
▶ インフラCI実践ガイド Ansible/GitLabを使ったインフラ改善サイクルの
実現
▶ Ansible実践ガイド第3版
▶ Using Ansible to Automate IBM Cloud - Preview
• https://www.youtube.com/watch?v=ZaH8mcHR5Uk
28
Ansible に関する書籍、関連動画

▶ さわって学ぶクラウドインフラ docker基礎からのコンテナ構築
▶ Docker実践ガイド第2版
▶ Ｄｏｃｋｅｒ／Ｋｕｂｅｒｎｅｔｅｓ実践コンテナ開発入門
▶ １５Ｓｔｅｐで習得Ｄｏｃｋｅｒから入るＫｕｂｅｒｎｅｔｅｓコンテナ
開発からＫ８ｓ本番運用まで
▶ Ｋｕｂｅｒｎｅｔｅｓ完全ガイドクラウドネイティブのキーテクノロジー
第２版
▶ ソフトウエアデザイン 2020年 03月号 (特集：徹底解説 OpenShift 4)
▶ Red Hat OpenShift4入門 Enterprise Kubernetesへのファーストステッ
プ
29
Docker コンテナ、Kubernetes、Openshift 関連書籍

Ansible入門者向け e-ラーニング
(RH294R)Red Hat System Administration Ⅲ:Linux Automation with Ansible e-ラーニングコース
RHCSA 認定試験 (EX200) に合格済み、または同等の Red Hat Enterprise Linux の知識と経験を
有するユーザー向けのコースです。
(株式会社アイ・ラーニングとRed Hat 社との提携コース、以下同様)
Ansible を使用してプロビジョニング、構成、アプリケーションのデプロイメント、および
オーケストレーションを自動化するために必要な技術を学びます。
標準学習時間： 32時間（90日）
詳細
https://www.i-learning.jp/products/detail.php?course_code=RHR64
4日間集中コースもあります
https://www.i-learning.jp/products/detail.php?course_code=RH512

Ansible 経験者向け e-ラーニング
(DO447R)Advanced Automation: Ansible Best Practices e-ラーニングコース
Ansible でのスキルアップを目指す経験豊富な Ansible Automation ユーザー向けのコースで
す。下記を学習目標とします。
• 推奨されるプラクティスに従い、Ansible Automation を記述して管理する
• Ansible の高度な機能を活用して、複雑なタスクを実行する
• Ansible Tower をデプロイして使用し、既存の Ansible のプロジェクト、プレイブック、
ロールを拡張して管理する
• DevOps ワークフローの一部として、プレイブックとインベントリーを効果的に管理す
る
詳細

コンテナ管理入門者向け e-ラーニング
(DO180R)Red Hat OpenShift I: Containers & Kubernetes e-ラーニングコース
下記のような対象者向けのコースです。
• ソフトウェア・アプリケーションのコンテナ化を検討している開発者
• コンテナ化技術やコンテナのオーケストレーションの知識を得たい管理者
下記の基本タスクを行えるようになります。
• Podman を使用してコンテナ化されたサービスを作成する
• コンテナおよびコンテナイメージを管理する
• カスタム・コンテナイメージを作成する
• コンテナ化アプリケーションを Red Hat OpenShift でデプロイする
• マルチコンテナ・アプリケーションをデプロイする
詳細
3日間集中コースもあります
https://www.i-learning.jp/products/detail.php?course_code=RH606

AnsibleおよびDockerで始めるInfrastructure as a Code

AnsibleおよびDockerで始めるInfrastructure as a Code

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to AnsibleおよびDockerで始めるInfrastructure as a Code

Similar to AnsibleおよびDockerで始めるInfrastructure as a Code (20)

More from Satoru Yoshida

More from Satoru Yoshida (9)

Recently uploaded

Recently uploaded (16)

AnsibleおよびDockerで始めるInfrastructure as a Code