デプロイ可能アーキテクチャーの作成

アーキテクチャーの計画と設計の手順を実行し、作成するコンポーネントのタイプを決定した後、アーキテクチャーを実現する自動化コードの作成を開始できます。このトピックでは、モジュールで構成されるデプロイ可能なアーキテクチャーの作成について説明します。

デプロイ可能なアーキテクチャを作成するには、必要なファイルを定義し、リリースを作成する必要があります。 GitHub,その後、それをプライベートカタログにオンボードして、組織内外の他のユーザーと共有できるようにします。

デプロイ可能なアーキテクチャを作るには、いくつかの選択肢がある：

自分で構築する：以下の説明を使って、あなた自身のデプロイ可能なアーキテクチャをゼロから構築してください。
既存のコードを修正する：既存のアーキテクチャーからコードをダウンロードし、ニーズに合わせて修正し、変更した新しいデプロイ可能なアーキテクチャーを作成する。
スタックアーキテクチャ: カタログ内で既にこれらのアーキテクチャを使用できる場合は、プロジェクト内でデプロイ可能なアーキテクチャをスタックすることもできます。

デプロイ可能なアーキテクチャーの構造について説明します。

本書で説明するデプロイ可能なアーキテクチャーは、1 つ以上のモジュールで構成されています。デプロイ可能なアーキテクチャーは、ソース・リポジトリー内の以下のもので構成されます。

![デプロイアブル・アーキテクチャーの解剖学*](images/da-anatomy.png "の解剖学*テラフォームベースの" caption-side="bottom"}の解剖"){: caption="*テラフォームベースのデプロイアブル・アーキテクチャーの解剖学

Terraform コード: ソース・リポジトリーには Terraform ファイルが含まれています。これらのファイルは、必要なインフラストラクチャー (エンド状態) を宣言し、インフラストラクチャーを作成、更新、および削除するための実際の API 要求を実行する Terraform プロバイダーに依存します。使用される最も一般的なプロバイダーには、 IBM Cloud® Terraform プロバイダーと Helm/Kubernetes/Rest API プロバイダーがあります。
スクリプト (オプション): 存在しない可能性のある関数 (Bash/Python) または臨時操作タスク (Ansible) の停止ギャップとして使用されます。詳しくは、デプロイ可能なアーキテクチャー用のスクリプトの作成を参照してください。
自動化されたテスト: インフラストラクチャーのデプロイ、検証、および破棄に使用される検証テスト。例については、 sample-deployable-architectures サンプル・リポジトリーの tests ディレクトリーを参照してください。
資料: アーキテクチャー図と README ファイルをソース・リポジトリーに含める必要があります。
カタログ・マニフェスト・ファイル: デプロイ可能なアーキテクチャーを IBM Cloud カタログで公開する方法を定義します。これには、名前、説明、フィーチャーなどの一般的なカタログの詳細に加えて、基礎となる Terraform 構成を指すバリエーション定義、 IBM Cloud® Security and Compliance Centerを使用してカタログへのオンボーディング時に検証されるコンプライアンス要求、およびデプロイ可能なアーキテクチャーを実行するために必要な IAM 権限が含まれます。詳しくは、カタログ・マニフェストのローカル編集を参照してください。
バリエーション: デプロイ可能なアーキテクチャーには、さまざまな機能や複雑さが含まれる場合があります。例えば、シンプルで低コストのデプロイメント用に基本機能を持つクイック・スタート・バリエーションを作成し、実動で使用される、より複雑なアーキテクチャーを持つ標準バリエーションを作成することができます。これらの各バリエーションは、それ自体がデプロイ可能なアーキテクチャーであり、オンボードされ、カタログに一緒に表示されるように構成されています。これらのバリエーションは、異なる作業ディレクトリー内の同じリポジトリーをソースとしており、 ibm_catalog.json ファイルに定義されています。詳細については、バリエーションを作成するを参照してください。

依存関係の指定とアーキテクチャの拡張

実験

ディプロイメント可能なアーキテクチャが別のアーキテクチャに依存している場合、ディプロイメント可能なアーキテクチャをカタログにオンボードするときに、その依存関係に関する情報を含めることができます。また、さまざまなユースケースに対応するために、オプションのアーキテクチャを追加することもできる。その結果、ユーザーにとってカスタマイズ可能なソリューションとなる。詳細については、オンボーディング中にデプロイ可能なアーキテクチャを拡張するを参照してください。

また、オンボードする前に、デプロイ可能なアーキテクチャのカタログマニフェストファイルに、自分のアーキテクチャと一緒に含めたい他のアーキテクチャに関する情報を提供することもできます。

カタログマニフェストファイルの dependencies セクションを使用して、オプションおよび必須アーキテクチャでカスタマイズ可能なソリューションを作成します。カタログマニフェストファイルで dependency_version_2 が true に設定されていることを確認してください。カタログマニフェストファイルで依存関係を扱う従来の方法はまだサポートされています。 dependency_version_2 を false に設定すると、 install_type を extension に設定し、 dependencies セクションに依存関係についての情報を提供することができる。そうすれば、依存関係のリストにある各アーキテクチャは、あなた自身のものをデプロイする必要がある。詳細およびこれらの値の設定については、カタログ・マニフェストのローカル編集を参照してください。

デプロイ可能アーキテクチャーの作成

デプロイ可能なアーキテクチャーを作成する際に、以下のハイレベル・タスクを実行することが期待できます。

ソース・リポジトリーを作成し、コードを追加します。
ibm_catalog.json マニフェスト・ファイルを作成して、カタログ内にタイルを作成する準備をします。
リリースを作成します。
コードをレビューして検証することにより、プライベート・カタログにカタログ・タイルを作成するためにコードをオンボードします。
デプロイ可能なアーキテクチャーを共有または公開する場所を選択します。

デプロイ可能なアーキテクチャーを作成するための以下の手順では、パブリック・サンプル・リポジトリーを使用して例を示します。

ソース・リポジトリーの作成

組織で定義されている要件を使用して、デプロイ可能なアーキテクチャーのソース・コードを保持するために使用できる GitHub リポジトリーを作成します。リポジトリーの作成については、 GitHub の資料を参照してください。すでに使いたいリポジトリがある場合は、この手順を省略できます。ソースコードをホストするために別の組織を使用することもできます。 GitLab,しかし、この文書の目的上、 GitHub使用されている。

必要な Terraform ファイルの作成

以下のセクションでは、デプロイ可能アーキテクチャーのプライベート・カタログへのオンボーディングの一環として必要となる .tgz ファイルを作成するために、 GitHub ソース・リポジトリーに必要な基本 Terraform ファイルについて説明します。

`main.tf`

main.tf ファイルは、作成したいリソースをプロビジョンするコードを配置する場所です。モジュールは、 terraform-ibm-modules から呼び出すことも、外部モジュールまたはプロバイダー・リソースから直接呼び出すこともできます。

以下に例を示します。

`outputs.tf`

outputs.tf ファイルには、デプロイ可能なアーキテクチャーに組み込むことができる出力値が含まれています。

以下に例を示します。

`provider.tf`

provider.tf ファイルには、プロバイダー名、API キー、コードが予期する地域などのプロバイダー構成が含まれています。

以下に例を示します。

`README.md`

README ファイルには、要件、モジュール、リソース、必要なアクセス権限、入力、および出力の各セクションを含む、デプロイ可能なアーキテクチャーに関する背景情報および使用情報が含まれています。

ソース・リポジトリーが terraform-ibm-modules 組織内にある場合、ほとんどの README ファイルが生成されます。そのため、入力や出力などの情報を手動で追加することはありません。変数名と説明は、 variables.tf ファイルから README ファイルに生成されます。

以下に例を示します。

`variables.tf`

variables.tf ファイルには、デプロイ可能なアーキテクチャーの必須変数とオプション変数が含まれています。

以下に例を示します。

`version.tf`

version.tf ファイルには、デプロイ可能なアーキテクチャーを実行するために必要な Terraform のバージョンとプロバイダーのバージョンに関する情報が格納されます。

デプロイ可能なアーキテクチャーに必要な Terraform プロバイダーは、デプロイ可能なアーキテクチャーとの一貫性のある結果を確保するために、範囲を使用するのではなく、正確なバージョンにロックする必要があります。

以下に例を示します。

カタログ・マニフェスト・ファイルの作成

カタログ・マニフェストは、リポジトリーのルートにある ibm_catalog.json と呼ばれるファイルです。このファイルは、カタログ内にタイルを作成するために必要なメタデータを定義します。例えば、名前、説明、フィーチャー、基礎となる Terraform 構成を指すバリエーション定義、 Security and Compliance Centerを使用してオンボーディング時に検証されるコンプライアンス要求、アーキテクチャーをデプロイするために必要な IAM 権限などです。また、ユーザーがカタログからアーキテクチャーをデプロイしようとしたときにデフォルトで選択する構成も定義します。詳しくは、マニフェスト・ファイルへのカタログ詳細のマッピングを参照してください。

フルスタックと拡張タイプのバリエーションを示すサンプル・リポジトリーの例を確認してください。

以下の 2 つの異なる方法を使用して、カタログ・マニフェスト・ファイルを作成できます。

このファイルは、テンプレートを使用して最初から作成できます。

以下の基本サンプルを使用してソース・リポジトリーでオンボーディング・プロセスを開始し、コンソールでのオンボーディング中に変更を行った後にマニフェスト・ファイルをダウンロードして、更新されたファイルをソース・リポジトリーに追加することができます。

以下に、このオプションを開始するためにリポジトリーに追加して編集できる基本的なマニフェスト・ファイルを示します。

{
    "products": [
        {
            "flavors": [
                {
                    "architecture": {},
                    "compliance": {},
                    "install_type": "fullstack"
                }
            ],
            "label": "catalog-create-sample-da-0.0.1",
            "name": "catalog-create-sample-da-0.0.1",
            "offering_icon_url": "url",
            "product_kind": "solution",
            "provider_name": "Community",
            "short_description": "A simple deployable architecture.",
            "tags": [
                "dev_ops"
            ],
            "version": "0.0.1"
        }
    ]
}

次のステップ: デプロイ可能なアーキテクチャーをプライベート・カタログにオンボードする

ソース・リポジトリーに必要なファイルが含まれている Git リリースが作成されたので、デプロイ可能なアーキテクチャーの 1 つのバージョンと、それに含まれているすべてのバリエーションをオンボードできます。オンボーディングとは、カタログの詳細を確認し、 IBM Cloudでテスト・デプロイメントとコンプライアンス要求を検証することによって、プライベート・カタログにカタログ・タイルを作成するプロセスです。ステップバイステップのプロセスについては、デプロイ可能なアーキテクチャーのオンボーディングを参照してください。