Server administrieren - wo fange ich an?

Sicherheitsproblem in irgendeiner verwendeten Bibliothek? Bei Docker muss man erst einmal warten, bis das in zig Images behoben wird. (Oder selbst bauen, aber dann gehen viele Vorteile wieder verloren, weil man erst mehr Aufwand hat.)

Bei Shared Libs auf Systemebene habe ich das Problem nicht. Ein Update zentral eingespielt (notfalls das Package selbst neu gebaut mit einem Hotfix), einmal Dienste bzw. Prozesse neu starten und fertig.

Ich kann auch verstehen, dass man Docker für bestimmte Szenarien gerne verwendet bzw. aufgrund der Abhängigkeiten fast schon verwenden muss. Aber ein Allheilmittel für jeden Mini-Krempel ist es meiner Meinung nach nicht. Wenn ich mir so ansehe, wofür das teilweise eingesetzt wird, kann ich nur mit dem Kopf schütteln...

Zitat von KB19

Aber ein Allheilmittel für jeden Mini-Krempel ist es meiner Meinung nach nicht. Wenn ich mir so ansehe, wofür das teilweise eingesetzt wird, kann ich nur mit dem Kopf schütteln...

Wie so häufig: Es gibt kein Allheilmittel.

Ich setze sehr gerne ausführlich docker bei mir ein.

Als dann ein Freund fragte ob ich für ihn paar Domains redirecten kann (live.domain.tld auf twitch, chat.domain.tld auf Discord usw.) war ich so bequem und hab auf einem meiner Server (für mich) einfach eine docker-compose.yml angelegt mit einem Container der das redirecting macht.

- Hätte ich hierfür auch einen apache/nginx installieren können? Ja

- Hätte ich dafür länger gebraucht, da ich mich mit den Configs dafür nicht auskenne? Ja

- Was kann ich besser supporten? Docker

Und dennoch baue ich das gerade alles ein bissle zurück und binde das alles in ein Webhosting ein, da ich mir Aufwand/Kosten/Server (@ home) sparen möchte

Grundlegend liebe ich docker für den Umgang.

Ich hab meine docker-compose.yml files die alles beschreiben.

- Image

- Datenbank

- URL für den Reverseproxy

- Ausgehender Port von dem Image wird auf 443 gebogen

- Ort für die persistenten Daten

Was auf dem System noch läuft? Ist mir egal.
Eine Nextcloud neben die anderen drei? Jop.

Noch 5 Wordpress dazu? Jop

Wie wäre es mit einem Uptime Kuma? Easy

Muss ich dafür irgendwo in Config Daten von Apache/Nginx/Reverse Proxy basteln? Nö, ist ja alles in der docker-compose.yml beschrieben.

Test von update von Nextcloud/Wordpress?

Zieh ich mir eben eine neue Instanz hoch oder nutze eine der vorhanden.

Ist auch easy mit den Tags von den Containern.

Es ist nicht die eine Sache die ich an Docker liebe, sondern das gesamte Paket.

Aber ich kann auch verstehen das es für andere Menschen nichts ist. Es ist eine andere Art der Administration.

Mein Server ist nicht mehr so meine geliebte Kuh die ich mit der Flasche vom Kalb her großgezogen hab.

Es ist auch noch kein Schlachtvieh wie in der Cloud mit automatischer Skalierung, Ansible, Terraform/Terragrunt usw.

Und ja: Das Free Rate Limit vom Dockerhub ist blöd, da bin ich auch schon gegen gelaufen...

Ich denke für den Start ist eine Kombination aus Caddy (welches sich automatisch um die https Zertifikate kümmert) und Uptime Kuma ganz nett (neben dem Docker-Buch vom Kofler...). Da kann man mal ein bisschen rumspielen, schauen wo Uptime Kuma die Datenbank ablegt, dort evtl etwas mit sqlite rumschnüffeln. Dann vielleicht mal ein Update von Uptime Kuma machen und ein bissl mit dem Container rumspielen.

Vielleicht nochmal kurz ein Wordpress aus Spaß dranklemmen und auch dafür sofort ein https Zertifikat dank Caddy haben.

Das ist schon nett und spart einem manchmal wirklich ne ganze Menge Zeit.

Für bestimmte Software wie z.B. Uptime Kuma ist Docker halt auch wirklich prädestiniert - weil wegen dem Node-JS Zeugs willste da eh nen richtigen Proxy Server davor haben. Und wenn du das alles sauber in Containern abbildest ist es halt deutlich schöner als von Hand installiert.

Zitat von TBT

Es scheiden sich die Geister, ob man einen Datenbankcontainer für alle Anwendungen, die einen benötigen, macht und diesen überall einbindet, oder jedem Applikationscontainer seine eigene DB mitgibt. Ich finde das zweite Modell - auch wenns mehr Ressourcen benötigt - sinnvoller, da dann die Apps eigenständig sind und sich nicht gegenseitig beeinflussen können.

In der Tat, ich war historisch ein Freund einer dicken (Postgres) Datenbank irgendwo für alles, weil ich fand, daß Tuning, Datensicherung, Monitoring dann einfacher sind. Doch jetzt, wo ich Container gerne mal neu und isoliert aufbaue, stellt der Datenbank-Krempel (Export, Teilimport, Kopie, was auch immer) einen zusätzlichen Schritt dar, den ich mir mit getrennten Datenbank-Containern je Service spare. Dito für redis, mongo, was auch immer.

Zitat von KB19

Sicherheitsproblem in irgendeiner verwendeten Bibliothek? Bei Docker muss man erst einmal warten, bis das in zig Images behoben wird. (Oder selbst bauen, aber dann gehen viele Vorteile wieder verloren, weil man erst mehr Aufwand hat.)

Selbst bauen: ist doch einfach, wenn man in der docker-compose.yml das korrekte build script von github gleich mit einbaut, wie in:

  image: tiredofit/nextcloud:27-latest
  build: 
    context: https://github.com/tiredofit/docker-nextcloud.git#27-3.6.10
    args: 
      NEXTCLOUD_VERSION: 27.1.3

Eine weitere Hilfe ist mir eine zentrale .env Datei, die in die Unterverzeichnissen meiner services hineingelinkt ist.

Mir ist aber schon klar, daß das mit Kubernetes noch viel schöner wäre. Wenn ich dann in Rente bin, hab ich Zeit dafür.

Bud davon würde ich Dir abraten:

Zitat

Bud davon würde ich Dir abraten: Also könnte chmod -R -u www-data 777 /home/bud/ mein Problem lösen?

Ich trenne stets mein Home-Verzeichnis von jene auf denen Web-Anwendungen liegen.
Fazit: Ansatz gut - aber lege einen anderen Pfad an wo Du Deine Web-Anwendungen liegen hast und passe diese in der jeweiligen Konfigurationsdatei Deines Web-Server an.

Au Mann mit Docker wäre das nicht passiert

ooohhhh sorry nicht bös gemeint

Zitat von Bud

Anfangen bzw. testen möchte ich das Ganze mit der munin.conf. Diese unterscheiden sich nur darin, dass der jeweilige Server auf dem munin läuft, sich selbst mit 127.0.0.1 überwacht – gibt es irgendeinen Grund, warum ich hier nicht die normale IP des Servers verwenden sollte? Weil wenn nicht, kann ich diese drei Dateien 1:1 aufbauen.

Du kannst auch deinen Munin Server über die normale IP überwachen. Das ist gar kein Problem. Du musst nur sicherstellen, dass der Agent (auf dem Munin Server) auch auf dieser IP lauscht und nicht nur auf 127.0.0.1. Darüber hinaus in der Firewall sicher stellen, dass der Munin Port nicht nach außen hin freigegeben ist. 127.0.0.1 ist lediglich der Standardwert, damit die mitgelieferte Konfiguration universell einsetzbar ist. Aber es ist auch völlig ok, dies auf die normale IP zu ändern, wenn das für dich einfacher ist.

Aber eigentlich wäre 127.0.0.1 hier doch einfacher, wenn man die Dateien übertragen will, oder?

Achso, ja, nee. Denkfehler.

Zitat von aRaphael

Aber eigentlich wäre 127.0.0.1 hier doch einfacher, wenn man die Dateien übertragen will, oder?

Achso, ja, nee. Denkfehler.

Ein Klassiker: Hacker hackt 127.0.0.1: http://dauerzocken-24.de/forum/?do=showthread&id=954

Zitat von TBT

Ein Klassiker: Hacker hackt 127.0.0.1: http://dauerzocken-24.de/forum/?do=showthread&id=954

"Ha! Der Pfosten hat echt das gleiche Kennwort wie ich!"

Zitat von TBT

Ein Klassiker: Hacker hackt 127.0.0.1: http://dauerzocken-24.de/forum/?do=showthread&id=954

Vielleicht hätte man einen Disclaimer hinsichtlich der verrohten Sprache anbringen sollen.

Zitat von eripek

Vielleicht hätte man einen Disclaimer hinsichtlich der verrohten Sprache anbringen sollen.

Du bist doch bestimmt schon groß. Du kannst das ab.

Zitat von Bud

Es sollte ja nicht daran liegen, dass der Server mit einem Snapshot bespielt wurde, oder? Zumindest pingen müsste ich ihn doch dennoch können.

Hast du die IP statisch eingerichtet gehabt? Dann musst du die noch Anpassen auf die Neue IP

Edit: gehe jetzt mal davon aus das es ein Neuer Server ist weil du hier gefragt hattest: Snapshot auf Neuen Server