[offtopic] Docker images und Zugriff auf Shares

Begonnen von bugster_de, 26 Juli 2018, 09:14:45

Vorheriges Thema - Nächstes Thema

bugster_de

kam mir auch schon in den Sinn auf nginx zu schwenken; man hört ja nur Gutes. Aber die verschiedenen Apache Configs habe ich auf dem heutigen Server bereits vorhanden, so dass sie nur angepasst werden müssen. NGINX hab ich noch nie gemacht und das möchte ich mir im ersten Schritt nicht auch gleich noch antun. Mit der Docker Nutzung habe ich ja die schöne Möglichkeit, alles nach einander umzustellen. Sprich erstmal mit Apache starten und wenn das alles läuft, mach ichs mit einem nginx Container wieder kaputt so dass ichs dann wieder reparieren kann :-)


bugster_de

aber eins noch zu den Usern von oben:
wenn ich das richtig sehe, dann sollte der User, der auf dem Host den Container startet nicht der gleiche User sein, wie der auf den der root im Container gemapped wird. Und der mapping user darf auch nicht zur Gruppe docker auf dem Host gehören, denn sonst kann root im Container sich einen neuen Container starten und damit Zugriff auf den Host kriegen.

Sprich:
User docker_creator auf dem Host gehört zur Gruppe docker und führt docker run, docker start etc. aus
User docker_mapper auf dem Host wird in der daemon.json eingetragen und auf ihn wird root und aufwärts gemapped. Er darf nicht in der Gruppe Docker sein.
Die ID von docker_creator darf nicht im Mapping Bereich von docker_mapper wie in /etc/subuid angeben liegen, denn sonst kann man im Container so lange die User ID hochzählen, bis man einen User hat, der auf den docker daemon zugreifen darf und kann damit auf den Host springen.

Wernieman

#32
Wir haben hier einen Proxi auf den Wird-Computer gesetzt. Quasi als "Loadbalancer". Ob der Container dann apache, nginx oder irgend etwas anderes hat, ist dem proxy exgal.

Dazu dann noch ein Script geschrieben, was auf docker-events reagiert und automatisch die Config für den proxy baut.

der jwilder-proxy hat den Nacheil, das er in allen docker-proxy-netzen sein muß. Steht dort auch als Einschränkung. Dadurch, das wir den proxy auf dem Wird-Rechner haben, können wir viele docker-netzwerke abbilden und auch unter kupernetis oder docker-swarm arbeiten. Die docker-Container slber müssen dann auch nicht extern erreichbar sein (sofern es http/https-Protokolle sind)
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

bugster_de

@Wernieman: ich verstehe grösstenteils nur Bahnhof :-)

ZitatWir haben hier en Proxa auf den Wird-Computer gesetzt.
Wenn ich den Satz mal umschreibe: "wir haben hier einen Proxy auf den Wirt-Computer gesetzt". Richtig?
heisst also, der Proxy Server läuft nicht im Docker sondern direkt auf der Host Maschine? Wenn man den dünn hält (er also nur Proxy macht), dann hat man auch das Thema SW Update für den Proxy-Server gut im Griff.

Ich habe halt die Erfahrung gemacht, dass so mancher Update von Apache dann das ein oder andere Modul nicht mehr zur Verfügung hatte. So geht z.B. meine SVN Server seit geraumer Zeit nicht mehr von aussen zu erreichen, weil bei irgendeinem Apache Update ein Modul wohl raus geschmissen wurde. Ich habe zwar noch eine ganze Weile versucht das wieder hin zu bekommen, aber nicht geklappt und so habe ich dann halt den SVN Zugriff von aussen erstmal raus geschmissen. Und genau von solchen Querabhängigkeiten will ich weg. Jede Applikation kriegt ihren eigenen Container / Compose und somit kann jede Applikation einzeln einen Update erfahren bzw. ein Update kann erstmal ausprobiert werden ohne dass es ggf. gleich Querwirkungen gibt, die man im Moment des Updates noch gar nicht merkt.
Ganz beliebt im Spiel der Querwirkungen ist auch owncloud, php-Versionen und php-Module etc.

Wie gesagt, ich bin Privatmann mit Familie und auch anderen Hobbies. Sprich ein update muß so einfach sein, dass ich es ohne große Orgie einmal wöchentlich machen kann. Es muß aber auch komplex genug sein, dass ich es nicht mal eben auf dem Sofa beim Fernsehen ohen Nachdenken mache und mir dann was zerschiesse.
Deshalb habe ich mir jetzt einen extra User angelegt, der zur Gruppe docker gehört der aber kein Shell Login hat. Somit muß ich immer sudo -u mein_docker_user docker xxx machen. Diese Befehlszeile ist lang genug, damit man mal kurz nachdenken muß, was man da tut aber nicht zu komplex, so dass man es sich nicht merken kann.
Die Container selber haben nun immer drei Standard-Volumes, die auf den Host gemappt sind:
- Daten (also z.B. die html Seiten des Webservers)
- Konfigurationen (also z.B. alles was in /etc/apache2 drin steht)
- logfiles, so dass ich die mit einem einfachen Script auf dem Host einsammeln kann und automatisiert durchforsten

Ablauf zum Update eines Containes wäre dann wie folgt
- container stoppen
- Kopie der Daten und Konfiguration erstellen
- Image auf Basis Dockerfie neu bauen, da ich in meinen Dockerfiles am Anfang erst mal apt-get update, upgrade etc. drin habe
- Container wieder neu starten

Die Speicherung der Daten und Konfigs in einem Host Volume hat den Vorteil, dass sie automatisch in meinem Backup enthalten sind. Ich habe schon beim jetzigen Server auf allen Festplatten im Server drei Unterverzeichnisse: Hoch, Mittel, Egal.
Alles was in Hoch drin ist hat ein doppeltes Backup: es wird auf eine zweite Platte im Rechner ge-tared und als rotierendes Backup abgelegt sowie mittels rsync auf eine Cloud ausserhalb des Hauses gespiegelt (rsync löscht hier keine Files sondern fügt nur die neuen hinzu bzw. macht den Update der bestehenden und ist nur unidirektional konfiguriert)
Alles was in Mittel drin ist ist nur im rotierenden Backup auf die zweite Platte enthalten. Das backup Script auf dem Host klappert alle Festplatten ab und sicher genau nach diesem Muster. Das Script selber läuft unter einem extra User, der auf den Host nur Leserechte hat und somit, selbst wenn es mal "Amok" läuft auch nichts kaputt machen kann.
Alles was in Egal drin ist, wird gar nicht ge-backupt.
Somit also Daten und Konfiguration nach Hoch, Logfiles nach Egal.

Uff. Overkill? Vielleicht. Aber mein Bruder hatte seine ganzen privaten Fotos nur auf seinem Laptop und als da die Festplatte kaputt war, waren die Familienbilder inkl. der Kinderfotos aus 10 Jahren futsch. Er hat über 1.000,- € bei einem Festplatten-Recovery Betrieb bezahlt und war danach froh, dass sie zumindest einige der Kinderbilder retten konnten. Das ist der Nachteil der digitalen Zeit: man muß sich halt echt um das Backup kümmern. Aber das sagt ja deine Signatur schon aus :-)




Wernieman

"inkl. der Kinderfotos aus 10 Jahren futsch"
..... 4 ....

Die Obige Anzahl gibt die Laufende Anzahl Leute wieder, von denen ich weiß, das Sie Bilder durch Rechnerdefekte verloren haben.  2 davon Kinderbilder. Das zum Thema Backup ....
(In der Zahl ist Dein Beispiel includiert, war vorher also 3...)

nginx hat den Vorteil, das er schlank und supereinfach als Proxy ist. Kann ich empfehlen. Alternativ wäre hier z.B: ein richtiger Proxy wie ha-proxy (oder squid etc.), aber dort geht die Komplexität wieder hoch.

Also ein Linux + docker + nginx ist relativ einfach upzudaten. Da Schwierigste ist dabei eigentlich docker.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

bugster_de

Ok, ok ich hab es ja verstanden: nginx ist die Macht 😀
Erstes Ziel ist es aber trotzdem den neuen Server schnell produktiv zu bekommen und die komme ich im ersten Schuss schneller hin, wenn ich die bestehenden Kontakte umziehe und anpasse. Im zweiten Schritt kann ich dann einzelne Applikationen durch was anderes ersetzen.

ZitatDa Schwierigste ist dabei eigentlich docker.
Dem ist so, da ja jedes Image eigene Spezialitäten mit bringt. Ich habe mir jetzt jeweils die Kommandozeilen für die Container notiert überlege aber gerade, ob ich mir nicht ein Script pro Container erstelleelches die Update Prozedur wie oben beschrieben automatisiert.
Ich hab gestern Abend noch mein Wordpress mit MySQL umgezogen. Es war eine echte Kommandozeilen Orgie.

bugster_de

Hi,

so die wichtigsten Dienste, die ich brauche, um den Server in Betrieb gehen zu lassen laufen jetzt unter Docker.  Allerdings sind alle Container auf einen User des Host gemappt. Ich habe nicht heraus gefunden, wie ich für jeden Container einen extra User nehme und ich in einem halben Jahr noch weiß, was ich da getrieben habe.

ZitatLies Dich mal in "docker-compose" ein. Wird von den meisten Stiefmützterlich behandelt, macht aber langfristig das Leben einfacher.
Hab ich getan und auch erste Container Ansammlungen damit gebaut. Das hat mich aber zwei Nachtschichten gekostet. Teils, weil docker-compose, sagen wir mal, nich im Aufbau befindlich ist und teils weil bestimmt Kombinationen aus Images einfach nicht zusammen laufen. So habe ich es z.B. nicht geschafft ownCloud 10.0.9 und mysql 8 aus dem Container raus ans Laufen zu bekommen. Ich musst OC 10.0.3 und mysql 5.6 nehmen und danach ind en jeweiligen Containern updates machen. wordpress mit mysql 8 funktioniert hingegen top.

Damit ich es in Zukunft leichter habe, habe ich mir jetzt für jede Container Sammlung drei Dateien gemacht
- das dockerfile (logisch)
- eine .env Datei (auch logisch)
- eine Batch-Datei, die eventuell vorhandene Daten der Container auf dem Laufwerk kopiert, dann die docker-compose oder im Falle eines Eigenbau Images die docker build und create Funktionen mit der langen Aufrufliste an Parametern aufruft. Das dient auch gleichzeitig der Dokumentation.

Desweiteren agiert immer noch der Apache als Proxy Server und der Server war auch schon mal probehalber am Netz. Geht also soweit und nun kann ich mich beim nächsten Regentag an den Umzug der Festplatten machen

bugster_de

Hi,

da ich hier viel Infos und Hilfe erhalten habe, dachte ich mir ich gebe mal Rückmeldung, wie der Stand der Dinge nun so ist.
der eigentliche Plan war, den neuen Server sukzessive aufzusetzen und wenn er läuft dann mit dem live zu gehen und den alten abzuschalten. Wir hatten vor ca. 6 Wochen einen Stromausfall bei uns und danach wollte der alte Server nicht mehr booten, da das Netzteil defekt war, also kam Schwung in die Sache und ich haben den neuen schneller in Betrieb genommen, als ich eigentlich wollte.

Die Lernkurve bei Docker war doch etwas holpriger als gedacht.
Meine Major Learnings sind:

  • das Beste vorneweg: wenn man eine coole, neue Software entdeckt, die man mal ausprobieren möchte, dann ist Docker genial. Man zieht sich oder baut sich einen Container, testet die Software und wenn sie nichts ist, dann kann man sie rückstandslos entsorgen.
  • auf dem Docker Hub gibt es viele Images von fragwürdiger Qualität. Bei so manchem Service habe ich Stunden zugebracht, um es dann doch nicht ans Laufen zu bekommen oder zumindest nicht so ans Laufen zu bekommen, wie man sich das wünscht. Deshalb habe ich die allermeisten Container nun auf Basis eigener Images mit eigenem Dockerfile gebaut und nehme mir sehr oft die jeweiligen Dockerfiles der wackeligen Images als Startpunkt her. Generell bin ich von den Images der lunuxserver.io Jungs sehr angetan. Die sind immer gut
  • die eigenen Images baue ich mir auf Basis des Ubuntu 18.04 Images. Das ist zwar nicht so schlank wie das Alpine Image, aber es ist einfacher zu warten. Ich bin kein Vollzeit admin und um sich z.B. in die Images einzuloggen hilft es mir, dass es immer das gleiche Kommando ist (docker exec -it container /bin/bash) sowie innerhalb des Containers die update Commands
  • Lese und Schreibrechte sowohl im Dateisystem als auch bei Hardware Geräten in Kombination mit einem gemappten root User sind spannend. Solange der Dienst im Container als root läuft, welche auf dem Wirtsystem auf einen speziellen User gemapped ist, kann man das in den Griff bekommen. Wenn aber der Dienst im Container unter einem anderen User läuft (z.B. Apache als www-data), dann ist diese User ID auf dem Wirtssystem nicht bekannt. Es gibt hier kein generelles Kochrezept; man muß sich einfach Container für Container ansehen und die Lösung erarbeiten
  • Zugriff auf Hardware, die auf dem Wirtssystem dem root gehört löse ich momentan so, dass ich per cron Job beim Booten den Besitzer der Hardware umstelle. Ist gefühlt keine gute Lösung, aber es geht bisher
  • das mappen des root Users im Container auf einen anderen User auf dem Wirtssystem geht eigentlich nur mit überschaubarer Komplexitätä, wenn man nur einen User auf dem Wirtssystem hat. Sprich alle Container-root mappen auf den gleichen User auf dem Wirt. Bei allem anderem ist mir die Kompexität zuviel geworden
  • die allermeisten Dienste in den Containern stellen ein Webinterface auf dem Port 80 bereit, welcher dann auf einen anderen Port auf dem Wirt gemappt werden muß. Da verliert man, wenn man nur genügedn Dienste am Laufen hat, den Überblick da die Container IPs dynamisch zugewiesen werden. Ich muß mir das nochmal anschauen, wie ich den Containern feste IPs vergeben kann

Momentan habe ich folgende Dienste am Laufen:
Apache als Reverse-Proxy, mit dem die Dienste dann aus dem Netz erreichbar sind. Sowohl Dienste auf dem Server als auch andere Dienste (FHEM) im Haus
Plex (Basis: Eigenbau)
Owncloud (Basis offizielle owncloud Image, aber das ist m.E. nicht toll und wird noch auf Eigenbau umgestellt)
TVHeadend mit 3 DVB-C Karten (auf Basis linuxserver.io Image; sehr gut!)
Zentrales Kodi / Kodi-Datenbank für die verschiedenen Kodis im Haus (Basis linuxserver.io)
verschiedene Gameserver (Assetto Corsa, Project Cars 2) für private Gaming Sessions mit Freunden (Basis: Eigenbau)
Teamspeak Server als Kompanion zu den Gameservern (Eigenbau)
einen Blogserver, in dem ich mir alle möglichen Dinge merke (z.B. wie man die Container baut) (Eigenbau)
einen Sourceforge Server, auf dem ich meine verschiedenen Code-Snippets ablege (z.B. FHEM Scripte) (Eigenbau)

Und im Staging als Dienste, um die mal auszuprobieren, bevor ich sie wirklich nutze
nextcloud (offizielles Image)
Emby (offizielles Image)
Photoshow (Web-Album aller Bilder) (Basis: linuxserver.io)
Einen Apache mit cgi / perl / phyton drin als rumspiel Einheit, bevor Änderungen gleich live gehen (Eigenbau)

Da ich hier im Forum auch einiges an Hilfe erhalten habe beim Start mit Docker, gerne Fragen, wenn ich helfen kann.

Wernieman

Würde Dir empfehlen, anstatt die HTTP-Ports vom Docker-Container auf Wirts-Ports umzustellen, einen Proxy (wie z.B. nginx) davorzustellen. Kann Dir auch gerne dafür ein Script geben. Ist die Einfachere Lösung.

bezüglich "root-.Zugriff":
Die meisten Container sollten doch eigentlich mkeine Zugriff "nach außen" benötigen. Alle Daten liegen innerhalb des Containers und werden dort auch innerhalb verarbeitet.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

bugster_de

#39
Hi,

Skript wäre gut und würde mich interessieren.

Momentan habe ich das per Apache gemacht so wie du schreibst: der Container hat z.B. 172.16.0.10 mit einem Dienst auf Port 80. Dieser Dienst ist auf dem Host dann z.B. auf Port 8080 gemappt (mit der Option -p 8080:80 bei docker create) und somit ist unter 192.168.0.50:8080 der Dienst erreichbar (192.168.0.50 ist die IP des Host im netz zu Hause). Der Apache Container mit Reverse Proxy mappt dann z.B. die Location meinedns.com/owncloud auf 192.168.0.50:8080. Beim Zugriff von außen ist der Apache auch für die Verschlüsselung mit HTTPS zuständig.
Die Zuweisung der 172.16.0.10 passiert beim Starten des Containers automatisch
Das geht alles zwar so wie es soll, da den Containern (bisher) immer die gleiche IP zugewiesen wird aber gefühlt fände ich es schöner, wenn ich da feste Adressen hätte. Kann nicht genau sagen wieso, ist halt gefühlt :-)

ZitatDie meisten Container sollten doch eigentlich keine Zugriff "nach außen" benötigen. Alle Daten liegen innerhalb des Containers und werden dort auch innerhalb verarbeitet.
Nicht ganz. Die Mediendateien liegen bei mir auf dem Filesystem des Host und das aus mehreren Gründen

  • ich kann mehrere Container auf diese Daten zugreifen lassen ohne dass ich die Daten duplizieren muß. So werden z.B. unsere Familienfotos durch Plex, Photoshow, Kodi lesend zur Wiedergabe benutzt
  • ich laufe nicht Gefahr, dass ich durch versehentliches Löschen des Container Images auch gleich die Daten mit lösche, wenn man mal einen Container etwas anders konfiguriert neu aufsetzt
  • ich kann die Zugriffsrechte (lesend/schreibend) besser steuern. Die Container laufen alle mit einem gemappten User, welcher auf die Mediendateien nur lesenden Zugriff hat. Somit kann auch ein Dienst, der mal "Amok" läuft oder durch falsche Klicken eines Users im Dienst mir nicht die Dateien löschen
  • das Dateisystem des Host ist in drei Bereiche aufgeteilt: 0_High, 5_Medium und 9_Low. Dies sind die Prios für das Backup. Alles was in den Ordneren für 0_High liegt erhält doppeltes Backup: einmal auf dem Server selbst auf eine 2. Platte (rotierendes, inkrementelles Backup) und einmal als rsync in eine Cloud ausserhalb unseres Hauses (auf einen Server bei einem Freund von mir, der im Gegenzug seine Daten zu mir synced), alles was in 5_Medium ist, geht nur in das einfache Backup auf die zweite Platte im Server und alles was in 9_Low ist hat gar kein Backup. Damit ich nun diese Dateisystem Komplexität weder ind en Containern noch auf den User Shares abbilden muß, mounte ich mittels mhddfs diese Daten in ein Share namens media. Darin befinden sich dann Unterordner z.B. für Biider. Diese sind bereits read-only gemountet und beim docker create mappe ich nur auf /media/Bilder ebenfalls mit der ro Option.
    Alle Container, die auch mal Medien schreiben müssen (z.B. Aufnahmen bei TVHeadend oder den Code des Sourceforge) erhalten einen extra Ordner auf dem Host nun aber mit Schreibzugriff, der wieder in 0, 5, 9 gemappt ist. TV-Aufnahmen brauchen kein Backup also 9, SVN Code braucht doppeltes Backup, also 0. TV-Aufnahmen werden dabei ebenfalls wieder in das /media Share mittels mhddfs eingeblendet, so dass sie z.B. via Plex zur Wiedergabe bereitstehen
  • die Configs der Container (z.B. Plex-Datenbank, TVHeadend Config) liegen ebenfalls in Ordnern des Hostsystems, so dass sie nun auch in mein zentrales Backup-Skript automatisch eingebunden sind, da auch hier wieder 0, 5, 9 gilt. Die Configs liegen dabei in 0, da sie zumeist eh nicht viel Speicherplatz brauchen, die Plex-DB liegt in 5

Und mit dem gesagten war es mir wichtig, dass der root im Container nicht der root auf dem Host ist, denn nun kann ich fein-granular zuweisen, was ein Container mit welchen Daten machen darf.
Kompliziert? Ja sicherlich, aber mit 0, 5, 9 bin ich nun nach meinem Verständniss gegen Festplatten-Defekte, Einbruch mit Server_Diebstahl, Brand- und Wasserschaden geschützt. Ja, ich benötige für diese Backup-Strategie einiges an Festplatten-Kappa, aber ganz ehrlich: eine 4 TB Platte kostet ~100,- € aber das ist immer noch billiger wie alle Familienfotos zu verlieren


Wernieman

Gegen Backups habe ich nicht, im Gegenteil. leider kenne ich mittlerweile 5 Leute, die Bilder verloren habe. Im mir bekannten schlimmsten Falle alle Bilder vom ersten Lebensjahr des ersten Kindes. Das ist nicht wiederholbar.


Bezüglich port 80/443:
Hier in der Firma haben wir auf so einem System  ein NGINX laufen. Zusätzlich ein Script, was bei einem hoch/runtrefahren eines Containers die COnfig des NGINX-Proxy ändert.
Inspiriert wurde das ganze durch den "Wilder-Proxy", ein passender Docker-Container. Der hat nur den Nachteil, das alle Container im gleichen "Docker-Netz" sein müssen. Das ist hier nicht der Fall.

Habe das Projekt lider nur im Internen GIT .... müsste mir sonst mal überlegen, des auf githost zu publizieren ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

bugster_de

ich hab schon überlegt auf nginx für den Proxy zu wechseln. Dann habe ich Traefik entdeckt un dder bindet sich automatisch in die Docker Netzwerke ein. Somit macht er dann den Update der IP Adressen etc. automatisch. Ich spiele gerade damit rum um mal zu schauen, ob das was ist.

Aber anderes Thema im gleichen Kontext:
mein Owncloud läuft an einer Stelle doch noch nicht wie es soll.
ich habe einen Container mit Apache als Reverse-Proxy udn einen Container mit Owncloud. Der Apache Container ist von aussen auf dem Port 443 (https) erreichbar und im Netz innen über 443 und 80 (http) zu erreichen. Der Apache Container ist auf die Ports 80 und 443 vom Host gemappt, der Owncloud Container ist auf den Port 8082 vom Host gemappt. Host hat die Ip 192.168.2.50.
Ich erreiche owncloud unter folgenden Zugriffen (dieses klappt also):
http://192.168.2.50/owncloud
https://192.168.2.50/owncloud
http://192.168.2.50:8082/owncloud

ich erreiche die Ownloud Seite im Browser nicht unter
https://meine-dyndns.de/owncloud

Die verschiedenen Owncloud Desktop-Clients und Handy Clients können aber via https://meine-dyndns.de/owncloud  synchronisieren. Das klappt wunderbar und ist auch das wichtigste. Aber ich steige nicht dahinter, warum ich Owncloud durch den Apache erreichen kann, auch mittels hhtps, nur halt das Webinterface nicht aufgeht.

<location /owncloud>
  ProxyPass http://192.168.2.50:8082/owncloud
  ProxyPassReverse http://192.168.2.50:8082/owncloud
  ProxyHTMLEnable On
  ProxyHTMLURLMap /  /
  ProxyHTMLURLMap /owncloud /owncloud
  SetOutputFilter INFLATE;proxy-html;DEFLATE
</location>