OCI Ecosystem

tags : Containers, Docker, Kubernetes, Podman

Resources §

• https://github.com/containers

FAQ §

What do we talk about when talking about containers in practice §

• specific container image format
• run-time environment
• container registry API
• Other stuff, hence there is a choice in how we can define how a container itself and its ecosystem is implemented. To standardize all this we have the OCI.
• We have 3 specifications
  • OCI Image spec
  • OCI Runtime spec
  • OCI Distribution spec (Container registry)

OCI Specs §

OCI Image Specification §

• A series of tarballs called “layers”.
• Consists of a JSON configuration (containing environment variables, the path to execute, and so on)

Image creation w Dockerfile §

• Create OCI images w Docker and Podman CLI
• From Dockerfile without Docker/Podman
  • kaniko : Build images w Dockerfile from environments without Docker, eg. from inside of a container.
  • buildah : Can be used to created images w and w/o Dockerfile. Podman uses it. Can create images from existing containers.
• Unsure
  • moby/buildkit?
  • img,
  • https://buildpacks.io/
  • https://umo.ci/
  • https://github.com/project-stacker/stacker

Image creation w/o Dockerfile §

Doing this gives you more flexibility eg. create image layers in parallel, decide how layers cache etc.

• jib : OCI Images for java applications w/o Dockerfile and Docker
• ko : For building OCI images for no CGO Golang stuff.
• apko : Building OCI images directly from apk for alpine

OCI Runtime §

• Simply a program that implements the OCI Runtime spec, this program actually runs the container.
• It does things like setting mounts, cgroups, ns(if using ns), loading processes, tears down etc.
• It does not care about what is the actual implementation of the “container” is.
• Examples
  • Native runtimes
    • runc (created by Docker)
    • crun (tries to be faster than runc)
  • Sandboxed runtimes
    • runsc (oci runtime inside gvisor)
  • Virtualized runtimes
    • firecracker-containerd (uses containerd w firecracker)
    • kata containers (uses qemu to create vm and run container there)

OCI Distribution (Container registry) §

Container registries are general purpose storage with the added benefit of being able to programmatically understand how the pieces are related.

• They use the distribution API
• Docker manages a big one: DockerHub, but you can host your own, use Quay, Harbor etc.
• Related tools
  • Skopeo
    • Does stuff w images and repositories
    • copy images to/from container registries.
    • inspect image without pulling etc.
  • https://github.com/containerd/stargz-snapshotter

The engine and orchestrator §

Container engines §

• Helps us make use of Image spec + Runtime + Dist
• Implements client side of the distribution
• Interprets images
• Launches containers using a runtime of its choice
• Provides tools/APIs for managing images, processes, and storage.

by Docker team w CNCF §

• Docker (This is the old docker, the whole thing as we know it)
• containerd is embedded into Docker.
• containerd (K8s CRI compatible)
  • By Docker team w CNCF
  • Uses runc for OCI runtime
  • container processes are forked from containerd process.
  • Included in docker, can be used standalone, or with CRI w Kubernetes. Extensible w plugins.
  • CRI compatible but not locked into k8s unlike CRI-O
  • Uses grpc, doesn’t do things like talk to registry etc. without additional software, containerd doesn’t do anything differently from Docker, it just does less.
  • Follows a smart client model
    • When used with Docker, funny enough, dockerd is the smart client for containerd.
    • When used w K8s, CRI plugin is the smart client.
    • ctr (debugging), nerdctl (smart client for standalone containerd)

by RedHat team w CNCF §

• Podman (for Docker replacement and better systemd support)
• CRI-O (K8s CRI compatible)
  • CRI-O is a separate project(K8s only), not embedded into Podman
  • Uses crun for OCI runtime
  • Developed in lockstep with the Kubernetes release cycle

Container orchestrator (eg. K8s) §

These basically scheduling and run containers using a container engine

K8s §

• The interface Kubernetes uses to interact w the container engine is named CRI
• Kubernetes initially used dockershim as Docker doesn’t directly support CRI. Later things were changed, now K8s uses CRI-O/ containerd
• dockershim is deprecated and now maintained w a new name by a third party.
• Other than orchestrating containers, k8s can now also do vms it seems.

Nomad §

• See Nomad
• Simpler alternative to Kubernetes
• Single cli: Creates daemons called agents which can run in server/client/both modes.