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