Tekton Pipelinesはk8sコンテナ上で動作するCIワークフローであるため、データは揮発します。
順序については
Tekton Pipelinesの制御フローで解説していますが、コンテナ間でディレクトリ内のフラットファイルを共有するには
Workspaces機能を利用します。
Workspaceはtask
で利用を宣言しpipelinerun
やtaskrun
から供給する、という構造になっています。
ストレージの種類はkubernetesが提供するストレージ機能を利用でき、pipelinerun
のspec.workspaces
に指定します。
Task内のワークスペース
単一Taskは複数のsteps
を定義でき、各stepは個別のコンテナが起動します。
このsteps間で共有するWorkspaceにはemptyDir
を利用できます。
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
spec:
workspaces:
- name: workdir
emptyDir: {}
emptyDirはオプションが乏しいため、使い方に注意はとくにありません。
ただし、emptyDirが後続のタスクでクリアされていない事象に遭遇することがあります。
この場合、Tektonの機能ではなくkubernetes標準のvolumes
でemptyDir
をセットアップすると安定します。
Pipelineのワークスペース
Pipeline内の複数タスク間でもWorkspaceを利用してファイル共有できます。
ただし、この構成の場合にはemptyDir
ではなく、PersistentVolume
を利用する必要があります。emptyDir
のワークスペースを用いると、後続タスクから参照した際に空になっています。
よって、この構成では公式のガイドに沿ってPersistentVolumeClaim
のワークスペースを指定します。
PersistentVolume
はwrite可能なコンテナを1つに限定しているケースが多いため、sidecarなどでフィットしない構成もあります。
PersistentVolumeは、多くの場合、各クラウドプロバイダのディスクサービスを要求する挙動となるでしょう。サーバーノードの空き容量を利用するような挙動ではないことには注意が必要です。
また、PersistentVolumeClaim
のワークスペースがクリアされていない事象に遭遇することがあります。
この場合、良い対処法はないためrm
するかTask内のワークスペース構成に変更することで安定させるしかないでしょう。
ワークスペースを利用すると、単機能のコンテナを定義しやすくなりTaskの共通化に効果的ではありますが、動作安定とのトレードオフがあるため、検証にもとづいて構成を決定する必要があります。
ConfigMap / Secret
ここまでの用途とは異なり、設定をreadonlyで供給する目的で、ConfigMap
やSecret
もworkspace経由で指定できます。
これらは各タスクのvolumes
にも定義できますが、設定変更により異なる用途に活用できるケースではWorkspace経由の供給が意味を持ちます。
![](https://storage.googleapis.com/unicornltd/chuma1.jpg)
Chuma Takahiro