Happy Terraforming!! IaCとクラウドで変わるこれからのDevOps / Happy Terraforming!!

Copyright © 2019, Oracle and/or its affiliates. All rights reserved. |
Happy Terraforming!!
IaCとクラウドで変わるこれからのDevOps
早川博 | @hhiroshell
日本オラクル株式会社
ソリューション・エンジニアリング統括セールスコンサルタント
#codetokyo19 #codetokyo19B3

View Slide

自己紹介
早川博（はやかわひろし）
• Cloud Nativeな技術スタック担当のプリセールスエンジニア
– Kubernetes / Microservices / DevOps
• エンジニアコミュニティ「Cloud Native Developers JP」オーガナイザー
• Developer Summit 2018、Japan Container Days 12.18 登壇
2
@hhiroshell

View Slide

目次
• イントロダクション
• DevOps と Infrastructure as Code
• Terraform の基礎
• OCI Resource Manager
3

View Slide

イントロダクション
4

View Slide

新しいビジネスの発見
既存ビジネスの遂行
バックオフィス業務の効率化
New IT
Old IT
ITシステムへの新しいニーズ
※Kelly Goetsch
「Oracle: Building Cloud Native Software」
より一部改変
Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 5

View Slide

IT活用の主目的の変化
• IT活用の主目的が変化し、何を作るのが正解か
が不明確に
→ システム開発に求められるものの変化
✓サービスの早期リリース
✓市場の動向/反応を早期フィードバックして対応
6
正解のない中で開発を進めるということ → 短期間での繰り返しリリース
業務
効率化
ビジネス
創造
社内
社外
社内業務の
効率化
社外顧客向け
新ビジネス
創造
SoR
SoE
短期間での繰り返しリリースが必要

View Slide

ソフトウェアシステムのモダンな開発プロセス
要件定義
⚫ 基本設計
⚫ 詳細設計
⚫ 実装
⚫ 単体テスト
⚫ 結合テスト
⚫ 基本設計
⚫ 詳細設計
⚫ 実装
⚫ 単体テスト
⚫ 結合テスト
⚫ 基本設計
⚫ 詳細設計
⚫ 実装
⚫ 単体テスト
⚫ 結合テスト
⚫ インフラ設計
⚫ 環境構築
⚫ システムテスト
⚫ 性能テスト
⚫ 受け入れテスト
アプリケーション開発アプリケーション開発アプリケーション開発
運
用
インフラ開発・運用
⚫ 環境構築
⚫ 性能テスト
運
用
⚫ 環境構築
⚫ 性能テスト
運
用
要件定義スプリント1 スプリント2 スプリント3
アプリ開発者
インフラエンジニア

View Slide

ソフトウェアシステムのモダンな開発プロセス
要件定義
⚫ 基本設計
⚫ 詳細設計
⚫ 実装
⚫ 単体テスト
⚫ 結合テスト
⚫ 基本設計
⚫ 詳細設計
⚫ 実装
⚫ 単体テスト
⚫ 結合テスト
⚫ 基本設計
⚫ 詳細設計
⚫ 実装
⚫ 単体テスト
⚫ 結合テスト
⚫ 環境構築
⚫ 性能テスト
アプリケーション開発アプリケーション開発アプリケーション開発
運
用
⚫ 環境構築
⚫ 性能テスト
運
用
⚫ 環境構築
⚫ 性能テスト
運
用
アプリ開発者
インフラエンジニア
短期間で繰り返し開発・リリースしていく
（数日～数週間ごと）

View Slide

• プロジェクト管理の手法
– 進捗管理、タスク管理手法が
短期開発に向いていない
– 計画変更を柔軟に取り込むこ
とができない
• 開発・運用の組織文化
– 運用担当者は本番環境の変
更を嫌うため、高頻度のリリー
スに協力的でない
– 情報共有の手段が効率的で
なく連携が不足
– テストからリリースに至るオペ
レーションが多く、運用担当者
が対応できない
9
• アーキテクチャ
– 大規模なアプリケーションの場
合、変更の影響範囲の把握
が難しく、実装に時間がかか
る
– 回帰試験の工数が膨大にな
るためテストに時間がかかる
高頻度リリースを実現する上での課題
開発に関わるあらゆる面で高頻度リリースのための最適化が試みられている
アジャイル開発 DevOps
マイクロサービス
アーキテクチャ

View Slide

• プロジェクト管理の手法
– 進捗管理、タスク管理手法が
短期開発に向いていない
– 計画変更を柔軟に取り込むこ
とができない
• 開発・運用の組織文化
– 運用担当者は本番環境の変
更を嫌うため、高頻度のリリー
スに協力的でない
– 情報共有の手段が効率的で
なく連携が不足
– テストからリリースに至るオペ
レーションが多く、運用担当者
が対応できない
10
• アーキテクチャ
– 大規模なアプリケーションの場
合、変更の影響範囲の把握
が難しく、実装に時間がかか
る
– 回帰試験の工数が膨大にな
るためテストに時間がかかる
このセッションのテーマ
本日のテーマはDevOpsです！
アジャイル開発 DevOps
マイクロサービス
アーキテクチャ

View Slide

DevOps と Infrastructure as Code
11

View Slide

DevOpsが登場した背景
• 開発チーム(Dev)と運用チーム(Ops)の対立
12
開発チーム(Dev)と運用チーム(Ops)の対立関係が高頻度リリースの障壁に
“ “
”
Devの役割が“システムに新しい機能を追加する”である一方、Opsの役割は“システム
の安定稼働”である。
そのため、Devが新しい機能を追加したくても、Opsはシステムの安定稼働のために変更
を加えたがらない、という対立構造が作られてしまっていた。
アプリケーションの
問題です！
環境の問題だ！

View Slide

組織文化とツールによって開発サイクルを円滑に回すのがDevOps
DevOpsで実現する円滑な開発サイクル
・基盤に依存しないアプリケーション
・スケールしやすいアプリケーション
・テスト、リリースの自動化
アプリケーション開発者
Dev
IT担当者
Ops
Devの目指すもの
・スケール可能な運用フロー
・迅速なデプロイを実現する作業プロセス
・高度なモニタリング
Opsの目指すもの
コミュニケーションタスク管理・進捗管理
バージョン管理
成果物管理
ビルド、テストの自動化環境構築の自動化
② ITツールの活用
① 組織文化
お互いを尊敬し、信頼し合う文化
お互いの成果へのフィードバック

View Slide

開発サイクルを円滑に回すために環境構築の自動化が必要
DevOpsの開発サイクルにおけるプラクティス
計画
開発
ビルド
テスト
デプロイ
(本番)
運用
監視
システムの監視情報を
次の開発にフィードバック
本番環境へのデプロイを
自動化（継続的デリバリー）
環境構築の自動化
(Infrastructure as Code)
DevとOpsの
バージョン管理システムの共有
ビルドの自動化と定期実行
（継続的インテグレーション）
テスト環境へのデプロイを
自動化
環境構築の自動化
(Infrastructure as Code)
イミュータブル・インフラストラク
チャの利用（クラウドなど）
イミュータブル・インフラストラク
チャの利用（クラウドなど）

View Slide

Infrastructure as Code
• システムの実行環境（開発、テスト、本番）をコードで定義して管理する手法・ツール
• ソフトウェア開発のプラクティスをシステム管理に応用
– バージョン管理、テスト、継続的インテグレーション…
• インフラの構成管理に加え、プロビジョニングの自動化と繰り返し再現を可能にする
15
DevOpsサイクルにおける環境構築の自動化の取り組み
ソースコード管理システム
VM
構成定義ファイル
{} パラメータ
インフラ環境
コードによって
インフラ構成を定義

View Slide

• 環境構築のリードタイム削減
– IaCツールを利用した、環境の自動構築
• テスト品質の向上
– 同一環境を繰り返し再現できることで本
番とテスト環境の差異をなくす
– 人手によるミスを撲滅
16
Infrastructure as Codeによって得られるメリット
環境構築のリードタイム削減とテスト品質の向上を実現

View Slide

IaCツールの比較観点
• 管理対象: コンフィグレーション vs. オーケストレーション
– 個々のサーバーの構成情報に注目するか、多数のリソースの協調動作に注目するか
• インフラの特性: ミュータブル vs. イミュータブル
– リソースは変更して利用を継続する必要があるか、削除して作り直すことが可能か
• コーディングスタイル: 手続的 vs. 宣言的
– 手続的の方がトラブルシュートしやすい。宣言的の方がシンプルで可読性に長ける
• アーキテクチャ: クライアントーサーバー vs. クライアントのみ
– クライアントのみのほうがツールの取り回しが良い
17
多数あるIaCツールから適切なツールを選択するには、比較観点を整理する必要がある

View Slide

クラウドリソースの管理に適したIaCツールの選定
Chef Puppet Ansible SaltStack Terraform
管理対象コンフィグレーションコンフィグレーションコンフィグレーションコンフィグレーションオーケストレーション
インフラの特性ミュータブルミュータブルミュータブルミュータブルイミュータブル
コーディングスタイル手続的宣言的手続的宣言的宣言的
アーキテクチャクライアント／
サーバー
クライアント／
サーバー
クライアントのみクライアント／
サーバー
クライアントのみ
18
Terraformが好相性
• 復数のリソース組み合わせてシステム成立させる → オーケストレーション
• リソースの削除と再作成が容易 → イミュータブル

View Slide

Terraform の基礎
19

View Slide

Terraformとは
• 米HashiCorp社が開発しているインフラの構成管理ツール
– https://www.terraform.io
– https://github.com/hashicorp/terraform
• Providerと呼ばれる機構により、主要クラウドサービスを始めとする多種多様な
インフラの管理に対応
– AWS, Google Cloud Platform (GCP), Microsoft Azure, Oracle Cloud Infrastructure(OCI)
を含む100超のプラットフォームに対応
• インフラのリソースをJSONの拡張形式で宣言的に定義
20
多種多様なインフラに対応可能なIaCツール

View Slide

Terraformの使い方 – 構成定義ファイル / 変数指定ファイル
• 構成定義ファイル (*.tf)
– 管理対象の構成情報を記述
– 構成要素をResourceオブジェクトとして抽象化して表現することで、多種多様な管理対象
リソースを統一感のある記述で表現
– HashiCorp Configuration Language (HCL)と呼ばれる独自のJSON拡張フォーマット
• 変数指定ファイル (terraform.tfvars / *.auto.tfvars)
– 構成定義ファイル内の変数に与える値を記述するファイル
21
変数の値は terraform 実行時のコマンドオプションとして指定することも可能です
i

View Slide

Terraformの使い方 – 構成定義ファイル / 変数指定ファイル
resource "oci_core_instance" “example-vm" {
compartment_id = "${var.compartment_ocid}“
display_name = "${var.core_instance_name}“
shape = "${var.core_instance_shape}“
availability_domain = "${var.core_instance_availability_domain}“
create_vnic_details {
subnet_id = "${var.core_instance_subnet_ocid}“
}
(… snip …)
}
1
2
3
4
5
6
7
8
9
10
11
compartment_ocid = "ocid1.compartment.oc1.. aaaaaaaasrtzjri4uhmhcfrlsm7cllcjifz4dz6z…"
core_instance_name = “example-vm"
core_instance_shape = “VM.Standard2.2“
(… snip …)
1
2
3
4
example-vm.tf
terraform.tfvars

View Slide

Terraformの使い方 – プロバイダ
• プロバイダ
– 各種インフラのAPIを実行するプラグイン
– 構成定義ファイル上に “provider” リソースとしてインフラのAPIの接続情報などを記述する
• プロバイダの記述例（Oracle Cloud Infrastructureの場合）
– この内容を構成定義ファイル内に記述する
23
provider "oci" {
tenancy_ocid = “${var.tenancy_ocid}“ # テナントの識別子
user_ocid = “${var.user_ocid}“ # 実行ユーザーの識別子
fingerprint = “${var.fingerprint}“ # APIキーの公開鍵のフィンガープリント
private_key_path = “${var.private_key_path}“ # APIキーの秘密鍵
region = “${var.region}“ # データセンターリージョン
}
1
2
3
4
5
6
7
provider.tf

View Slide

Terraformの使い方 – Terraformの実行
• 構成定義ファイル、変数指定ファイルを格納したディレクトリで以下を実行
– terraform init : ワークディレクトリの初期化（プロバイダのロードなど）
– terraform plan : Dry Runを行ってファイルをバリデーション
– terraform apply : 環境構築の実行
24
変数指定ファイル
> terraform init # ワークディレクトリの初期化
> terraform plan # Dry Run
> terraform apply # 環境構築の実行
クラウド環境
VM

View Slide

Terraformの使い方 – 状態管理の仕組み
• 管理対象のリソースの状態は状態ファイルによって管理される
• 状態ファイル (terraform.tfstate)
– デフォルトでTerraform実行時のワークディレクトリに生成される
– チーム開発向けにリモートのストレージ（バックエンド）に配置すること可能。状態ファイ
ルをロックすることによって同時実行による事故を防止
25
クラウド環境
VM
状態ファイル
オブジェクトストレージ
✓ DB作成成功
✓ VM作成失敗

View Slide

Terraformの課題
• チーム開発（複数人でひとつのインフラを管理）のためのセットアップと管理のコ
ストが大きい
• アプリケーション開発者が使いこなすには敷居が高い
26
クラウド環境を利用したDevOpsでTerraformを利用するには、2つの課題がある

View Slide

Terraformの課題 1/2
ストが大きい
– 状態ファイルをリモートで管理するためバックエンドを作成する必要がある。環境が増えると
その数だけのセットアップが必要
– 構成定義ファイルの複製が復数環境に存在することになり、構成の管理が難しくなる
（最悪誤った修正を環境に適用してしまうケースも）
27
クラウド環境
VM
状態ファイル
オブジェクトストレージ

View Slide

Terraformの課題 2/2
– 1つのテンプレートセットを使うまでに必要な作業が多い
1. クライアント（terraformコマンド）のセットアップ
2. テンプレートの取得とバックエンドの設定
3. クラウドを操作するための認証情報の設定（APIキーの発行とテンプレートへの記載）
4. その他テンプレート固有のパラメータを、適切な値を判断して設定
（他に、クライアント環境に依存する問題のトラブルシューティングなども必要）
– アプリ開発者の判断で開発環境を作ったり消したりできるのが理想
28

View Slide

OCI Resource Manager
29

View Slide

OCI Resource Managerとは
• Oracle Cloud Infrastructure上で利用可能なTerraformの実行環境
• OCIのアカウントと権限さえあれば、Resource Managerを通してTerraformの実
行が可能になる
• OCIのリソースの管理に特化
30
Cloud化されたTerraformの実行環境
{} パラメータ
Resource Manager Stack OCI
VM

View Slide

OCI Resource ManagerのStack
• Resource Managerにおける実行環境の単位。構成定義ファイルのアップロード
と変数の値（変数指定ファイル相当）を指定して作成
• OCIのIAMによるアクセス制御と、Stack内での自動状態管理が働くことで、
チーム開発で必要な管理がクラウドに任せられる
31
StackによってTerraformのコマンドベースのI/F隠蔽
{} パラメータ
Resource Manager Stack
OCI
インフラ管理者A
Stack 作成
( 構成定義ファイルと {}パラメータ)
チームメンバー
ア
ク
セ
ス
制
御
実行
(plan, apply, destroy)
状態管理

View Slide

Demo ①
Resource Manager の Stack
32

View Slide

OCI Resource ManagerによるTerraformの課題の解決
ストが大きい
→ Stackとして作成したTerraformの実行環境を共有することで、利用者ごと
の環境の作成、維持が不要に
→ OCIのIAMとの連携により、アクセス制御のための追加の設定が不要
→ StackのUIによりアプリ開発者でも環境の作成、削除が実行可能に
33
Resource Managerによって、Terraformの課題を解決することができる

View Slide

OCI Resource Managerの発展的な使い方
34

View Slide

OCI Resource ManagerのDevOpsユースケース – 1/2
• ソースコード管理と連携したBlue / Green
– インフラの環境ごとのバージョン管理と、自動構築による省力化／高速化
35
高度なデプロイメントの実践に適用
Terraformテンプレート
とパラメータファイル
CIツール
{} パラメータ
Blue Stack
Green Stack
{} パラメータ
VM
LB
VM
OCI
エンドユーザーからの
トラフィック
Developer Cloud
Service

View Slide

OCI Resource ManagerのDevOpsユースケース – 2/2
• 開発環境の申請、自動払い出しシステム
– 開発環境の作成、提供をセルフサービス化。インフラ管理者のタスクを削減
36
インフラ管理者の日常業務の削減にも貢献
OCI
Object Storage Functions Resource Manager
アプリ開発者
{} パラメータファイル
環境払い出し依頼
Webフォーム/Chat bot…etc
{} パラメータ
Stack
VM
開発業務で利用
Stackを操作
（環境の削除・再作成）

View Slide

Demo ②
DevOpsユースケース
37

View Slide

まとめ
• システムを短期間で繰り返しリリースするための取り組みとして、DevOpsと
Infrastructure as Codeが有効
• クラウドインフラを管理するIaCツールとしてTerraformが適している
• OCI Resource ManagerによってTerraformの課題を解決して、チーム開発に最
適なIaC環境をゲットしましょう
38

View Slide

Happy Terraforming !!

View Slide

Safe Harbor Statement
The preceding is intended to outline our general product direction. It is intended for
information purposes only, and may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality, and should not be relied upon
in making purchasing decisions. The development, release, timing, and pricing of any
features or functionality described for Oracle’s products may change and remains at the
sole discretion of Oracle Corporation.
40

View Slide


View Slide

42

View Slide

Happy Terraforming!! IaCとクラウドで変わるこれからのDevOps / Happy Terraforming!!

Happy Terraforming!! IaCとクラウドで変わるこれからのDevOps / Happy Terraforming!!

hhiroshell

More Decks by hhiroshell

Other Decks in Technology

Featured

Transcript