Warum mit Kaniko bauen?

Wer bisher Container baut, tut dies in der Regel mithilfe des Docker Daemons. Dieser läuft aber mit root Rechten auf dem Rechner. Das stellt also ein Sicherheitsrisiko dar, welches wir gern vermeiden wollen. Ausserdem können wir ohne den Daemon auch einfacher Container direkt in Kubernetes bauen.

Kaniko selbst läuft demnach auch in einem Container, so ist auch das ausprobieren für uns wieder einfach, ohne unseren Rechner zu verschmutzen.

Kaniko Lifecycle

Erster Schritt

Als kleines Beispiel nutzen wir folgendes mini Dockerfile.

FROM alpine:3.9
RUN apk add --no-cache nginx

Ausserdem legen wir eine Datei namens auth.json an um Kaniko die Möglichkeit zu geben, direkt in eine Registry zu pushen.

Natürlich muss hier das Auth-Token zum Account passen.
So wirds erzeugt: echo -n 'bee42:secret-password' | base64

{
    "auths": {
        "https://index.docker.io/v1/": {
            "auth": "YmVlNDI6c2VjcmV0LXBhc3N3b3Jk"
        }
    }
}

Diese Datei mounten wir nun mit in unseren Kaniko Container:

docker run \
    -v $(pwd):/workspace \
    -v $(pwd)/auth.json:/kaniko/.docker/config.json \
    gcr.io/kaniko-project/executor:latest \
    --dockerfile Dockerfile --destination "bee42/kaniko-test" --tarPath "/workspace/kaniko-image.tar" --context dir:///workspace/

Da wir die Flag --tarPath angegeben haben, wird unser Image lokal als kaniko-image.tar gespeichert und wir können es mit Docker importieren.

Wie wir sehen, funktioniert zwar alles, es dauert aber doch recht lang.

Kaniko kann aber, ebenso wie wir es vom Docker Daemon gewöhnt sind, Layer cachen.

Tuning

Um nun das Layer Caching zu nutzen braucht Kaniko ein wenig Nachhilfe. Dazu ändern wir unseren Befehl wie folgt:

docker run \
    -v $(pwd):/workspace \
    -v $(pwd)/auth.json:/kaniko/.docker/config.json \
    -v $(pwd)/kaniko/cache:/cache \
    gcr.io/kaniko-project/executor:latest \
    --cache-repo "bee42/kata-cache" \
    --dockerfile Dockerfile.kaniko --cache  \
    --destination "bee42/kata-test"  --context dir:///workspace/

Wir haben also die --cache flag angegeben. Dadurch erwartet Kaniko ausserdem ein Repo, indem die Cache Layer gespeichert werden können. Dieses wird dann mit --cache-repo "bee42/kaniko-cache" spezifiziert. Ausserdem mounten wir den Order /cache im lokalen Filesystem um den Prozess weiter zu beschleunigen.
Im obigen Befehl haben wir keinen lokalen Path angegeben, da wir nun mit --destination ein Repository angeben,in welches das Image direkt gepusht wird. Um eine andere Registry zu wählen, kann man den Inhalt der auth.json anpassen.

Fazit

Wir sehen, dass Kaniko noch nicht so intuitiv und einfach zu benutzen ist, wie es mit dem Docker Daemon geht, aber eine durchaus praktikable Alternative darstellt um Container Images zu bauen.

Ausserdem ist es bei weitem nicht die einzige Alternative, OCI Images zu bauen. Hier findet ihr noch ein paar weitere Möglichkeiten, wie man fernab von Docker Inc. Images bauen kann:

• Jib ist eine Alternative extra für Java, welche besonders hohe Schnelligkeit, daemonless und sogar repeatable builds bieten will.
• Orca baut direkt auf runc auf. Ebenfalls ohne root und daemon.
• Introduction von Kaniko