[offtopic] Docker images und Zugriff auf Shares

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

Vorheriges Thema - Nächstes Thema

bugster_de

Hi Leute,

ich weiß, das ist offtopic, aber da hier im Forum so viele Leute mit Know-How unterwegs sind dachte ich ich versuche es einfach mal.

Ich bin gerade dabei meinen alten Ubuntu Server durch eine neu-aufgebaute Maschine zu ersetzen. Der alte Server hat in Summe 6 Festplatten mit Daten und alle Anwendungen sind flat auf dem System installiert (also keine VM, Docker oder sonstiges). Beim Neuaufbau möchte ich dies nun durch Docker Images für die einzelnen  Anwendungen ersetzen, da dies wohl durchaus den Wartungsaufwand des Systems in Grenzen hält. Die Daten auf den Festplatten sind Stand heute nur einmal vorhanden aber werden von verschiedenen Anwendungen benutzt. Z.B. liegt all meine Musik an einer Stelle und wird von Squeeze-Server, Plex und Samba (für Sonos) benutzt. Manche Anwendungen haben dabei nur Lese Rechte auf die Daten, andere haben Lese/Schreibrechte. Ein Skript besorgt dann das Backup der Daten, die man natürlich nur einmal backupen muß, da die Daten ja nur einmal vorhanden sind. Auch macht das Script ein Backup der Konfig-daten (z.B. auch mysql datenbank für den Owncloud-Server)

Das würde ich beim neuen System natürlich gerne auch wieder so machen aber im neuen System liegen dann ja alle Anwendungen in ihrem jeweiligen, eigenen Docker Image. So ganz schlau werde ich aber aus der Docker-Doku nicht. Man kann wohl ein Volume anlegen und dies dann in verschiedenen Docker Images nutzen. Heisst aber, ich müsste die verschieden Daten dann in das Volume verschieben? Andere Methode scheint zu sein, die Daten auf dem Laufwerk im Docker zu mounten. Hat das Performance Nachteile?


Falls sich jemand fragt "ja aber wenn das heute mit flacher Installation doch läuft, warum auf Docker umbauen?" oder "warum überhaupt ein neuer Server, wenn der alte doch läuft?"
- gerade ownCloud und TVHeadend haben mir schon so manche Nacht gekostet, nach einen update die Dinger wieder ans Laufen zu bekommen. TVHeadend hat typischerweise einen gewissen zeitlichen Versatz zwischen Erscheinen einer neuen Ubuntu Version und der Bereitstellung der Pakete. Von Docker verspreche ich mir, dass ich nicht immer alles gleichzeitig hochziehen muß
- der bisherige Server ist ein Core-2 Duo, den ich mal am Wertstoffhof aus dem Container gezogen habe. Da ich festgestellt habe, dass alle Endgeräte mit h264 oder h265 mit mp3-stereo als erstem Audio Stream sehr gut umgehen können, encode ich alle Videos auf dieses Format mit ffmpeg. Die Performance von ffmpeg ist dabei aber doch arg überschaubar. Der neue Server baut auf einem Pentium G4560 auf, der das in Hardware kann.
- um beim Streamen von Inhalten Bandbreite zu sparen würde ich gerne die Streams in Echtzeit umkodieren. Also nicht das TV-Signal in MPEG2 sondern in h264/h265 streamen. Mit einem Core2-Duo aber nicht mal ansatzweise machbar






Wernieman

Du kannst in docker auch ein Pfad reinmounten:
Siehe Doku: https://docs.docker.com/storage/bind-mounts/

Was übrigens gerne vergessen wird ... die Container sollten auch upgedatet werden!
- 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

Danke für die Info. Ich hatte das zwar schon mal gelesen, aber noch nicht ganz verstanden, wie es sich mit den Access Rights verhält. Die allermeisten Ordner sind bei mir für die allermeisten Applikationen nur als read-only zugreifbar und dies steuere ich Stand heute über user,group,others Rechte der Folder.

ZitatWas übrigens gerne vergessen wird ... die Container sollten auch upgedatet werden!
Auf jeden Fall ! Ich verspreche mir aber von den Dockern dabei folgendes:
- ich kann die einzelnen Docker unabhängig voneinander updaten und vorallem unabhängig vom OS. Schönes Beispiel ist immer ein Release Upgrade von Ubuntu oder nur dem Kernel, den man vorallem wegen Sicherheit natürlich zügig einspielen sollte. Führt aber dann dazu, dass z.B. TVHeadend nicht mehr geht oder ich den OS Upgrade zurück halten muß, bis dann endlich ein TVHeadend zur Verfügung steht.
- ich kann ein neues Docker-Image erstmal ausprobieren. Ich stoppe das alte Image, verschiebe es an eine andere Stelle, ziehe mir das neue Image und probiere es aus. Wenn es geht dann gut, wenn es Probleme gibt kann ich erstmal das alte Image wieder nutzen.
ich weiß: man sollte solche Spielerein auf einem Test-System machen und nicht auf dem Live-System. Ich habe aber die Erfahrung gemacht, dass ich die Feinheiten der Nutzung eigentlich nur im Real Betrieb sehe.

Wernieman

Kleiner Hinweis: Verwende Dock hier im Betrieb aus genau den Gründen ;o)

Da ich es beruflich mache (aber noch ohne kupernetes o.Ä.) , gehe ich (bzw. wir) über "docker-compose" und tragen die Konfig in eine nette Datei ein., Die ist dann auch einfacher Versionierbar (git o.Ä.)
- 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

chris1284

#4
Ich halte es so (habe plex,openhab,habridge und homekit auf docker umgestellt) das jeder container einen eigenen User inkl Group hat (ohne Home und ohne Shell logon. Dazu einen eigenen Ordner für jeden container mit den Volumes (mit -v eingebunden, für zb config, usw). Auf die Ordner at nur root und die group des users Zugriff. Für die Einbindung gestehender Ordner (zb Filme) habe ich dann den User (zb plex) in die dort berechtigte "Filme-write" Gruppe aufgenommen. Leider muss man sagen da man ja keine  2. Gruppe "Filme-read" berechtigen kann

Leider ist es in der Windowswelt doch besser geregelt, hier kann ich zich Gruppen auf einen Ordner unterschiedlichst berechtigen. Wie bekommt man das unter Linux hin?
Ein User, Eine Gruppe, und alles anderen sind doch arg beschränkt. Bei shares geht es ja zum glück über samba besser fein zu berechtigen aber auf dem host...
Gibts hier Lösungen für zb owner [irgend ein User] full, Group[1] full, Group[2] read, rest nichts ?


kaputt

Zitat von: chris1284 am 27 Juli 2018, 18:08:02Gibts hier Lösungen für zb owner [irgend ein User] full, Group[1] full, Group[2] read, rest nichts ?
evtl. Access Control Lists (kurz ACL).
Gruß aus L.E.
Uwe

Bei U/Linux hilfreich aber nicht nötig, bei Windows nötig aber nicht hilfreich!
Rechtschreibfehler sind beabsichtigt und Ausdruck meiner Persönlichkeit

Wernieman

Die Lösung IST ACL ... übrigens macht es Windows auch nicht anders ;o)
- 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

chris1284

danke für den Hinweis, hatte ACL nicht als extra aktivierbare Option auf dem Schirm, warum sowas nicht default aktiviert ist.... :o

Wernieman

Weil man es auf einem "Singel-User-System" oder auch einfachem Serversystem einfach nicht braucht. Da macht es die Sache einfach nur komplizierte ....
- 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

Hi,

wusste ich doch, dass hier Leute unterwegs sind die sich auskennen :-) Danke !

Ich habe das alles jetzt mal aufgesetzt und die ersten Docker Container laufen so wie sie sollen und auch (fast) wie ich mir das gedacht habe.

Zitatdas jeder container einen eigenen User inkl Group hat
das war auch mein Gedanke und wollte das so aufsetzen. Wenn ich z.B. shares habe, auf die mehrere Container zugreifen sollten wollte ich mir eine Gruppe machen und dann die einzelnen Docker User dieser Gruppe hinzufügen.
ABER: das ganze geht schief, wenn der Docker Container auf Hardware zugreifen muß. Dies ist z.B. bei TVHeadend der Fall mit Zugriff auf die /dev/dvb Fernsehkarten. Diese gehören auf dem Host System typischerweise root:root und werden nach jedem reboot auch wieder dem root:root zugeordnet. Das kann man zwar mit udev Regeln am Host auch hinbekommen, aber dies ist eine Ecke im Linux, bei der meine Kenntnisse doch arg dünn bis nicht vorhanden sind. Muß ich mich mal reinfuchsen.
Auf manchen Systemen gehören die DVB Karten wohl root:video  und dann würde es reichen, den docker user der Gruppe video zuzuordnen. Bei meinem Ubuntu 18.04 ist es aber wie gesagt root:root und ich möchte auf keinen Fall den Docker User der Gruppe root zuordnen

Weitere "Baustelle" bei der ich noch nicht ganz durchgestiegen bin: mein Host System wird ein Ubuntu 18.04.1 LTS, manche Docker-Images setzen aber auf älteren Ubuntu Images auf (z.B. TVHeadend auf 14.04). Ich bin da etwas skeptisch vorallem bei Containern die dann auch von außen erreichbar sein werden und damit natürlich voll im "Wind" des Internets stehen. Klar findet man auf dem Hub auch Images mit neuerer Basis aber momentan orientiere ich mich bei der Image Auswahl vorrangig an Images, die von Docker selbst kommen oder falls nicht vorhanden solche die eine große Anzahl an positiven Sternen und Downloads haben. Wie auch immer: sollte ich da in das Image rein gehen und eine apt-get dist-upgrade machen oder mir im Fall der Fälle doch selbst ein Image bauen?
In das Bauen eigener Images habe ich mich eingelesen und es scheint ja machbar zu sein.

Zitatüber "docker-compose" und tragen die Konfig in eine nette Datei ein
das wird auch noch ein Thema werden, wenn mehrere Container für eine Applikation laufen müssen. Z.B. mysql und owncloud

Bringt mich aber zu einer weiteren Frage: momentan baue ich die Container von Hand mit dem docker create commando. Bei manchen von den Images ist aber die Konfigzeile endlos lang und ich würde mal vermuten, in einem halben Jahr weiß ich die nicht mehr auswendig. Baut ihr euch da Scripte, so dass man den Update eines Images quasi automatisch machen kann?

Wernieman

Nur mal kleine Anmerkungen auf die Schnelle. Für größere ist es mir aktuell zu heiß/schwül

Zitat von: bugster_de am 02 August 2018, 17:52:56
Weitere "Baustelle" bei der ich noch nicht ganz durchgestiegen bin: mein Host System wird ein Ubuntu 18.04.1 LTS, manche Docker-Images setzen aber auf älteren Ubuntu Images auf (z.B. TVHeadend auf 14.04). Ich bin da etwas skeptisch vorallem bei Containern die dann auch von außen erreichbar sein werden und damit natürlich voll im "Wind" des Internets stehen. Klar findet man auf dem Hub auch Images mit neuerer Basis aber momentan orientiere ich mich bei der Image Auswahl vorrangig an Images, die von Docker selbst kommen oder falls nicht vorhanden solche die eine große Anzahl an positiven Sternen und Downloads haben. Wie auch immer: sollte ich da in das Image rein gehen und eine apt-get dist-upgrade machen oder mir im Fall der Fälle doch selbst ein Image bauen?
In das Bauen eigener Images habe ich mich eingelesen und es scheint ja machbar zu sein.
das wird auch noch ein Thema werden, wenn mehrere Container für eine Applikation laufen müssen. Z.B. mysql und owncloud
Ubuntu 14.04 ist noch voll im Support. Außerdem gibt es auch Images, die mit einem minnimalerem Basissystem (alpine?) gebaut werden. Lasse die Images am besten, wie sie sind. Nur wenn Du es wirkoich brauchst, d.h. die Images verbessern mußt, dann ...


Zitat von: bugster_de am 02 August 2018, 17:52:56
Bringt mich aber zu einer weiteren Frage: momentan baue ich die Container von Hand mit dem docker create commando. Bei manchen von den Images ist aber die Konfigzeile endlos lang und ich würde mal vermuten, in einem halben Jahr weiß ich die nicht mehr auswendig. Baut ihr euch da Scripte, so dass man den Update eines Images quasi automatisch machen kann?
Antwort: docker-compose
- 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

Danke. Ich schaue mir das Docker-compose dann mal an.

Images selber bauen wollte ich eigentlich vermeiden wenns geht aber das Basis Image sollte schon Ubuntu bleiben, denn sonst fang ich bei alpine wieder an die Install und Upgrade Befehle zu lernen.

Thema Zugriff auf Hardware: selstsam: es gab bereits eine Regel für DVB Hardware, die eine Gruppe zugeordnet hat, aber die greift nicht für den folder /dev/dvb/apater0 sondern nur für alles was da drin liegt. Ich habe mir jetzt also einfach einen cron job beim Boot angelegt, der den Owner und die Gruppe von /dev/dvb/ ändert. Jetzt geht es auch mit einem speziellen user pro container. Keine Ahnung ob das so elegant ist, aber es tut.


Wernieman

Zitatcron job beim Boot angelegt,

Also entweder per udev, per "init-Script" (bzw. systemd) oder ....  aber per cron-job? Alle X-Minuten??
- 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

Hi,

ZitatAlso entweder per udev
udev besitzt heute schon eine Regel, die die Geräte als root:video anlegt ,aber der Folder /dev/dvb/adapter0 bleibt bei root:root. Keine Ahnung wie ich das in einer udev Regel umstelle. Führt aber beim TVHeadend Contaier dazu, dass ich --device=/dev/dvb nur machen kann, wenn der Container unter root läuft, da alle anderen User gar nicht das Recht haben, die Inhalte des Ordners zu sehen. Deshalb also entweder den Besitzer der Geräte und der Folder auf einen anderen User umhängen oder halt 'others' ebenfalls Lese- und Schreibrechte geben. Zeiteres fand ich aber jetzt nicht so sexy

Zitatper "init-Script" (bzw. systemd)
geht natürlich auch

Zitataber per cron-job? Alle X-Minuten??
ich hab ihn mir jetzt mal beim reboot angelegt, da ich eine PCI Karte ja eher nicht im laufenden Betrieb einstecke. Aber Du hast Recht: sollte in der Zukunft mal eine SUB DVB Karte dazu kommen, dann könnte das bei reboot schief gehen. Ich mach die Regel auch noch mal mit alle X Minuten rein.


Wernieman

ZitatIch mach die Regel auch noch mal mit alle X
Genau das fande ich fraglich .... ich würde nicht per cron etwas so entscheidenes alle X-Minuten durchführen lassen.

Ans reboot-hängen .. das hatte ich übersehen ;o)
Gibt übrigens noch X verschiedene Wege, um es umzusetzen ...
- 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

#15
zu meinem Post oben: das Problem beim linuxserver/tvheadend Image is wohl bekannt:
https://github.com/linuxserver/docker-tvheadend/issues/44
https://blog.linuxserver.io/2017/02/19/how-to-set-up-tvheadend-with-your-dvb-t2-receiver/
dort empfehlen sie auch den Owner von /dev/dvb so zu ändern, dass der Container User darauf zugreifen kann.
Mir ist bei der Lösung auch nicht ganz wohl, aber momentan läuft der neue Server ja noch nicht im produktiven Betrieb und ich kann mal schauen, ob es eklige Seiteneffekte geben wird, bevor er produktiv geht. Wenn es keine Seiteneffekte gibt, dann gehe ich erstmal mit dieser Lösung.

Falls Seiteneffekte auftreten kann ich natürlich immer noch jede einzelne Karte mittels --device=/dev/dvb/adapterX an den Container übergeben.

bugster_de

#16
also, ich hab mich jetzt weiter rein gefuchst ind die Docker Geschichte, aber das Thema mit den User Mappings ist doch nicht ganz so leicht.

Wenn ich einen Apache2 Container aufsetze, sieht mein Dockerfile wie folgt aus:
FROM httpd:2.4
COPY ./mydata /usr/local/apache2/htdocs/
USER 1003:1003

der User 1003 ist dabei der User dkr_apache auf dem Host System. Somit sollte nach meinem Verständniss der root im Container (UID=0) auf den user dkr_apache (uid=1003) auf dem Host System gemapped werden.

Wenn ich nun
sudo docker build -f ./Dockerfile -t my_apache2 .
sudo docker run -it --name=apache -p 28080:80 my_apache2

mache, dann erhalte ich die Fehlermeldung:
(13)Permission denied: AH00072: make_sock: could not bind to address 0.0.0.0:80

Ich brauch da mal einen Gedankenstoß, da ich offensichtlich auf dem Schlauch stehe.
Darf der User 1003 auf dem Host System den Port 28080 nicht nutzen? Ich habe extra einen sehr hohen Port zum Test genommen
Oder ist der User im Dockerfile der User der im Container dann die Scahen ausführt? Und wenn ja, wie mappe ich dann den root des Containers auf den 1003 user des Host?

Und wenn ich Dockerfile die Zeile User 1003:1003 weglasse und statt dessen
sudo docker run -dit --name=apache --net=bridge -u 1003:1003 -p 28080:80 -v /mount/int/hd02/0_High/1_Appdata/apache/:/mmdata my_apache2
gehts auch nciht, da der Apache im Container dann ebenfalls nicht hoch kommt.

Und ohne die -u Option
sudo docker run -dit --name=apache --net=bridge -p 28080:80 -v /mount/int/hd02/0_High/1_Appdata/apache/:/mmdata my_apache2
wenn ich dann im Container eine Datei in /mmdata anlege und diese dann auf dem Host System anschaue, dann wurde sie von root erzeugt :-(

in der /etc/docker/daemon-json habe ich:
"userns-remap": "root",
und die /etc/subuid sieht so aus
root:100000:65536

Wernieman

Ports unter 1024 darf nur root anlegen.

Lies Dir mal die Fehlermeldung durch:
(13)Permission denied: AH00072: make_sock: could not bind to address 0.0.0.0:80
- 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

Hi,

danke!
Sprich im Container muß ich apache als root laufen lassen oder Apache auf einen Port > 1024 loslassen oder aber den container mit dem User 1003 und --cap-add starten.

Aber wie schaffe ich es, dass im Container root mit der UID = 0 auf dem Host auf den User dkr_apache mit UID = 1003 gemappt wird? Denn das wäre mir eigentlich am liebsten.

Wernieman

Da wir hier docker mit der Gruppe docker laufen lassen (wird irgendwann zu kupernetis oder docker swarm migriert) kann ich es Dir nicht sagen ...
- 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

#20
Hi,

das heisst ihr führt alle docker Befehle als user docker in der Gruppe docker aus? Sprich dieser User hat dann Zugriff auf den Docker Daemon?

P.S.: ich habe mir jetzt ein eigenes Docker-Image auf Basis Ubuntu:18.04 mit installiertem Apache zum rumprobieren gebaut. Das geht eigentlich schon mal ziemlich gut und hat den Vorteiu, dass ich weiß, was darin konfiguriert wurde und wie ich es umfummeln kann. Scheint zumindest zum Lerne, was bei Docker wie zusammen hängt für mich der Weg im Moment. Bei heruntergeladenen Images wusste ich nicht so ganz genau, ob es jetzt an mir liegt oder das Image entsprechend konfiguriert ist.

P.S.2: sollen wir diesen Thread mal nach Off-Topic verschieben oder hier lassen? Da es jetzt seit kurzem ja ein offizielles FHEM Docker Image gibt würde ich mal vermuten ich bin dann nicht der einzige, der diese Fragen stellt.



Wernieman

Wieso "docker-Befehle"?
ein Docker-Container ein Dienst. Teilweise kümmer sich auch der docker-Deamon um ein start eines Containers, wenn dieser "weg" ist. Als reiner Server-Dienst haben wir damit keinen einzelnen docker-Befehl ... oder ich verstehe Dich jetzt falsch ...
- 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

wenn ich als normaler user folgendes mache:
docker start my_apache
dann kommt eine Fehlermeldung
wenn ich aber
sudo docker start my_apache
mach, dann geht es.  Sprich der root darf die Docker Befehle ausführen, mein normaler User nicht, was so auch erstmal richtig ist.

Wenn ich dich richtig verstehe, dann habt ihr euch einen User names docker angelegt, diesem die Rechte gegeben die obigen Befehle auszuführen und somit wird der Conatiner dann unter dem User docker ausgeführt. Richtig verstanden?

Übrigens: ich hatte einen Denkfehler drin: innerhalb des Containers wird der Apache natürlich NICHT als root ausgeführt sondern als www-data

Wernieman

Wenn ein User in der Gruppe docker ist, kann er Container starten/stoppen.

Aber Achtung: Durch einfaches Tricksen kann er sich über ein Container auch root-.rechte beschaffen
- 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

ha, Danke ! So langsam kommt Licht ins Dunkel. Ich befürchte aber, dass bei mir im Kopf die verschiedenen Docker- und Host-User noch zu nebulös durcheinander gehen, so dass ich noch nicht mal mein Problem sauber beschreiben kann

Wenn ich also sudo usermod -aG docker horst mache, dann darf der User horst docker start my_apache ohne sudo ausführen. Und nun hätte ich erwartet, dass der User root im Container sich auf den User horst auf dem Host mappt. Dem ist aber nicht so. Root im Container ist auch root auf dem Host.

Es wäre aber genau mein Wunsch, dass root im Container sich auf den horst auf dem Hostsystem mapped, denn kann ich dem Horst nur genau die Rechte auf dem Host geben, die er zur Ausfürhung seiner Aufgabe braucht. Da jeder Container tendenziell ein single-trick-pony sein soll, braucht man natürlich auch für jeden Container dann einen User. Initial viel Aufwand, aber die einzelnen Rechte lassen sich fein granular zu teilen.

Wernieman

#25
Security-Technisch sollte man wissen, das es relativ einfach ist, aus einem Container auszubrechen. Anders als z.B. bei einer Virtuellen Maschine.

Sicherheitstechnisch ist die Relation:
nativ auf der Maschine <-> Docker <-> VM

Eigentlich machst Du es eigentlich über die Zuordnung der Fileysteme, d.h. ein Image bekommt nur die Pfade zu sehen, welche es braucht. Eine Zuordnung z.B. über / wäre deshalb ...... negativ

Mann kann per Docher auch einen Container auf einem eigenen User mappen lassen .... nur damit habe ich keine Erfahrung ...
- 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

#26
Oh Mann, jetzt ist bei mir der Groschen gefallen. Der ist sogar so laut gefallen, dass ihr das bestimmt durch das Internet hören konntet :-) Ich schreib das jetzt hier mal nieder als Merker für mich selbst mit der Bitte um Korrektur, falls es doch immer noch nicht stimmt (und ich den Groschen wieder aufheben muß)

Im Prinzip ganz einfach. Ich möchte einen Container mit Apache drin haben. Dazu gibt es auf dem Host einen user namens docker_apache der z.B. die UID 1003 und GID 1003 hat.
In der /etc/docker/daemon.json trägt man dann "userns-remap": "docker_apache", ein. In der /etc/subuid bzw. /etc/subgid trägt man docker_apache:1003:65536 wobei die 1003 hier auch eine beliebig andere Zahl sein kann, aber wenn man die gleiche Zahl nimmt, dann kann man die Rechte auf dem Host mittels dem Namen (hier docker_apache) setzen und muß nicht die UID aus dem subuid nehmen.

Nun kann man den Container mittels docker run bauen. Das muß dann nichtmal mit dem User docker_apache passieren sondern kann jeder andere User sein, der zu der Gruppe docker gehört. Und nun wird der User root im Conmtainer auf den User docker_apache auf dem Host gemapped. Das sieht man z.B. daran, wenn man innerhalb des Containers als root eine Datei in einem Volume erzeugt. Innerhalb des Containers gehört die Datei dem root:root, auf dem Host System gehört sie docker_apache:docker:apache.

Soweit so gut. Aber: da ich nun den Conatiner mit -p 80:80 starten kann heisst das, dass der User, mit dem der Container gestartet wurde offensichtlich das Recht hat auch Ports < 1024 in Beschlag zu nehmen. Das muß dann wohl durch die Gruppenzugehörigkeit docker erreicht worden sein.

ZitatSicherheitstechnisch ist die Relation:
nativ auf der Maschine <-> Docker <-> VM
auch dieser Groschen fiel jetzt. Ich komme halt eher aus der VM Welt und Docker hat dazu im Vergleich weniger Trennung zum Host System.

ZitatEine Zuordnung z.B. über / wäre deshalb
das ist bei obigem schon mal eminent wichtig, aber somit kann ich
1.) nur Folder zuordnen, die für den Container wirklich gebraucht werden
2.) dem Folder die entsprechenden Rechte geben

Ich muß mich jetzt aber nochmal zurück lehnen und neu überlegen, ob Docker der Pfad meiner Wahl ist. Als Ziel hatte ich vorranging eine bessere Wartbarkeit meines Servers, da nicht jedes update auf dem Server gleich in das große Zittern ausartet, ob den nun noch alles geht. Das ist mit Docker auf jeden Fall erreichbar. Eine Verbesserung der Sicherheit kommt auch mit, aber nicht in dem Maße, wie es z.B. eine VM hätte. Docker erhöht die Sicherheit aus meiner Sicht vorallem dadurch, dass es für einen Angreifer erstmal undurchsichtiger ist, mit was er es zu tun hat und dann benötigt er noch das entsprechende Wissen, um aus der VM auszubrechen.
Um aber vorallem die Wartbarkeit des Containers sicher zu stellen müssen die Datzen und Konfigurationen aus dem Container raus genommen werden (Volumes). Also bei Apache z.b. /var/www/html, damit man dann bei Bedarf den Container auf Basis eines neuen ubuntu:latest mit apt-get upgrade im Dockerfile neu bauen kann.

Wie gesagt es gibt noch vile zu lernen, aber so starte ich esrtmal, denn mit diesem Setup kann ich zukünftig auch noch umbauen, wenn meine Lernkurve weiter hoch geht

Wernieman

Genau, alle Pfade mit persistenten Daten (z.B: auch bei DBs) dürfen nicht im Docker-Image liegen, sondern durch Volumen" rausgelinkt sein. Entweder auf dem Host-Dateisstem oder auf docker-volumen. Sonst bekommt man ein Geschwindigkeitsproblem, welches auch so bei der Docker-Doku erwähnt wird.

Gegenüber VMs hat docker den Vorteil, das kein Komplettes 2. System laufen muß, sondern nur die "nötigen" Libarys. Auch kann der SPicher dynamischer verwaltet werden, bei VMs geht er schneller "weg".

Grundsätzlich:
Lies Dich mal in "docker-compose" ein. Wird von den meisten Stiefmützterlich behandelt, macht aber langfristig das Leben einfacher. Mit einer docker-compose.yml kannst Du dann ein "Ökosystem aufbauen". z.B. ein LAMP-System mit DB + Apache in einem Eigenen Netzwerk. So hast Du auch eine Abschöttung, das z.B. der DB-Server nur vom Apache erreichbar ein muß.

Am Anfang schwieriger, am Ende einfacher. Habe hier z.B: ein Zulip-Container per docker-compose aufgebaut, damit ein Update/Neustart (oder Umzug) einfach schneller (und einfacher) geht. Gleichzeitig auch eine Doku, wie die Container gestartet werden.
- 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

Danke. Das Docker-compose steht bei mir eh als nächstes auf der Liste der Einarbeitung, da es sich für mich vorallem mal wie eine gute Möglichkeit angehört hat, mehrere Container, die zusammen gehören auch in einem Rutsch inklusive definierten Startreihenfolge zu starten. Also zuerst den mysql un dann erst Wordpress.

Der ganze Plan sieht wie folgt aus:
- es gibt einen container mit Apache, welcher als Proxy-Server dann von aussen erreichbar ist (deshalb auch der User Heck-Meck). In diesem Container ist nur Apache ohne PHP oder sonstwas drin und er routet nur auf die jeweiligen Container basierten Anwendungen dahinter oder auch die Anwendungen, die auf einem anderen Rechner im Haus laufen (z.B. FHEM). Nach aussen ist auch nur Port 443 für https mit eigenem Zertifikat offen.
- für jede Anwenung gibt es einen Schwung von containern. Z.B. einen Container für Wordpress der seinen eigenen Container für mysql hat. Genauso dann einen für owncloud mit einem eigenen mysql Container, was dann das fein-ziselierte Backup sowie Wartung erleichtert. Diese zusammengehörenden Container (z.B. owncloud mit seinem mysql) müssen dann mittels docker-compose zusammen gefasst werden
- manche Anwendungen brauchen auch nur einen Container (z.B. tvheadend, plex), dann geht das auch ohne compose

Performance beim Zugriff von aussen ist nicht ganz so entscheidend, da ich ja eine sehr limitierte Anzahl an Usern drauf habe und von denen ich mit Abstand der Power-User bin. Einzi der TV Zugriff von aussen braucht vermutlich ganz gut Durchsatz, wobei dies genau der Hauptgrund für den neuen Server ist: encoding in real-time. Sprich der Container encoded den Stream und reicht dann h265 nach aussen weiter

Performance beim Zugriff innerhalb des Netzes ist vermutlich schon entscheidender, denn hier nutzt die ganze Familie die komplette Bandbreite an Multi-Media Möglichkeiten voll aus. Bisher ging ich dabei nicht davon aus, dass auch hier ein Proxy Server dazwischen muß, denn die Mediendateien etc. sind auf dem Server alle read-only gesetzt, so dass auch ein Virus, der von aussen mittels Laptop eingeschleppt wurde die Daten wohl eher nicht zerstören oder verschlüsseln kann. Die Shares sind im Netz auch nicht sichtbar, sprich man kann auch nicht nach ihnen suchen sondern muß sie schon kennen und auch den entsprechenden User plus Passwort wissen.
Im Rahmen der Möglichkeiten sollte ich doch damit gegen Script-Kiddies etc. geschützt sein, oder? Einen professionellen Angreifer, der wirklich Energie und Tage lang Arbeit rein steckt wird das nicht aufhalten können, aber da frage ich mich, warum ich ein Angriffsziel sein sollte.

Router ins Internet ist auch keine Massenware wie Fritzbox oder Telekom Router (auch wenn die echt top sind)







FunkOdyssey

Anstatt Apache2 würde ich es mit folgenden Lösungen machen:
https://github.com/jwilder/nginx-proxy
https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion

In der YML sind es nur 2-3 Zeilen, die für den FHEM-Zugriff ergänzt werden müssen. Ganz einfach.

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>