高度なTerraformモジュールを使用したOracle Cloud Infrastructure Kubernetes Engine (OKE)のデプロイ

はじめに

これは、Oracle Cloud Infrastructure Kubernetes Engine (OKE)自動化シリーズの2番目のチュートリアルで、最初のTerraformを使用したOracle Cloud Infrastructure Kubernetes Engineクラスタの作成の基礎的な概念に基づいています。この記事では、高度な自動化とモジュラー設計を導入して、Oracle Cloud Infrastructure(OCI)にスケーラブルで自己回復性のある高度にカスタマイズ可能な環境をプロビジョニングすることで、OKEデプロイメントを次のレベルに引き上げます。

Oracleエンジニアおよびお客様向けに設計されたこのガイドでは、基本的なTerraform構成を、任意のデプロイメント・サイズに合せた構造化、再利用可能なモジュールに変換できます。Infrastructure as Code (IaC)の原則をTerraform (コミュニティ・バージョン)と組み合せてJenkinsおよびOracleのコマンドライン・インタフェース(CLI)と組み合せることで、OKEクラスタ、その構成および自動テスト用のsingle-clickプロビジョニング・ソリューションが提供されます。

このチュートリアルでは、次の4つの主要な領域について説明します。

  1. モジュール設計および自動化: VCN、OKEクラスタ、要塞ホストなどのコア・コンポーネント用に再利用可能なモジュールを構築し、互換性を確保して管理を簡素化し、コードの再利用を促進します。
  2. 動的構成: 単一のコードベースから環境固有の設定(dev、test、prod)を管理して、一貫性のある繰返し可能なデプロイメントを実現します。
  3. 拡張ノード・プール: 特殊なシェイプ、互換性のあるOKEイメージおよびインテリジェントなワークロード配置用のラベルを使用して、リソースの使用量とコストを最適化します。
  4. シームレスなCI/CD統合: Terraform、JenkinsおよびOCI CLIを統合するパイプラインを使用して、OKEのプロビジョニングおよび更新を自動化し、効率的なone-clickデプロイメントを実現します。

このガイドで説明するアーキテクチャでは、階層ネットワーク・トポロジを使用して、セキュアでスケーラブルな基盤を作成します。コントロール・プレーン、ワーカー・ノード、ポッドおよびロード・バランサのトラフィックを分離することで、あらゆる規模のエンタープライズ・ワークロードに柔軟に対応できます。ネットワーキング、クラスタ、ノード・プールなどの環境のプロビジョニングを完全に自動化し、ソリューションをニーズに合わせてカスタマイズおよび拡張するためのツールを提供する方法について説明します。

このチュートリアルでは、Kubernetes、ネットワーキングおよびIaCの原則を理解するとともに、Terraform、OCI CLI、Jenkinsなどのツールに関する実用的な知識を前提としています。最終的には、自己回復性、高パフォーマンス、スケーラブルなOKE環境をOCIに導入するスキルがあり、特定の要件に柔軟に適応できます。

Oracle Cloud Infrastructure Kubernetes Engine (OKE)の概要

Oracle Cloud Infrastructure Kubernetes Engine (OKE)はマネージド・サービスですが、ミッションクリティカルなワークロードを正常に実行するには、意図的で適切に構造化されたアーキテクチャ・アプローチが必要です。基本的な設定からスケーラブルなエンタープライズ・グレードの環境に移行するには、慎重な計画と、TerraformなどのInfrastructure as Code (IaC)ツールの使用が必要です。

モジュール化と自動化は、OKEがスケーラビリティ、セキュリティ、および運用効率を確保するために不可欠です。構造化されたモジュールと自動化ツールを活用することで、企業は一貫性のあるミッションクリティカルなワークロードを導入および管理し、手作業によるエラーを削減し、市場投入までの時間を短縮することができます。

次の図は、階層ネットワーク・トポロジ、プライベートAPIエンドポイントおよびセキュア・アクセス制御が強調表示されたOKEアーキテクチャを示しています。

OKEアーキテクチャ

アーキテクチャの詳細な例は、Oracleドキュメントを参照してください。

アーキテクチャに関する考慮事項
スケーラブルなOKE環境を構築するには、少なくとも次の主要な技術的課題に対処する必要があります。

主な設計要素
このモジュラー・ソリューションは、階層化されたネットワーク・アーキテクチャ上に構築されており、OKE上のエンタープライズ・ワークロードのセキュアでスケーラブルな基盤を提供します。

OKE用のモジュラTerraform自動化の構築

flat Terraform構成をstructuredに変換するには、反復可能でスケーラブルな環境を作成するためにモジュラー設計が不可欠です。このアプローチにより、企業規模での組織、コードの再利用性、メンテナンス性が向上し、チーム間の互換性とコラボレーションのためのバージョニングが可能になります。

変換プロセス: フラットから構造化モジュール

最初のチュートリアルで説明したフラット・モジュールから、次の方法でコードをモジュラ設計にリファクタリングします。

  1. ディレクトリの再構築: 子モジュール(vcn、oke、bastion)を作成し、リソースをそれぞれのフォルダに編成します。
  2. 主な原則の適用:
    • 構造とロジック: 自己完結型ディレクトリ(modules/vcn、modules/oke、modules/bastionなど)にリソースをカプセル化し、一体型コードをmain.tf、variables.tfおよびoutputs.tfに分割して、読みやすさと保守性を確保します。
    • 入力/出力およびバージョニング: variables.tfで入力を定義し、outputs.tfで出力を公開し、シームレスなデータ・フローおよび互換性のためにTerraformモジュール・バージョニング(sourceではversion制約)を使用します。
    • オーケストレーション: countなどの条件付きロジックをルート・モジュール・レベルで処理し、子モジュールはリソースに集中します。

ディレクトリ構造: フラットとモジュラー

フラット・モジュール: 1つのモノリシック・ディレクトリで、いくつかのファイルにすべてのリソースが含まれます。概念実証には簡単ですが、複雑さが増すにつれて管理不能になります。

フラットモジュール構造

構造化モジュール: 各リソース・グループ(VCN、OKE、要塞)は、独自のモジュール・ディレクトリにあります。ルート・モジュールは、依存関係と最上位の構成を編成します。

拡張モジュール構造

モジュールの例

モジュールを使用する理由

モジュール・オーケストレーション- ルートmain.tf

ルートmain.tfは、3つのキー・モジュール(modules/vcn、modules/okeおよびmodules/bastion)のデプロイメントを順番に編成します。各モジュールは、構成フラグ(is_vcn_created、is_oke_created、is_bastion_created)に基づいて条件付きで起動されるため、デプロイメントの柔軟性が確保されます。次に、オーケストレーション・フローの簡略化されたバージョンを示します。main.tf全体を詳細に説明することなく、主要なモジュール・ロジックを強調表示します。

オーケストレーション・フロー:

  1. VCNモジュール(modules/vcn):
    • 仮想クラウド・ネットワーク(VCN)および関連するサブネット(Kubernetes APIおよびワーカー・ノードのプライベート・サブネット、ロード・バランサおよび要塞のパブリック・サブネットなど)をプロビジョニングします。
    • is_vcn_createdによって制御されます。有効になっている場合、VCNが作成されます。それ以外の場合、既存のVCNが想定されます(その使用済サブネットOCIDを指定する必要があります)。
    • スニペットの例: 
         module "vcn" {
       count = var.is_vcn_created ? 1 : 0  
       source = "./modules/vcn?ref=v1.0.0"  # Specify the module version  
       # Key variables: compartment_id, vcn_cidr_block, subnet configs, ...  
   }

      ノート:

      • このブログでは、提供されているVCNモジュールを使用して新しいネットワークを作成することを前提としています。
      • 既存のVCNを使用する場合は、このシリーズの最初のブログTerraformを使用したOracle Cloud Infrastructure Kubernetes Engineクラスタの作成を参照してください。このブログでは、is_vcn_createdフラグが導入されています。
      • この柔軟性をここに追加するには、is_vcn_createdをfalseに追加/設定し、Kubernetes APIエンドポイント、ワーカー・ノード、ポッド、ロード・バランサおよび要塞ホストのサブネットのOCIDsとともにVCNのOCIDを提供します。
  2. OKEモジュール(modules/oke):
    • OCI Kubernetes Engine (OKE)クラスタ(コントロール・プレーンおよびオプションの管理対象ノード・プールを含む)をデプロイします。
    • サブネットIDのVCNモジュールに依存します。is_oke_createdおよびis_vcn_createdがtrueの場合にのみ起動されます。
    • スニペットの例: 
         module "oke" {
       count = var.is_oke_created && var.is_vcn_created ? 1 : 0  
       source = "./modules/oke?ref=v1.0.0"  # Specify the module version   
       # Key variables: vcn_id, subnet IDs, k8 version, node pool config, ...  
   }
  3. 要塞モジュール(modules/bastion):
    • プライベート・リソースへの安全なSSHアクセス用の要塞ホストを作成します。
    • パブリック・サブネットIDのVCNモジュールに依存します。is_bastion_createdおよびis_vcn_createdがtrueの場合にのみ起動されます。
    • スニペットの例: 
         module "bastion" {
       count = var.is_bastion_created && var.is_vcn_created ? 1 : 0  
       source = "./modules/bastion?ref=v1.0.0"  # Specify the module version   
       # Key variables: bastion_subnet_id, SSH keys, parameters...  
   }

重要なノート:

OKEのモジュラTerraform構造を確立した後、次のステップはデプロイメントを自動化することです。自動化により、一貫性が確保され、手動エラーが削減され、プロビジョニング・プロセスが迅速化され、新機能やサービスの迅速な提供が可能になり、市場投入までの時間(TTM)が直接向上します。

自動化オプション

Terraform CLI、OCI Resource Manager (ORM)、OCI CLI、Ansible OCIモジュール、Helmなど、いくつかのツールでOKEデプロイメントを自動化できます。ただし、このガイドでは、Oracle Cloud Infrastructure (OCI)のコードとしての最も重要な2つのInfrastructure as Code (IaC)アプローチ(Terraform CLIおよびOCI Resource Manager (ORM))に焦点を当てています。

どちらのツールも、同じ宣言型HashiCorp構成言語(HCL)を利用しますが、運用モデルは異なります。

それぞれの選択肢を詳しく見ていきましょう。

オプション1: Terraform CLIを使用したOKEリソースのデプロイ

Terraform CLIは、ローカル環境を完全に制御する必要がある場合に最適です。状態ファイルを管理し、共有バックエンドを使用して効果的にコラボレーションできる個々の開発者や小規模なチームに最適です。移植性により、ローカル、VM、コンテナ、OCI CloudShell、CI/CDランナー(Jenkinsなど)など、あらゆるマシンから実行できます。ただし、この柔軟性には、状態ファイルの管理や、チーム・メンバー間のローカル設定の一貫性の確保などの責任があります。

まず、Terraform CLIソース・コード・パッケージをダウンロードして解凍し、Terraform作業ディレクトリに保存します。このパッケージには、main.tf、terraform.tfvarsサンプルおよび詳細なモジュール構成(oke_advanced_module.zipのダウンロード)が含まれています。

Terraform CLIを使用したOKEのデプロイには、変数およびネットワーキングの構成からOKEクラスタ、ノード・プールおよび要塞ホストの設定まで、7つの主要なタスクが含まれます。次に、Terraform CLIを使用してOKE環境をプロビジョニングおよび検証する詳細なステップを示します。

タスク1.1: Terraform変数の構成

terraform.tfvarsファイルを、tenancy_ocid、リージョン、compartment_ocid、network_compartment_ocidなどの環境固有の詳細で更新します。次のフラグを有効にして、リソースの作成を制御します。

タスク1.2: ネットワーキング構成

VCNとそのサブネットのCIDRブロックを定義します:

タスク1.3: OKEクラスタ構成

タスク1.4: ノード・プールの構成

タスク1.5要塞ホストの構成

タスク1.6: Terraformコマンドの実行

次のコマンドを実行して、インフラストラクチャをデプロイします。

	terraform init
	terraform validate	
	terraform plan
	terraform apply

terraform applyが完了すると、OKEクラスタに次のものがプロビジョニングされます。

タスク1.7: 検証とクリーニング

  1. OCIコンソールに移動して、クラスタ構成を確認します。
  2. 完了したら、terraform destroyを実行してリソースをクリーン・アップします。

Jenkins CI/CDパイプラインを使用したOKEデプロイメントの自動化
OKEデプロイメントをDevOpsパイプラインに統合する場合、Terraform CLIは優れた選択肢です。Terraformを使用したOracle Cloud Infrastructure Kubernetes Engineクラスタの作成に詳しく説明されているこのアプローチでは、bashスクリプトを使用してプロセスをオーケストレーションします。このワークフローは、自動実行のためにJenkinsパイプラインに統合できます。

オプション2: OCI Resource ManagerによるOKEの自動化

OCI Resource Manager (ORM)は、インフラストラクチャの導入にマネージド型のクラウドネイティブ・ソリューションが必要な場合に理想的な選択肢です。特に、セキュリティ、一元化された状態管理およびガバナンスが重要な、コラボレーション可能なエンタープライズ環境に適しています。ORMの主な利点は、OCI内のデプロイメント・ライフサイクル全体を処理し、状態ファイルを安全に格納して競合を防止することです。これにより、ローカル設定や共有バックエンドの管理が不要になります。さらに、ORMとOracle Cloudを深く統合することで、Identity and Access Management (IAM)などのOCIネイティブ機能を活用して、セキュリティと制御を強化できます。

このチュートリアルでは、OCI Resource Manager (ORM)とOCI CLI、Bashを組み合せて、それらをJenkins CI/CDパイプラインに統合し、ドリフト検出、セキュアな状態管理、互換性のためのバージョニングによるチーム・コラボレーションなどの追加のDevOps機能を備えた完全なone-click自動化フローを提供します。

OCIリソース・マネージャ・フロー
次の図は、7つのステップで構成されるORMワークフローを示しています。
ORMワークフロー

  1. ソース構成: IaC構成の起点を定義します(OCIオブジェクト・ストレージ、GitHub、Zipファイルなど)。
  2. Terraformテンプレート: インフラストラクチャは、Terraformを使用して定義されます。
  3. OCIリソース・マネージャ: ORMはTerraformテンプレートを取得し、プロビジョニング・プロセスを管理します。
  4. スタックの作成: ORMでは、テンプレートを使用してOCIリソースのスタックを作成します。
  5. 計画: 実行する処理の概要を示す計画を生成します。
  6. 適用: プランに基づいてリソースを提供します。
  7. 破棄: 不要になったときにリソースをプロビジョニング解除します。

OCIリソース・マネージャ(ORM)から新しいモジュールを使用してOKEクラスタをデプロイするには、ORMの拡張モジュール(oke_advanced_module_orm.zip)をダウンロードすることから始めます。このバージョンはORM用に事前構成されており、変数はREPLACE_WITH_YOUR_OWN_VARIABLE_VALUEなどの汎用プレースホルダに設定されます。

タスク2.1: ソース構成

variables.tfを、リージョン、ネットワーキングCIDR、フラグなどの環境固有の詳細で更新して、リソースの作成(VCN、OKEクラスタ、ノード・プール、要塞ホスト)を制御します。

次のbashスクリプトは、ORMリソース・ソースのzipファイルを作成します。

ソース・ディレクトリ(~/oke_advanced_module_orm)を確認して、stackconfig.zipという名前のファイルにすべてのterraformリソース定義が含まれていることを確認します。

タスク2.2: OCIリソース・マネージャ・スタックの作成

OCI CLIを使用して、ORMスタックを作成します。次のスクリプトは、プロセスを簡略化します。

Bashスクリプト: create_new_oke_stack.sh。

	#!/bin/bash
	
	# Load environment variables (e.g., COMPARTMENT_ID, STACK_NAME, etc.)
	source "./env-vars"

	# Create the Oracle Resource Manager stack and capture the OCID
	stack_output=$(oci resource-manager stack create \
	--compartment-id "$COMPARTMENT_ID" --display-name "$STACK_NAME" \
	--description "$STACK_DESCRIPTION" --config-source "$CONFIG_SOURCE")

	# Extract the OCID of the newly created stack and display it
	STACK_OCID=$(echo "$stack_output" | jq -r '.data.id')

	echo "Stack OCID: $STACK_OCID"

タスク2.3: スタック・プラン・ジョブの実行

Planジョブを実行して変更内容を検証してから適用します。このドライ・ランは、インフラストラクチャの変更に透明性を提供します。

Bashスクリプト: create_oke_stack_plan_job.sh

	#!/bin/bash

	# Load environment variables (e.g., STACK_OCID)
	source "./env-vars"

	# Create a plan job for the specified stack
	plan_job_output=$(oci resource-manager job create-plan-job \
		--stack-id "$STACK_OCID")

	# Extract the OCID of the plan job and check for errors
	PLAN_JOB_OCID=$(echo "$plan_job_output" | jq -r '.data.id')
	if [[ -z "$PLAN_JOB_OCID" ]]; then
		echo "Error: Failed to retrieve plan job OCID." >&2
		exit 1
	fi

	echo "Plan job OCID: $PLAN_JOB_OCID"

タスク2.4: 適用ジョブの作成

Applyジョブを使用して、OKEクラスタおよびノード・プールなどの関連リソースをプロビジョニングします。

Bashスクリプト: create_oke_stack_apply_job.sh

	#!/bin/bash

	# Load environment variables (e.g., STACK_OCID, EXEC_PLAN_STRATEGY)
	source "./env-vars"

	# Create an apply job for the specified stack
	apply_job_output=$(oci resource-manager job create-apply-job \
		--stack-id "$STACK_OCID" \
		--execution-plan-strategy "$EXEC_PLAN_STRATEGY")

	# Extract the OCID of the apply job and check for errors
	APPLY_JOB_OCID=$(echo "$apply_job_output" | jq -r '.data.id')
	if [[ -z "$APPLY_JOB_OCID" ]]; then
		echo "Error: Failed to retrieve apply job OCID." >&2
		exit 1
	fi

	echo "Apply job OCID: $APPLY_JOB_OCID"

タスク2.5: 破棄ジョブの実行

環境が不要になったときにDestroyジョブを実行して、リソースをクリーンアップします。

Bashスクリプト: create_oke_stack_destroy_job.sh

	#!/bin/bash

	# Load environment variables (e.g., STACK_OCID, EXEC_PLAN_STRATEGY)
	source "./env-vars"

	# Create an  jotroy for the specified stack
	apply_job_output=$(oci resource-manager job create-destroy-job \
		--stack-id "$STACK_OCID"  \
		--execution-plan-strategy "$EXEC_PLAN_STRATEGY")

	# Extract the OCID of the destroy job and check for errors
	DESTROY_JOB_OCID=$(echo "$apply_job_output" | jq -r '.data.id')
	if [[ -z "$DESTROY_JOB_OCID" ]]; then
		echo "Error: Failed to retrieve destroy job OCID." >&2
		exit 1
	fi

	echo "Apply job OCID: $DESTROY_JOB_OCID"

JenkinsとOCI Resource ManagerによるOKEの自動化

Jenkinsパイプラインを作成して、エンドツーエンドのプロビジョニング・プロセスを自動化しました(タスク2.1から2.4)。パイプラインは、OCI CLIを使用してbashスクリプトを実行し、ORMと対話します。

次のイメージは、最初の4つのタスクのone-click自動化を示しています。簡略化のためにdestroyステップは含まれていません。

OKEJenkinsPipeline

パイプラインには、ソース構成、ORMスタックの作成、プラン生成、リソース・プロビジョニングおよびオプションのリソース・プロビジョニング解除が含まれます。

次のステップ:

OKEプロビジョニングにTerraformを使用すると、一貫性、自動化およびスケーラビリティが保証されます。モジュラー設計とOCI Resource ManagerおよびCI/CDパイプラインを組み合わせることで、導入をよりシンプルかつ簡単に維持できます。次のチュートリアルでは、監視、セキュリティおよび本番準備のためのベスト・プラクティスについて説明します。これらの基盤に基づいて、モジュールをOracle AIOpsに拡張し、AIアプリケーション用のエンドツーエンドのOKEブループリントを作成し、AI主導の可観測性によるロギング分析が異常を検出し、コンテナ・プラットフォームのセキュリティを強化する方法を説明します。

確認

その他の学習リソース

docs.oracle.com/learnで他のラボを確認するか、Oracle Learning YouTubeチャネルで無料のラーニング・コンテンツにアクセスしてください。また、education.oracle.com/learning-explorerにアクセスして、Oracle Learning Explorerになります。

製品ドキュメントについては、Oracle Help Centerを参照してください。