Containers, Containers everywhere ...

  • Hallo Forum,


    nachdem meine Selbsthoster Abstinenz (https://forum.netcup.de/sonsti…-hosted-vs-cloud-dienste/) nicht mal ein Quartal ausgehalten hat, schwirre ich zurzeit um das Thema "Container" herum. Aus technischer Sicht find ich fürs Homelab und meine, großteils privaten und nur ein bisschen kommerziellen, Anwendungszwecke kaum Argumente für mehrere "echte" VMs. Meine Bedürfnisse lassen sich auf jeden Fall mit namespaces und cgroups bedienen.


    Das Interesse nicht am Teller zu sitzen sondern darüber hinauszublicken oder gar von außen am Rand einhändig runterzuhängen ist bei mir generell sehr groß. Bisher war die Angelegenheit "Container" bei mir auf zahlreiche berufliche, und einige private Vorhaben mit Docker beschränkt. Kurz auch Proxmox mit LXC Containern für die privaten Zwecke, bis eben die vorhin besagte Selbsthoster Abstinenz für ein paar Monate durchgeschlagen hat. Durch Jobwechsel kam auch Docker Abstinenz dazu, die jetzt aber auch wieder vorbei ist weil ich auch dort jetzt wieder eine kleine Docker Farm bewirtschaften darf.


    Meine aktuellen, privaten, Anwendungsfälle lassen sich prinzipiell mit Docker abdecken. Es sind Anwendungen, die ich mit bestimmter Software in einem abgeschlossenen System betreiben möchte. Für ein paar Tage hab ich daher überlegt, einfach alles unter das Häubchen "Kubernetes" zu hängen. Das war allerdings eher dem Interesse an K8S geschuldet, und es löst sich damit nicht mein grundlegendes Problem mit Docker: Ich warte ich den Krempel nicht beruflich tagtäglich. Ich hab auch keine Lust, alle paar Tage oder Wochen die Docker Setups nacheinander zu aktualisieren und mir mühsam ein Bild davon zu machen, auf welche verhaltenskreativen Ideen die Maintainer der benutzten Docker Images im aktuellen Realease gekommen sind, um mir beim Update den Tag zu versauen.


    Das Thema Docker und alles was daran hängt hat sich daher für meine privaten Anwendungen mehr oder weniger von Natur aus erledigt - quasi einfach die falsche Technologie.


    Es folgten ein paar Tage Grübelei, ob nicht doch mehrere separate VMs = mehrere Tarife hier bei netcup und der eine oder andere Raspberry Pi im Schrank (seh ich mal ähnlich einer VM) zielführend wären. Das erschien mir zu sinnvoll, technisch zu einfach und zu viel semi-analoger Verwaltungsaufwand. Sorry netcup, aber das CCP ist immer noch die kleine Schwester vom Krümelmonster und wenn ich mir was zu Weihnachten wünschen darf, dann dass ich CCP und SCP über eine REST API oder ein Ansible Modul bedienen kann.


    Also wieder zurück zu Containern. Proxmox auf den Tisch, liegt da ja schon in der Ecke rum. Die Proxmox GUI ist bei mir umsonst, da ich schon bei der ersten Berührung damit angefangen hab, manuelle Klicks durch automatisierte Ansible Tasks zu erledigen. Mittlerweile seh ich nach dem Beenden des Installers nichts mehr davon. Ich kämpfe höchstens damit, einen Weg zu finden, einen Klicki-Bunti-Workflow der GUI auf CLI und Ansibletauglichkeit umzulegen. Daher entstand die Idee, das doch einfach mit Vanilla LXC zu erledigen, ohne Umwege, ganz direkt.


    Und dann ist da ja noch LXD. Aber was ist eigentlich LXD? Es findet sich erstaunlich wenig aktuelles darüber. Abgesehen von den Releases auf der LXD News Page, gibts dazu nur uralte Artikel die "von diesem neuen LXD Dings da" handeln und äußerst skeptisch mutmaßen, ob dieses LXD diesem Docker den Rang ablaufen kann. Dabei sind das für mich zwei paar Schuhe. Trotzdem endet gefühlt fast jeder Artikel über LXD und LXC damit, dass man sich vielleicht doch mal Docker ... und so ...


    Nun bin ich spitz auf LXD. Das was man dazu findet (=die offizielle Doku) und die diversen Scripts dazu von janxb 's ServerUtils (https://github.com/janxb/ServerUtils) lassen mich glauben, dass LXD kein absoluter Schwachsinn ist. Die Reise wird daher wahrscheinlich in diese Richtung gehen.


    Warum also so viel Gelaber und dieser elendslange Monolog den wahrscheinlich schon viele Nerds auf einer verlängerten Toilettensitzung mit dem Alter Ego geführt habeen (daher eigentlich eh ein Dialog)? Mich interessieren eure Anwendungen und Erfahrungen mit Containern. Was treibt ihr damit? Warum Container und nicht vollvirtualisiert? Warum vollvirtualisiert und nicht Container? Warum Docker und nicht *insert-other-container-technology*? Setzt jemand Kubernetes ein obwohls technisch totaler Overkill ist? Was ist mit Proxmox? Schmeißt noch docker-compose, Swarm, OpenStack, RancherOS, Core OS, und was euch sonst noch zum Thema "Container" einfällt, ins Feuer. Ob dieser Thread als einsamer Monolog ohne Antwort, oder als gediegen geführter Flamewar über LXC vs. Docker endet ist mir egal. Mich interessiert, was euch an Containern interessiert, und was ihr damit aus welchen Gründen tut oder nicht tut.

  • Kubernetes ist mir für privat zu schwergewichtig. Ich fahre gerade keep it simple Ansätze. Ich möchte weniger Zeit in die Administration stecken.


    Ich setze bei neuen Sachen oft auf die Proxmox Container. Die sind sehr leicht und systemD inzwischen bugfrei genug um das zu betreiben.


    Habe einen RS mit LXD auf ZFS. Der funktioniert auch gut. Da kommt jetzt noch KVM Support dazu, vielleicht ersetzt das bei mir später mal Proxmox.

    Docker verwende ich hauptsächlich für Software deren manuelle Installation und Pflege zu aufwändig ist. Was mich an Docker noch stört ist das fehlende Monitoring ob irgendwelche Software im Container veraltet ist. Das meldet mir mein Monitoring für alle lxc/lxd Container.

  • Was treibt ihr damit?

    Ich hoste meine ganzen Applikationen sauber voneinander getrennt in LXC Containern unter Proxmox. Diese bekommen ihr Basis-Setup (+ ggf. Erweiterungen) per Ansible. Und wenn was ans Netz soll, dann arbeite ich auf dem Host mit Port Forwarding.


    Warum Container und nicht vollvirtualisiert?

    Ich benutze Container aus einem ähnlichen Gesichtspunkt wie du - ich denke sehr wohl, dass man auf einem Server mehrere Applikationen betreiben kann - aber man muss das irgendwie sauber trennen, damit es einfacher verwaltbar ist. KVM wäre dabei leistungstechnisch zu viel Overhead. Zudem sehe ich den Gesichtspunkt, dass ich nicht für jede meiner Applikationen eine Public IP brauche. Um die komme ich bei einzelnen Servern hier bei Netcup aber nicht drumrum, da ich die immer mit kaufe - das sind Kosten, die unnötig sind und diese umgehe ich damit.


    Warum Docker und nicht *insert-other-container-technology*?

    Ich fasse das mal anders herum zusammen - bei Docker muss ich mich einerseits auf die Maintainer verlassen und andererseits kontrolliert Docker meine Firewall komplett selbst. Das ist für mich eigentlich ein absolutes No-Go.


    Was ist mit Proxmox?

    Finde ich toll. Ich automatisiere zwar nicht ganz so viel, aber Proxmox bringt ja auch eine eigene API mit... ich ziehe mir dadurch in meinem Unbound Container die Hostnames und Container IDs aus Proxmox und schraub mir damit meine lokale DNS Konfiguration zusammen. Funktioniert ganz gut. :)

  • Finde ich toll. Ich automatisiere zwar nicht ganz so viel, aber Proxmox bringt ja auch eine eigene API mit... ich ziehe mir dadurch in meinem Unbound Container die Hostnames und Container IDs aus Proxmox und schraub mir damit meine lokale DNS Konfiguration zusammen. Funktioniert ganz gut. :)

    Ich bin kein Fan von split horizon DNS Setups aber man kommt ja wohl doch nicht drum herum wenn geNATtete Container über die öffentliche Domain untereinander kommunizieren können müssen. Da hatte ich auch den Gedanken einen kleinen Unbound Container einzusetzen. Hab den Gedanken dann mit einem "Alter werd nicht schrullig" zu mir selbst verworfen, und hatte Unbound dann direkt am Proxmox Host aufgesetzt. Schön zu lesen, dass mein Gedanke wohl doch nicht so daneben war ^^.

  • Ich fasse das mal anders herum zusammen - bei Docker muss ich mich einerseits auf die Maintainer verlassen und andererseits kontrolliert Docker meine Firewall komplett selbst. Das ist für mich eigentlich ein absolutes No-Go.

    Hier möchte ich mich mal mit einer Frage dranhängen.


    Speziell zu docker: Wie sichert ihr euer System ab, damit Angriffe nicht auf das Hostsystem durchschlagen?


    Hintergrund:
    Auf einem von mir betreuten Server sollen demnächst ein paar docker-container platziert werden. Ich selbst werde nicht für die container zuständig sein, wohl aber für den Server. Da ich mit docker noch wenig Erfahrung habe, würde ich hier gerne wissen, welche Sicherheitsriegel ich einziehen kann.

  • Hier möchte ich mich mal mit einer Frage dranhängen.


    Speziell zu docker: Wie sichert ihr euer System ab, damit Angriffe nicht auf das Hostsystem durchschlagen?


    Hintergrund:
    Auf einem von mir betreuten Server sollen demnächst ein paar docker-container platziert werden. Ich selbst werde nicht für die container zuständig sein, wohl aber für den Server. Da ich mit docker noch wenig Erfahrung habe, würde ich hier gerne wissen, welche Sicherheitsriegel ich einziehen kann.

    Externe Firewall davor - wenn du mich fragst. Ansonsten kannst du halt schauen, dass du z.B. alle nicht öffentlichen Dienste an interne IP's bindest. Über iptables hast du bei Docker keine wirkliche Kontrolle, du musst da den Maintainern der Container vertrauen.


    Ich bin kein Fan von split horizon DNS Setups aber man kommt ja wohl doch nicht drum herum wenn geNATtete Container über die öffentliche Domain untereinander kommunizieren können müssen.

    Ähm. Naja ich habe da halt auch einige Dienste, die nur intern erreichbar sind. Und ein VPN. Und einen PiHole. Die wollen ja auch irgendwo DNS Auflösungen machen. Der Resolver ist nur intern erreichbar und hat halt zusätzlich eine lokale Zone namens rz.meinedomain.de... funktioniert ganz gut so, muss ich sagen.

    Zudem mache ich das auch, weil ich Dienste betreibe, die recht viele Auflösungen durchführen - GoAccess wäre da so ein Beispiel... das will ich dem Netcup DNS Server nicht antun. Und natürlich sind Unabhängigkeit und Privatsphäre bei einem eigenen Resolver noch von Vorteil.

  • Hallo Forum,

    [...] Docker [...] Proxmox [...] LXC [...] LXD [...] Kubernetes [...]

    Zwei Punkte in Kürze:

    • Docker ist ein totes Pferd (derzeit allenfalls noch ein Zombie). Gerade, wenn es irgendwann in Richtung Kubernetes gehen soll, unbedingt auf Podman setzen (Sicherheitsaspekte, Nutzerbasis, verfügbarer Support, systemd-Support (work-in-progress), konzeptionelle Ähnlichkeit zu Kubernetes ("Testumgebung für K8S"), ...).
    • Meines Wissens mochte Proxmox lange Zeit nicht mit LXD, sondern setzte auf LXC (lies: bzgl. integriertem Support; ein "Aufflanschen" ist möglich, aber mehr oder weniger witzlos). War für mich ein Grund, eine potentielle Nutzung von Proxmox nicht weiterzuverfolgen. LXD hat IMHO mit der Qualiätssicherung zu kämpfen, entwickelt sich aber, wenn man weiß, wie man tote Cluster wieder repariert, recht vielversprechend (Unterstützung von Containern und VMs, Anbindung an MAAS, besagte Clustermöglichkeit, ...). Ich empfehle, sowohl die IRC-Kanäle, das Discourse-Forum und insbesondere die GitHub-Bugreports/-Diskussionen zu studieren. Es gibt viele Howtos, aber das Zwischen-den-Zeilen-Lesen und Lernen geschieht via IRC/GitHub.
  • Ich bin mit den Containern nie richtig warm geworden. Kommt aber immer auf den Anwendungszweck an. Persönlich finde ich es cool, wenn der Ubuntu-Container auf dem Mac einfach "instantan" den Desktop anzeigt im Gegensatz zur VM.

    Auf der Arbeit kann ich die IT auch verstehen das einzusetzen. Genau dann wenn Software X nur mit Library Y unter Umgebung Z funktioniert, dann macht man einen Container draus und sichert den. Der ist dann (hoffentlich?) auch in Jahren noch ausführbar. Die Alternative ist wie jetzt virtuelle Maschinen mit xyz/DOS laufen zu haben, weil das Gerät zwar von der Hardware noch auf dem Stand der Technik wäre, die Steuersoftware aber mit aktuellen Systemen nicht läuft. (Was ja schon ein deutlicher Fortschritt ist, es laufen hier ja auch alte "richtige" Rechner mit Floppydrive und Co. Da ist Virtualisierung schon ein Segen)


    Auf dem Server kann ich mit Containern nichts anfangen, da wäre ich immer (stand Heute) für Vollvirtualisierung. Ich kann da einfach keine Vorteile dieses komplexen Systems erkennen. Auf dem Produktivsystem wird nicht getestet, ich benötige keine 10 verschiedenen Versionen einer Software (höchstens PHP, das gibts aber auch aus den Paketquellen) und ich weiß gerne, was die Software tut

    Manche Leute faseln tatsächlich was von Sicherheitsgewinn, wenn irre komplexe Software mit 12 Schichten und Gedöns zusätzlich auf dem System läuft; das konnte ich bisher noch nicht nachvollziehen. Insbesondere, wenn die Leute dann Jahre alte Container einsetzen ("kann ja nix passieren, ist in einem container").

  • Ähm. Naja ich habe da halt auch einige Dienste, die nur intern erreichbar sind. Und ein VPN. Und einen PiHole. Die wollen ja auch irgendwo DNS Auflösungen machen. Der Resolver ist nur intern erreichbar und hat halt zusätzlich eine lokale Zone namens rz.meinedomain.de... funktioniert ganz gut so, muss ich sagen.

    Zudem mache ich das auch, weil ich Dienste betreibe, die recht viele Auflösungen durchführen - GoAccess wäre da so ein Beispiel... das will ich dem Netcup DNS Server nicht antun. Und natürlich sind Unabhängigkeit und Privatsphäre bei einem eigenen Resolver noch von Vorteil.

    Da hast du dann doch einige Gründe mehr für einen Unbound Container :D


    • Docker ist ein totes Pferd (derzeit allenfalls noch ein Zombie). Gerade, wenn es irgendwann in Richtung Kubernetes gehen soll, unbedingt auf Podman setzen (Sicherheitsaspekte, Nutzerbasis, verfügbarer Support, systemd-Support (work-in-progress), konzeptionelle Ähnlichkeit zu Kubernetes ("Testumgebung für K8S"), ...).

    Über die Jahre hab ich angefangen es zu ignorieren, wenn eine Technologie, Framework oder ähnliches in die Pension geschickt wurde. Docker war was das angeht ja gefühlt eine Totgeburt, gerade da hab ich mich dann doch lange verwehrt es über Bord zu werfen weils genug Anwendungsfälle für Docker und zu wenig Alternativen für die Anwendungsfälle gab. Mir war allerdings nicht klar wie sehr Docker doch schon in den Seilen hängt, und Podman ist ja inzwischen doch schon ein Jahr stabil. Da hab ich Aufholbedarf.


    • [...] Ich empfehle, sowohl die IRC-Kanäle, das Discourse-Forum und insbesondere die GitHub-Bugreports/-Diskussionen zu studieren. Es gibt viele Howtos, aber das Zwischen-den-Zeilen-Lesen und Lernen geschieht via IRC/GitHub.

    Besten Dank, die werd ich durchpflügen. Die Entwicklung von LXD find ich auch sehr ansprechend. Gerade, dass sie den Horizont der Container um Unterstützung für VMs erweitert haben, lässt schon vermuten, dass sich Canonical damit nicht nur ein Hobby zurechtgelegt hat, sondern was brauchbares damit vor hat.


    Speziell zu docker: Wie sichert ihr euer System ab, damit Angriffe nicht auf das Hostsystem durchschlagen?

    Konkret zu dieser Frage hab ich keinen vernünftigen Ratschlag. Unabhängig davon wirst du allerdings eventuell dein blaues Wunder erleben. Docker saut ordentlich in iptables rum. Wenn die Container erstmal auf dem von dir administrierten Server laufen, wirst du nach einem Blick auf die aktiven iptables Regeln das Bedürfnis haben den Server vorsorglich offline zu nehmen ... Man kann Docker das austreiben, muss dann aber selbst dafür sorgen, dass die Container networken können. Das ist mehr als nur ein Gefrickel. Docker hat in der eigenen Doku einen kleinen Abschnitt dazu: https://docs.docker.com/network/iptables/

  • Speziell zu docker: Wie sichert ihr euer System ab, damit Angriffe nicht auf das Hostsystem durchschlagen?

    Hintergrund:

    Auf einem von mir betreuten Server sollen demnächst ein paar docker-container platziert werden. Ich selbst werde nicht für die container zuständig sein, wohl aber für den Server. Da ich mit docker noch wenig Erfahrung habe, würde ich hier gerne wissen, welche Sicherheitsriegel ich einziehen kann.

    Externe Firewall davor - wenn du mich fragst. Ansonsten kannst du halt schauen, dass du z.B. alle nicht öffentlichen Dienste an interne IP's bindest. Über iptables hast du bei Docker keine wirkliche Kontrolle, du musst da den Maintainern der Container vertrauen.

    Konkret zu dieser Frage hab ich keinen vernünftigen Ratschlag. Unabhängig davon wirst du allerdings eventuell dein blaues Wunder erleben. Docker saut ordentlich in iptables rum. Wenn die Container erstmal auf dem von dir administrierten Server laufen, wirst du nach einem Blick auf die aktiven iptables Regeln das Bedürfnis haben den Server vorsorglich offline zu nehmen ... Man kann Docker das austreiben, muss dann aber selbst dafür sorgen, dass die Container networken können. Das ist mehr als nur ein Gefrickel. Docker hat in der eigenen Doku einen kleinen Abschnitt dazu: https://docs.docker.com/network/iptables/

    Danke für die Antworten!


    Momentan liebäugle ich mit der Variante, docker erstmal über die docker-Konfiguration (daemon.json) mit { "iptables" = false } den Zugriff auf die iptables generell zu untersagen um dann konkret über ufw die Dinge zu erlauben, die container dürfen. Schau mer mal, ob ich das hinbekomme... ;-)

  • Auch bezugnehmend auf mein früheres Posting: Mit alias docker=podman ist schon viel gewonnen, vgl. https://youtu.be/YkBk52MGV0Y (Red Hat hat regelmäßig Vorträge rund um das Thema Podman auf diversen Veranstaltungen).

    Die "Kompatibilität" ist mir beim Nachlesen untergekommen, ist schon interessant.

    Meine (beruflichen) Docker Anwendungsfälle halten sich jetzt gerade NOCH in Grenzen. Mein größtes Problem wär zurzeit noch, dass die Setups alle auf docker-compose beruhen. Von Experimenten wie podman-compose möcht ich grundsätzlich Abstand halten. Könnte das aber fürs erste nutzen um damit Podman Container zu starten und von den laufenden Containern Pods zu generieren. Zurzeit ist die Baustelle nämlich noch offen und jedes dieser Pakete wird nochmal zum digitalen Parkplatz planiert und geht erst produktiv wenn ich alles soweit hab, dass ich die Baustelle innerhalb von 10 Minuten automatisiert durchspielen und aufsetzen kann. Mir wird Podman zunehmend sympathisch - wenn auch nicht geeignet für meine Homelab Anwendungsfälle.

  • Problem wär zurzeit noch, dass die Setups alle auf docker-compose beruhen.

    Ich kann da nur sehr Lösungen wie Ansible empfehlen. Ich ziehe privat damit das meiste was ich so an Docker laufen habe hoch.


    Mir haben in docker-compose die templating Features nicht ausgereicht. Daher habe ich dann irgendwann angefangen Ansible dafür zu benutzen. Teilweise auch in Build Pipelines.


    Das mir da dann ein "up" oder "down" für alle Container auf einmal fehlt habe ich bisher noch nicht vermisst. Container stoppen + docker system prune -a regelt.

  • Wenns nach mir allein ginge, wär Docker gar kein Thema. Das ganze Werk ist im bisherigen Zustand, wo vollvirtualisierte VMs zum Einsatz kommen, allerdings derartig verunstaltet, dass ich den Neuaufbau vor Eingriffen anderer schützen will, indem ichs so einfach wie möglich mach. Da docker-compose im fraglichen Umfeld jeder beherrscht, ist das zurzeit das Mittel der Wahl um zu verhindern, dass es wieder entgleitet. Das Basissetup bis zum `docker-compose up` geschieht schon mit Ansible.

  • Hi, das ist eine sehr interessante Konversation hier. Ich möchte mich mal hier anschließen und vor allem die Begrifflichkeiten Kubernetes und Rancher / RancherOS vertreten.


    Keine Ahnung ob hier schon mal jemand mit Rancher gearbeitet hat. Ich nutze es auf diversen Netcup VPS und RS um diverse Cluster zu managen. Falls sich jemand mal mit Kubernetes auseinander setzen möchte, der sollte sich unbedingt Rancher mal ansehen. Es ermöglicht es auf sehr einfache Weise einen Kubernetes Cluster aufzusetzen. Einfach ein paar CentOS Server aufsetzen, Docker drauf und auf einen dieser Server mit docker run -d --restart=unless-stopped -p 80:80 -p 443:443 -v rancher:/etc/rancher/ -n rancher rancher/rancher

    loslegen. Am Webinterface wird man dann durch den Prozess geleitet um einen Kubernetes Cluster zu erstellen. Prinzipiell muss hierfür auch einfach nur ein Docker Run Command auf jeder Node ausgeführt werden. 15 Minuten bis zu einem Funktionierenden Cluster genügen völlig.


    Ich bin dabei einen Service zu starten, wo sich User Space für Container anmieten können. Ähnlich wie es @sensorback erwähnt hat, werden quasi Kubernetes Namespaces mit zugewiesener CPU Leistung, RAM und Storage zur Verfügung gestellt, worauf dann diverse Anwendungen gehostet werden können. Prinzipiell läuft das alles nach einem Container-As-A-Service bzw. Application-As-A-Service Konzept. Für den User entfallt somit der komplette Administrationsaufwand den er hätte, wenn er VMs mieten würde. Zudem kann ich durch Kubernetes eine hohe Verfügbarkeit garantieren. Auch für mich als Betreiber entsteht kaum Administrationsaufwand. Durch selbst geschriebene Scripts kann ich sofort nach der Bestellung eines Netcup Servers, die Einrichtung automatisch durchführen lassen und den Server einem Cluster zuweisen.

    HOSTING42 - Eine "Container as a Service" Plattform - Work in Progress - Tester gesucht

    Mehr auf www.hosting42.at | Anfragen gerne an office@hosting42.at

  • Ich habe Docker nie Verstanden und vielleicht ist es meinem leichenhaften Verstand geschuldet, wenn ich sage dass es fahrlässig ist, Docker produktiv einzusetzen.

    Ich bin doch abhängig von dem Ersteller des Containers und laufe Gefahr ständig Lücken im System zu haben.


    @sensorback was sind das denn für private Anwendungsfälle, dass sie es Wert sind, sich damit so sehr auseinander zu setzen?;)

    Ich habe für Ressourcen schonende Dinge einfach je einen 1€ VPS und fertig ist das Ganze.

    Basics umsetzen (SSH, Ports, Root deaktivieren, Firewall, f2b, unattended-up etc) und die Dinger laufen seit Jahren ohne Befund.

  • doch abhängig von dem Ersteller des Containers

    Was das angeht, gibt es keinerlei Unterschied zu DEB/RPM Paketen. Da muss man genauso gucken von wem man diese benutzt. Und es gibt im Docker Hub auch da eine Trennung zwischen "offiziellen" und "inoffiziellen" Images. Und man sollte natürlich nur die offiziellen bzw selbst gebaute nutzen.