継続的インテグレーション タスクとカスタム タスクを実行するには、Automation Pipelines パイプラインに対してワークスペースを構成する必要があります。
パイプライン ワークスペースで、[タイプ] に Docker または Kubernetes を選択し、各エンドポイントを指定します。Docker および Kubernetes プラットフォームは、継続的インテグレーション (CI) タスクまたはカスタム タスクを実行するために Automation Pipelines が展開するコンテナのライフサイクル全体を管理します。
- 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 クラスタ内に Automation Pipelines によって一意の名前が作成されます。 | Kubernetes ワークスペースに固有。 |
[プロキシ] | Kubernetes クラスタ内のワークスペース ポッドと通信するために、Automation Pipelines は、各 Kubernetes クラスタの名前空間 選択するオプションは、展開した Kubernetes クラスタの性質によって決まります。
|
|
[NodePort] | Automation Pipelines では、Kubernetes クラスタ内で実行されているコンテナとの通信に NodePort が使用されます。 ポートを選択しない場合、Automation Pipelines は、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) タスクを構成して、まずコードのクローンを作成してから、ビルドやテストなどの他の手順を実行する必要があります。 |
[キャッシュ] | Automation Pipelines ワークスペースでは、一連のディレクトリまたはファイルをキャッシュして、その後のパイプライン実行を高速化できます。これらのディレクトリは、たとえば .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 エンドポイントを使用する場合、Automation Pipelines は、継続的インテグレーション (CI) タスクまたはカスタム タスクを実行するために必要な ConfigMap、シークレット、ポッドなどの Kubernetes リソースを作成します。Automation Pipelines は、NodePort を使用してコンテナと通信します。
パイプラインの実行の間でデータを共有するには、パーシステント ボリュームの要求を指定する必要があります。Automation Pipelines はパーシステント ボリュームの要求をコンテナにマウントしてデータを保存し、以降のパイプラインの実行に使用します。