継続的インテグレーション タスクとカスタム タスクを実行するには、 Code Stream パイプラインに対してワークスペースを構成する必要があります。
パイプライン ワークスペースで、[タイプ] に Docker または Kubernetes を選択し、各エンドポイントを指定します。Docker および Kubernetes プラットフォームは、継続的インテグレーション (CI) タスクまたはカスタム タスクを実行するために Code Stream が展開するコンテナのライフサイクル全体を管理します。
- Docker ワークスペースには、Docker ホスト エンドポイント、ビルダー イメージ URL、イメージ レジストリ、作業ディレクトリ、キャッシュ、環境変数、CPU 制限、メモリ制限が必要です。Git リポジトリのクローンを作成することもできます。
- Kubernetes ワークスペースには、Kubernetes API エンドポイント、ビルダー イメージ URL、イメージ レジストリ、名前空間、NodePort、パーシステント ボリュームの要求 (PVC)、作業ディレクトリ、環境変数、CPU 制限、メモリ制限が必要です。Git リポジトリのクローンを作成することもできます。
パイプライン ワークスペースの構成には、次の表に示すように、いくつかの共通パラメータと、ワークスペースのタイプに固有のパラメータがあります。
| 選択 | 説明 | 詳細および可用性 |
|---|---|---|
| [タイプ] | ワークスペースのタイプ。 | Docker または Kubernetes で使用できます。 |
| [ホスト エンドポイント] | 継続的インテグレーション (CI) およびカスタム タスクが実行されるホスト エンドポイント。 | Docker ホスト エンドポイントを選択すると、Docker ワークスペースで使用できます。 Kubernetes API エンドポイントを選択すると、Kubernetes ワークスペースで使用できます。 |
| [ビルダー イメージ URL] | ビルダー イメージの名前と場所。このイメージを使用して Docker ホストおよび Kubernetes クラスタ上にコンテナが作成されます。継続的インテグレーション (CI) タスクとカスタム タスクは、このコンテナ内で実行されます。 | 例：fedora:latest ビルダー イメージには、curl または wget が必要です。 |
| [イメージ レジストリ] | ビルダー イメージがレジストリ内にあり、そのレジストリが認証情報を必要とする場合は、イメージ レジストリ エンドポイントを作成し、ここでそれを選択することで、レジストリからイメージを取得できるようにする必要があります。 | Docker および Kubernetes ワークスペースで使用できます。 |
| [作業ディレクトリ] | 作業ディレクトリは、継続的インテグレーション (CI) タスクの手順が実行されるコンテナ内の場所であり、Git Webhook によってパイプラインの実行がトリガされたときにコードのクローンが作成される場所です。 | Docker または Kubernetes で使用できます。 |
| [名前空間] | 名前空間を入力しないと、指定した Kubernetes クラスタ内に Code Stream によって一意の名前が作成されます。 | Kubernetes ワークスペースに固有。 |
| [プロキシ] | Kubernetes クラスタ内のワークスペース ポッドと通信するために、 Code Stream は、各 Kubernetes クラスタの名前空間 選択するオプションは、展開した Kubernetes クラスタの性質によって決まります。
|
|
| [NodePort] | Code Stream では、Kubernetes クラスタ内で実行されているコンテナとの通信に NodePort が使用されます。 ポートを選択しない場合、 Code Stream は、Kubernetes によって割り当てられる短期ポートを使用します。短期ポートの範囲（30000 ～ 32767）に対する入力を許可するようにファイアウォール ルールが構成されていることを確認する必要があります。 ポートを入力する場合は、クラスタ内の別のサービスがそのポートを使用していないこと、およびポートがファイアウォール ルールで許可されていることを確認する必要があります。 |
Kubernetes ワークスペースに固有。 |
| [パーシステント ボリュームの要求] | この機能により、Kubernetes ワークスペースのファイルをパイプラインの実行間で保持することができます。パーシステント ボリュームの要求に名前を指定すると、ログ、アーティファクト、およびキャッシュを保存できます。 パーシステント ボリュームの要求の作成の詳細については、https://kubernetes.io/docs/concepts/storage/persistent-volumes/ にある Kubernetes のドキュメントを参照してください。 |
Kubernetes ワークスペースに固有。 |
| [環境変数] | ここで渡されるキーと値のペアは、実行されるパイプライン内のすべての継続的インテグレーション (CI) タスクとカスタム タスクで使用できます。 | Docker または Kubernetes で使用できます。 ここで変数への参照を渡すことができます。 ワークスペースで提供される環境変数は、パイプライン内のすべての継続的インテグレーション (CI) タスクとカスタム タスクに渡されます。 ここで環境変数が渡されない場合、これらの変数は、パイプライン内のそれぞれの継続的インテグレーション (CI) タスクとカスタム タスクに明示的に渡す必要があります。 |
| [CPU リミット] | 継続的インテグレーション (CI) コンテナまたはカスタム タスク コンテナ向けの CPU リソースを制限します。 | デフォルトは 1 です。 |
| [メモリ リミット] | 継続的インテグレーション (CI) コンテナまたはカスタム タスクコンテナ向けのメモリを制限します。 | 単位は MB です。 |
| [Git クローン] | [Git クローン] を選択し、Git Webhook がパイプラインを呼び出すと、コードのクローンがワークスペース（コンテナ）内に作成されます。 | [Git クローン] が有効になっていない場合は、パイプライン内で別の明示的な継続的インテグレーション (CI) タスクを構成して、まずコードのクローンを作成してから、ビルドやテストなどの他の手順を実行する必要があります。 |
| [キャッシュ] | Code Stream ワークスペースでは、一連のディレクトリまたはファイルをキャッシュして、その後のパイプライン実行を高速化できます。これらのディレクトリは、たとえば .m2、npm_modules などです。パイプラインの実行間でデータのキャッシュを必須にしない場合、パーシステント ボリュームの要求が不要になります。 コンテナ内のファイルやディレクトリなどのアーティファクトは、複数のパイプライン実行で再利用するためにキャッシュされます。たとえば、node_modules フォルダや .m2 フォルダをキャッシュできます。[キャッシュ] には、パスのリストを指定できます。 例： workspace:
type: K8S
endpoint: K8S-Micro
image: fedora:latest
registry: Docker Registry
path: ''
cache:
- /path/to/m2
- /path/to/node_modules
|
ワークスペースのタイプに固有。 Docker ワークスペースでは、Docker ホスト内にある、キャッシュされたデータ、アーティファクト、およびログを保持するための共有パスを使用することで、[キャッシュ] が実行されます。 Kubernetes ワークスペースで [キャッシュ] の使用を有効にするには、パーシステント ボリュームの要求を指定する必要があります。それ以外の場合、[キャッシュ] は使用できません。 |
パイプライン ワークスペースで Kubernetes API エンドポイントを使用する場合、 Code Stream は、継続的インテグレーション (CI) タスクまたはカスタム タスクを実行するために必要な ConfigMap、シークレット、ポッドなどの Kubernetes リソースを作成します。 Code Stream は、NodePort を使用してコンテナと通信します。
パイプラインの実行の間でデータを共有するには、パーシステント ボリュームの要求を指定する必要があります。 Code Stream はパーシステント ボリュームの要求をコンテナにマウントしてデータを保存し、以降のパイプラインの実行に使用します。
