継続的インテグレーション タスクとカスタム タスクを実行するには、Code Stream パイプラインに対してワークスペースを構成する必要があります。このワークスペースは、Docker エンドポイントおよび Kubernetes API エンドポイントをサポートします。パイプライン ワークスペースを構成するときは、ビルダー イメージを含める必要があります。

パイプライン ワークスペースで、Docker または Kubernetes を選択し、Docker ホスト エンドポイントまたは Kubernetes API エンドポイントを含めます。Docker および Kubernetes プラットフォームは、継続的インテグレーション (CI) タスクまたはカスタム タスクを実行するために Code Stream が展開するコンテナのライフサイクル全体を管理します。

  • Docker ワークスペースには、Docker ホスト エンドポイント、ビルダー イメージ URL、イメージ レジストリ、作業ディレクトリ、キャッシュ、環境変数、CPU 制限、メモリ制限が必要です。Git リポジトリのクローンを作成することもできます。
  • Kubernetes ワークスペースには、Kubernetes API エンドポイント、ビルダー イメージ URL、イメージ レジストリ、名前空間、NodePort、パーシステント ボリュームの要求 (PVC)、作業ディレクトリ、環境変数、CPU 制限、メモリ制限が必要です。Git リポジトリのクローンを作成することもできます。

パイプライン ワークスペースの構成には、次の表に示すように、いくつかの共通パラメータと、ワークスペースのタイプに固有のパラメータがあります。

表 1. ワークスペースの領域、詳細、および可用性
選択 説明 詳細および可用性
[タイプ] ワークスペースのタイプ。 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 ワークスペースに固有。
[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 ワークスペースでは、一連のディレクトリまたはファイルをキャッシュして、その後のパイプライン実行を高速化できます。これらのディレクトリは、たとえば .m2npm_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 はパーシステント ボリュームの要求をコンテナにマウントしてデータを保存し、以降のパイプラインの実行に使用します。

Kubernetes ワークスペースで、証明書ベースの認証にオンプレミスの Kubernetes API エンドポイントを使用する場合は、クラウド プロキシが最新バージョンに更新されていることを確認する必要があります。最新バージョンでない場合、認証が失敗する可能性があります。