拡張機能
「 IBM Cloud Schematics 用エージェント」に関するよくある質問への回答。
GA エージェント・リリースの更新はどのようなものですか?
以下は、エージェント・リリースの機能です。
- CLI および UI を使用したエージェント・デプロイメント・エクスペリエンスの向上。
- エージェントで Ansible プレイブックを実行することをサポートします。
- エージェントへのワークスペース・ジョブまたはアクション・ジョブの動的割り当て。
エージェントのインストールと使用にはどのようなコストがかかりますか?
以下は、 Schematics エージェントをデプロイして使用する場合のコスト明細です。
エージェントをデプロイして実行するために必要な前提条件インフラストラクチャーは、以下のように課金されます。
- サブネット、パブリック・ゲートウェイなどの VPC インフラストラクチャー・エレメントのコスト。
- 3 ノードのワーカー・プールでの VPC 上の IBM Cloud Kubernetes Service (クラスター) のコスト。
- IBM Cloud Object Storage のコスト
Agent サービスの実行:
- エージェントでジョブを実行するためのコストは発生しません。
- Schematics バージョン 1 エージェント機能は、課金対象外の機能です。 将来のバージョンは課金対象になる可能性があります。
1 つのクラスターに複数のエージェントをインストールすることはできますか?
IBM Cloud Kubernetes Service クラスターにインストールできるエージェントは 1 つのみです。 追加のエージェントをデプロイするには、追加のクラスターが必要です。 クラスターに複数のエージェントをインストールしようとすると、名前空間の競合エラーでデプロイ・ジョブが失敗します。
エージェントではどの Terraform バージョンがサポートされていますか?
Schematics でサポートされている 2 つの最新バージョンの Terraform のみが、エージェントでサポートされます (例: Terraform v1.13 および Terraform v1.14)。 旧バージョンの Terraform はサポートされていません。 旧バージョンの Terraform を使用するワークスペースは、エージェントを使用する前に、サポートされているいずれかのバージョンに更新する必要があります。
エージェントを使用する前にアップグレードするには、 新しい Terraform バージョンへのアップグレード の手順を参照してください。
ワークスペースの実行が terraformx.x: executable file not found in $PATH で失敗するのはなぜですか
ワークスペースで使用されている Terraform のバージョンは、エージェントではサポートされていません。 エージェントは、Terraform v1.13、および v1.14 、または Schematicsでサポートされている 2 つの最新バージョンの Terraform を使用してワークスペースをサポートします。 旧バージョンの Terraform を持つワークスペースは、エージェントによってサポートされるいずれかのバージョンに更新する必要があります。
詳しくは、 アップグレードの非推奨スケジュールとユーザー・アクション を参照してください。
エージェントではどのようなタイプのジョブを実行できますか?
エージェントで Schematics ワークスペースの Terraform ジョブとアクション・ジョブを実行できます。
エージェントで実行されているジョブの Schematics ジョブの結果とログを表示するにはどうすればよいですか?
ワークスペース・ジョブ・ログまたはアクション・ジョブ・ログは、 Schematics UI コンソールで使用可能です。 Schematics ワークスペース API または CLI を使用してジョブ・ログにアクセスすることもできます。
エージェント・リリースで必要な最小クラスター構成は何ですか?
エージェントには、 b4x16 以上のタイプの 3 つ以上のワーカー・ノードを持つ IBM Cloud Kubernetes Service サービスが必要です。
エージェントにはいくつのワークスペースを割り当てることができますか?
現在、任意の数のワークスペースをエージェントに割り当てることができます。 ワークスペース・ジョブは、エージェント割り当てポリシーに基づいて、エージェント上で実行するためにキューに入れられます。 エージェントは、1 分のポーリング間隔で、実行するジョブについて Schematics を定期的にポーリングします。 デフォルトでは、エージェントは 3 つのジョブのみを並行して実行します。 残りのジョブはキューに入れられます。
エージェント上で並行して実行できるジョブの数はいくつですか?
Schematics エージェントは、3 つの Git ダウンロード、ワークスペース・ジョブ (Terraform コマンド)、およびアクション・ジョブ (Ansible プレイブック) を並行して実行できます。 追加のジョブはキューに入れられ、前のジョブが実行を完了したときに実行されます。
エージェントのデフォルトのポーリング間隔は何ですか?
Schematics は、エージェントのジョブのキューを維持します。 デフォルトでは、エージェントは 1 分ごとにジョブをポーリングします。
エージェントの操作時に実行タイムアウトの制限はありますか?
Schematics エージェントは、 local-exec、 remote-exec 、および Ansible プレイブックの実行のタイムアウト制限を緩和します。 マルチテナント・サービスでは、すべてのユーザーによる公平なサービス利用を確保するために、これらの時間は 60 分に制限されています。 エージェントで実行されるジョブには期間は適用されません。 ジョブ実行時間が長いと、すべてのクラスター・ジョブをタイムリーに実行するために、より多くのユーザー・クラスター容量とワーカー・ノードが必要になります。
ソフトウェア・インストール・タスクを実行する長期実行ジョブには、 Continuous Delivery などのサービスを使用することをお勧めします。
エージェント・サービスでの agent-location フラグと location フラグの違いは何ですか?
--agent-location パラメーターは、エージェント・サービスがデプロイされるクラスターの領域を指定する変数です。 例えば、us-south です。 これはクラスター領域と一致する必要があります。
--location パラメーターは、 Schematics サービスでサポートされる地域 ( us-south、 us-east、 eu-de、 eu-gb など) を指定する変数です。 エージェントは、このロケーションから Schematics サービス・インスタンスをポーリングして、処理のためのワークスペースまたはアクション・ジョブを探します。
エージェントは、異なるリソース・グループに関連付けられているワークスペース・ジョブを実行できますか?
はい。エージェントは、アカウント内の任意のリソース・グループに関連付けられたワークスペースまたはアクション・ジョブを実行できます。 エージェント (割り当て) ポリシーは、リソース・グループ、地域、およびユーザー・タグに基づいて、ジョブの実行を特定のエージェントに割り当てるために使用されます。
エージェントは、異なる Schematics 領域に属するワークスペースおよびアクションを処理できますか?
エージェント・デプロイメントは、ジョブ実行のために Schematics ホーム・リージョンに関連付けられています。 これらのユーザーは、同じ領域 ( North America、 Europe など) で定義されたワークスペース・ジョブまたはアクション・ジョブのみを実行できます。
エージェントは、定期的にホーム Schematics 領域をポーリングして、ジョブを取り出して実行します。 ホーム領域を含む領域に対して定義されたワークスペース・ジョブまたはアクション・ジョブのみを実行できます。 例えば、エージェントがシドニーのユーザー・クラスターにデプロイされ、そのホーム・ロケーションとして eu-de が構成されているとします。 エージェントは、 eu-de 領域と eu-gb 領域の両方を含むヨーロッパ地域のジョブをポーリングします。 シドニー・エージェントを使用してリソースをデプロイするには、 eu-de 地域または eu-gb 地域でワークスペースまたはアクションを作成する必要があります。
エージェントを使用して複数のアカウントのジョブを実行することはできますか?
いいえ、エージェントは単一の親 Schematics アカウントに関連付けられており、このアカウントに属するワークスペースまたはアクションに対してのみジョブを実行できます。
既存のワークスペースはエージェント上でジョブを実行できますか?
はい。 ワークスペースおよびアクションは、エージェントで実行するためにポリシーによって選択されます。 Schematics agent-selection-policy は、ターゲット・エージェントで実行する既存の (または新規の) ワークスペースまたはアクションを割り当てます (タグ、リソース・グループ、ロケーションのポリシー属性と一致する場合)。
例えば、 tag=dev を使用する既存のワークスペース wks-0120 があり、そのワークスペースを Agent-1 で実行する場合などです。 tag == dev の場合に Agent-1 を選出するためのルールを使用して、 agent-selection-policy を作成します。 後で、計画、適用、更新などのワークスペース・ジョブが動的にルーティングされ、
Agent-1 で実行されます。
エージェントをデプロイするには、どのような IAM 権限が必要ですか?
アクセス許可について詳しくは、 エージェントの許可 を参照してください。
エージェントの実行中に、 IBM Cloud Kubernetes Service のポッドまたはコンテナの「信頼済みCAルート証明書ストア」に、自己署名証明書や TLS 証明書を登録することは可能ですか?
はい、以下の手順に従って、証明書をエージェント・ランタイムに注入します。
4 つの .cer 拡張ファイル名では、スペースを下線に置き換えるように変更してください。
-
kubectrlコマンドに示されているように、.cerファイルを使用して構成マップを作成します。kubectl -n schematics-runtime create configmap xyz-root —-from-file 2014-2044_xyz_Root.cerkubectl -n schematics-runtime create configmap xyz-authentication —-from-file 2014-2029 xyz_Users_Authentication.cerkubectl -n schematics-runtime create configmap xyz-infrastructure —-from-file 2014-2029 xyz_Infrastructure.cer -
構成マップ・ファイルを、ディレクトリー
/etc/ssl/certs/内のボリュームとして、共有xyz_agent_deployment_filesディレクトリー内のファイルagent-runtime-deployment-certs.yamlとしてマウントします。
共有ディレクトリー xyz_agent_deployment_files には、以下の名前の 2 つの yaml ファイルがあります。 - agent-runtime-deployment-certs.yaml および - agent-runtime-deployment.yaml.
agent-runtime-deployment-certs.yaml ファイルは、証明書を更新し、追加の変更を加えずに証明書を注入するために必要なデプロイメントの詳細を提供する agent-runtime-deployment.yaml ファイルを追加します。
実行するターゲット・エージェントを動的に選択するために使用されるワークスペースまたはアクションの属性
Schematics のワークスペースまたはアクションの以下の属性は、エージェントインスタンスを動的に選択するために使用されます。
- リソース・グループ
- ロケーション (地域)
- タグ
エージェント・インスタンスの エージェント割り当てポリシー は、ワークスペースまたはアクション・ジョブを実行するために選択されるエージェントを決定します。
以下に、タグの使用法のサンプル・シナリオを示します。
組織に 3 つの異なるネットワーク分離ゾーン ( Dev、 HR-Stage、 HR-Prod など) があり、3 つのエージェント (それぞれ 3 つのネットワーク分離ゾーンに 1 つずつ) がインストールされている場合。 Dev で実行されているエージェントの agent-assignment-policy が定義され、セレクターが tags=dev になりました。 tags=dev を持つすべてのワークスペースは、自動的に Dev エージェントにバインドされます。 つまり、 Dev エージェントを使用して、Terraform テンプレートを ( Git リポジトリーから) ダウンロードし、Terraform ジョブを実行します。 同様に、 agent-assignment-policy には、ジョブ実行用のエージェントを定義するためにワークスペースの他の属性を含めることができます。
エージェントでデバッグ・モードを有効にする方法
以下の手順に従って、エージェントのデバッグ・モードを有効または無効にすることができます。
- IBM Cloud にログインします。
- ナビゲーター・ウィンドウから Kubernetes をクリックし、 「クラスター」 をクリックします。
- Kubernetes クラスター」 ページで、 クラスター > Kubernetes ダッシュボードをクリックします。
- 「デフォルト」 ドロップダウンをクリックして、 「名前空間」 のリストを表示します。
- ドロップダウンに、 Schematics-job-runtime 名前空間を入力します。
- 「構成およびストレージ」 から 「構成マップ」 をクリックします。
- 「構成マップ」 ページから。 schematics-jobrunner-config に対して 3 つのドットをクリックします。
- 「編集」 をクリックして、 「YAML」 タブと 「JSON」 タブがある 「リソースの編集」 ページを表示します。
- ジョブ・ランナー・マイクロサービス・ロギングの
JR_LOGGERLEVELパラメーターを編集できるようになりました。 デフォルトでは、値は-1です。これは、JR_LOGGERLEVELを0として編集する必要があることを有効にするためにデバッグを無効にすることを示します。 - 「 更新 」をクリックして、編集内容を反映させてください。
- 「デフォルト」 ドロップダウンをクリックして、 「名前空間」 のリストを表示します。
エージェントのベータ版をエージェントの一般出荷版 (GA) バージョンにアップグレードできますか?
いいえ、エージェント・ベータ・セットアップをエージェント GA バージョンにアップグレードすることはできません。
Schematics エージェントは Terraform クラウド・エージェントと同じですか?
Schematics エージェントは、 Terraform クラウド・エージェントと同様の役割を実行します。
エージェントは IBM Cloud クラウド・リソースで実行されますか?
Schematics エージェントは、ワークスペースおよびアクションのワークロードのみを実行できます。 ベータ版の場合、エージェントはユーザー・アカウントの IBM Cloud IBM Cloud Kubernetes Service クラスターにデプロイされます。
Schematics エージェントで 30 個のジョブをサポートするために必要な最小クラスター構成は何ですか?
IBM Cloud® Virtual Servers for Virtual Private Cloud または IBM Cloud® Kubernetes Service クラスターの場合。 bx2.4x16 フレーバーの 9 最小数のノードが必要です。また、以下のエージェント・マイクロサービス・デプロイメントを編集して、規定のレプリカ数になるようにします。
| マイクロサービス | レプリカの数 |
|---|---|
| ジョブ・ランナー | 4 |
| サンドボックス | 8 |
| ランタイム-WS | 16 |
エージェントによって作成されたジョブをユーザーが識別する方法
ワークスペース・ジョブ・ログを使用して、エージェントによってワークスペースが作成されたことを識別できます。
ワークスペースがエージェントによって作成され、それでもワークスペース・ジョブ・ログに参照がない可能性はありますか?
いいえ。エージェントがワークスペースを作成する場合は、ワークスペースのジョブ・ログに参照が表示されている必要があります。 参照が表示されない場合は、ポリシー検証が失敗したことを確認する必要があります。
Schematics エージェントは、プライベート Git インスタンスとの接続を確立できますか?
はい、 Schematics エージェントは、プライベート Git インスタンスとの接続を確立します。 ただし、 SSL の証明書を所有している必要があり、エージェントのマイクロサービスにおいて以下の手順に従う必要があります。
Jobrunner、Sandbox、およびRuntime-wsのエージェント・マイクロサービスにおいて、 SSL 証明書を設定し、接続を確立します。- Kubernetes Service 構成マップのマウントを使用して構成を行う必要があります。
-
必要な SSL 証明書を含むConfigMapを作成します。例えば、
kubectl -n schematics-job-runtime create configmap mytestcert --from-file cert.pem -
configmap をボリュームとして使用し、
Jobrunner、Sandbox、およびRuntime-wsマイクロサービスのデプロイメント・ファイルで共有としてマウントします。apiVersion: apps/v1 kind: Deployment metadata: annotations: deployment.kubernetes.io/revision: "1" kubernetes.io/change-cause: job_runner_1.0 creationTimestamp: "2023-09-14T12:18:07Z" generation: 1 labels: app: jobrunner name: jobrunner namespace: schematics-job-runtime resourceVersion: "23425" uid: fa66583a-8bdb-40a1-9b05-df2c2bf56656 spec: progressDeadlineSeconds: 600 ..... ..... volumes: - hostPath: path: /var/log/at type: "" name: at-events - hostPath: path: /var/log/schematics type: "" name: ext-logs - name: mytestcert #### added as a volume configMap: name: mytestcert status: availableReplicas: 1 conditions: - lastTransitionTime: "2023-09-14T12:18:42Z" lastUpdateTime: "2023-09-14T12:18:42Z" message: Deployment has minimum availability. reason: MinimumReplicasAvailable status: "True" type: Available - lastTransitionTime: "2023-09-14T12:18:07Z" lastUpdateTime: "2023-09-14T12:18:42Z" message: ReplicaSet "jobrunner-7f9ffdf959" has successfully progressed. reason: NewReplicaSetAvailable status: "True" type: Progressing observedGeneration: 1 readyReplicas: 1 replicas: 1 updatedReplicas: 1
-
Schematics エージェントは、プライベート Git インスタンスとの接続を更新できますか?
はい。エージェントをメタデータで更新して、プライベート Git インスタンスでのカタログのオンボーディングを実行できます。 サンプルの更新 API 要求を参照用に使用します。
このステップは、エージェントにメタデータがない場合にのみ実行します。
curl -X PUT 'https://schematics.cloud.ibm.com/v2/agents/<agent_id>'
-H 'Authorization: Bearer <token>'
-H 'X-Feature-Agents: true'
-H 'refresh_token: <refresh_token>'
-d '{
"agent_metadata": [
{
"name": "purpose",
"value": ["git"]
},
{
"name": "git_endpoints",
"value": ["https://myprivate-gitinstance/testrepo"]
}
]
}'