作成するコンポーネントの種類を決定するにはどうすればよいですか?

モジュールを作るべきか、デプロイ可能なアーキテクチャーを作るべきか、デプロイ可能なアーキテクチャーを積み重ねるべきか、どのように判断するのか違いを比較し、以下のセクションのユース・ケースを評価して、決定に役立てましょう。

展開可能なアーキテクチャとモジュールの比較

以下の表に、デプロイ可能なアーキテクチャーのモジュールとタイプの主な違いの比較と簡単な要約を示します。

コンセプトの比較
メソッド	スコープ	結合 (coupling)	デプロイ可能	作成者
モジュールの作成	狭い	狭	いいえ	Developer
展開可能なアーキテクチャを作成する	中から広範囲	狭	ある	Developer
デプロイ可能なアーキテクチャーのスタック	ブロード	ルーズ	ある	すべてのユーザー

以下の表は、ユースケースに応じて、モジュール、デプロイ可能なアーキテクチャ、またはデプロイ可能なアーキテクチャをスタックして使用するかどうかを決定するのに役立ちます。

使用するコンポーネントの選択を助けてください
目的	推奨方法	注記
コーディングの自動化を加速	モジュールを使用する	モジュールは、再利用可能でキュレーションされた自動化を提供して、デプロイ可能なアーキテクチャーの開発者がより迅速にコーディングできるようにします。モジュールは開発者用であり、コンシューマー用ではありません。
クラウドがセキュアでコンプライアンスに準拠していることを確認します。	展開可能なアーキテクチャを使用する	デプロイ可能なアーキテクチャーは、アーキテクチャーのセキュリティーとコンプライアンスを強化します。デプロイ可能なアーキテクチャーのスコープが小さすぎる場合、準拠性を強制することはできません。例えば、仮想サーバー・インスタンスのみをデプロイするデプロイ可能なアーキテクチャーでは、ネットワーク・セキュリティーを確保できません。
ガードレールを使用してユーザーに選択権を与える	展開可能なアーキテクチャを積み重ねる	デプロイ可能なアーキテクチャを積み重ねることで、デプロイ可能なアーキテクチャを入れ替えたり、デプロイ可能なアーキテクチャを追加したりすることができ、ユーザーにより多くの選択肢を与えることができる。デプロイ可能なアーキテクチャーはセキュリティーとコンプライアンスを適用するため、スタッキングはソリューション全体のコンプライアンスを維持するのに役立ちます。展開可能なアーキテクチャを積み重ねることは、どのデータベースを使うかを選択するような場合に優れたアプローチである。
ユーザー作成のソリューションまたはアーキテクチャー	展開可能なアーキテクチャを積み重ねる	配置可能なアーキテクチャを積み重ねることで、ユーザーは、安全でコンプライアンスに準拠した配置可能なアーキテクチャで構成された、安全な独自の繰り返し可能なパターンを作成し、公開することができる。
分離されたアーキテクチャー・コンポーネント	展開可能なアーキテクチャを積み重ねる	デプロイ可能なアーキテクチャは、独立して開発し、バージョン管理することができるが、デプロイのために積み重ねることができる。
ユーザー・エクスペリエンスの簡素化	展開可能なアーキテクチャを使用する	デプロイ可能なアーキテクチャーは、大規模または複雑なアーキテクチャーの場合でも、ユーザーに入力の小さなリストまたは単純なリストを提供することができます。デプロイ可能なアーキテクチャーは、簡単に理解してデプロイできます。これに対して、デプロイ可能なアーキテクチャーのスタッキングは、デプロイ可能なアーキテクチャーが公開されているため、もう少し複雑になります。

IBM Cloud プロジェクトは、リソースがカタログからデプロイ可能なアーキテクチャーを介してデプロイされ、組織のセキュリティーおよびコンプライアンスのガードレール内で動作することを保証します。また、これらのリソースが最新の状態に保たれ、ドリフトが行われないようにします。

デプロイ可能なアーキテクチャの依存関係

依存関係は、1 つのデプロイ可能なアーキテクチャによってプロビジョニングされたリソースが別のアーキテクチャによって必要とされる場合に発生します。つまり、次の図に示すように、1 つのデプロイ可能なアーキテクチャによってプロビジョニングされるリソースは、別のアーキテクチャのデプロイ中に使用されます。

依存関係を持つデプロイ可能なアーキテクチャの視覚的な表現。デプロイ可能なアーキテクチャ A はリソースを出力し、それがデプロイ可能なアーキテクチャ B の入力として使用されます。 — 展開可能なアーキテクチャの依存関係

依存関係を扱う1つの方法は、デプロイ可能なアーキテクチャをスタックし、プロジェクト内でそれらの間の参照を追加することである。たとえば VSI on VPC landing zone デプロイ可能なアーキテクチャには、 Red Hat OpenShift Container Platform on VPC landing zone デプロイ可能なアーキテクチャを拡張するバリエーションが含まれる。これらのアーキテクチャをプロジェクト内で積み重ねることを検討してください。このアプローチは、前提条件となるアーキテクチャがまだ展開されていない場合に適しています。また、デプロイ可能なアーキテクチャをスタックするためにコードを編集する必要もありません。

多くのデプロイ可能なアーキテクチャはスタンドアロンであり、他のアーキテクチャの拡張ではありませんが、いくつかのデプロイ可能なアーキテクチャを拡張することを選択できます。建築カタログ詳細ページのセクション。オプションを選択してくださいこのアーキテクチャをどのように構築しますか? メニュー。

ただし、すでに展開している場合はRed Hat OpenShift Container Platform で VSI をデプロイする必要がある場合、VSI に必要なリソースはすでにプロビジョニングされています。展開する必要はありませんRed Hat OpenShift再びコンテナプラットフォームアーキテクチャ。 VSIアーキテクチャは、 Red Hat OpenShiftコンテナプラットフォームでは、VSIを展開することができ、アーキテクチャはRed Hat OpenShift必要に応じてコンテナプラットフォーム。

オプションでスワップ可能な展開アーキテクチャ

デプロイ可能なアーキテクチャをプライベート・カタログにオンボードすると、他のアーキテクチャとスタックして拡張できる。そうすることで、よりカスタマイズ可能なソリューションをユーザーに提供することができます。

なぜオンボーディングでスタックするのか？

オンボーディング時のアーキテクチャの積み重ねは、プロジェクトでのアーキテクチャの積み重ねに似ている。アーキテクチャーを搭載する際、必要なアーキテクチャーを積み重ねることで、依存関係を含めることができる。しかし、プロジェクト内でのアーキテクチャのスタックとは異なり、オンボーディング時のアーキテクチャのスタックには以下の機能が含まれます：

さまざまなユースケースに合わせたオプションのアーキテクチャを追加できる。
ユーザーが選択できるスワップ可能なアーキテクチャを追加できる。

オプション・アーキテクチャ

もしかしたら、あなたのアーキテクチャは他の展開可能なアーキテクチャとうまく機能するかもしれないが、依存関係を満たしたりコンプライアンスを満足させたりするためには必要ないかもしれない。配備可能なアーキテクチャをオプションとして追加し、ユーザーがプロジェクトに配備可能なアーキテクチャを追加するときに、それを含めるかどうかを選択できます。例えば、モニタリング・アーキテクチャは有用かもしれないが、必須ではない。

スワップ可能なアーキテクチャ

オンボーディング中に自社でスタックしたアーキテクチャは、他のアーキテクチャと交換することができる。スワップ可能なアーキテクチャは、同じ機能を提供する複数のオプションの中からユーザーに選択肢を与える。例えば、異なるデータベースを作成する2つのデプロイ可能なアーキテクチャを含めることができ、ユーザーはアーキテクチャで使用するデータベースオプションを決めることができます。

詳細については、「オンボーディング中にデプロイ可能なアーキテクチャを拡張する」を参照してください。

展開可能なアーキテクチャをプライベート・カタログに搭載する際に、オプションでスワップ可能なアーキテクチャを追加することができる。現在、プロジェクト内で配置可能なアーキテクチャを積み重ねても、オプションのアーキテクチャやスワップ可能なアーキテクチャはサポートされません。

Terraform と Ansible の比較

IBM Cloudでは、デプロイ可能なアーキテクチャーは、Terraform を使用して、デプロイ可能なアーキテクチャー (インターフェース) の入出力を宣言する必要があります。これは、 Ansible に機械可読インターフェース定義がないためです。そうでない場合、デプロイ可能アーキテクチャーの作成者は、 Ansible の事前スクリプトまたは事後スクリプトと Terraform を任意に組み合わせて使用して、デプロイ可能アーキテクチャーの作業を実行することができます。では、開発者は、どのテクノロジーを何に使用するかをどのように決定しますか?

コンフィギュレーション言語の比較
最初の列は、TerraformとAnsibleを比較するためのカテゴリである。 2 番目の列には、Terraform が列 1 のセット・カテゴリーにどのように関連しているかについての情報が示され、3 番目の列には、 Ansible が列 1 のセット・カテゴリーにどのように関連しているかについての情報が示されています。
	Terraform	Ansible
言語	宣言	手続き
構文	HCL (JSON に類似)	YAML (および他のスクリプトへのコールアウト)
デフォルトのアプローチ	可変インフラストラクチャー	不変のインフラ
フォーカス	インフラストラクチャー	構成
ドリフト	必要な状態との比較	べき等のタスク

Terraform はインフラストラクチャーの作成と管理に優れていますが、 Ansible はそのインフラストラクチャー上で稼働するソフトウェアとオペレーティング・システムの構成に優れています。 Ansible は手続き型であるため、一回限りの操作をスクリプト化することもできます。 Ansibleでは、バックアップからのリストアなどの保守作業が簡単です。

使用する設定言語の選択を助けてください
目的	推奨構成言語	注記
クラウド・インフラストラクチャーまたはサービスのデプロイ	Terraform	Terraform は、このユース・ケースを対象としており、変化するインフラストラクチャーの処理に優れています。 IBM Cloud は、セキュアで準拠したインフラストラクチャー・パターンを加速するために、Terraform モジュールとサポートされるデプロイ可能なアーキテクチャーを提供します。 Terraform 状態モデルを使用すると、開発者は変更をプレビューできます。これらの変更は、コンプライアンスについてスキャンすることができます。
ソフトウェアのインストールまたは構成	Ansible	事前作成されたコンテナー・イメージまたは仮想マシン・イメージがユース・ケースに適していない場合は、 Ansible を使用してソフトウェアのインストールと構成を処理することをお勧めします。 Ansible には、構成の編集、パッケージ管理、プロセスの再始動などの自動化操作に対する広範なサポートが用意されています。一般的に使用される何千ものソフトウェア・パッケージの構成を容易にするために、 Ansible モジュールおよびプレイブックの大規模なライブラリーが用意されています。
CCDB 統合	Ansible	CDB のようなオンプレミス・サービスへの動的呼び出しは、Terraform または Ansible で行うことができますが、プロシージャー型言語またはスクリプト言語で行う方が簡単です。
入力の検証	Terraform または Ansible	Terraform は、入力の妥当性検査を実行する能力が制限されていますが、宣言であり、ユーザー・インターフェースで使用できます。 Ansible は、デプロイ可能なアーキテクチャーへの入力がリモート・サービスに対して検査される動的入力検証を実行する機能を追加します。
Day 2 の保守アクション	Ansible	Day 2 の保守は、通常は手続き上の性質を持ち、 Ansibleで実行するのが最適です。例としては、手動によるバックアップ、リストア、鍵のローテーションなどがあります。
ドリフト管理	Terraform Ansible	Terraform を使用して、ドリフトが発生したかどうか、およびそのドリフトが何であるかを判別できます。これは、ドリフトの管理方法を決定するのに役立ちます。ドリフト情報は、自動化に変更を加えることができることを示している可能性があるため、強力です。 Ansible でドリフトを検出できません。しかし、べき等の ansible スクリプトを定期的に再適用することで、ドリフトを防ぐことができます。

デプロイ可能アーキテクチャーに事前スクリプトまたは事後スクリプトを組み込む方法について詳しくは、デプロイ可能アーキテクチャー用のスクリプトの作成を参照してください。

次のステップ: 公開先の決定

アーキテクチャーを計画し、作成するコンポーネントのタイプを決定したら、作成したソリューションを他のユーザーが利用できるように、ソリューションを共有または公開する予定の場所を検討する必要があります。共有または公開する予定の場所によっては、完了する必要がある要件または承認のレベルが異なる場合があります。