Hallo,
On Tue, May 07, 2019 at 09:10:45PM +0200, Uwe Kleine-König wrote:
Ich kenne das Docker-Universum eigentlich überhaupt
nicht, aber bei
"Hier, lade dieses Image runter und verwende das" ist mein Reflex so
ähnlich zu antworten wie Du auf das curl | php oben.
Vor ein paar Wochen, als es Google+ noch gab, habe ich auf selbigen
diesen Meme gelesen:
"docker run" ist das neue "curl | bash"
:-)
Aber: auch Andreas beginnt mit seinem Dockerfile nicht "auf der grünen
Wiese", sondern basiert auf Image ubuntu:18.04.
Sowohl ubuntu:18.04 als auch das von mir vorgeschlagene php:7-stretch
sind "offizielle" Images vom Docker Hub. Offiziell bedeutet hier,
dass die Images von der Firma Docker Inc. in Zusammenarbeit mit dem
jeweiligen Hersteller (Canonical bzw. PHP/Zend) die Images erstellt
und eine gewisse Zusicherung abgibt, dabei keinen Mist gebaut zu haben.
Die offiziellen Images haben nach meiner Erfahrung eine ordentliche
Qualität.
Daneben gibt es inoffizielle Images, die jeder User nach Erstellung
eines Accounts auf
hub.docker.com selber hochladen kann. Man erkennt sie
am dem Image-Namen vorangestellten Usernamen. Ein Beispiel ist das
von mir veröffentlichte Image hweidner/galera:
https://hub.docker.com/r/hweidner/galera
Wenn man eine Anwendung als Image für Docker paketiert, bewegt man
sich zwischen zwei Extremen. Man kann auf einem sehr generischen
Basis-Image aufbauen (z.B. ubuntu, debian oder sogar scratch, d.h. dem
leeren Image) und dann alles, was man benötigt, per länglichem Dockerfile
herstellen. Damit hat man viel Kontrolle, kann aber auch viel falsch
machen. Oder man nimmt ein Basis-Image, das dem gewünschten schon recht
nahe kommt, und kommt mit einem entsprechend kurzen Dockerfile aus. Meine
Erfahrung ist, dass man mit der zweiten Variante besser bedient ist,
sofern man weiterhin bei offizielles Basis-Images bleibt.
Der Grund, warum ich den curl | php Ansatz kritisiert habe, ist die
fehlende Reproduzierbeit, die eigentlich ein Kernbestandteil der
Arbeit mit Dockerfiles sein sollte. Ein Docker Build sollte stets
das gleiche Ergebis liefern, solange sich
- das Basis-Image,
- das Dockerfile selbst, und
- die von außen einkopierten Assets
nicht geändert haben. Die CI/CD Tools im Docker-Umfeld prüfen genau
diese Situationen und bauen dann bei Bedarf ein neues Image.
Es ist nicht prinzipiell schlecht, für den Bau eines Images auf Downloads
aus dem Internet zurück zu greifen; das ganze Open Source Universum lebt von
der Verbreitung über das Internet. Nur wäre die in meinen Augen bessere
Vorgehensweise, den Installer außerhalb des Dockerfile herunter zu laden,
zusammen mit den anderen Build Assets mit git o.ä. zu versionieren und dann
im Dockerfile nur noch mit COPY oder ADD in das Image zu übertragen.
Mal ein krasseres Beispiel: Vor ein paar Tagen habe ich diese Zeile in
einem Dockerfile gefunden.
(Quelle:
https://github.com/go-gitea/gitea/blob/master/Dockerfile)
RUN [...] echo "git:$(dd if=/dev/urandom bs=24 count=1 status=none | base64)" |
chpasswd
Das heißt: Es wird während des Docker Build 192 Bit Zufall erzeugt, mit
Base64 codiert und im Image als Passwort des Users git gesetzt. Alle
ausgelieferten Images haben somit das selbe Passwort. Das Passwort ist
sicherlich, so wie es erzeugt wurde, schwer zu knacken. Nur: wie will man
bei einem nicht-reproduzierbaren Build nachweisen, dass das Passwort im
ausgelieferten Image tatsächlich genau so erzeugt wurde, und nicht eine
Backdoor ist?
Gruß, Harald