Best Practises
Zuletzt geändert von Thomas Steinbach am 2017/06/29 12:54
- diese Seite gibt Best Practices zum Erstellen von Images mit Dockerfiles
- diese sind nach Empfehlung des Autors von ganz wichtig bis nützlich geordnet
- nach ein wenig Hintergrundwissen gibt der letzte Satz/Anstrich die Best Practice wieder
Inhalt
- der /tmp-Ordner
- apt-get install ohne Interaktion
- Scripte im Dockerfile starten
- SIGTERM durchreichen
- build context sauber halten
- häufig ändernde Startscripte
- Image direkt von einem Host auf einen anderen kopieren
der /tmp-Ordner
- nutzt man im Dockerfile den /tmp-Ordner, wird dieser mit nicht standardisierten Zugriffsrechten erstellt
- im Dockerfile die Zugriffsrechte richtig setzen:
RUN chmod 777 /tmp
apt-get install ohne Interaktion
Siehe Paketverwaltung
Scripte im Dockerfile starten
- wird im Dockerfile mit RUN ein Script gestartet, funktioniert dies nur, wenn das Script mit gültigem Shebang startet. z.B.: #!/bin/bash
SIGTERM durchreichen
- das stoppen eines Containers sendet SIGTERM lediglich an den Prozess mit der PID 1, den im Container gestarteten Prozess
- dies ist oft ein Nutzerscript, welches die eigentlichen Dienste startet. Die Dienste werden dann nicht über SIGTERM informiert und mit SIGKILL abgewürgt
- im Startscript sollte SIGTERM abgefangen werden und die Dienste sauber beendet werden
#!/bin/bash
trap stopServices SIGINT SIGTERM
stopServices() {
echo 'Stopping services...'
# ... run all stop instructions and scripts here
echo 'service2 stopped'
exit
}
trap stopServices SIGINT SIGTERM
stopServices() {
echo 'Stopping services...'
# ... run all stop instructions and scripts here
echo 'service2 stopped'
exit
}
build context sauber halten
- der build context ist das Verzeichnis, in welchem das Dockerfile liegt
- der gesamte Inhalt wird bei einem Build zum docker-deamon geschickt
- im build context kann innerhalb einer .dockerignore-Datei zeilenweise angegeben, welche Dateien und Ordner davon auszuschließen sind
- dennoch sollte der build context frei von build-fremden Dateien gehalten werden, und in einem größeren Dockerprojekt z.B. in den Unterordner /build_context ausgelagert werden
häufig ändernde Startscripte
- ... muss man vielleicht nicht unbedingt im Container verpacken
- sondern können zur Laufzeit eingehangen werden
Dockerfile:
CMD ["opt/myapp/bin/start.sh"]
Container-Start:
sudo docker run -d -v $PWD/myapp:/opt/myapp author/image
Image direkt von einem Host auf einen anderen kopieren
- pv installieren
- folgendes Script unter /usr/local/bin/dcp abspeichern
#!/bin/bash
docker save "$1" | gzip | pv | ssh "$2" 'gunzip | sudo docker load'
docker save "$1" | gzip | pv | ssh "$2" 'gunzip | sudo docker load'
- anschließend kann das Image mit dcp <image> <target-host> auf den Zielhost kopiert werden.