1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Configuration Management Tools…

Qualität des Artikels

  1. Thema

Neues Thema Ansicht wechseln


  1. Qualität des Artikels

    Autor: ixs 09.09.20 - 20:52

    Hallo Redaktion,

    der Artikel muss nochmal in's Lektorat. Er strotzt nur vor Fehlern.


    Ansible:
    - Hat keinen Master server, das ansible script kann überall ausgeführt werden, z.B. auf dem Notebook des Entwicklers
    - RDP wird nicht verwendet sondern WinRM
    - Playbooks brauchen keine Python Scripte, sie sind im gegenteil sehr unüblich.
    - Die API ist _nicht_ für externe Benutzung vorgesehen/supported.
    - Playbooks werden nicht in Python geschrieben, sondern in YAML und Jinja.
    - Reporting existiert.

    Chef:
    - Nein, chef nutzt keine Ruby-DSL, es ist plain ruby. Das ist gerade der herausragende Unterschied zu Puppet, das eine eigene DSL nutzt. Es ist übrigens auch ein Nachteil, weil es Leute dazu verleitet z.B. das Ruby-eigene system() anstelle des chefs "execute" zu verwenden und dann ist das cookbook nicht mehr idempotent.
    - Die Tatsache, dass manuelle Änderungen vom Configurationsmanagement übergebügelt werden ist nicht Chef-eigen, das ist Teil _jedes_ cfgmgmt Systems.

    Puppet:
    - Masterless puppet existiert, der Hinweis auf "Konfigurationsdateien die per Hand irgendwo abgeholt werden" ist jedoch an den Haren herbeigezogen. Im allgemeinen sieht der Ablauf so aus, dass es einen cronjob gibt der "cd irgendwas && git pull && puppet apply ..." macht. Und oh wunder, git ist automatisch aktualisiert.
    - Puppet braucht eben keine Ruby Kentnisse. Puppet ist zwar in Ruby geschrieben, aber die Puppet Manifests nutzen eine eigene, puppet-spezifische DSL. Hier ist Chef mit Puppet verwechselt worden.

    Saltstack:
    - Auch hier wurde wichtiges verwechselt. Salt via SSH ist _nicht_ der Normalzustand. Im Normalzustand nutzt Salt einen "minion" auf dem Zielsystem der mit dem "master" über ZeroMQ kommuniziert. Salt ist push oder pull, je nach Konfiguration.
    - Salt-ssh ist eine Möglichkeit, ohne agents cfgmgmt als push zu betreiben. Es gibt aber im Detail gewisse Limitierungen im Vergleich zu ZeroMQ. salt masterless geht übrigens auch, nur der Vollständigkeit halber.
    - Salt nutzt nicht "wie Ansible" YAML und Python. Wie schon gesagt, diese Aussage ist für Ansible so falsch, wie sie für Salt falsch ist. Salt nutzt per default YAML und Jinja2. Während bei Ansible der Jinja Parser nach dem YAML parsing auf die Dict Values ausgeführt wird, werden bei Salt die Files erst durch Jinja2 geschickt und dann durch den YAML Parser. Sollte dies nicht ausreichen, kann man den Parser auch austauschen und stattdessen etwas eigenes nutzen, z.B. pure Python. Dies ist aber bei weitem nicht der Normalfall.
    - Salt bietet nicht nur eine API für Events, es ist komplett Event-Driven. D.h. eine Logik wie "Datei /etc/passwd wurde auf minion X geändert, automatisch wieder den gewünschten Zustand herstellen" ist mit Bordmitteln zu erreichen.

    Zum Fazit:
    - Um in einem verteilten System (z.B. Cluster) die Reihenfolge von Operationen einzuhalten und z.B. auf die anderen Maschinen zu verteilen, ist Ansible wirklich grossartig durch sein top-to-bottom parsing und die Funktion "delegate_to". salt-ssh ist hier kein Vergleich und kann dies nicht in der Art leisten. Bei Salt heisst diese Option salt-orchestrator und erlaubt Systemübergreifende Abfolgen, Abhängigkeiten und Reihenfolgen festzulegen...
    - Die Vermeidung von Configuration-Drift, also das erzwingen eines Sollzustandes, ist mit _allen_ Tools notwendig. Ansible Tower oder Rundeck z.B. bieten die Möglichkeit ansible alle 30min zu starten und somit Änderungen automatisch durchzuführen. Puppet, Chef und Salt haben diesen Scheduler bereits eingebaut, können aber auch von einem Tool wie Rundeck oder den Firmeneigenen Dashboard-Systemen gemanaged werden.


    Die restlichen Aussagen im Artikel sind zwar nicht falsch, aber auch eher sehr ungenau bzw. nichtssagend.

    Zusammenfassend ein echt schwacher Artikel. 😐 Da hätte ich hier besseres erwartet.



    1 mal bearbeitet, zuletzt am 09.09.20 20:58 durch ixs.

  2. Re: Qualität des Artikels

    Autor: isaccdr 09.09.20 - 21:08

    ixs schrieb:
    ------------------------------------------------------------------------------.
    > - Puppet braucht eben keine Ruby Kentnisse. Puppet ist zwar in Ruby
    > geschrieben, aber die Puppet Manifests nutzen eine eigene,
    > puppet-spezifische DSL. Hier ist Chef mit Puppet verwechselt worden.

    Kommt drauf an wie sehr man Puppet ausreizt. Wenn man eigene Provider für Puppet schreiben will, kommt man um Ruby nicht herum. Zumindest braucht man heute aber kein Ruby mehr, um Data types zu definieren. Wahrscheinlich hat der Autor das aber nicht gemeint...

  3. Re: Qualität des Artikels

    Autor: ixs 09.09.20 - 21:50

    Klar, wenn man eigene Provider schreiben will oder wenn man Facter erweitern will etc. dann braucht man Ruby.

    Aber als normaler Anwender von Puppet, da braucht man das nicht.
    Das ist wie bei Salt oder Ansible: Python ist echt hilfreich, weil einem Jinja dann leichter von der Hand geht... Aber eine Vorraussetzung ist es nicht.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Interhyp Gruppe, München
  2. Ingeus GmbH, Nürnberg
  3. operational services GmbH & Co. KG, Frankfurt am Main, Berlin, Dresden, München
  4. meta Trennwandanlagen GmbH & Co. KG, Rengsdorf

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Asus TUF-RTX3080-10G-GAMING 10GB für 739€, MSI GeForce RTX™ 3080 GAMING X TRIO 10GB...
  2. (u. a. Zotac Gaming GeForce RTX 3090 Trinity 24.576 MB GDDR6X für 1.714.22€, Gigabyte Geforce...
  3. (u. a. Returnal für 79,99€, Lego Star Wars: Die Skywalker Saga für 59,99€, Overcooked: All...


Haben wir etwas übersehen?

E-Mail an news@golem.de