Von:
Datum: 28. Mai 2021
Bei der Migration von Docker zu ContainerD ändert sich nicht nur der Name sondern auch die Kommandozeilenaufrufe. Die Docker-Images bleiben kompatibel und können in ContainerD ausgeführt werden.
Im Folgenden findest du eine Gegenüberstellung der wichtigsten Kommandos von Docker und ContainerD einander gegenübergestellt.
ContainerD benutzt Namespaces um Zugriffsrechte verwalten zu können. Daher muss immer auch ein Namespace angegeben werden, auf den sich der aktuelle Befehl bezieht. Aus Convenience Gründen empfiehlt sich die folgende Erweiterung des lokalen Environments:
Mit dieser Konfiguration könnten die Aufrufe in diesem Cheatsheet verkürzt werden. Um die Kommandozeilen
Bei einem Pull der Images ist bei ContainerD stets eine Version anzugeben. Im Gegensatz zu Docker wird bei fehlender Versionsnummer nicht "latest" angenommen.
Lokale Daten von ContainerD werden unter den Verzeichnissen
Einloggen in den jeweiligen Imagehub, und herunterladen der Images.
Bereitstellen des Images aus dem lokalen Hub.
Ausgabe der aktuell im Namespace befindlichen Images.
Wichtig ist hier zu beachten, dass ContainerD und Buildah separate Speicher verwenden, das heißt ein mit Docker oder Buildah gebautes Image steht nicht direkt in ContainerD zur Verfügung.
Ausgabe der aktuell laufenden Container. Heraussuchen der ID des zu stoppenden Containers und stoppen des Containers.
Ausgabe der aktuell laufenden Container. Heraussuchen der ID des zu entfernenden Containers und entfernen des Containers.
Neuen Container starten basierend auf dem Image p8/xyz:10.
Entfernt Container automatisch, sobald diese gestoppt sind.
Wenn mehrere Container auf einem System laufen sollen, welche untereinander kommunizieren, vereinfacht diese Konfiguration die Kommunikation der Container untereinander.
Häufige Variante die im Container laufende Software von außen zu konfigurieren.
Einen Container mit privileged Rechten zu starten sollte wohl überlegt sein, da dies dem Container auf dem jeweiligen System Root Rechte einräumt.
Auf diese Weise kann ein Container Daten auf Daten außerhalb des eigenen Containers zugreifen, bzw Daten direkt auf die Festplatte/Storage Lösung des Hostsystems schreiben. Dies dient meist dazu, die durch die jeweilige Anwendung geschriebenen Daten über die Lebenszeit des Containers hinaus zu erhalten.
In der Regel werden Container gestartet, um längere Zeit zu existieren, und nicht automatisch geschlossen werden, wenn die Shell beendet wird, welche den jeweiligen Container gestartet hat. Diese Container werden detached gestartet, das heißt sie laufen nicht auf der Konsole, sondern im Hintergrund.
Images vom lokalen Rechner entfernen.
Ein laufender Docker Prozess produziert entsprechende Ausgaben auf der Konsole auf Stdout und Stderr. Diese können bei Docker durch die Benutzung des Log Commands eingesehen werden.
Ein ähnlicher Vorgang ist mit ContainerD nicht möglich. Den Befehl zum Abruf der Logs eines laufenden Containers ist nicht möglich. Wie mit dem Log eines Containers verfahren wird, ist abhängig davon, wie der Container gestartet wird.
Wird keine Option spezifiziert, so wird das Log standardmäßig auf die Konsole des CTR Prozesses ausgegeben.
Bei Containern die durch das Kubelet, also Kubernetes gestartet werden, werden die Logs unter /var/log/pods/${NAMESPACE}_${POD_NAME}-${POD_UUID}/${CONTAINER_NAME}/${RESTART_COUNT}.log abgelegt.
In dieser Datei befinden sich einzelne Log-Zeilen, welche den Timestamp, den Output-Kanal, sowie die eigentliche Log Zeile beinhaltet. Damit kann zu jeder Zeit bestimmt werden, ob es sich um eine Ausgabe auf Stdout oder Stderr handelt.