Beiträge von Gymnae

  • IPv6 Addressvergabe an Docker-Container

    Wait, nun bin ich weitergekommen. Ich habe die geroutete Adresse im ersten ipv6 subnet nun als IP-addresse für das eth0 device hinzugefügt, jetzt klappt die kiste. Ich hatte eure kommentare schlichtweg bisher nicht verstanden. der rfc podcast und ein ruhiger sonntag haben doch geholfen :)

  • IPv6 Addressvergabe an Docker-Container

    Leider bin ich nicht weitergekommen.

    Mein Setup sieht gerade wie folgt aus

    Maskierungen:

    yyy = vom neuen, zweiten ipv6 subnet

    xxx = originären subnet
    zzz = generelle maskierung


    Ich habe versucht das zweite ipv6 subnetz aus die virtuelle Schnittstelle von docker0 zu routen. Die Adresse 2a03:4000:2x:xx:xxxx:xxxx:xxxx:95b7/64ist die im SCP angebene routing Adresse vom zweiten ipv6 Subnetz in das Erste, wenn ich es recht verstehe.


    Ich kann gerade keine der vergebenen globalen Adressen aus dem zweiten Subnetz extern anpingen, intern geht es schon

    route -6 -n - verkürzt:

    Statische Einrichtung von eth0

    Statische Einrichtung von docker0 - der primären guest virtuellen NIC

    Code
    [Match]
Name=docker0

[Network]
Address=2a03:4000:2y:yyyy::100:1/110
Gateway=2a03:4000:2x:xx:xxxx:xxxx:xxxx:95b7

    Docker nimmt sich ein 119 Subnetz:

    --fixed-cidr-v6="2a03:4000:2y:yyy::101:1/110"' --default-gateway-v6="2a03:4000:2x:xx:xxxx:xxxx:xxxx:95b7

  • IPv6 Addressvergabe an Docker-Container

    Zitat von oliver.g

    Wieso haben die IPs in den Dockern die netmask 80? Hast du auf deinem Host IPv6 Forwarding aktiviert (Stichwort sysctl)?

    Ja, ich habe mir die Info aus dem Web zusammen geklaubt, siehe meinen ersten post:

    Code
    net.ipv6.conf.default.forwarding=1
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.eth0.proxy_ndp=0
net.ipv6.conf.default.accept_ra=0
net.ipv6.conf.default.autoconf=0
net.ipv6.conf.all.accept_ra=0
net.ipv6.conf.all.autoconf=0
net.ipv6.conf.eth0.accept_ra=0
net.ipv6.conf.eth0.autoconf=0

    Von ipv6 verstehe ich noch sehr wenig, muss ich zugeben.

  • IPv6 Addressvergabe an Docker-Container

    Zitat von oliver.g

    NIC = Network Interface Controller, also kurz für Netzwerkkarte.

    Nein, diese Adresse ist nicht Gateway, sondern die Zieladresse, an die die Pakete geroutet werden, die an Adressen aus deinem Zusatzsubnetz gesendet werden. Diese wird also als zweite IP deinem Netzwerkadapter zugewiesen. Das Gateway fe80::1 bleibt so.

    Merci für die Erklärung, ich habe es so probiert:

    sudo ip address add 2a03:4000:2x:xxx::/64 dev eth0

    aber noch keine änderung


    Es schaut gerade so aus:

  • IPv6 Addressvergabe an Docker-Container

    Zitat von oliver.g

    Hi, hast du dem primären NIC auch die Routing Adresse zugewiesen (siehe SCP in der Gateway Spalte)? Das ist die Adresse aus deinem ersten Subnet, auf die das zusätzliche Subnet geroutet wird. Die muss natürlich auch konfiguriert sein.

    Ich fummel ja gerne in der Konsole rum und weiß, was ein NIC ist. Aber jetzt habe ich nur Bahnhof verstanden.

    Der primäre NIC bei mir ist wohl eth0 und mit der Routing Adresse meinst du die lange IPV6 Adresse, die das SCP generiert hat? Wie würde diese Konfiguration vornehmen?


    EDIT:

    Meinst du so?

    Code
    Address=2a03:4000:2x:xxx::1/64
#Gateway=fe80::1
Gateway=2a03:4000:xx:xx:xxx:xxx:xxx:95b7 <- Adresse aus dem SCP in der Gateway Spalte
DNS=2606:4700:4700::1111

  • IPv6 Addressvergabe an Docker-Container

    Ich will ja keinen Zombie wiederbeleben, aber Dbone, @hannpi habt ihr das Problem lösen können?


    Auf meinem G8 VPS läuft CoreOS, auf diesem Docker.

    Den Tips in diesem thread folgend habe ich mir heute ein zweites ipv6 subnet bestellt und auf den Server gerouted. Nur IPs daraus kann ich nicht anpingen


    1. Screenshot aus dem SCP:

    forum.netcup.de/system/attachment/2650/


    2. ifconfig eth0

    Code
    eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 185.244.192.64  netmask 255.255.252.0  broadcast 185.244.195.255
        inet6 2a03:4000:2x:xx::1  prefixlen 64  scopeid 0x0<global> <- ipv6 subnet von anfang dabei
        inet6 fe80::e8f2:xxx:xxx:95b7  prefixlen 64  scopeid 0x20<link>
        inet6 2a03:4000:2x:xxx::1  prefixlen 64  scopeid 0x0<global> <- ipv6 subnet bestellt
        ether ea:f2:xx:xx:xx:b7  txqueuelen 1000  (Ethernet)
        RX packets 63039  bytes 26095949 (24.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 12772  bytes 1762320 (1.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

    Von einem extern host kann ich die zweite inet6 IP nicht anpingen:

    Code
    ping6 2a03:4000:2x:xxx::1
--- 2a03:4000:2x:xxx::1 ping6 statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

    Die originäre jedoch funktioniert:

    Code
    ping6 2a03:4000:2x:xx::1
16 bytes from 2a03:4000:2x:xx::1, icmp_seq=0 hlim=58 time=582.119 ms
16 bytes from 2a03:4000:2x:xx::1, icmp_seq=1 hlim=58 time=15.719 ms
16 bytes from 2a03:4000:2x:xx::1, icmp_seq=2 hlim=58 time=19.913 ms


    3. /etc/system/network/static.networking

    4. Folgende sysctl parameter werden beim systemstart übergeben:

    Code
    net.ipv6.conf.default.forwarding=1
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.eth0.proxy_ndp=0
net.ipv6.conf.default.accept_ra=0
net.ipv6.conf.default.autoconf=0
net.ipv6.conf.all.accept_ra=0
net.ipv6.conf.all.autoconf=0
net.ipv6.conf.eth0.accept_ra=0
net.ipv6.conf.eth0.autoconf=0


    5. ip -6 r

    Docker startet mit Environment='DOCKER_OPTS=--dns 1.1.1.1 --dns 1.0.0.1 --ipv6 --fixed-cidr-v6="2a03:4000:2x:xxx:1::/80"', einer entsprechende Route habe ich auch angelegt: sudo ip -6 route add  2a03:4000:2x:xxx:1:/80 dev docker0.


    Neue Docker container erhalten Adressen aus dem subnet 2a03:4000:2x:xxx:1:242:ac11:4, aber anpingen kann ich diese hosts auch nicht.
    Habe ich etwas vergessen?

  • Storagespace redundant?

    Danke für die Antworten.


    Hintergrund war, dass ich plane Daten (docker volumes) per duplicity inkrementell off-location zu speichern.
    Daher überlege ich noch ob ich das per NAMEENTFERNT, oder über den netcup storage space lösen werde.


    Die Kosten für NAMEENTFERNT sind nicht im Vorneherein nicht so leicht zu berechnen, in deren Calculator kann ich nur grobe Schätzungen eingeben. Bei netcup wollte ich erst mal wissen, ob das ganze auch eine Art SLA mit Redundanz bietet. Das weiß ich nun. Bleibt noch die Entscheidung, welcher Weg im Endeffekt günstiger und sicherer ist. Vielleicht ja beides gleichzeitig 8)


    Nutzt jemand den Storagespace für Backups?

  • Storagespace redundant?

    Storage-Verbund kann auch nur ein munterer Haufen von block devices in Blech sein ;)
    Bedeutet noch nicht, dass ein RAID meine Daten sichert.
    Eine definitive Aussage habe ich noch nicht gelesen..

  • Storagespace redundant?

    Hallo zusammen,


    ich habe zum Test für 3 EUR das "Standard"-Angebot von dem Storagespace gebucht. In der Betaphase konnte man, wie ich auf alten Screenshots gelesen habe, noch zwischen gespiegelten Platten und keiner Spiegelung unterscheiden.


    Wie sieht das bei dem nun buchbaren Produkt aus. Wird Serverseitig in einem RAID gespiegelt und eine gewisse Redundanz angeboten?


    Grüße und Danke

  • Docker & CoreOS auf Rootserver M Gen 6

    Habe ich mir mal durchgelesen :)
    Allerdings stehen da einige Sachen die, von dem was ich bisher gelesen habe, Quatsch sind:

    • Der Autor sagt postfix könne nicht laufen
      In der strengen Auffassung von einem Prozess pro Container ist das richtig, aber in der Realität sind viele der images auf docker hub und selbst die Beispiele Kombinationen von verschiedenen Prozessen zu einer Art Dämen im Container. Es gibt auch einige Postfix Images
    • Vendor Lock-in
      Ja, aber Docker ist Open-source, selbst wenn ein eigenes Containerformat entwickelt wird
    • Keine Kontrolle oder Signatur von images aus dem Hub
      Stimmt nur für community images, nicht aber für die base images. Ich sehe hier auch keinen Unterschied zu alternativen repositories von Ubunut o.ä. Vertrauen ist eine Sache. Auf Docker hub kann man auch in die images vor dem pull reinschauen und sich vergewissern, ob Schabernack getrieben wurde. Eine chain of trust bieten manche zudem ebenfalls an. Die Hashes der einzelnen image layers ermöglichten zudem eine Kontrolle und verhindern das unterjubeln von manipulierten basis paketen.


    Kurz, ich bin gerade ziemlich überzeugt. Noch kein Fanboy, noch habe ich gar nichts zum laufen gebracht :thumbup: Alle theorie ist grau :evil:

  • Docker & CoreOS auf Rootserver M Gen 6

    Meine letzten Antworten wurden entweder noch nicht freigeschaltet, oder kamen nicht durch.
    Wenn ich das recht lese müsste LXD mehr overhead produzieren, da in dessen containern vollwertige OS virtualisiert werden.
    Wenn ich mehrere Container mit ähnlichen Aufgaben anlegen würde, also z.B. wordpress und owncloud trennen mag, dann habe ich pro container vollwertige virtuelle Maschinen die ihre Ressourcen nicht teilen.


    Das Layer Konzept von Docker würde dies z.B. besser machen. Daher ist mehr der Vorteil von LXD für Einzelserver noch nicht ganz klar.


    Ich sehe bei Docker die Verlockung, komplett auf images auf dem hub zu setzen und damit die Sicherheit und Integrität der Appliances in die Hände von Dritten zu geben, die die images pflegen, oder dann einfach irgendwann aufhören.


    Danke für eure Tips auf jeden Fall. Ich denke ich lese mich weiter in Docker ein bevor ich loslege. Wenn ich zu schnell fertige images nutzen, mülle ich mir nur wieder das System zu und baue nix eigenes :)

  • Docker & CoreOS auf Rootserver M Gen 6

    Das klingt alles so dermaßen vielversprechend, dass ich mich da schön langsam einarbeiten werde.


    Danke für die Tips, Alpine Linux schaue ich mir als base genauer an.


    Die fertigen images aus dem docker hub nutzen als Basis einen bunten Blumenstrauss von Linux flavors, für den Anfang werde ich es mal mit denen probieren und dann selbst meine images nachbauen, um das System im Nachgang zu verschlanken. Mit den persistenten Daten in Volumes kann ich ja die images mit neuen bases im dockerfile umkonfigurieren,sehen ob das läuft und wenn nicht geht nichts verlorern...das ist...alles so flexibel. wow.


    Grüße

  • Docker & CoreOS auf Rootserver M Gen 6

    Danke euch für eure Antworten.
    Genau das mit dem zumüllen ist auf Lange Frist gold wert. Gerade bei kleinen privaten Servern, wo man "nur mal schnell" etwas ausprobieren möchte oder unbedingt diese eine library apt-get'en muss - da müllt sich das System mit der Zeit zu. CoreOS und strike Trennung in Container hält das Haus sauber :)


    Ich habe mir einen Rootserver bestellt und CoreOS läuft schon.


    Testweise habe ich das offizielle owncloud image eingespielt, welches mit nginx und php daher kommt.


    Was ich aber noch nicht ganz verstehe: Wenn nun noch z.B. ein wordpress dazu kommt, eine webmailer paket oder eine gallerie, dann bringen die alle u.U. andere base images mit und ihre eigenen Webserver. Die idlen dann die ganze Zeit und cachen RAM. Festplattenplatz ist die eine Sache, aber wie ist das mit cycles, RAM und Pagefiles?


    Teilen sich Docker container alle Resourcen fair auf, d.h. wenn in einem Container ein Webserver nichts zu tun hat, nimmt ihm Docker dann die Ressourcen weg und gibt diese frei? Zugegeben, dass könnte ich auch gerade googlen, aber vielleicht hat jemand Erfahrungen?


    Grüße und Danke

  • Docker & CoreOS auf Rootserver M Gen 6

    Servus zusammen,


    ich würde gerne von einem bestehenden VServer bei Hosteurope mit Ubuntu 12.04 LTS und Plesk 15 auf einen Rootserver mit CoreOS umsteigen. Großer Schritt, wird bestimmt erst mal eine steilere Lernkurve, aber in den letzten Jahren war Plesk mehr im Weg und Virtuizo mit seinem Kernel hat alles eingeschränkt.
    So viel zu der Vorgeschichte.


    Auf dem neuen Server möchte ich alles Containern. Weil das ja so viel Zukunftssicherer und wenn richtig gemacht sicherer sein soll.
    Hat der Rootserver M genug Dampf für folgendes Setup:

    Docker Container für

    • Mailserver mit Roundcube Frontend
    • Webgallerie (koken)
    • owncloud
    • mumble
    • fileserver
    • und noch ein extra php_fpm für eigene HMTL Dokumente


    Was ich bisher gelesen habe, sind die Docker Images für diese Anwendungen alle "fat" und bringen eine Webserver mit - das müsste ganz schon Overhead erzeugen.
    Hat jemand Erfahrungen mit Docker? Hat der Rootserver M genug Reserven für den Overhead, oder ist der sogar vernachlässigbar mit Docker?


    Ich bin mir nicht sicher, ob nicht doch ein Ubuntu 16.04 ab April die bessere Wahl wäre - nur habe ich mit 12.04 auf Plesk die Erfahrung gemacht, dass nach ein paar Jahren nur noch Heftpflaster und Hacks eine Modernisierung ermöglichen.


    Mit CoreOS und Docker könnte ich diese Woche noch loslegen :)