[FEATURE] Ordered Container Start in Score

[chrishumanitec]

Detailed description

Developers should be able to express rules that can be used to require some containers to be started and run before others within a single workload.

Context

Many workloads require some form of setup before the main container can run. For example, schema migration needs to be completed, static site data needs to be generated or shared state should be initiated. This set up can involve containers running to completion before another container starts, being ready/healthy before another container starts, or just have started before another container starts. This allows for patterns such as “Sidecars” or “Init Containers” to be implemented.

Many container orchestration platforms provide for ordered container start (Init Containers in Kubernetes, depends_on with service_started, service_healthy, or service_completed_successfully in Docker Compose, run.googleapis.com/container-dependencies in Google Cloud Run.) All of them allow for specifying the start order with various levels of support for conditions on when the next container should start.

Possible implementation

Proposal

Add a new before property to the container object. It would have the following schema:

description: Defines before which other containers this container should be started
title: Before
type: object
properties:
  containers:
    description: List of containers that should start after this container.
    type: array
    items:
      description: A container ID in this workload
      type: string
        minLength: 2
        maxLength: 63
        pattern: "^[a-z0-9][a-z0-9-]{0,61}[a-z0-9]$"
  ready:
    description: The status of the container before the next container are started.
    title: Ready
    type: string
    enum:
    - started
    - healthy
    - complete

Why not use after like compose depends_on ?

This is not a dependency relationship - more a preparatory relationship

Startup order of containers is not strictly speaking a dependency graph like in compose. In the usecase of init containers, the main container is not even run at the same time as the init container. Instead, some kind of state is managed before the main container runs.

In a well factored system, the main container should not have to worry about what init containers were run - rather just that the state is correct. Only the init containers themselves “know” that they need to leave the system is a certain state.

Default state is unaffected

By specifying using before rather than after, the default behavior in score is unaffected. Adding an init container only affects the init container and not the main container.

Example Score Files

Init containers

Score

containers:
  init-one:
    ...
    before:
      containers:
      - init-two
  init-two:
    ...
    before:
      containers:
      - main
  main:
    ...

Kubernetes Pod

apiVersion: core/v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - name: main
    ...
  initContainers:
  - name: init-one
    ...
  - name: init-two
    ...

Sidecars

Score

containers:
  init:
    ...
    before:
      ready: complete # implicit default
      containers:
      - main
  sidecar:
    ...
    before:
      containers:
      - main
      ready: started
  main:
    ....

Kubernetes Pod (prior to 1.29)

apiVersion: core/v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - name: main
    ...
  - name: sidecar
    ...
  initContainers:
  - name: init
    ...

Kubernetes Pod (after 1.29)

apiVersion: core/v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - name: main
    ...
  initContainers:
  - name: init
    ...
  - name: sidecar
    restartPolicy: Always
    ...

Additional information

No response