Hallo Flugpiloten,
ich habe mittlerweile ein halbwegs funkltionierendes Dockerfile zu Laufen gebracht:
---- # cat Dockerfile FROM ubuntu:18.04 MAINTAINER Andreas Delleske post@dellekom.de
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -yq --no-install-recommends \ apt-utils \ curl \ # Install apache apache2 \ # Install php 7.2 libapache2-mod-php7.2 \ php7.2-cli \ php7.2-json \ php7.2-curl \ php7.2-fpm \ php7.2-gd \ php7.2-mbstring \ php7.2-mysql \ php7.2-xml \ php7.2-zip \ php7.2-intl \ php-imagick \ # Install tools openssl \ nano \ mc \ graphicsmagick \ imagemagick \ ghostscript \ mysql-client \ iputils-ping \ locales \ ca-certificates \ && apt-get clean && rm -rf /var/lib/apt/lists/*
# Install composer RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
# Set locales RUN locale-gen en_US.UTF-8 en_GB.UTF-8 de_DE.UTF-8 fr_FR.UTF-8 it_IT.UTF-8
# Configure PHP for TYPO3 #COPY typo3.ini /etc/php/7.2/mods-available/ RUN phpenmod typo3 # Configure apache for TYPO3 RUN a2enmod rewrite expires RUN echo "ServerName localhost" | tee /etc/apache2/conf-available/servername.conf RUN a2enconf servername # Configure vhost for TYPO3 #COPY typo3.conf /etc/apache2/sites-available/ #RUN a2dissite 000-default #RUN a2ensite typo3.conf
EXPOSE 80
WORKDIR /var/www/html
#RUN rm index.html
CMD apachectl -D FOREGROUND
---- Apache, PHP laufen. ich hab auch phpMyAdmin ineinen Ordner im Webroot installiert.
Kann man was verbessern?
Nun habe ich außerhalb des Docks einen MYSQL (MariaDB)-Server am laufen.
Er kam mit Openmediavault als Paket, ich kann von der Kommandozeile (außerhalb Docker) drauf zugreifen, also MySQL-Rootpaswort stimmt. Port 3306 auf dem Hostrechner ist auch offen.
Nun will ich phpMyAdmin beibringen daß er nicht auf "localhost" sucht, sondern entweder auf der IP der physischen Maschine 192.168.22.65 oder auf der Docker-internen IP des "Gateway" 172.17.0.1 - beides funzt nicht.
Bisher habe ich MySQL immer über phpMyAdmin bedient und stehe jetzt ein wenig auf dem Schlauch welchen Hahn ich noch aufdrehen muß...
Weiterhin sehr dankbar für sachdienliche Hinweise.. :-)
Hallo,
ich habe mittlerweile ein halbwegs funkltionierendes Dockerfile zu Laufen gebracht:
Kann man was verbessern?
Ein paar Sachen, die mir auffallen:
Es fehlt noch die Angabe von "VOLUME /var/www/html" oder ähnliches. Dort sollen ja vermutlich die Daten und PHP-Skripte liegen, daher wäre es unpraktisch, wenn diese bei jedem docker rm gelöscht würden.
In einem Docker Container ist es üblich, Logfiles nicht in Dateien (die bei jedem docker rm gelöscht würden) zu schreiben, sondern Access-Logs an die Standardausgabe und Error-Logs an den Standardfehlerkanal zu schicken. Das sollte in die Apache Konfiguration noch eingebaut werden. Spätestens wenn der Container mal mit Kubernetes orchestriert wird, macht sich das bezahlt.
Sowas hier...
# Install composer RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
...macht den Build nicht-reproduzierbar. Das Ergebnis hängt vom Inhalt der angegebenen Webseite zum Build-Zeitpunkt ab. Außerdem handelt man sich damit schnell Sicherheitsprobleme ein. (Es ist für die Webseite problemlos möglich, unterschiedliche Inhalte auszuliefern, je nachdem ob die Seite interaktiv oder beim Docker Build heruntergeladen wird.)
Außerdem gibt es den Composer auch in Ubuntu, warum installierst du ihn nicht von dort?
Last not least: zum Lernen ist es sicherlich hilfreich, so ein Dockerfile mal von Hand zu schreiben. Für die produktive Nutzung würde ich aber eher auf eines der offiziellen PHP Images zurückgreifen, z.B. php:7-stretch
Gruß, Harald
Hallo,
On 5/7/19 2:50 PM, Harald Weidner wrote:
Sowas hier...
# Install composer RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
...macht den Build nicht-reproduzierbar. Das Ergebnis hängt vom Inhalt der angegebenen Webseite zum Build-Zeitpunkt ab. Außerdem handelt man sich damit schnell Sicherheitsprobleme ein. (Es ist für die Webseite problemlos möglich, unterschiedliche Inhalte auszuliefern, je nachdem ob die Seite interaktiv oder beim Docker Build heruntergeladen wird.)
Außerdem gibt es den Composer auch in Ubuntu, warum installierst du ihn nicht von dort?
Last not least: zum Lernen ist es sicherlich hilfreich, so ein Dockerfile mal von Hand zu schreiben. Für die produktive Nutzung würde ich aber eher auf eines der offiziellen PHP Images zurückgreifen, z.B. php:7-stretch
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.
Liebe Grüße Uwe
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
Hallo Harald und Uwe,
das war alles total hilfreich, vielen Dank!
Ich nutze auch schon composer aber eigentlich nur zum Entwickeln und baue dann den heruntergeladenen Kram fest in "mein Produkt" ein - im Unterschied zum üblichen Verfahren nicht in den Webroot (public/) sondern außerhalb (src/). Klar muß ich dann immer nachverfolgen welche Sicherheitsprobleme bekannt sind aber wenn ich immer alles automatisch updaten lassen würde müßte ich das genauso tun - für composer und seine zig Abhängigkeiten die er schon mitbringt.
Ich hab zum Glück bisher nur drei Libraries die ich einsetze: PHPMailer, tFPDF und HTMLPurifier. Der Rest sind ein paar PHP modules.
JavaScript kommt mir auf absehbare Zeit nicht ins Haus :-) - ich versteh nicht genug um damit sicher umzugehen, vor allem bin ich sehr skeptisch bei den ganzen gegenseitig abhängigen libraries, die Moden die da so kursieren und eingefangene Problemen durch Inkonsistenzen zwischen den APIS der Dinger.
Irgendwann bald will ich meinen Code auditieren lassen (hättet Ihr eine Empfehlugn durch wen? SySS Tübingen?) und wenn man Pakete inkludiert müßte man eigentlich jedes dieser Pakete mit auditieren lassen. Soviel Geld hab ich nich :)
Danke nochmal!
Hallo,
On Wed, May 08, 2019 at 10:22:49AM +0200, Andreas Delleske wrote:
JavaScript kommt mir auf absehbare Zeit nicht ins Haus :-)
Auf dem Server (node.js oder so) kann ich das verstehen. Aber kommt man heutzutage noch ohne browserseitiges JS aus?
Irgendwann bald will ich meinen Code auditieren lassen (hättet Ihr eine Empfehlugn durch wen? SySS Tübingen?)
Der einzige Dienstleiser, den ich kenne, ist Felix von Leitner (https://www.fefe.de) bzw. seine Firma Code Blau (https://www.codeblau.de/). Ich bin mir allerdings nicht sicher, ob die auch PHP auditieren; kenne ihn eher im C/C++ Umfeld.
Gruß, Harald
Hi Harald,
JavaScript kommt mir auf absehbare Zeit nicht ins Haus :-)
Auf dem Server (node.js oder so) kann ich das verstehen. Aber kommt man heutzutage noch ohne browserseitiges JS aus?
Naja, ich betrachte es schon als mein Alleinstelliungsmerkmal :-)
Und klar geht es. Man hat halt keine Vorschläge von Suchwörtern mehr während mal tippt, das meiste andere läßt sich anders lösen.
BTW ich finde schon daß die Standards sich so entwickeln sollten daß man Dinge hinbekommt die man sonst nur mit JS schaffen würde. Geht ja auch in die Richtung mit den transitions, canvas und so; Uploadbalken..
Ich habe gefühlsmäßig ein grundsätzliches Problem damit, anderen in meinem Kontext Sachen machen zu lassen die ich weder sehen noch beeinflussen kann. ich finde es ziemlich wichtig daß HTML eine offene Schnittstelle ist, JS macht sie obskur.
Der einzige Dienstleiser, den ich kenne, ist Felix von Leitner (https://www.fefe.de) bzw. seine Firma Code Blau (https://www.codeblau.de/). Ich bin mir allerdings nicht sicher, ob die auch PHP auditieren; kenne ihn eher im C/C++ Umfeld.
Uh, der is ja auch superberühmt aber vielen Dank! Manche lächeln ja über PHP :) - eines Tages wird man ziemlich sicher auch PHP-Code automatisiert in Python überführen können, warum soll ich da jetzt schon mit rummacken wenn Python 2.7 immer noch da ist.. und so.. Python-Hosting hab ich noch selten gesehen..
-
Andreas Delleske -
Harald Weidner -
Uwe Kleine-König