Sie haben sich schließlich der Gnade der Container ergeben und festgestellt, dass sie viele Probleme lösen und viele Vorteile haben:
- Container sind unveränderlich: Betriebssystem, Bibliotheken, Ordner und Anwendungen - da all dies direkt im Container gespeichert ist, sind Sie zu 100% sicher, dass das in der Qualitätssicherung getestete Image immer in Produktion geht. Und es wird genauso funktionieren.
- Leichte Container: Ein Container verschwendet keinen Speicher. Anstelle von Hunderten von Megabyte und Gigabyte benötigt ein Container nur Speicher für den Hauptprozess.
- Container sind schnell: Ein Container startet so schnell wie ein normaler Linux-Prozess. Nicht Minuten, sondern buchstäblich Sekunden.
Viele glauben jedoch immer noch, dass Container virtuelle Maschinen sind, und vergessen ihre wichtigste Eigenschaft ...
Vergängliche Behälter
Aufgrund der Verfügbarkeit sollten Sie Ihren Umgang mit Containern ändern.
Und hier ist, was auf keinen Fall getan werden sollte, um die Vorteile von Containern nicht zu verlieren:1. Es ist nicht erforderlich, Daten im Container zu speichern. Während des Lebenszyklus können Container aufgehängt, zerstört und ersetzt werden. Wenn die Anwendung in einem Container ausgeführt wird, sollte Version 1.0 dieser Anwendung ohne Datenverlust und andere Probleme problemlos auf Version 1.1 geändert werden können. Wenn Sie also Daten speichern möchten, müssen diese darauf geschrieben werden. Dann müssen Sie jedoch darauf achten, dass die beiden Container nicht an dieselbe Stelle schreiben, um die Daten nicht zu beschädigen. Überprüfen Sie daher, ob Anwendungen Daten korrekt in den gemeinsam genutzten Speicher schreiben.
2. Die Anwendungsbereitstellung muss nicht aufgeteilt werden. Einige Leute denken, dass ein Container dieselbe virtuelle Maschine ist. Und die meisten von ihnen glauben, dass Anwendungen in vorhandenen Containern bereitgestellt werden sollten. Tatsächlich ist dies auch möglich, insbesondere in der Entwicklungsphase, wenn ständig debuggt und bereitgestellt wird. Sie sollten jedoch die CD-ROM mit kontinuierlicher Lieferung zur Übertragung an die QS-Abteilung oder die Produktion nur als Teil ihres eigenen Images eingeben. Denken Sie daran: Behälter sind unerschütterlich.
3. Sie müssen keine großen Bilder erstellen. Ein großes Bild ist schwieriger zu verteilen. Daher sollte das Image nur die Dateien und Bibliotheken enthalten, die zum Starten des Anwendungsprozesses wirklich benötigt werden. Sie müssen keine unnötigen Pakete installieren oder Updates ausführen (yum update), die eine neue Ebene im Image erstellen und viele Dateien darauf schreiben.
4. Verwenden Sie keine einschichtigen Behälter. Um mehrschichtige (mehrstufige) Dateisysteme effektiv zu nutzen, erstellen Sie immer separate Schichten für das Betriebssystem, für die Definition des Benutzernamens, für die Konfiguration und schließlich für die Anwendung selbst. So wird es einfacher, Bilder neu zu erstellen, zu pflegen und zu verteilen.
5. Sie müssen keine Bilder aus laufenden Containern erstellen. Verwenden Sie mit anderen Worten nicht den Docker-Commit-Befehl, um ein Bild zu erstellen, da solche Bilder nicht reproduzierbar sind. Verwenden Sie stattdessen immer ein Dockerfile oder andere S2I-Tools (Source-to-Image), die die Reproduzierbarkeit gewährleisten. Darüber hinaus können Sie in Dockerfile Änderungen problemlos verfolgen, wenn Sie sie im Quell-Repository (git) speichern.
6. Sie müssen nicht nur das neueste Tag verwenden. Dieses Tag ist so etwas wie SNAPSHOT für Maven-Benutzer. Aufgrund der Vielschichtigkeit des Container-Dateisystems sind Tags sehr nützlich. Sie können jedoch eine unangenehme Überraschung erwarten, wenn Sie beispielsweise nach einer monatelangen Pause beschließen, ein Bild zu erfassen, und plötzlich feststellen, dass die Anwendung nicht mehr gestartet wird, weil die übergeordnete Ebene (FROM in der Dockerfile-Sprache) durch eine neue Version ersetzt wurde, die keine Abwärtskompatibilität unterstützt. Oder weil die falsche Version aus dem Build-Cache abgerufen wurde, auf den Sie gewartet haben. Darüber hinaus sollte das neueste Tag auch beim Bereitstellen von Containern in der Produktion vermieden werden, da Sie nicht verfolgen können, welche Version des Images gestartet wird.
7. Es ist nicht erforderlich, mehr als einen Prozess in einem Container auszuführen. Container eignen sich ideal für einen einzelnen Prozess (http-Daemon-Daemon, Anwendungsserver, DBMS). Andernfalls können alle möglichen Probleme auftreten, z. B. das Durchsuchen der Protokolle oder das separate Aktualisieren von Prozessen.
8. Es ist nicht erforderlich, Anmeldeinformationen in einem Image zu speichern. Verwenden Sie hierfür Umgebungsvariablen. Verschreiben Sie keine Anmeldungen und Passwörter im Bild. Verwenden Sie stattdessen Umgebungsvariablen, um relevante Daten aus Quellen außerhalb des Containers abzurufen. Das Postgres-Bild ist ein gutes Beispiel dafür, wie man das richtig macht.
9. Prozesse müssen nicht als Root ausgeführt werden. „Docker-Container werden standardmäßig als Root ausgeführt. (...) Während sich die Technologie weiterentwickelt, werden möglicherweise andere, sicherere Standardstartoptionen angezeigt. Unter den gegenwärtigen Bedingungen kann die Root-Anforderung als Bedrohung angesehen und möglicherweise nicht in allen Umgebungen bereitgestellt werden. Um einen anderen Benutzer als root anzugeben, für den der Container gestartet wird, wird die USER-Direktive verwendet. “(Auszug aus der Anleitung für Docker-Bildautoren)
10. Sie müssen sich nicht auf IP-Adressen verlassen. Jeder Container hat eine eigene interne IP-Adresse, die sich nach dem Neustart des Containers ändern kann. Wenn die Anwendung oder der Mikrodienst mit einem anderen Container kommunizieren muss, verwenden Sie Umgebungsvariablen, um den gewünschten Hostnamen von einem Container in einen anderen auf die Portnummer zu übertragen.
Erinnerst du dich? Jetzt können Sie es sicher verwenden. Praktische Tipps zur Verwendung von Containern finden Sie in unserem Blog.