プライベートカタログへのデプロイ可能なアーキテクチャのオンボーディング
デプロイ可能なアーキテクチャを組織内の他のメンバーと共有する準備が整ったら、プライベートカタログに追加できます。 さらに、オンボーディングフローを使用してアーキテクチャを検証することもできます。
デプロイ可能なアーキテクチャをプライベートカタログに登録するには、ソースコードをカタログに追加し、デプロイ可能なアーキテクチャの詳細を編集した後、検証を行う必要があります。 次に、展開可能なアーキテクチャのコスト見積もりとコンプライアンス情報を確認します。 完了したら、デプロイ可能なアーキテクチャを共有したり、 IBM Cloud で公開したりできます。
開始前に
デプロイ可能なアーキテクチャを導入する前に、以下の前提条件を必ず満たしてください。
- 従量課金 (PAYG) またはサブスクリプションのアカウントを使用していることを確認してください。 詳しくは、アカウント・タイプの表示を参照してください。
- プライベートカタログおよびデプロイ可能なアーキテクチャを操作するために必要なアクセス権限があることを確認してください。
- IBM Cloud Schematics サービスにおけるマネージャーの役割
- カタログ管理サービスに対するエディター役割
- アカウント内のすべてのリソース・グループに対するビューアー役割
- SecretsReader Secrets Manager サービス上で、 Secrets Manager のインスタンスに安全な値を保存する予定がある場合は、その役割を設定してください
- Workload Protection サービスにおけるリーダーの役割
- カスタマイズされたデプロイ可能なアーキテクチャにおいて特定のリソースに必要なその他の役割
- プライベート・カタログを作成します。
- デプロイ可能なアーキテクチャのソースコードが、 GitHub または GitLab リポジトリに保存されていることを確認してください。 ソースコードをリポジトリに追加する方法については、 「ソースコードリポジトリの設定」 を参照してください。
仕組みを確認したいが、すぐに使えるデプロイ可能なアーキテクチャが用意されていない? 当社のサンプルデプロイ可能アーキテクチャをご利用ください。
ソースコードのパッケージング
デプロイ可能なアーキテクチャをプライベートカタログに登録するために必要な .tgz ファイルを作成するには、ソースコードのリリースバージョンを作成する必要があります。 リリースの作成に関するヘルプについては、 「リポジトリでのリリースの管理」 を参照してください。
プライベートなソースコードリポジトリを使用している場合は、 Git の個人用アクセストークンまたはシークレットが Secrets Manager.
プライベートカタログへのデプロイ可能なアーキテクチャの追加
デプロイ可能なアーキテクチャをプライベートカタログに追加するには、次の手順を実行します。
-
IBM Cloud コンソールで、コンソールの 「管理 」>「 カタログ 」>「 プライベートカタログ 」ページに移動します。
-
商品を追加したいプライベートカタログを選択してください。 カタログの詳細ページが開きます。
-
製品の追加をクリックします。 サイド・パネルが開きます。
-
製品タイプとして 「デプロイ可能なアーキテクチャ」 を選択してください。
-
配信方法として テラーフォーム または スタックを選択する。
-
ソースコードが配置されているリポジトリの種類を選択してください。
ソースコードがプライベートリポジトリにある場合、 Git の個人用アクセス トークンまたはシークレット Secrets Manager を使用して認証する必要があります。
-
ソースコードへのリンクを 「ソース URL 」フィールドに追加してください。 それは.に似ているはずです
https://github.com/IBM-Cloud/terraform-sample/archive/refs/tags/v1.1.0.tar.gz。デプロイ可能なアーキテクチャをテスト目的でオンボーディングする場合、
.yaml.tgzファイルを用意する必要はありません。 アーキテクチャのルートレベルへのリンクを提供できます。 -
バリエーションを選択してください。
バリエーションとは、既存の展開可能アーキテクチャに異なる機能や複雑性を適用するタイプの展開可能アーキテクチャである。 例えば、デプロイ可能なアーキテクチャにはクイックスタートのバリエーションがあり、内部テスト向けのシンプルで低コストなデプロイを実現する基本機能を備えている場合があります。 また、本番環境での使用に耐える、もう少し複雑な標準バリエーションを用意しているかもしれません。
-
ソフトウェアのバージョンを、メジャーバージョン、マイナーバージョン、リビジョンの順で入力してください。 例えば、
1.0.0です。 通常、このバージョンはリリーススナップショットのバージョン番号と一致します。 -
カタログ内でデプロイ可能なアーキテクチャをグループ化したいカテゴリを選択してください。
-
製品の追加をクリックします。 製品の概要ページが表示されます。
カタログエントリの編集
デプロイ可能なアーキテクチャをプライベートカタログに正常にオンボードした後、ユーザーがそのアーキテクチャを使用しようと試みた際に表示される情報を指定する必要があります。 情報には、製品の説明、ドキュメントへのリンク、および製品が容易に見つけられるようにするキーワードが含まれます。
-
コンソールの 「管理 」>「 カタログ 」>「 プライベートカタログ 」ページに移動します。
-
商品を追加したプライベートカタログを選択してください。 カタログの詳細ページが開きます。
-
以前にオンボーディングした製品を選択してください。
-
カタログでの掲載方法を編集する。
- カタログエントリの詳細セクションで、 「編集」 をクリックします。
- デプロイ可能なアーキテクチャとともにインポートされた情報を確認し、必要に応じて編集を行ってください。
- カタログエントリのプレビューを確認し、入力内容が期待通りに表示されていることを確認してください。
- 選択が終わったら、 保存をクリックします。
-
製品の 「About 」ページを編集してください。 ユーザーがカタログから製品を選択すると、製品の詳細や利用可能な機能について確認できる 「製品について 」セクションが表示されます。
- アクション ドロップダウンで、商品ページの編集を選択します。
- 製品の説明を入力してください。その説明には、製品がユーザーにもたらす価値と利点を明記してください。
- 特定の機能情報を追加するには、 機能 > 機能の追加をクリックします。
- 製品レベルの特徴を追加し、そのプロセス、能力、および結果を説明する。 ユーザーは製品ページの冒頭で、バージョンやアーキテクチャの差異に関係なく製品全体に適用される高レベルの製品機能を確認できます。 たとえば、製品が仮想プライベートクラウドを作成する場合、機能タイトルとして「仮想プライベートクラウドの作成」、機能
Creates Virtual Private Clouds``Virtual Private Clouds are created for you with the necessary underlying network components.説明として「仮想プライベートクラウドの作成」を追加できます。 特定のバリエーションやバージョン向けの機能を追加するには、 ハイライトを追加 することで実現できます。 - 更新 をクリックします。
コンソールを介した詳細の指定
ユーザーは、製品のカタログ登録情報の一部として定義したバージョンレベルの情報を確認できます。 このフローの一部として提供される情報は、関連する個々のコンポーネントの機能をユーザーが理解するのに役立ちます。
選択内容を次のリリースに引き継ぐには、マニフェストファイルを生成できます。 マニフェストファイルは、カタログエントリの信頼 ibm_catalog.json できる情報源です。 そこには、製品に関するすべての情報と、お客様が行った選択内容が含まれています。 ファイルを生成した後、ソースコードリポジトリのルートレベルに追加する必要があります。 コードで作業することを好む場合、以下のセクションはマニフェストファイルを通じて直接設定できます。 ファイルの構成方法の詳細については、
「マニフェストファイルのローカル編集」 を参照してください。
詳細に入る
デプロイ可能なアーキテクチャをプライベートカタログに追加した後、コンソールのステップバイステップのガイドを使用して、製品の一般情報を更新できます。 コンソールページにアクセスするには、以下の手順を実行してください。
- コンソールの 「管理」>「カタログ」>「プライベートカタログ 」ページに移動します。
- 商品を追加したプライベートカタログを選択してください。 カタログの詳細ページが開きます。
- 以前にオンボーディングした製品を選択してください。
- [バージョン] タブで、情報を提供したい製品のバージョンを選択してください。
- 以下の情報をガイドとして、デプロイ可能なアーキテクチャの詳細を設定してください。
バージョン詳細の設定
「 構成バージョン 」タブでは、アーキテクチャの特定バージョンに関する情報を確認および更新できます。 デプロイメントの詳細を設定し、必要なIAMアクセスを定義し、ユーザーに通知したい変更内容を明記します。
デプロイ可能なアーキテクチャを拡張したい場合は、他のアーキテクチャと積み重ねることで実現できます。 アーキテクチャに必要な依存関係を含めることができます。また、特定のユースケース向けにソリューションを拡張するのに役立つオプションのアーキテクチャも追加できます。 詳細については、 「オンボーディング時のデプロイ可能なアーキテクチャの拡張」 を参照してください。
デプロイ可能なアーキテクチャで特定のTerraformランタイムバージョンが必要な場合、デフォルトのバージョンを上書きできます。 ソースコードリポジトリ内で入力変数として TF_VERSION を含めた場合、カタログエントリを作成した際に自動的に更新されるはずです。
入力変数とは、ユーザーが製品を使用する際に指定するパラメータのことです。 ソースコードと共にインポートされた入力変数と出力変数を確認・変更できます。また、このステップの一環として、デプロイ可能なアーキテクチャに変数を追加することも可能です。 変数を追加する際、その変数が必須か、表示されるか、または提供される形式を更新できます。
製品の新バージョンをリリースする際、ユーザーが新バージョンを使い始める前に通知したい変更点があるかもしれません。 情報を3つのカテゴリに分類できます——互換性のない変更、新機能、および一般的な更新です。
- 互換性を損なう変更点 :以前のバージョンを使用しているユーザーに混乱を招く可能性のある、新バージョンのコード変更点を詳細に記述してください。
- 新機能 :ユーザーが活用したいと思う可能性のある、新バージョンで提供される新機能を強調表示します。
- 更新内容 :新バージョンに対して行われた一般的な更新内容を記述してください。 例えば、バグ修正や既存機能の改善など。
前書きおよび後書きを含む
デプロイ可能なアーキテクチャに対して、検証、デプロイ、アンデプロイの前後で、プレスクリプトまたはポストスクリプトを実行できます。 スクリプトは、カタログマニフェストファイルで指定されたデプロイ可能なアーキテクチャの特定バージョンに設定され、プロジェクトを通じて実行および検証されなければなりません。
スクリプトは提供物に対して任意ですが、使用される場合はリポジトリ内の「.」 scripts という名前のディレクトリに配置する必要があります。 スクリプトファイル自体は、以下の命名規則に従わなければ <action>-<stage>-ansible-playbook.yaml なりません。 オプションには、 validate、、 action``deploy および が undeploy 含まれます。 オプションには、および stage``pre が含まれます post。 現時点では、プレイブック形式のAnsibleスクリプトのみがサポートされています。
すべてのスクリプトは、複数回実行しても失敗しないことが必須である。 例えば、デプロイ前またはデプロイ後のスクリプトは、複数回実行されても正しく動作しなければならない。 デプロイ後のスクリプトはカタログ管理データベースにリソースを追加する場合があり、複数回実行された場合に重複リソースが追加されないよう注意が必要です。
詳細情報(例を含む)については、 「デプロイ可能なアーキテクチャ向けスクリプトの作成 」を参照してください。
展開可能なアーキテクチャの詳細を追加する
クラウド上でデプロイ可能なアーキテクチャを他のユーザーが利用できるようにする場合、以下の情報を提供する必要があります:
- デプロイ可能なアーキテクチャ内のコンポーネントがどのように連携するかを詳細に示すアーキテクチャ図。
- ユーザーが自身のニーズに最適なアーキテクチャのバージョンやバリエーションを見極めるのに役立つ、主な特徴や利点。
使用条件の追加
ユーザーが IBM Cloud サービス契約以外の使用許諾契約書に同意する必要がある場合は、契約ごとに URL を指定します。
README ファイルの編集
展開可能なアーキテクチャのインストール手順を、readmeファイルに文書化してください。
バージョンの検証
検証の対象を選択してください。 製品が検証されると、リソースがデプロイされる。 スタンドアロンでデプロイ可能なアーキテクチャの場合、ターゲットは現在のアカウント内の Schematics ワークスペースか、特定のプロジェクトのいずれかになります。 デプロイ可能なアーキテクチャスタックには、プロジェクトを使用する必要があります。 選択したオプションによっては、追加の設定情報が必要になる場合があります。 ターゲットの設定が完了したら、アーキテクチャがターゲットに正常にデプロイするために必要な入力変数と出力変数の値を指定する必要があります。 変数の設定が完了したら、バージョンを検証できます。
アカウント内のリソースは、セキュリティとコンプライアンスの管理セクションでコンプライアンス評価を実行するまでクリーンアップしないでください。
バージョンがCRAスキャンにより検証に失敗した場合、アカウントの管理者は失敗をオーバーライドしてデプロイを実行することを選択できます。 その他の理由で検証が失敗した場合、オファリングを公開する前に発見された問題を修正することを強く推奨します。
コストの見直し
アーキテクチャの展開に関連するコストを完全に理解していることを確認してください。 見積もり費用を生成する前に、バージョンを検証する必要があります。
準拠性の管理
組織内でデプロイ可能なアーキテクチャを他者に提供する場合、デフォルトのインストールによってアーキテクチャが満たす特定のコンプライアンス制御を指定できます。 規制管理への準拠状況は、 IBM Cloud® Security and Compliance Center Workload Protection によって評価されます。
- コントロールの追加 をクリックします。
- Workload Protection のインスタンスとポリシーを選択してください。 事前定義されたポリシーを選択するか、 Workload Protection にアクセスして独自のポリシーを作成することができます。
- 展開可能なアーキテクチャがポリシーの全制御要件を満たすか、または制御要件の一部を満たすことができるかを指定してください。
- アーキテクチャが制御項目のサブセットしか満たせない場合、満たせる制御項目を選択し、それらを追加しなければならない。
- Workload Protection を使用して、特定した制御への準拠を確認してください。 Workload Protection はインベントリを使用して準拠状況を追跡します。 在庫結果は毎日更新されます。 アーキテクチャが生成するリソースを展開し、インベントリ結果の更新を待ちます。 詳細については、「 是正措置の確認と優先順位付け 」をご覧ください。
- カタログ UI の 「コンプライアンス管理 」タブで、 「結果を追加」 をクリックします。
- インスタンスを選択し、 [適用] をクリックして最新のインベントリ結果を適用します。
要件の確認
ウォークスルーを完了したら、選択内容を確認し、製品をカタログに公開する準備が整っていることを確認してください。 準備ができたら、 共有する準備が整ったをクリックします。
マニフェストのダウンロード
コンソールを通じて製品構成に変更を加えた場合は、変更内容が製品の将来のリリースに確実に反映されるよう、マニフェストファイルを生成してダウンロードすることを推奨します。
マニフェストをダウンロードするには、以下の手順を実行できます。
- コンソールの 「管理 」>「 カタログ 」>「 プライベートカタログ 」ページに移動します。
- 以前にオンボーディングされた製品を選択してください。 詳細ページが開きます。
- [バージョン ]タブで、マニフェストを生成したいバージョンを選択します。
- [アクション ] ドロップダウンメニューから、[ マニフェストを生成 ] を選択します。
- ファイルをソースコードリポジトリのルートフォルダに.
ibm_catalog.jsonとして追加してください。
カタログ設定のダウンロード
プロジェクトから積み重ね可能なデプロイ可能なアーキテクチャを オンボーディングする場合、マニフェストファイルに加えて追加のファイルが生成されます。 コンソールを使用してカタログ構成を更新した場合、変更内容を次のリリースに引き継ぐために、ファイルをダウンロードしてソースコードリポジトリに追加することがベストプラクティスです。
- コンソールの 「管理 」>「 カタログ 」>「 プライベートカタログ 」ページに移動します。
- 以前にオンボーディングされた製品を選択してください。 詳細ページが開きます。
- [バージョン ]タブで、マニフェストを生成したいバージョンを選択します。
- [アクション ] ドロップダウンメニューから、[ マニフェストを生成 ] を選択します。
- ファイルをソースコードリポジトリのルートフォルダに追加してください。
バリエーションの追加
ベースとなるデプロイ可能なアーキテクチャの機能を基盤として構築される、新たなバージョンのアーキテクチャとして、さらなるバリエーションを追加できます。 ソースリポジトリ内の別々の作業ディレクトリで 複数のバリエーションを作成し、マニフェストファイル ibm_catalog.json の配列 flavors でそれらを指定した場合、各バリエーションを個別にオンボードする必要があります。
この時点で、最初のバリエーションは既にオンボーディング済みです。 次に、次のバリエーションをオンボードするための デプロイ可能なアーキテクチャの追加 から再開できます。 次のバリエーションを導入する際のポイントをいくつかご紹介します:
- リポジトリリリースのソース URL は、そのリリース内のすべてのバリエーションで共通であり、同じバージョン番号でインポートされるべきです。 製品名とバージョン番号は、バリエーションを相互に関連付ける方法であり、その結果として同じカタログタイル上にオプションとして表示されます。
- デプロイ可能なアーキテクチャの詳細を追加するページでは、ステップ3にハイライトの追加が含まれます。 これらはマニフェスト
ibm_catalog.jsonファイル内の機能として知られています。 マニフェストに既に追加済みかもしれませんが、こちらで確認できます。 そうでない場合は、ハイライトを追加してください。 これらは、この特定のアーキテクチャの短い能力、プロセス、容量、またはその他の特徴であるべきです。 すべてのバリエーションで同じハイライト「名前」を使用します。 説明文こそが差異があるべき箇所である。 これにより、ユーザーはカタログ詳細ページ上のテキストのハイライト表示を利用して、各アーキテクチャの違いを評価できるようになります。
次のステップ:共有と公開
デプロイ可能なアーキテクチャがプライベートカタログに追加され、詳細が設定されたので、組織内の他のメンバーと製品を共有する準備が整いました。 共有に関するヘルプについては、 「製品の共有」 をご覧ください。
デプロイ可能なアーキテクチャを IBM Cloud カタログに公開したい場合は、Partner Centerを使用して承認を得て公開することで、構築したソリューションをすべてのユーザーが利用できるようになります。 詳細については、 「デプロイ可能なアーキテクチャの公開」 を参照してください。