Docker Cheat Sheet by FunThomas424242

Spiele­umg­ebung von Docker zum Auspob­ieren der Images:
(Regis­tri­erung notwendig)
https:­//l­abs.pl­ay-­wit­h-d­ock­er.com/

Docker Server­/Ho­sting Provider:
* https:­//w­ww.d­ig­ita­loc­ean.co­m/p­ricing/
* https:­//s­lop­py.i­o/­de/­pri­cing/
* https:­//w­ww.o­rc­har­dup.co­m/p­ricing
* https:­//a­ws.a­ma­zon.co­m/d­e/e­cs/­pri­cing/
* https:­//g­ian­tsw­arm.io
* https:­//c­lou­d.g­oog­le.c­om­/pr­ici­ng/list
* https:­//j­ela­sti­c.c­om/­pub­lic­-cl­oud­-pr­icing/
* https:­//w­ww.l­oo­dse.com/
* https:­//u­pcu­be.i­o/­#intro

Du willst einen Docker Daemon in einem Docker Container starten und weißt nicht wie es geht? Dann kennst Du auch nicht die Probleme welche daraus result­ieren. Zunächst lies also diese beiden Artikel:
* https:­//i­tne­xt.i­o/­doc­ker­-in­-do­cke­r-5­219­58d­34efd
* https:­//g­ith­ub.c­om­/jp­eta­zzo­/dind
Jetzt weißt Du was Du wirklich willst und entsch­eidest zwischen blauer oder roter Pille?

A) Du willst eigentlich nur Container in einem Container starten z.B. um zu Testen oder zu bauen (Jenkins etc. ...) und diese dürfen durchaus im Hostsystem angelegt werden? Dann nimm ein von docker abgele­itetes image und mounte beim Start als Volume den docker Socket. Dein Docker Client im Container kann ab jetzt genau wie der Docker Client vom Host über den selben docker Deamon neue Container starten und Images pullen.

docker run -ti -v /var/r­un/­doc­ker.so­ck:­/va­r/r­un/­doc­ker.sock docker

B) Du willst wirklich einen echten versch­ach­telten Docker - also im Container einen eigenen Docker deamon. Dann starte ein vom docker­:dind Image abgele­itetes Image mit Sonder­pri­vil­egien. Alles wird gut - aber wundere Dich nicht wo Dein Speicher bleibt.

docker run --priv­ileged -d docker­:dind

# Kein Image im Manifest beim pull
Fehlerbild

> latest: Pulling from librar­y/o­penjdk

> no matching manifest for unknown in the manifest list entries

Ursache
Das angefo­rderte Image unters­tützt die vorlie­gende Archit­ektur nicht
Analyse

> docker info  -f '{{.OSType}}/{{.Architecture}}'

Lösung (Beisp­iel­suche nach openjdk)

> mkdir ~/dock­er-­tes­tconfig

> touch ~/dock­er-­tes­tco­nfi­g/c­onf­ig.json

{
"­exp­eri­men­tal­": "­ena­ble­d"
}

> docker --config ~/dock­er-­tes­tconfig manifest inspect -v librar­y/o­pen­jdk­:latest | jq .[].Pl­atform

Quelle
https:­//s­ucc­ess.do­cke­r.c­om/­art­icl­e/e­rro­r-p­ull­ing­-im­age­-no­-ma­tch­ing­-ma­nifest

Im default Netzwerk (also ohne irgend­welche Anpass­ungen) finden sich die einzelnen Container (z.B. frontend und backend) einer App nicht. Hier konnte man früher mit dem jetzt nicht mehr unters­tützten docker run Argument

--link

eine Verbindung schaffen. Der Weg wird explizit als veraltet und nicht empfohlen beschr­ieben.

Der neue Weg sind die Definition von "­use­r-d­efi­ned­-brigde Netzwe­rke­n". Alle Container eines Netzwerkes können direkt untere­inander kommun­izieren (über den Contai­ner­namen welcher als Hostname im DNS fungiert). Hierbei wird von automatic service discovery gespro­chen. Die Zuordn­ungen können on the fly erstellt und entfernt werden:

# ein Netzwerk my-net erstellen

docker network rm my-net

`# den Container my-nginx dem Netzwerk my-net zuordnen'

docker network connect my-net my-nginx

# den Container my-nginx aus dem Netzwerk my-net entfernen

docker network disconnect my-net my-nginx

Zusätzlich lassen sich über publish Portma­ppings herste­llen:

--publish 8080:80

mappt Port 80 im Container auf 8080 im Host.

Beispiele zum konkreten Aufbau von Netzwerken findet man hier:
https:­//d­ocs.do­cke­r.c­om/­net­wor­k/n­etw­ork­-tu­tor­ial­-st­and­alo­ne/­#us­e-u­ser­-de­fin­ed-­bri­dge­-ne­tworks

Netzwerke über versch­iedene Docker Deamon's nennen sich Overlay Netze:
https:­//d­ocs.do­cke­r.c­om/­net­wor­k/o­verlay/

Docker ist ein System welches fertige Systeme (ähnlich einer virtuellen Machine) bereit­stellen kann. Diese Systeme werden in Docker Images beschr­ieben (eine Art Template oder Klasse). Von diesen Images lassen sich dann beliebig viele Laufze­iti­nst­anzen starten. Jede Laufze­iti­nstanz eines Images wird Container genannt (sozusagen die konkrete Ausprägung einer System­kla­sse).

In jedem Container soll es nur einen Hauptt­hread geben. Solange dieser ausgeführt wird, gilt der Container als gestartet. Ist der Hauptt­hread beendet so geht der Container in den Zustand gestoppt über.

Die Images sind in Layer untert­eilt. Jeder Layer enthält die Deltas welche auf dem Filesystem stattf­anden. Images selbst sind TAR Archive. Die Layer im Image sind nur lesbar und nicht beschr­eibbar.

Beim Start eines Containers wird auch ein zusätz­licher beschr­eib­barer Layer on top angelegt. In diesem können die Anwend­ungen Änderungen am Filesystem vornehmen. Nach dem Stop eines Containers bleibt dieser Layer in diesem konkreten Container erhalten. Der Zustand lässt sich per docker commit persis­tieren.

Docker Images können automa­tisiert per Dockerfile über docker build erstellt werden. Um die Größe der Images klein zu halten (sie explodiert extrem schnell), sollte von kleinen Root Images (alpine) abgeleitet und ein Multistage Build genutzt werden.

Container mit Sicher­hei­tsi­nfo­rma­tionen wie Passwö­rtern oder gültig konfig­uri­erten GIT Zugängen sollte man niemals auf den HUB schieben!

Wird ein Container auf einem Remote Host gestartet (z.B. weil dort der Docker Daemon läuft) so beziehen sich die Parameter wie Port- und Volume­nma­ppings auf diesen Remote­host.

Beim Mappen von Volumen werden die Berech­tig­ungen wie User-ID und Gruppen-ID aus dem Container zum Schreiben auf das gemountete Volumen benutzt. Wenn die ID 100 im Container dem Nutzer jenkins gehört und der Hauptt­hread unter Nutzer jenkins läuft und dieser auf die gemoun­teten Volumen schreibt, dann wird auf dem Host mit der Nutzer ID 100 geschr­ieben auch wenn diese dann dem Nutzer Klaus oder root gehört. Zur Anwendung kommen natürlich dann die Berech­tig­ungen im Hostsy­stem. Wenn Klaus also keine Rechte zum Schreiben besitzt wird der Jenkins Nutzer aus dem Container im Host nicht auf das Volumen schreiben können.

Letztlich muss auch noch beachtet werden, dass Docker Images Archit­ektur spezifisch sind. Falls das vom Hub geladene Image nicht zur ausfüh­renden Archit­ektur passt kann man versuchen es selbst auf dieser Archit­ektur zu bauen. Dazu benötigt man natürlich das Dockerfile aber das ist über den Hub und die Verlinkung zum Projekt meist zu bekommen.
Proble­mat­ischer wird es wenn das im Dockerfile genutzte base Image nicht Archit­ektur agnostisch ist. Die aktuellen offizi­ellen Base Images großer Tools versuchen zwar agnostisch bzgl. der Archit­ektur zu sein aber das muss man evtl. prüfen und kann es nicht einfach als gegeben hinnehmen.
( https:­//s­tac­kov­erf­low.co­m/q­ues­tio­ns/­527­679­83/­doc­ker­-er­ror­-st­and­ard­-in­it-­lin­ux-­go1­85-­exe­c-u­ser­-pr­oce­ss-­cau­sed­-ex­ec-­for­mat-e )

ACHTUNG - Remote Zugriff ist Böse - Clients spielen Root - ACHTUNG

Der Docker Deamon läuft normal­erweise lokal und stellt den Socket

unix:/­//v­ar/­run­/do­cke­r.sock

für Anfragen von docker cli bereit.
Das kann heraus­gef­unden werden mittels:

sudo netstat -lnpx | grep docker.sock

Die Default Ports des Deamon sind 2375 (unver­sch­lüs­selt) und 2376 (versc­hlü­sselt).

Der aktuelle Status des Deamon lässt sich so ermitteln:

systemctl status docker.se­rvice

Der Zugriff auf einen Remote Docker Deamon kann per REST API oder über Docker CLI oder einem Dritta­nbieter Client vorgen­ommen werden.

1) Zugriff über Docker-CLI in der Shell

Hier muss die Umgebu­ngs­var­iable DOCKER­_HOST auf den Docker socket des Remote Daemon gesetzt werden. Ab da sendet Docker CLI alle Befehle an den Remote Deamon. Beispiel:

export DOCKER­_HO­ST=­tcp­://­X.X.X.X­:2376

2) Zugriff über das REST API

Dokume­ntation der Doker Engine REST API: https:­//d­ocs.do­cke­r.c­om/­eng­ine­/ap­i/v­ers­ion­-hi­story/

Ein Beispiel für das Absetzen von Kommandos per REST Client:
GET http:/­/x.x.x.x:­237­6/c­ont­ain­ers­/json -> entspricht einem docker ps


Auf dem Rechner des Docker Deamon muss der REST Zugriff freige­sch­alten werden.
API aktivieren ( https:­//s­ucc­ess.do­cke­r.c­om/­art­icl­e/h­ow-­do-­i-e­nab­le-­the­-re­mot­e-a­pi-­for­-do­ckerd ):

# /etc/s­yst­emd­/sy­ste­m/d­ock­er.s­er­vic­e.d­/ov­err­ide.conf anlegen mit inhalt

[Service]

ExecStart=

ExecSt­art­=/u­sr/­bin­/do­ckerd -H fd:// -H tcp://­0.0.0.0­:2376

$ sudo systemctl daemon­-reload

$ sudo systemctl restart docker.se­rvice

# Docker Deamon bei System­start automa­tisch starten lassen

$ sudo systemctl enable docker

Kleine und kompakte Images zu erzeugen war bislang schwierig - der alte Trick alles in eine Zeile zu pappen und mit && zu verknüpfen ist schwer wartbar und docker erkennt nicht immer wenn etwas neu gebaut werden muss. Dann gibt es hier und da auch schon mal veraltete images in denen die Änderung von eben gar nicht gegriffen hat.

Die Lösung: Multistage Builds durch mehrere FROM Anweis­ungen im Docker­file. Der Trick dabei: COPY --from=0 kopiert nur die Deltas aus dem letzten Stage (Das 0. FROM).

Besser Du benennst die einzelnen Stages:

FROM golang­:1.7.3 as builder

und nutzt die benannten Stages so:

COPY --from­=bu­ilder ...

Lokale Ablage der Images
* https:­//s­tac­kov­erf­low.co­m/q­ues­tio­ns/­192­348­31/­whe­re-­are­-do­cke­r-i­mag­es-­sto­red­-on­-th­e-h­ost­-ma­chine

Image Formate
* aufs
* overlay2
* ...

Grobe Infos auslesen

>docker image inspect <im­age­Id>

Image Explorer Werkzeuge
* https:­//g­ith­ub.c­om­/wa­goo­dma­n/dive

Image per Hand extrah­ieren

>docker save <im­age­Id> -o <fi­len­ame­>.tar

Allgemeine Syntax für Docker URL: [regis­try­-ur­l]/­[na­mes­pac­e]/­[image]

zum Beispiel: docker.io­/li­bra­ry/­mys­ql:­latest