プロジェクトを編成および管理するためのベスト・プラクティス
これらのベストプラクティスは、 IBM Cloud® で プロジェクトをリソースとインフラストラクチャーをコード・デプロイメントとして定義および管理する成果物の集合。 成功させ、安全に管理するための基本的なビルディングブロックを提供します。 プロジェクトは、コード・ベースのデプロイメントを最適に管理すると同時に、複数のアカウントにわたってコンプライアンスを維持し、チーム・メンバーとコラボレーションする方法として、規制対象企業にとって有益です。
1 次プロジェクト・アカウントの作成
IBM Cloud プロジェクトの主な利点は、Infrastructure as Code デプロイメントを一元的に管理およびコラボレーションできることです。 エンタープライズを使用している場合、すべてのプロジェクトを保管するための 1 次アカウントまたはホーム・アカウントを設定すると、1 つのロケーションでプロジェクトを管理および追跡するのに役立ちます。
1 次アカウントを設定することの有用性は、エンタープライズ構造によって異なります。 1 つのアカウントでプロジェクトを作成し、他のアカウントにリソースをデプロイすることができます。 ユーザーは、現在ログインしているアカウント内にあるプロジェクトのみを表示できます。 また、複数のプロジェクトのレポートは、同じアカウント内のプロジェクトに対してのみ生成できます。 これは、企業内のすべてのプロジェクトまたは類似の基幹業務を持つすべてのプロジェクトに対して共通のホーム・アカウントを確立するというもう 1 つの便利な利点です。 プロジェクトを 1 次アカウントに保持し、環境 (開発、テスト、および実動) ごとに別々のアカウントにデプロイすることで、エンタープライズ管理を簡素化します。
すべてのユーザーがアカウント内の目的とプロジェクトを識別しやすくするために、アカウントに人間が理解できる名前を付けます。 例えば、 Front-end UI team や Back-end API team などです。
認証方式の定義
デプロイ可能なアーキテクチャーを構成するときには、認証方式を追加する必要があります。 認証方法は、リソースが配置されるターゲットアカウントを識別し、配置を承認する。 トラステッド・プロファイルまたは既存のシークレットを使用して認証することを選択できます。
トラステッド・プロファイルの使用
一部のサービスでは、信頼できるプロファイルを使用してアーキテクチャーを完全に構成およびデプロイすることができません。 詳しくは、 プロジェクトの既知の問題と制限 を参照してください。
トラステッド・プロファイルを使用して、自分のアカウントまたは別のアカウントにアーキテクチャーをデプロイすることができます。 組織によっては、アーキテクチャーをデプロイする際に、信頼できるプロファイルを使用し、複数のアカウントの管理者と調整することにより、別のアカウントへのアクセスが必要になる場合があります。 別のアカウントの IBM Cloud プロジェクト・サービスが、アーキテクチャーをデプロイするために自分のアカウントにアクセスする必要がある場合は、信頼できるプロファイルとサービス ID を使用して、アカウント内のデプロイメントを許可します。 プロジェクトのトラステッド・プロファイルの作成について詳しくは、 Using trusted profiles to authorize a project to deploy an architecture を参照してください。
IBM Cloud® Secrets Manager の使用
Infrastructure as Code（ IaC ）をデプロイする場合、APIキー、SSHキー、SSL証明書など、インフラを構成するために必要なシークレットが存在することが多い。 このような場合、これらのシークレットを Secrets Manager インスタンスに格納することをお勧めします。 プロジェクトは、 Secrets Manager に格納されているAPIキーの参照を、デプロイ可能なアーキテクチャへの入力として直接サポートする。 詳細は、「 Using API key with Secrets Manager to authorize project to deploy 」を参照してください。
プロジェクトを作成する前に、 アカウントマリプロジェクトアカウント内に Secrets Manager サービスインスタンス を作成してください。これにより、 アカウントアカウント内のすべてのプロジェクトで利用可能になります。
作成できるいくつかの異なるシークレット・タイプがあります。 任意のシークレット・インスタンスを使用して、プロジェクトの API キーを保管します。 詳しくは、 UI での任意のシークレットの作成 を参照してください。
通常、アカウント内のすべてのプロジェクトに対して単一の Secrets Manager インスタンスが使用されます。 そのインスタンス内のシークレットは、アクセス制限に適合するシークレット・グループに編成できます。 例えば、プロジェクトごとにシークレット・グループを使用したり、関連するプロジェクトのセットにシークレット・グループを使用したりすることができます。
環境を使用したデプロイメントの制御
プロジェクト内では、環境を使用して、関連する構成をグループ化することができます。 環境には、入力値や認証の詳細などのプロパティを含めることもできる。 これらのプロパティーは、環境を選択すると自動的に構成に追加されます。これにより、ターゲット・アカウントへのデプロイメントを正確に行うことができます。 構成を編集するときに、 「詳細の定義」 セクションで、使用する構成の環境を選択できます。
環境を使用する利点
環境により、デプロイメントの制御が容易になります。 環境を指定し、プロパティーを追加することにより、その環境を使用している構成間で同じ値が共有されることが分かります。 コンフィギュレーション内では、環境によって自動的に提供される値を上書きすることができます。
環境は、関連する構成を 1 つのプロジェクト内でグループ化する手段を提供します。 例えば、開発アカウントと同じターゲット・アカウントにデプロイしたい一連の構成があるとします。 開発環境を作成し、ターゲット・アカウントの認証の詳細をその環境に追加することができます。 開発環境を使用している各構成に認証方式が追加されます。
必要な数の環境を作成できますが、プロジェクト内の環境の数を少なくしておくことをお勧めします。 複数のアカウントにわたってデプロイメントに標準の環境セットを使用すると、アーキテクチャーの構成とデプロイが容易になります。
詳しくは、 環境の作成 を参照してください。
構成の編成
関連するすべての構成を単一のプロジェクトに編成することを検討してください。 このようにして、1 つの場所からデプロイメントを管理し、それらがセキュアで準拠していることを確認することができます。 これは、必要なインフラストラクチャーを作成するためにデプロイ可能な 1 つ以上のアーキテクチャーで構成される場合があります。その後、開発、テスト、実動などの複数のリージョンおよび環境をサポートするために、このアーキテクチャーを複製する必要があります。
ユーザーが各構成の機能を理解できるように、構成に命名規則を使用してください。 例えば、VPC ベースのデプロイ可能アーキテクチャーと、VPC ベースに依存する Kubernetes クラスターのデプロイ可能アーキテクチャーを使用するデプロイメントでは、以下のように構成に名前を付けることができます。
| 名前 | デプロイ可能なアーキテクチャー | 環境 | 注記 |
|---|---|---|---|
| Dev-VPC-グローバル | VPC ベース | 開発 | 開発環境用の基本 VPC の作成 |
| Dev-Kub-ダラス | Kubernetes クラスター | 開発 | 開発のためにダラスにクラスターを作成します |
| デヴ・クブ・ロンドン | Kubernetes クラスター | 開発 | 開発のためにロンドンにクラスターを作成します |
| 実動-VPC-グローバル | VPC ベース | 実動 | 実稼働環境用の基本 VPC の作成 |
| Prod-Kub-Dallas (実動-Kub-ダラス) | Kubernetes クラスター | 実動 | 実動用にダラスでクラスターを作成します |
| Prod-Kub-London (実動-Kub-ロンドン) | Kubernetes クラスター | 実動 | 実動用にロンドンにクラスターを作成する |
| Prod-Kub-東京 | Kubernetes クラスター | 実動 | 実動用に東京でクラスターを作成します |
| Prod-Kub-シドニー | Kubernetes クラスター | 実動 | 実動用のシドニーでのクラスターの作成 |
project.json ファイル内の開発構成を複製し、必要に応じてそれを変更して、テスト済みの開発デプロイメントから実動デプロイメントを迅速に作成することができます。
プロジェクトのアクセス・グループの作成
プロジェクトへのアクセスは Identity and Access Management (IAM) によって管理される。 プロジェクトごとに 2 つまたは 3 つのアクセス・グループを作成し、プロジェクトで作業するユーザーをそれらのアクセス・グループのいずれかに割り当てることをお勧めします。 例えば、プロジェクト名- コストや可用性を監視する必要があるユーザーにプロジェクトへの読み取り専用アクセスを提供するリーダーアクセスグループと、プロジェクト名- プロジェクトに変更を加え、リソースをデプロイする必要がある操作ユーザー用のライター アクセス グループ。 必要に応じて、2 つのライター・アクセス・グループを作成できます。1 つは構成を追加して入力値を入力できるユーザー用で、もう 1 つはリソースをデプロイできるユーザー用です。
| アクセス・グループ | 役割 |
|---|---|
| プロジェクト名-読者 | リーダー、ビューアー |
| プロジェクト名-ライター | マネージャー、オペレーター |
新規プロジェクトを作成するには、ユーザーに特定のアクセス権限が割り当てられている必要があります。 詳しくは、「 プロジェクトへのユーザーのアクセス権限の割り当て」を参照してください。
モニターに必要なアテンション項目
ニーズ・アテンション項目は、検証、承認、失敗、およびバージョン更新をモニターするために最適です。 ニーズ・アテンション項目を定期的に確認することにより、プロジェクトと構成が最新のものであり、準拠していることを確認することができます。
プロジェクトによって作成されたリソースのアンデプロイ
構成をデプロイするときに、作成されたリソースをプロジェクト内のグループとして管理できます。 これらのリソースは Terraform プランに基づいて作成され、 Schematics ワークスペースで個別に管理できます。
Schematics ワークスペースから個々のリソースを破棄することはできますが、プロジェクトを使用して作成されたリソースではドリフトが発生するため、推奨されません。 代わりに、プロジェクト UI から 1 回のクリックで、構成に関連付けられているすべてのリソースを一度にアンデプロイできます。 これにより、構成のデプロイ先のターゲット環境からデプロイメントが削除されます。 構成を削除せずにリソースをアンデプロイすると、将来構成を再度デプロイする必要がある場合に役立ちます。
デフォルトでは、プロジェクトまたは構成を削除すると、デプロイされたリソースはすべて自動的にアンデプロイされます。 この設定は有効のままにすることをお勧めしますが、プロジェクトを開いて 「管理」 > 「設定」 に移動することで、無効にすることができます。 この設定を無効にすると、構成またはプロジェクトを削除してもリソースはデプロイされたままになりますが、プロジェクト内でそれらのリソースを簡単に管理することはできなくなります。 デプロイされたリソースは、プロジェクトまたは構成が削除された後も使用可能なままであれば、ターゲット・アカウントに対して引き続きコストを発生させることができます。 詳細については、リソースの展開解除。