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

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

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

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

| イントロダクション 4

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

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

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

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

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

| DevOps と Infrastructure as Code 11

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

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

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

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

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

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

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

| Terraform の基礎 19

| 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ツール

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

| 22 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

| 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

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

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

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

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

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

| OCI Resource Manager 29

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

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

| Demo ① Resource Manager の Stack 32

| OCI Resource ManagerによるTerraformの課題の解決 • チーム開発（複数人でひとつのインフラを管理）のためのセットアップと管理のコストが大きい → Stackとして作成したTerraformの実行環境を共有することで、利用者ごとの環境の作成、維持が不要に → OCIのIAMとの連携により、アクセス制御のための追加の設定が不要 • アプリケーション開発者が使いこなすには敷居が高い → StackのUIによりアプリ開発者でも環境の作成、削除が実行可能に 33 Resource Managerによって、Terraformの課題を解決することができる

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

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

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

| Demo ② DevOpsユースケース 37

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

| 39 Happy Terraforming !!

| 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

| 41

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

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

More Decks by hhiroshell

Other Decks in Technology

Featured

Transcript