This is a summary of things we've discovered while doing investigating if it would make sense for Concourse to use tekton as another runtime. Much of the material here was part of concourse/rfcs#22
all containers inside the pod share the same workspace -> breaks the container isolation contract Concourse provides ( Tekton provides process isolation but not filesystem isolation when using a )
Tekton injects a binary before your code that executes your command and then writes to a file when it finishes
they achieve sequential execution of (Tekton) Task Steps by making every subsequent container wait until they see the file of the previous container (remember that every container in the pod shares the same workspace)
seems kinda gimmicky, but it's hard to do sequential containers in pods without putting everything in init containers
Concourse supports both sequential and parallel execution of (Concourse) steps, therefore (Tekton) Tasks are a poor fit as they can only do sequential execution (their roadmap does indicate that they're looking to change this in the future). Instead we would most likely have to use a (Tekton) Pipeline or even create multiple (Tekton) Tasks and manage them explicitly
the way they transfer bits between the (Tekton) Tasks is that it's copied onto a shared PVC, mounted to an init container on the new Task, contents are then copied to the shared workspace accessible to the Step container
VERY under-developed right now
the Git Resource can only pull, you have to do pushes from within your Step
Concourse workers manage a large number of volumes to pass between containers, some examples include: resource get and put steps, task input and output steps, task step caches, resource check caches
we rely on Copy on Write volumes pretty heavily for optimization
if we want to pass files between (Tekton) Tasks we would have to use something like PVCs or GCS buckets
Tekton only supports GCS buckets for now, but there is issue to support the other IaaS's
Tekton creates one PVC per PipelineRun to store the input/output of all the Resources in the run
by default the size of this PVC is 5Gi, this might be awkward for us since we have no way of knowing the size of the files ahead of time
Concourse would have to create, mount, and delete PVCs, Tekton does not provide anything to make this easier
Resource incompatibility seems like the biggest problem to me; the rest seems on a skim like it could be obscured behind some sort of abstraction boundary.
This is a summary of things we've discovered while doing investigating if it would make sense for Concourse to use tekton as another runtime. Much of the material here was part of concourse/rfcs#22
Tekton version: v0.2.0
Concept mapping (Core)
Mostly to do with how Concourse concepts map to Tekton concepts
Task
Pipeline
Resource
Concept mapping (Runtime)
See #3798 for mappings to k8s as a whole
Volumes
get
andput
steps, taskinput
andoutput
steps, task step caches, resource check cachesReferences
The text was updated successfully, but these errors were encountered: