スコープ

デプロイ可能なアーキテクチャーのスコープを明確に定義することが重要です。これは、必要なすべてのリソースを含めることができるだけの包括的なものであると同時に、不要な複雑さを回避するために十分な重点を置く必要があるためです。

ベスト・プラクティスは、通常は 1 つの単位として一緒にデプロイされ、同様のアクセス権とアクセス権を必要とし、同じライフサイクルを持つインフラストラクチャー・リソースを組み込むことです。 例えば、 VPC landing zone デプロイ可能なアーキテクチャー について考えてみましょう。 このデプロイ可能なアーキテクチャーには、以下のインフラストラクチャー・リソースを含む、明確に定義されたスコープがあります。

これらのリソースは通常、1 つの単位として一緒にデプロイされ、同様のネットワーク管理権限とアクセス権を必要とし、同じライフサイクルを持ちます。つまり、以下のようになります。

• 関連付けられたサブネット、パブリック・ゲートウェイ、およびセキュリティー・グループを使用して新規 VPC がプロビジョンされた場合などに、一緒に作成されます。
• サブネット、パブリック・ゲートウェイ、およびセキュリティー・グループを更新する必要がある VPC のネットワーク構成に変更が加えられた場合などに、一緒に更新されます。
• VPC が廃止され、そのすべての関連リソース (サブネット、パブリック・ゲートウェイ、セキュリティー・グループなど) が削除された場合など、一緒に削除されます。

構成可能性

展開可能なアーキテクチャの基本原則は複合化可能性であり、複数の展開可能なアーキテクチャを積み重ねることで、より広範な展開可能なアーキテクチャを作り出すことができる。 このモジュラー・アプローチにより、自動化リソースの柔軟性と再利用性を最大限に高めることができます。

構成可能性を実現するには、デプロイ可能なアーキテクチャーを以下のように設計する必要があります。

• 出力値を通じて表示される情報量を最大化しながら、出力タイプを単純化します。 この手法により、デプロイ可能なアーキテクチャーの自動化を幅広いシナリオで再利用できるようになり、さまざまな自動化ソリューションの汎用性の高いビルディング・ブロックになります。

• リソース・グループ、 IBM® Key Protect for IBM Cloud® または Hyper Protect Crypto Services インスタンス、および IBM Cloud Secrets Manager インスタンスなど、既存のデプロイ済みリソースへのオプションの参照を許可します。 その後、ユーザーは既存のインスタンスを構成したり、既存のリソース・グループにデプロイしたりできるため、自動化の汎用性が向上します。 Secrets Manager のデプロイ可能なアーキテクチャー は、この原則の有効な例です。 ユーザーが既存の Secrets Manager インスタンス、リソース・グループ、および KMS 暗号鍵を再利用できるようにすることで、この自動化は高度な柔軟性と適応性を提供します。 例えば、以下の操作を行うことができます:

  • 既存の Secrets Manager インスタンスの ID を渡してそのインスタンスを構成し、既存のインスタンスにシークレット・グループを作成します。
  • Key Protect または Hyper Protect Crypto Servicesなどの既存の鍵管理システムと統合します。
  • 既存のリソース・グループにデプロイするか、カスタマイズ可能な命名規則を使用して新しいリソース・グループを作成します。

あるいは、このデプロイ可能なアーキテクチャーでは、新規 Secrets Manager インスタンス、新規リソース・グループ、およびその他のリソースを最初から作成して、スタンドアロン・ソリューションを提供することもできます。

コンポーザビリティを採用することで、展開可能なアーキテクチャは、他の展開可能なアーキテクチャと積み重ねることで、より複雑なソリューション・アーキテクチャに容易に統合することができる。 例えば、 Retrieval Augmented Generationパターンは、 Secrets Manager の展開可能なアーキテクチャを含む複数の展開可能なアーキテクチャをどのように組み合わせて複雑なソリューションを構築できるかを示している。 コンポーザビリティを念頭に置いて設計された展開可能なアーキテクチャは、こうした複雑なソリューションの基盤となる。

展開可能なアーキテクチャを積み重ねると、各メンバーの展開可能なアーキテクチャは独立した構成状態を維持し、個別の展開、更新、または展開解除が可能になる。 このモジュラー・アプローチにより、コスト、コンプライアンス、サポート、品質の保証を、含まれる展開可能なアーキテクチャから得ることができる一方、全体的なソリューションは、独自の説明とリファレンス・アーキテクチャにより、独自のバージョンを維持することができる。 詳しくは、 展開可能なアーキテクチャをスタックするとはどういうことか？

コンシューマビリティー

デプロイ可能なアーキテクチャーは、コンシューマビリティーを念頭に置いて設計する必要があります。これにより、ユーザーは理解してデプロイすることが容易になります。 これを実現するために、デプロイ可能なアーキテクチャーは、以下を含む包括的な文書を提供する必要があります。

前提条件

デプロイメントに必要なソフトウェア依存関係とインフラストラクチャー要件。

詳細な入力変数および出力値の説明

目的、データ型、およびデフォルト値が含まれます。

必要な最小限の権限

デプロイ可能なアーキテクチャーの自動化を実行するために必要な許可。

ダイアグラムおよびアーキテクチャー・マップ

デプロイ可能なアーキテクチャーのコンポーネントおよび関係のビジュアル表示。

簡素化された構成

導入と管理が容易です。

リソース要件の削減

導入可能なアーキテクチャーを最適化して、CPU とメモリーの所要量の削減など、ハードウェアとリソースの要件を最小限に抑え、より手ごろな価格で効率的なものにします。

効率的な導入

より迅速かつ簡単に開始できます。

デプロイ可能なアーキテクチャーを簡単に利用できるようにするもう 1 つの側面は、クイック・スタート・バリエーションを含む複数のバリエーションを提供することです。 デプロイ可能なアーキテクチャーのクイック・スタート・バージョンを提供する必要があります。これは、より安価で高速に実行できます。 例えば、 VPC landing zone 上の Red Hat OpenShift Container Platform の QuickStart バリエーション のデプロイ可能アーキテクチャーは、完全にカスタマイズ可能な仮想プライベート・クラウド (VPC) 環境を単一のリージョンに作成し、ワークロード用のセキュアな VPC に単一の Red Hat OpenShift クラスターを提供します。 このクイック・スタート・バリエーションは、デモンストレーションおよび開発の目的で設計されており、実行にかかるコストは 1 カ月当たり 400 ドル未満です。

対照的に、 Red Hat OpenShift VPC landing zone デプロイ可能アーキテクチャー上のコンテナー・プラットフォームは、 IBM Cloud Framework for Financial Services 参照アーキテクチャーに基づいて、{{site.data.keyword.redhat.month}} を作成し、セキュアになります。 また、管理 VPC サービス、ワークロード VPC サービス、管理 VPC とワークロード VPC の分離、高度なネットワーク・セキュリティー・アーキテクチャーの決定などの高度な機能も備えています。

コード品質

Linting とコード・フォーマット設定を活用します。 一貫性のあるコーディング・スタイルとフォーマット設定を適用して、コードの読み取りと保守を容易にします。 デプロイメント中の問題を防止するために、コード内のエラーおよび警告を検出します。 Terraform コードだけではなく、デプロイ可能なアーキテクチャー内のすべてのリソースに関連するツール (Bash スクリプト、 Python スクリプト、YAML ファイルと JSON ファイル、Golang など) を取り込むことを検討してください。

例：

• Terraform コードをフォーマットするには、 terraform_fmt を参照してください。
• go-fmt は、Go コードをフォーマット設定します。
• Python コードをフォーマットするには、 black を参照してください。
• isort: Python インポートをソートします。
• flake8。 Python コードでエラーおよび警告を確認します。
• shellcheck は、シェル・スクリプトにエラーおよび警告がないかどうかを検査します。
• golangci-lint で、Go コードにエラーおよび警告がないかどうかを確認します。

構成の検証

静的検証を使用して、デプロイ可能なアーキテクチャーの構文と構成を検査し、それが正しく一貫性のあるものであることを確認します。 デプロイ可能なアーキテクチャーの構成を検証して、デプロイメント中にエラーが発生しないようにします。 ここでも、Terraform コードだけでなく、デプロイ可能なアーキテクチャー内のすべてのリソースに関連するツール (Bash スクリプト、 Python スクリプト、YAML ファイルと JSON ファイル、Golang など) を組み込むことを検討してください。

例：

• Terraform 構成を検証するには、 terraform_validate を参照してください。
• checkov。Terraform コードにセキュリティーとコンプライアンスの問題がないかどうかを確認します。
• 「 tflint 」をクリックして、エラーおよび警告がないかを確認します。
• detect-secrets。コード内のシークレットを検出します。
• hadolint。 Docker ファイルでエラーおよび警告がないかどうかを確認します。
• helmlint Helm チャートでエラーおよび警告を確認します。

テスト

インフラストラクチャー・コードのテストに関しては、アプリケーション・コードの場合と同様に、純粋な単体テストはありません。 代わりに、テスト戦略には、インフラストラクチャーを実際の環境にデプロイし、それが機能することを検証してからアンデプロイすることが含まれます。

継続的統合

デプロイ可能なアーキテクチャーの信頼性、整合性、および保守容易性を確保するために、開発サイクルの早い段階で品質検査とテストが統合される、シフト・レフト・アプローチをお勧めします。 このアプローチは、エラーや欠陥を早期にキャッチするのに役立ち、ダウンストリームの問題の可能性を減らし、全体的な品質を向上させます。

このアプローチの一環として、以下の品質検査が推奨されます。

クライアント・サイドの品質管理

コードをコミットする前に開発者マシンで検査を実行するには、クライアント・サイドの Git commit hooks を使用する必要があります。 これには、コーディング標準、構文エラー、および機密データの検査が含まれます。 「コミット前」 などのツールを使用して、このプロセスを自動化できます。

CI プラクティス

継続的統合 (CI) のベスト・プラクティスに従う必要があります。 ソフトウェア・エンジニアリング製品の一般的な手法は、以下のようなデプロイ可能なアーキテクチャー開発に適用されます。

• タイムリーなレビューを促進し、マージの競合を削減するために、焦点を絞った小規模なプル・リクエスト (PR) を処理する。
• 長期間存続するフィーチャー・ブランチを防止し、マージの複雑さを軽減するために、定期的にコード変更をメイン・ブランチに統合します。
• コードの品質と一貫性を確保するために、自動化されたテストとコード・レビューを実装する。
• デプロイ可能なアーキテクチャーの構成と構文を継続的に検証して、正確さと一貫性を確保する。

CI パイプライン

これらのプラクティスを自動化するために CI パイプラインをセットアップする必要があります。これにより、デプロイ可能なアーキテクチャーでのすべてのコード変更が体系的にテストされ、検証されるようになります。 このパイプラインにより、デプロイ可能なアーキテクチャーが正しく一貫して機能し、エラーや障害が早期にキャッチされることが保証されます。