snaxilian schrieb:
Bzgl. Reverse Proxy kannst dir ja mal
https://github.com/nginx-proxy/nginx-proxy ansehen.
Hab ich schon entdeckt, ich will mir aber nicht die Umgebungsvariablen dafür versauen, welche sich z.T. ja auch mit dem Projekt überschneiden können. Docker hat dafür extra eine Label-Sektion eingeführt, nur wird diese leider kaum verwendet. Als Fork gibts davon
https://github.com/adi90x/rancher-active-proxy (
Issue #172), was mit Labels arbeitet, allerdings spielt das wohl nur mit
Rancher zusammen. Irgend ne Fehlermeldung hab ich da bekommen, von wegen dass irgendwelche "metadata" nicht gefunden wurde oder so und der Container dann unnütz ist.
snaxilian schrieb:
Beim Monitoring würde ich jetzt spontan an checkmk oder icinga2 denken.
Sieht schon mal vielversprechender aus, schau ich mir demnächst an. Danke.
snaxilian schrieb:
Aber wie so oft gilt: Die meisten simplen Lösungen sind am Ende doof weil man alles selbst machen muss um ein Ergebnis zu haben und die meisten "fertigen" Lösungen sind doof weil sie zu viel liefern und man ungewolltes wegfiltern muss...
Wie wahr, wie wahr... Bin mit FreshRSS auch nicht zufrieden, aber noch am Glücklichsten im Gegensatz zu tt-rss (selbst damit nen Docker Container aufsetzen ist ne Qual...), selfoss, miniflux, CommaFeed usw.
RalphS schrieb:
”zu restriktiv“ im Sinne von vorkonfiguriert. Mit sowas kann ich nichts anfangen. Plus, “irgendwer” hat was “irgendwie“ hingehustet.
Gut, das ist aber eher ein allgemeines Problem, dass von irgendwo irgendwelcher Code ausgeführt wird. In Projekten wird ja teilweise auch jeglicher Mist aus NPM Packages geladen, die dann teilweise Malware enthalten. Im Docker Hub siehst du allerdings bei den meisten Projekten das Dockerfile selbst oder es sind genügend Links zu Github verlinkt, wo man das Dockerfile einsehen kann. Alternativ gibts noch
dive, womit man von Images das Dockerfile einsehen kann. Projekte ohne Dockerfile schließe ich aber auch kategorisch aus. All zu komplex sind die Dockerfiles aber auch nicht, weshalb man das relativ fix reviewen kann.
Ich nutz bspw. auch nie fertige Images von kleinen Projekten oder Einzelpersonen (außer zum Test), sondern zieh sie mir immer lokal ins Projekt, schau drüber, bau den Container dann selbst und push sie in meine eigene Gitlab Docker Registry zum Projekt. Anders sieht es bei Base-Images wie ubuntu, alpine, nginx, apache, mysql, redis und Co. aus. Die nutz ich natürlich, weil die entsprechenden Projekte ne hohe Reputation haben und ich denen auch entsprechend vertraue.
Ich bezweifel allerdings, dass Jails eine entsprechend hohe Reproduzierbarkeit besitzen wie Container Images. Wenn ich ein Projekt umziehen muss, muss ich nur die Daten verschieben und er läuft 1:1 wie vorher. Serverwechsel sind somit das Unproblematischste überhaupt und ich hab nur die Daten der Anwendung vorliegen.
Bei mir läuft soweit eigentlich jeder Dienst als Container, bis auf SSH, SMB und ein Nginx Reverse Proxy. Certbot pack ich grad in ein Image neben meinem Nameserver um automatisch Wildcard-Zertifikate ausstellen zu können, dann bin ich die Abhängigkeit auch vom Host los. Mich nervt aktuell eigentlich nur noch, dass PHP, Python (u.a. von Certbot) und Ruby auf dem Host installiert sind und ich somit noch nich ganz abhängigkeitenfrei bin... Aber einen Tod muss man leider sterben. Sosnt ist nur das Minimum vom Ubuntu Server installiert, plus kleine Tools für die Shell wie ZSH und Linuxbrew.
Sicherheitstechnisch ist auch alles ausreichend i.O., denn durch User Namespacing laufen die Container auch nie als root. Ebenso ist jedes Projekt in seinem eigenen Subnetz und kein Container hat bei mir irgendwelche Capabilities oder auf den Host Zugriff.
