@jeff Ich antworte mal wild auf alles 😉
Das Konzept "Reverse proxy mit Diensten, die nur auf loopback lauschen" ist total sinnvoll und skaliert.
Neue Dienste mache ich nur so. Wenn man möchte, hat man einen Wildcard-Record im DNS (*.example.com) und auf dem Reverse proxy ein Wildcard-Zertifikat von LE (es gibt übrigens nicht nur LE als kostenlose CA mit ACME-Support) - und schon hat man seine neue Website in kürzester Zeit am Netz.
Docker-Container aktuell halten: containrrr.dev/watchtower/
Bei Containern sollte man aber unbedingt darauf achten, daß man Images verwendet, die auch gepflegt werden, also günstigstenfalls solche, die vom Softwareanbieter selbst kommen. Wie bei friendica zum Beispiel 😉
fail2ban: Wird m.E. überbewertet. Wer Du unsichere Dienste anbietet, sollte die reparieren - und das kann fail2ban nicht. Immerhin hält es die Logs kürzer 😉 Wäre nicht meine erste Prio.
Go: Das ist nun ziemlich egal, in welcher Sprache eine Software geschrieben ist, solange man nicht debuggen möchte. Go hat den Vorteil, daß es (immer?) nur ein Binary ist, das alle Abhängigkeiten reingelinkt hat und dann aber auch entsprechend groß ist.
Ansible/Python: Ansible IST Python! Und wers richtig ausreizen möchte, kann als Template-Sprache Jinja einsetzen, was einem Pythonista entgegenkommen sollte.
Ansible ist nichts, was man in zwei Stunden lernt. Aber die Doku ist gut, es gibt eine große Community.
Und man muß die Kosten-Nutzen-Relation sehen. Bei privaten 5 Kisten würde ich wohl kein Ansible einsetzen, es sei denn, ich wäre ein neugieriges Spielkind mit Spaß an Software.
@linux on Linux.Community
Rules
This is an on-topic community. All content must adhere to our CODE OF CONDUCT.
Ihr habt hier ja jetzt immer wieder ansible angeführt. Ich bin selbst darüber vor ein paar Monaten gestolpert und fand das vom Lesen so ganz spannend. Wie ist denn so eure Erfahrung mit dem Einarbeiten in ansible? Und letztendlich ja auch Docker?
Ist das eine Sache von "mal n Stündchen einlesen und dann gehts los" oder ist das für jedes Thema eher "Eine Woche bei Keks und Kaffee einschließen und durchboxen"? Ich finde es ja super toll, immer etwas Neues zu lernen. Allerdings lässt einem das Leben nicht immer den Freiraum dazu ...
Anderseits, wenn ich jetzt 4 Tage mit dem BashScripten verbringe, kann ich auch 2 Tage in ein neues Tool investieren und bin dann schon nach 3 Tagen vielleicht fertig. Vielleicht 😉
+1 for #ansible!
@jeff @linux IMO kommt es darauf an was dein Ziel ist. Willst du deinen eigenen Server managen auf dem etwas Software läuft die du betreibst, ober geht es schon um mehrere Systeme?
Für **mich** ist aktuell die entspannteste Lösung:
- caddy als rev. proxy für alles was von außen erreichbar ist
- docker (compose), ohne port exposing für alle Anwendungen auf meinem Server
- selektives Updaten von Hand
- optional: zur Einrichtung und Wartung Ansible
@lukasrotermund Gute Frage: Es sind meine eigenen Server. Mit Software für mich, die Familie und Freunde. Es sind inzwischen mehrere (5) Server. Manches muss ich austesten und schrotten dürfen. Das mache ich dann ungern auf Systemen, die zwar privat aber dann doch produktiv im Einsatz sind 😉
Ansible habe ich kurz schon gesehen und um Docker mache ich regelmäßig einen Bogen 😉 Das ist mir alles noch recht neu und unbekannt. Wenn ich mal hier und da ein bis zwei Stunden Zeit zum "Linuxen" habe, dann kann ich im Moment nur das machen, was ich kenn und kann. Und ein Script in Bash runter zu hacken, ist mir alt bekannt 😉 Das Einarbeiten in Neues braucht mir dann doch mehr zusammenhängende Zeit zum konzentrierten Lernen. Ahne ich zumindest ...
Caddy kenne ich noch nicht. Kurz einen Blick geworfen und gesehen, dass es in "go" geschrieben ist. Noch nie mit zutun gehabt. Wäre das dann ein Ausschlusskriterium? Gefühlt ja -wäh neu! -, aber in der Praxis? 🤔
@jeff ah ok, I see.
Ich sehe es pragmatisch :), natuerlich kommen docker und co. mit ihren ganz eigenen Problemen und Fallstricken, aber IMO machen sie mir am Ende auf gleich viel weniger Kopfschmerzen als vorher. Meinen Server umzuziehen bedeutet fuer mich nur noch:
- Basic setup einrichten (ufw, fail2ban, ssh, user, docker, ...)
- Meine docker compose yaml zu kopieren
- und ein docker compose up auszufuehren
Selbst wenn ich was kaputt mache ist es schnell korrigiert.
1/3
@lukasrotermund Ja, das klingt nach entspanntem Umzug 🙂 Ist denn das DockerSystem vom darunterliegendes OS unabhängig? Also, wenn ein Wechsel von zum Beispiel Debian 11 auf 12 ansteht, dann kann es ja doch die eine oder andere Änderung nach sich ziehen.
@jeff Exakt. Unter Linux spielt es keine Rolle was das unterliegende System ist, hier nutzt docker fuer die Resourcen (mem, cpu) cgroups, zur Prozess Abgrenzung namespaces und fuers networking iptables.
Unter Windows und Mac wird dafuer eine Linux VM gestartet. Laeuft also im Grunde auf allen Systemen aehnlich (volumns unterscheiden sich her etwas in der performance wegen der VM bridge).
Aber da ich eh ueberall Linux habe interessiert mich das nicht :)
@lukasrotermund Jep - ich bin auch nur noch auf den Spuren des Pinguins unterwegs - Fenster und Äpfel kann man auch anders 😁
Ok, geht dann docker so in die vage Richtung einer VM? Im Inneren stets das gleiche System und draußen ist egal?
Ok, geht dann docker so in die vage Richtung einer VM? Im Inneren stets das gleiche System und draußen ist egal?
Jein.
Beispiel:
Dockerhost:
❯ uname -a
Linux halde 6.1.0-30-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.124-1 (2025-01-12) x86_64 GNU/Linux
❯ cat /etc/*release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
Wir gehen in den Container, hier ein pihole:
❯ docker exec -ti pihole bash
halde:/# uname -a
Linux halde 6.1.0-30-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.124-1 (2025-01-12) x86_64 GNU/Linux
halde:/# cat /etc/*release
3.19.7
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.19.7
PRETTY_NAME="Alpine Linux v3.19"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"
halde:/#
Beachte, daß auch im Container (ein Alpine, kein Debian) sich ein Debian-Kernel meldet.
Weil es eben keine VM ist, sondern den Kernel des Hosts verwendet. Deshalb kann es auch kein lauffähiges Windows-Image geben, das auf Docker für Linux läuft.
Es ist sozusagen eine Vm auf Applikationsebene, nur die Applikation wird virtualisiert.
Mit Docker kann man spielen, da macht man nichts kaputt (außer dem Container vielleicht). Und da Docker seine Daten außerhalb des Containers speichert, kann man den Container nach Lust und Laune vergurken. Einfach das Image löschen und neu ziehen.
@rainer @lukasrotermund Man, das klingt spannend! Woher bekomme ich jetzt mal 2 Wochen am Block Zeit, um mich da reinzufuchsen? 🤔 🙂
@jeff Ansible hat den Vorteil, dass man seinen eigenen (oder fremde) Playbooks einfach konfigurieren und ausfuehren kann. Hier wird einfach ein geplanter Endzustand beschrieben.
z.B.:
- Sorge dafuer das diese SSH Keys hinterlegt sind
- Sorge dafuer das fail2ban eingerichtet ist
- Sorge dafuer das docker installiert ist
Caddy ist einfach ein Webserver. Den nutze ich als rev. Proxy, damit meine Docker Container nicht direkt am Internet haengen. Docker tut sich hier mit der UFW schwer.
2/3
@jeff Dazu hab ich auch was in Textform:
-> https://lukasrotermund.de/posts/i-retired-nginx-for-caddy-and-never-looked-back
Caddy ist in Go geschrieben, aber das muss man nicht koennen um Caddy zu bedienen. Die Konfigurationen sind halt um ein so vielfaches einfacher als bei Apache und Nginx.
Zusaetzlich brauchst du den Certbot fuer Lets Encrypt nicht mehr, da Caddy das Certificate Handling fuer dich uebernimmt.
3/3
@lukasrotermund Ok, den Caddy schaue ich mir näher an. Das ConfigFile vom Caddy ist im Vergelich zum Apachen oder nginx ja kaum noch ConfigFile zu nennen 😉
@jeff Exakt mein Gedanke :) und es laeuft und laeuft. Fuer meine use cases voellig ausreichend und so charmant simple.