ワークスペースの使用計画
以下の質問をプロンプトとして使用して、ワークスペースを計画および設計します。
- ワークスペースを Git リポジトリーに関連付けるにはどうすればよいですか?
- アプリケーション環境に必要なワークスペースの数はいくつですか?
- Terraformの設定ファイルを環境やワークスペース間で再利用するにはどうすればよいですか？
- ワークスペースへのアクセスを制御し、管理するにはどうすればよいですか？
ワークスペースおよび Git リポジトリー
ワークスペースでは、 Git のプライベートまたはパブリックリポジトリ（ GitHub、 GitLab、 Bitbucket、 Azure、 DevOps ）からTerraformテンプレートを使用します。 この表は、リポジトリー・ソースのフォーマットを示しています。
| Git リポジトリー | URL |
|---|---|
GitHub |
https://github.com/<your_user_name>/<repo_name>/tree/<branch_name>/<folder_name> |
GitLab |
https://gitlab.com/<your_user_name>/<project_name>/tree/<branch_name>/<folder_name> |
Bitbucket |
https://bitbucket.org/<your_user_name>/<repo_name>/src/<branch_name>/<folder_name>https://<username>@bitbucket.org/<workspace_name>/tf_cloudless_sleepy/src/master |
Azure DevOps |
https://azure.com/<your_user_name>/<repo_name>/src/<branch_name>/<folder_name>https://visualstudio.com/<your_user_name>/<repo_name>/src/<branch_name>/<folder_name> |
アプリケーション環境に必要なワークスペースの数はいくつですか?
IBM Cloud Schematics で必要なワークスペースの数は、アプリケーションの構造と、アプリケーションまたはマイクロサービスを開発、テスト、および公開するために必要な環境によって決定されます。
経験則として、各マイクロサービスと使用する環境ごとに個別のワークスペースを検討してください。 例えば、検索、支払い、レビューのマイクロサービスコンポーネントで構成される製品アプリケーションをお持ちの場合、各マイクロサービスコンポーネントとそれらの開発、ステージング、本番環境用に個別のワークスペースを作成することを検討してください。 各コンポーネントと環境に個別のワークスペースを用意することで、他のコンポーネントに影響を与えることなく、Terraform構成ファイルと関連するクラウドリソースの開発、デプロイ、更新を行うことができます。
3 つのマイクロサービスで構成されるアプリケーションのワークスペース構造 IBM Cloud Schematics を観察して、以下のイメージを確認します。
インフラストラクチャーの責任が複数のチームに分散している組織では、1 つのワークスペースを使用してステージング環境または実稼働環境全体を管理することはお勧めしません。 すべてのクラウドリソースを単一のワークスペースで展開すると、さまざまなチームがこれらのリソースの更新を調整したり、アクセスを管理したりすることが難しくなる場合があります。 別個のワークスペース。リモート状態のデータ・ソースを使用してインフラストラクチャー定義を共有することにより、別個の責任領域を作成するメカニズムが提供されます。
Git リポジトリをどのように構成すれば、ワークスペースをマッピングできますか？
Git リポジトリを構成して、マイクロサービスを構築するすべての Terraform 構成ファイルを1つのリポジトリにまとめ、 Schematics、または GitHub のブランチやディレクトリで入力変数を使用して、開発、ステージング、本番環境を区別できるようにします。
以下の表に、さまざまなワークスペース環境に対応付けるために Git リポジトリーを構成する方法をリストします。
| オプション | 説明 |
|---|---|
| 1 つの Git リポジトリーで、変数を使用して環境を区別する | マイクロサービス・コンポーネントを構成する Terraform 構成ファイルを保管するための Git リポジトリーを 1 つ作成します。 複数の環境で同じ構成を再利用できるように、Terraform 構成ファイルはできる限り汎用的な内容にします。 開発環境、ステージング環境、および実稼働環境の詳細を構成するために、構成ファイルで Terraform 入力変数を使用します。 入力変数はワークスペースの作成時に IBM Cloud Schematics に自動的にロードされます。 ワークスペースをカスタマイズするには、環境固有の値を変数に入力します。 このセットアップは、マイクロサービス・コンポーネントのライフサイクルを管理するチームが 1 つで、各環境の構成に大きな違いがない場合に有用です。 |
| 1 つの Git リポジトリーで、ブランチを使用して環境を区別する | マイクロサービス・コンポーネント用の Git リポジトリーを 1 つ作成し、環境ごとに別の Git ブランチを使用して Terraform 構成ファイルを保管します。 このセットアップでは、環境を明確に区別できるので、特定の構成にアクセスして変更できるユーザーをより厳密に制御できます。 環境ごとに異なる構成にならないように、1 つの構成ファイル内の変更がブランチ間でどのように取り込まれるかを必ずセットアップしてください。 |
| 1 つの Git リポジトリーで、ディレクトリーを使用して環境を区別する | 存続期間の短いブランチが適し、環境間で構成が大幅に異なる組織では、環境の構成ごとにディレクトリーを作成することを検討してください。 このセットアップでは、master・ブランチにコミットされた変更を、すべてのディレクトリーが listen します。 環境ごとに異なる構成にならないようにするために、1 つの構成ファイル内の変更がディレクトリー間でどのように取り込まれるかを必ずセットアップしてください。 |
| 環境ごとに Git リポジトリーを 1 つ使用する | 環境ごとに 1 つの Git リポジトリーを使用します。 このセットアップでは、ワークスペースと Git リポジトリーが 1 対 1 の関係になるため、Git リポジトリーごとに別の権限を適用できます。 チームで複数の Git リポジトリーを管理してリポジトリー間の同期を維持できるようにしてください。 |
複数の環境およびワークスペースで構成ファイルを再利用する方法
標準化された Terraform テンプレートを作成し、テンプレートの使用をニーズに合わせてカスタマイズするために変数を使用することで、管理が必要な Terraform 構成ファイルの数を最小限に抑えるようにしてください。
IBM Cloud 用の Terraform モジュール・レジストリーにある Terraform モジュールを使用できるようになりました。
標準化された Terraform テンプレートまたは Terraform モジュールを使用することによって、開発のベスト・プラクティスへの遵守を組織内で徹底することや、すべての Terraform 構成ファイルを同じ構造にすることができます。 Terraform 構成ファイルの構造がわかっているので、開発者は、ファイルの理解、変数の宣言、コードへの貢献、エラーのトラブルシューティングを行いやすくなります。
ワークスペースに対するアクセスの制御方法
IBM Cloud Schematics は、IBM Cloud® Identity and Access Management と完全に統合されています。 ワークスペースへのアクセス、および、IBM Cloud Schematics を使用してインフラストラクチャー・コードを実行できるユーザーを制御するには、ユーザー・アクセス権限の管理を参照してください。
以前に Terraform スタンドアロンで使用されたリポジトリーがある場合は、何に注意する必要がありますか?
IBM Cloud Schematics はTerraform-as-a-Serviceを提供しているため、ワークスペースを使用して既存のTerraformテンプレートを再利用することができます。 Terraform テンプレートの作成方法と Git リポジトリーの構造によっては、 IBM Cloud Schematicsを正常に使用するために変更が必要になる場合があります。
- プロバイダー・ブロック宣言: IBM Cloud Schematics は IBM Cloud® Identity and Access Management と統合されているため、すべての IAM 対応リソースに IBM Cloud API キーが自動的に取得されます。この情報を
providerブロックに指定する必要はありません。 ただし、クラシックインフラストラクチャリソースではAPIキーは取得されません。 詳しくは、providerブロックの構成を参照してください。 - Terraform コマンド・ラインおよび IBM Cloud プロバイダー・プラグイン: IBM Cloud Schematics を使用する場合は、Terraform コマンド・ラインや IBM Cloud Provider Plug-in for Terraform をインストールする必要はありません。 リソースのプロビジョンを自動化する場合は、代わりに IBM Cloud Schematics コマンド・ライン・プラグインを試してください。
ワークスペースの継続的デリバリー・ツールチェーンのセットアップ
IBM Cloud の継続的デリバリー・パイプラインにソース・リポジトリーを接続し、Terraform 実行プランが自動的に生成され、Terraform 構成ファイルを更新するたびに IBM Cloud で Terraform コードが実行されるようにします。
- アカウントに Continuous Delivery サービス・インスタンスがまだない場合、作成します。
- IBM Cloud カタログから、Continuous Delivery サービスを開きます。
- サービスを作成する IBM Cloud リージョンを選択します。
- 料金プランを選択します。
- サービス・インスタンスの名前を入力し、リソース・グループを選択し、サービス・インスタンスに関連付けるタグを入力します。
- **「作成」**をクリックして、アカウント内にサービス・インスタンスを作成します。
- ワークスペースダッシュボードからワークスペースを選択します。
- **「設定」**タブを選択します。
- **「サマリー」セクションで、「継続的デリバリーを有効にする (Enable continuous delivery)」**をクリックします。
- ツールチェーンを構成します。
- ツールチェーンの名前を入力し、このツールチェーンをデプロイするリージョンとリソース・グループを選択します。 リージョンとリソース・グループは、Schematics ワークスペースに使用したリージョンとリソース・グループと異なっていても構いません。
- Terraform 構成ファイルが格納されているソース・リポジトリーのタイプを選択します。 例えば、GitHub などです。
- ソース・リポジトリーの情報を確認します。 例えば、Terraform ファイルが GitHub に格納されている場合、継続的デリバリー・ツールチェーンを作成する GitHub サーバーとリポジトリーを確認します。 これらのフィールドは、ワークスペース構成に基づいて事前に入力されています。
- オプション: ツールチェーンで Git の Issue とコード変更の追跡を有効にするかどうかを選択します。
- **「デリバリー・パイプライン」**アイコンを選択して、デリバリー・パイプラインを構成します。
- 表示されるワークスペース ID が正しいことを確認します。
- IBM Cloud API キーを入力します。 API キーがない場合は、**「新規 + (New +)」**をクリックして作成します。
- **「作成」**をクリックして、ツールチェーンのセットアップを終了します。 ツールチェーンに関して構成したツールの概要が表示されます。
- **「デリバリー・パイプライン」**を開きます。 「デリバリー・パイプライン」には、ソース・リポジトリーから更新を取得するステージ、Terraform 実行プランを作成するステージ、このプランを適用するステージ、ワークスペースに対してヘルス・チェックを実行するステージが含まれます。
- ソース・リポジトリーの Terraform ファイルを更新し、デリバリー・パイプラインで対象の変更が処理される方法を確認します。 いずれかのステージが失敗する場合、**「ログと履歴の表示 (View logs and history)」**をクリックしてエラーのトラブルシューティングを開始します。 ログと履歴の表示に関する詳細は 、「 Schematics のジョブの詳細の確認」 を参照してください。