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

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

Oracle Code Tokyo 2019(https://www.oracle.co.jp/events/code/2019/)での発表資料です
Terraform と OCI Resource Managerを使ってInfrastructure as Codeをやる話。

36bb9dcd778d2a9621d44e92425d0907?s=128

hhiroshell

May 17, 2019
Tweet

Transcript

  1. Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

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

    | 自己紹介 早川 博(はやかわ ひろし) • Cloud Nativeな技術スタック担当のプリセールスエンジニア – Kubernetes / Microservices / DevOps • エンジニアコミュニティ 「Cloud Native Developers JP」 オーガナイザー • Developer Summit 2018、Japan Container Days 12.18 登壇 2 @hhiroshell
  3. Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

    | 目次 • イントロダクション • DevOps と Infrastructure as Code • Terraform の基礎 • OCI Resource Manager 3
  4. Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

    | イントロダクション 4
  5. Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

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

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

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

    | 8 ソフトウェアシステムのモダンな開発プロセス 要件定義 ⚫ 基本設計 ⚫ 詳細設計 ⚫ 実装 ⚫ 単体テスト ⚫ 結合テスト ⚫ 基本設計 ⚫ 詳細設計 ⚫ 実装 ⚫ 単体テスト ⚫ 結合テスト ⚫ 基本設計 ⚫ 詳細設計 ⚫ 実装 ⚫ 単体テスト ⚫ 結合テスト ⚫ インフラ設計 ⚫ 環境構築 ⚫ システムテスト ⚫ 性能テスト ⚫ 受け入れテスト アプリケーション開発 アプリケーション開発 アプリケーション開発 運 用 インフラ開発・運用 ⚫ インフラ設計 ⚫ 環境構築 ⚫ システムテスト ⚫ 性能テスト ⚫ 受け入れテスト 運 用 インフラ開発・運用 ⚫ インフラ設計 ⚫ 環境構築 ⚫ システムテスト ⚫ 性能テスト ⚫ 受け入れテスト 運 用 インフラ開発・運用 要件定義 スプリント1 スプリント2 スプリント3 アプリ開発者 インフラエンジニア 要件定義 スプリント1 スプリント2 スプリント3 短期間で繰り返し開発・リリースしていく (数日~数週間ごと)
  9. Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

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

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

    | DevOps と Infrastructure as Code 11
  12. Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

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

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

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

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

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

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

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

    | Terraform の基礎 19
  20. Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

    | 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ツール
  21. Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

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

    | 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
  23. Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

    | 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
  24. Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

    | Terraformの使い方 – Terraformの実行 • 構成定義ファイル、変数指定ファイルを格納したディレクトリで以下を実行 – terraform init : ワークディレクトリの初期化(プロバイダのロードなど) – terraform plan : Dry Runを行ってファイルをバリデーション – terraform apply : 環境構築の実行 24 構成定義ファイル 変数指定ファイル > terraform init # ワークディレクトリの初期化 > terraform plan # Dry Run > terraform apply # 環境構築の実行 クラウド環境 VM
  25. Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

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

    | Terraformの課題 • チーム開発(複数人でひとつのインフラを管理)のためのセットアップと管理のコ ストが大きい • アプリケーション開発者が使いこなすには敷居が高い 26 クラウド環境を利用したDevOpsでTerraformを利用するには、2つの課題がある
  27. Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

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

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

    | OCI Resource Manager 29
  30. Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

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

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

    | Demo ① Resource Manager の Stack 32
  33. Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

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

    | OCI Resource Managerの発展的な使い方 34
  35. Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

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

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

    | Demo ② DevOpsユースケース 37
  38. Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

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

    | 39 Happy Terraforming !!
  40. Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

    | 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. Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

    | 41
  42. 42