Login
Newsletter
Werbung

Thema: Container knabbern am Markt für virtuelle Maschinen

14 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von \°/ Holger H. \°/ am Do, 2. August 2018 um 15:45 #

Weil sooo berauschend sind jetzt die Produkte vom VMWare auch nicht!

  • 0
    Von Verfluchtnochmal-05995bd7b am Do, 2. August 2018 um 18:15 #

    Bla - Container laufen üblicherweise so gut wie pberall INNERHALB von virtuellen Maschinen und ersetzen sie nicht und warum du prinzipiell VM mit VMware gleich setzt verstehst wohl auch nur du

    • 0
      Von Josef Hahn am Do, 2. August 2018 um 18:28 #

      Ich habe auch verstanden, warum der OP hier VMWare nennt. Siehe Artikeltext.

      Wie du rausliest, dass er es mit VM gleichsetzt, verstehe ich nur nicht?!

      • 0
        Von Verfluchtnochmal-05995bd7b am Do, 2. August 2018 um 18:30 #

        Weil er genauso wie der blöde Artikel nichts verstanden hat

        Da wurde jemand gefragt der Container vertreibt und dann über die Antworten wundern?

        • 0
          Von Anonymous am Do, 2. August 2018 um 23:23 #

          Deine Messages würden nachhaltiger rüberkommen, wenn du nicht so herumpöbeln würdest.

          Ich verstehe zwar nicht viel von dem Zeugs und habe beruflich schon gar nicht damit zu tun, aber der Titel der Meldung ("Container knabbern am Markt für virtuelle Maschinen") sagt ja bereits das gleiche wie du: VM sind in dem Marktsegment dominant.

          Und ein Artikel wird nicht dadurch blöde, dass er einen Konkurrenten der etablierten Technik zitiert. Die meisten Leser werden so viel Lesekompetenz besitzen, dass sie das nicht als neutrale Aussage einschätzen.

    0
    Von Verfluchtnochmal-05995bd7b am Do, 2. August 2018 um 18:28 #

    Anhand von "So gelten weitere Fragen auch den Kosten, die VMware-Lizenzen verursachen. Sie liegen bei 55% der Teilnehmer über 100.000 USD im Jahr" kannst du dir mal ausrechnen wer da eigentlich gefragt wurde

    Keine Ahnung was man veranstalten muss um da hin zu kommen, auf alle Fälle verdammt gross sein, und selbst da setzen 60% ihre Container weiterhin in VMs auf

    Wenn du mit 3 Hosts auskommst (Und da kannst du bei 2 Sockets pro Host einiges drauf laufen lassen) zahlst du für die Support-verlängerung keine 2000 *alle 3 Jahre* (Essentials Plus - vCenter, 3 Hosts, 6 CPU-Lizenzen, unlimited Cores) also hör auf von Dingen zu reden von denen du nichts verstehst

    Warum setzt man Container AUF eine bestehende Virtualisierungsinfrastruktur?

    Weil man damit Hochverfügbarkeit und Redundanz gleich miterschlägt und sich drauf verlassen kann dass die Container bei einem Hostauffall weiterlaufen ohne das wiederholt zu implementieren - Viel SPass auf Bare-Metal und viel Spass alles bei 0 neu aufzubauen und zu testen versus ein paar VMs durch weitere Konsolidierung in selbigen zu ersetzen

    Aber niemand der noch ganz dicht ist erssetzt die komplette Infrastruktur mit Containern weil es keine probleme löst sondern sie nur verschiebt

    Und aj, auch dort wo du 100k im jahr für VMware bezahlst ist das nur Peanuts sonst bräuchtest du keine Enterprise-Lizenzen auf hunderten pyhsischen Blechen, die laufen dort nämlich nicht zum Selbstzweck sondenr bringen die Kohle vielfach wieder rein

    • 0
      Von irgendwer am Fr, 3. August 2018 um 10:17 #

      Dafür, dass du so rum posaunst und andere für dumm verkaufen willst, hast du dich erstaunlich wenig mit der Materie auseinandergesetzt.

      Kubernetes macht genau das, was du als Pluspunkt für VMs ansetzt, auf Bare Metal. Performancetests zeigen, dass Leistung (insb. Latenzen) und Ressourcenverbrauch dabei deutlich verbessert werden. Wenn das Nutzungsszenario Container vorsieht, ist das durchaus eine Wahl, die man ins Auge fassen kann.

      Und selbst wenn man es auf VMs betreiben will. Die Kosten sind dabei selbst bei VMware Essentials noch höher und Features geringer als bei manch anderer Lösung für ein unbeschränktes Komplettpaket. Essentials Plus ist ja doch sehr beschränkt.

      Ist ja schön, dass du noch immer was verdienst, obwohl du Geld zum Fenster raus schmeißt. Andere wollen vielleicht einfach die paar für dich unbedeutende Kröten nochmals mehr verdienen.

      • 0
        Von Verfluchtnochmal-05995bd7b am Fr, 3. August 2018 um 15:40 #

        Blöderweise ist aber das Isolationslevel von Containern ein wesentlich schlechteres als von virtuellen Maschinen womit du in der Praxis ohnehin beides brauchst und Virtualisierung nicht einfach komplett durch Container ersetzen kannst (Es sei denn du willst einen ganz grossen Fehler machen)

        Also wirst du VMs definitiv nicht komplett los

        Du musst also einigermassen blöde sein wenn du HA auf 2 Layern umsetzt statt deine Contrainer auf einer bereits vorhandenen virtualisierten Infrastruktur aufzusetzen

        Wenn es um Server geht hat das Blech genau eine Aufgabe: Den Hypervisor booten, ob der jetzt VMware, Proxmox oder RHEV ist tut da erstmal wenig zur Sache

        • 0
          Von irgendwer am Fr, 3. August 2018 um 16:12 #

          Erstens stimmt das so nicht, genau darum geht es ja gerade auch bei Containern: Isolation. Es gibt einen Unterschied zwischen Container und VMs, ja. Aus der ungeschützten chroot-Zeit sind wir aber lange raus. Die sind teils so gut isoliert, dass man in der Praxis auch Container an völlig unterschiedliche Kunden (somit sehr hohem Bedarf an Isolation!) vermieten kann. Einen Fehler macht man da noch lange nicht. Ganz im Gegenteil. Container sind sogar ein Mittel zu _größerer_ Isolation. Indem man Services isolieren kann (geringerer Ressourcenoverhead halt), die sonst innerhalb eines Userlands (einer VM) laufen.

          Und zweitens benötigt man das oftmals überhaupt gar nicht.

          Du hast nur deinen eigenen, offensichtlich eher beschränkten Usecase im Blick und sprichst jedem Dummheit zu, der diesen nicht mit dir teilt.

          Teils gibt es Bedarf an tausenden isolierten Microservices, die locker mehrere ganze Bleche für sich beanspruchen können. Da ist es ein deutlicher Overkill und Ressourcenverschwendung, ganze Cluster aufzusetzen, auf denen jeweils pro Blech nur eine VM läuft. Zumal das sehr problematisch ist, denn bei Ausfall eines Nodes muss die VM ja im Ganzen von einem anderen Node übernommen werden. Doppelte Last? Nicht drin. Also müssen doch mehrere VMs pro Blech laufen, so dass man diese bei Ausfall gleichmäßiger verteilen kann. Und schon nimmt der Ressourcenoverhead weiter zu. Die Latenz geht in den Keller. Overhead, der nicht nötig ist.

          Verteilt man im HA-Failover-Fall die einzelnen Container sowieso selber, kann man wiederum auf die HA-VM verzichten. Der Container-Host läuft am nackten Blech. Ein viel einfacherer und gleichmäßigerer Lastausgleich bei geringerem Ressourcenoverhead.

          Kein Wunder dass selbst einfache Systeme für kleinere Betreiber (wie Proxmox) mittlerweile selber direkt Container verwalten können. Das Prinzip ist da zwar anders als bei Docker, der Container ein vollständiger Host und kein Microservice, eignet sich dennoch durch den deutlich geringeren Ressourcenoverhead für Aufgaben (z.B. für eine Verteilung vieler kleiner Services), für die VMs einfach Overkill sind. Größere Systeme ala OpenStack, Amazon, Azure, etc. gehen daher keinen anderen Weg. Da kriegt man für seine Microservices sicher _keine_ eigene VM und gut isoliert sind die allemal.

          Sicher kann es durchaus sinnvoll sein, seine Container nur in einer VM laufen zu lassen. Aber nicht ausschließlich.

          • 0
            Von Verfluchtnochmal_5987109 am Fr, 3. August 2018 um 21:02 #

            Bla - 99 Prozent eines containers kann ich mit einem fucking systemd service abbilden weil so gut wie alle relevanten Optionen recht simpel exposed und mit template units umgesetzt werden können

            Ein wirklich gutes systemd unit hat die gleiche Isolierung eines containers ohne dessen Nachteile in der Verwaltung

            NEIN du hast auf einem blech nicht nur eine VM weil das völlig schwachsinnig wäre, du hast auf diversen blechen einen Haufen an VM's die container bzw isolierte services hosten aber du entkoppelst wenn du kein Depp bist Hardware/Failover komplett von Anwendungen und ein container ist auch nur eine Anwendung

0
Von dasa am Do, 2. August 2018 um 19:48 #

Während versucht wird, mittels Reproducible Builds die Erstellung von Paketen nachvollziehbar zu machen, werden andererseits Lösungen wie Docker und LXC auf den Markt geworfen, bei denen die Images nicht vor Manipulationen geschützt sind. Zwar gibt es die Möglichkeit, Images zu signieren. Doch wird dies AFAIK kaum genutzt.

Die einzig für mich akzeptable Lösung war OpenVZ 6. Hier habe ich meine "OS Templates" noch aus den Stage3 Tarballs des Gentoo Projektes erstellt. Diese sind glücklicherweise signiert. Mit OpenVZ 7 ist man leider davon abgekehrt. Hier wird ähnlich Docker auf ein Repo zurückgegriffen. :(

  • 0
    Von Verfluchtnochmal-05995bd7b am Do, 2. August 2018 um 19:52 #

    Gottseidank muss man diesen ganzen gehypten Dreck nicht benutzen

    Software die nicht als RPM gebaut werden kann ommt nicht auf mein System, gertig, so einfach ist das

    0
    Von dockeruser am Do, 2. August 2018 um 20:33 #

    Ich nutze an fertigen Images eigentlich nur Debian, Ubuntu und Alpine - und wenn es hoch kommt mal von einem RDBMS, sofern das lokal läuft. Alles andere ist mir zu intransparent. Selbst wenn die Images irgendeine Qualitätskontrolle durchlaufen, was ist mit den Dockerfiles auf denen sie basieren? Dann hat man im Zweifelsfall viele Layer von Dockerfiles, und damit viele Angriffspunkte - oder Möglichkeiten zur Schlamperei.

    • 0
      Von dasa am Sa, 4. August 2018 um 14:05 #

      Vielen Dank. Alpine Linux war bisher nicht auf meinem Radar. Mal schaun, ob die Distro was taugt. Laut Wikipedia Eintrag scheints viel versprechend zu sein. Bare minimum, hardened Distro mit exzellenter Xen Unterstützung.

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung