Oracle Resource Managerによる高度なTerraformスタック・ロジック (2023/11/01)

https://blogs.oracle.com/cloud-infrastructure/post/adv-terraform-stack-logic-oracle-resource-manager

投稿者：Zachary Smith | Principal Solution Architect

このブログ投稿では、Oracle Resource Managerスタックを使用してTerraformコードに高度なロジックを作成する方法を示します。このブログの例は、Data Lakehouseのクイック・スタート・スタックと、Oracle Container Engine for Kubernetes (OKE)のApache Airflowのクイック・スタート・スタックです。

Resource Managerスタック・スキーマ

Oracle Resource Managerは、Infrastructure as Code (IaC)モデルを介してリソースをインストール、構成および管理するのに役立つTerraformスタック・サポートを提供する、無償のフルマネージドOracle Cloud Infrastructure (OCI)サービスです。Oracle Resource Managerスタックについて最初に理解する必要があるのは、基礎となるTerraformコードにスキーマ・オーバーレイを使用することです。このスキーマでは、Oracle Cloudコンソール・インタフェースを使用して変数選択を抽象化できます。また、このスキーマでは、OCI内の非常に強力な動的統合もサポートされており、テナンシ内の使用可能な値のリストを公開する合理化されたメカニズムが提供されます。次に例を示します。

• Region selection
• Compartment ID
• Core image selection
• Compute shape selection
• VCN selection
• Subnet selection
• Availability domain selection
• Fault domain selection
• Database system selection
• Database system home folder
• Database system ID selection
• Autonomous database ID selection

これらの動的統合に加えて、スキーマでは、個々の変数または変数グループを表示および非表示にするためのブール・ロジックもサポートされます。この機能により、高度なワークフロー・ロジックをスキーマ・オーバーレイに組み込むことができます。

データレイクハウス・スタックの概要

データレイクハウス・スタックにより、データレイクハウス・コンポーネントを個別または一括で導入できます。また、仮想クラウド・ネットワーク(VCN)やサブネットの作成、Identity and Access Management (IAM)ポリシーなどのコンポーネントをサポートするための基礎となるすべての前提条件も含まれています。

まず、アーキテクチャ図を見てみましょう。

この図は、リソースがターゲット・コンパートメントに作成されることを示しています。各サービスのVCNおよび関連するサブネットを作成または選択でき、対応するOCIサービスをデプロイメントの自動化の一部として使用できます。次の図は、このリポジトリの視覚化を示しています。

最上位レベルには、ファイル内のコアTerraformコンポーネントvariables.tfがあります。このコンポーネントには、スタックに必要なすべての変数、IAMポリシーを含むIAM.tf、および各モジュールをデプロイするためのコアTerraformコードを持つmain.tfが含まれます。ファイルschema.yamlは、この基礎となるTerraformのオーバーレイです。ユーザー・ワークフローに含める必要がある変数は、その変数に含まれている必要があります。静的またはワークフローに含まれない変数は、スキーマで非表示にできます。スキーマは、Oracle Resource Managerが取得する最上位ディレクトリに配置する必要があります。

テンプレート内の各モジュールは自己完結型であり、少なくともmain.tf (コア)とサポートするvariables.tfで構成されます。変数は、最上位レベルmain.tfからモジュールに渡されます。モジュールは、Terraform countパラメータを使用してオンとオフになります。このパラメータは、スキーマ内のブール条件セットでサポートされています。ブールがfalseの場合、カウントは0で、モジュールは作成されません。それ以外の場合は、trueの場合、モジュール数は1に設定され、モジュールが構築されます。スキーマは、variables.tfの変数パラメータを上書きしますが、両方の場所にデフォルトを含めることができます。variables.tfレベルのデフォルトは、妥当性チェックのためにTerraformレベルで使用され、スキーマで設定されたものがUIに表示されるデフォルトです。これらのデフォルト値は、スキーマが優先されることを認識して、schema.yamlとvariables.tfの間で一貫している必要はありません。

スキーマ変数および可視性

スキーマでは、コンソールUIで変数および変数グループの表示を切り替えることができます。データ・レイクハウス・スタックが初めてロードされるとき(デフォルトで)、IAMポリシー、VCN、サブネットなど、必要な前提条件がオンになっているコンポーネントのみになります。

UIでは、データ・レイクハウス・コンポーネント変数グループのすべてのモジュールがデフォルトでオフになっています。「VCNオプション」セクションには、既存のVCNを使用するためのブール、可用性ドメイン・セレクタ、およびVCNのその他のカスタマイズ・オプションが含まれます。これらのセクションをサポートするために、schema.yamlコードは次の出力を提供します。

スキーマの行1から4はメタデータ用です。5行目では、変数グループ・セクションが開始されます。各変数グループの先頭にはタイトルが付いており、その変数はグループの一部です。行6-13と行14-23は最初の2つのグループを定義します。変数または変数グループ・レベルで可視性をトリガーできます。Autonomous Data Warehouse変数グループ・セクションを見てみましょう:

34行目では、可視性オプションがdeploy_ADB変数に設定されています。この変数は、105行目の後にすべての変数を設定する変数グループ・セクションの後にインスタンス化された最初の変数として、スキーマ内で後で定義されます。

108行目では、この変数をブールとして定義し、UIにチェック・ボックスとして表示されます。デフォルトはfalseで、選択されていません。UIでボックスを選択すると、スキーマ表示のブールに依存するため、Autonomous Data Warehouseの変数グループが表示されます。

この情報は、main.tf Terraformにもカスケードされます。ブール"deploy_ADB"は、行24でAutonomous Data Warehouseモジュールをオンにするために使用されます。次のスクリーンショットは、モジュールに渡される変数がスキーマ・オーバーレイからミラー化される様子を示しています。

モジュール・ソースはリポジトリに対してローカルですが、ソースは、Oracle DevRelリポジトリから様々なOCI Cloud Bricksテンプレートを使用するなど、リモート・モジュールを参照することもできます。この関数を使用すると、スタックから独立してモジュールを管理できます。

変数グループにブール数が増えると、より強力な動的ワークフローがサポートされます。この例では、さらに2つのブールがあります。1つは専用Exadataインフラストラクチャ用、もう1つはデータベースのプレビュー・バージョン用です。モジュール自体は、複数のパラメータをサポートするdatabase_autonomous_database Terraformリソースを使用します。データ・ウェアハウスはAutonomous Databaseのワークロード・タイプ・フラグであるため、モジュールでハードコードされています。ただし、専用Exadataインフラストラクチャは、基礎となるインフラストラクチャを専用インフラストラクチャまたは共有に設定するフラグです。この区別は、コストとパフォーマンスの両方に影響します。

また、Terraformでは、このオプションが有効になっている場合、ライセンス・モデルをnullに設定する必要があるという結果もあります。「専用Exadataインフラストラクチャ」が選択されている場合、プレビュー・ライセンス・オプションを非表示にして、この依存関係を設定します:

また、条件付きと同じブール・ロジックに基づいて、モジュールに渡されるこれらのパラメータを健全性チェックするように`main.tf`モジュールを設定することもできます。

この変数は、287-289行目に示すように、is_autonomous_dedicatedがtrueでない場合に表示されます。既存のVCNの選択時に同じロジックが使用され、Booleanがtrueを返す場合を除き、サブネットの選択が非表示になります。

スキーマで事前定義された変数グループを設定すると、ユーザー・ワークフローに含まれない変数を非表示にできます。このセクションには、スキーマに定義されていないvariables.tfファイル内のすべての変数が含まれているか、UIに分類されていない変数が表示されます。

この場合、テンプレートは、事前定義されている変数や変更すべきでない変数を非表示にしています。

スキーマ選択に基づく動的なTerraform生成

スキーマの相互作用に基づいてTerraformコードを動的に構築するために使用できる高度なカスタマイズの別の例を見てみましょう。この例では、フレキシブルOCIシェイプをInfrastructure-as-a-Service (IaaS)テンプレートの一部としてどのようにサポートできるかを見て、Terraformリソースの一部として特定のパラメータを含める必要がある場合があります。この例では、このOKE-airflow Oracle Quick Startを使用して、Apache AirflowをOKEに配備します。

テンプレート・アーキテクチャは、ノード・プールとAirflowコンテナのポッドがあるデプロイ済OKEクラスタを示しています。また、IaaSエッジ・ノードを要塞としてデプロイします。

OCIには、要塞とOKEノード・プール・ワーカーの両方について、基礎となるIaaSに複数のオプションがあります。第2世代のインフラストラクチャは、Intel X7ハードウェアに基づいており、OCPUおよびメモリーの静的構成を備えています。新しいインフラストラクチャは柔軟性があり、動的な数のOCPUとメモリー割当てをサポートします。コア・インスタンスのTerraformプロバイダ・ドキュメントには、これらのパラメータが表示されます。リソースのshape_configサブセクションには、柔軟なシェイプを選択する際に必要となるオプションの変数cpusおよびmemory_in_gbsがあります。

ノード・プール・シェイプを選択するために、この機能をスキーマ・オーバーレイに構築する方法を見てみましょう。まず、スキーマにoci:core:instanceshape:nameコンソール統合を使用する変数が必要です。

このシェイプにはコンパートメントに対する依存関係があるため、これは248-249行目に含まれています。デフォルトでは、メニューで自動的に選択されるシェイプが設定されます。これは、テナンシ内の選択したコンパートメントで使用可能なシェイプに基づいて動的に移入されます。

フレキシブル・シェイプを選択すると、次のことが起こります。

• OCPU変数の可視性を切り替えます。
• memory_in_gbs変数の表示を切り替えます。
• ノード・プールのシェイプ選択用のshape_configブロックを作成します。

最初の二つはかなり単純です。いくつかの追加のスキーマ・ロジックを使用して、これらの各パラメータの表示フラグを設定します。

「or」と「-eq」を使用して可視性がオンになります。これらの追加は、コンパレータ(-eq)のいずれか(または)がtrueを返す場合にtrueを返します(可視)。メニューで4つのフレックス・シェイプのいずれかが選択されている場合、このコマンドはtrueを返し、UIにOCPU変数を表示します。memory_in_gbsについても同様です。これらのパラメータは、スキーマでflex_ocpuおよびflex_gbsとして設定され、OKEクラスタ・モジュールに渡されます。

59-60行目では、これらのパラメータはモジュールに渡され、若干異なる変数名として設定されます。これにより、OKEノード・プールのプロバイダ・ドキュメントがミラー化されます。また、is_flex_shapeのブール値を渡しています。このブールでは、ノード・プールのシェイプがこの配列で一致する場合に、Terraform contains関数を使用してtrueを返します。このブール値は、OKEモジュールのローカル値で使用されます。trueの場合、そのローカル値はOCPUおよびメモリーに渡されたパラメータを返します。それ以外の場合は、nullを返します。

さらに、ノード・プール構成では、ローカル値によってトリガーされる動的Terraformコード・ブロックを使用してこの出力が使用されます。

行47から53は、その動的ブロックを定義します。ローカルが値を返すと、48行目で検出され、その後、Terraformの一部として50行目から51行目にコンテンツが作成されます。ローカルがNULL値を返した場合、48行目もNULLとしてトリガーされ、構成はレンダリングされません。この関数を使用すると、スキーマ・オーバーレイ内のシェイプを動的に選択して、モジュール・コード内の変数の包含または除外をトリガーできます。

まとめ

このブログ・シリーズが、OCIでOracle Resource Managerを試して、クラウド・デプロイメント・ワークフローを推進する動的なスタックを作成するよう促してくれることを願っています。これらのツールを使用すると、単純なポイント・アンド・クリック・インタフェースを介してエンド・ユーザーの複雑なスタック・デプロイメントを自動化する強力な方法が提供されます。

高度なTerraformに関する知識を高めることに興味がある場合は、Oracle Developerコミュニティ・サイトでTerraform 101シリーズをお薦めします。また、Yevgeniy Brikmanによる『Terraform: Up & Running、 2nd Edition』をお読みください。

今すぐOracle Cloud Infrastructureアカウントにサインアップし、Oracleクイック・スタートGitHubで利用可能な素晴らしいTerraformデプロイメントの一部をお試しください。