Container Collection

Containers for Kubernetes deployment_

---

Available Images

Container	Status
flakes-action-latest	🚧
kaniko-v24.10.01	🚧

Container Rules

Containers in this project should be useful in Kubernetes. They will be:

• semantically versioned
• rootless
• logging to stdout in JSON format if possible
• using one process per container
• having no s6-overlay
• built on Alpine
• immutable
• do no monkey business after deployed

Additionally I may in the future support:

• multiple architecture. For now containers are generated for amd64

Tag immutability

Instead of using immutable version tags as seen on e.g. linuxserver.io we use calver and sha256-digests.

If pinning an image to the sha256 digest, tools like [Renovate](https://github.com/renovatebot/renovate) support updating the container on a digest or application version change.

The schema used is: YYYY.MM.Minor@sha256:digest. This is not as pretty, but functional and immutable. Examples:

Container	Immutable
code.252.no/tommy/containers/flakes-action:v24.10.1	❌
code.252.no/tommy/containers/flakes-action:v24.10.1@sha256:1234...	✅

Kubernetes Pod Security Standard

In Kubernetes we assume that you have pod-security.kubernetes.io/enforce set to restricted. There may be some exceptions to this if the container actually requires more privileges.

E.g. for the flakes-action, which runs as user ID 1000, this means that the following settings should be used for the pod (all containers in a pod):

spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 1000
    fsGroup: 1000

For a container this means:

spec:
  [...]
  containers:
  - name: flakes-action
    [...]
    securityContext:
      runAsUser: 1001
      capabilities:
        drop: ["ALL"]
      privileged: false
      allowPrivilegeEscalation: false
      runAsNonRoot: true
      seccompProfile:
        type: RuntimeDefault

Configuration volume

For applications that need to have persistent configuration data the config volume is hardcoded to `/config` inside the container.

Deprecations

Containers here can be deprecated at any point, this could be for any reason described below.

1. The upstream application is no longer actively developed
2. The upstream application has an official upstream container that follows closely to the mission statement described here
3. The upstream application has been replaced with a better alternative
4. The maintenance burden of keeping the container here is too bothersome

Credits

A big thanks goes to Buroa@github for the inspiration to the repo structure and concept.