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

Wie sind die Praxiserfahrungen mit den Tools?

  1. Thema

Neues Thema Ansicht wechseln


  1. Wie sind die Praxiserfahrungen mit den Tools?

    Autor: isaccdr 09.09.20 - 13:31

    Arbeite selbst seit 5 Jahren mit Puppet und in meinen Augen ist ein großes Manko, dass der Aufwand sich da reinzuarbeiten sehr hoch ist. Das liegt nicht daran das man bei custom Sachen Ruby können muss sondern daran, dass man mit Puppet richtig viel Murks machen kann, wenn man sich nicht an Patterns wie "Roles and Profiles" hält und Dinge wie Hiera nicht kennt. Puppet ist da einfach historisch gewachsen und solche Sachen haben sich nur aus best practices herausgebildet, ohne dass es zum eigenen Standard von Puppet gehört nach dem die Codebase designt sein muss..

    Ich habe leider schon oft extrem schlechten und unperformanten Puppet Code gesehen, einfach weil die Leute nicht geschult werden und einfach mal anfangen. Und dadurch das man in Puppet praktisch alles machen kann, ist das Resultat oft grauenhaft.

    Ist das bei Ansible & Co. auch so?



    1 mal bearbeitet, zuletzt am 09.09.20 13:32 durch isaccdr.

  2. Re: Wie sind die Praxiserfahrungen mit den Tools?

    Autor: Trockenobst 09.09.20 - 13:58

    isaccdr schrieb:
    --------------------------------------------------------------------------------
    > Ist das bei Ansible & Co. auch so?

    Ansible wirkt auf den ersten Schlag super easy. Wir haben 50+ Server gehabt und mussten die immer wieder neu Provisionieren. Die hacker Freunde im Haus standen drauf.

    Die einfachen Sachen gingen schnell. Software drauf, Server starten, Firewall up. Schön. Dann willst du Server 13, 18, 29 spezifisch updaten - das wird dann schon schwieriger im YAML. Ältere Versionen zurück rollen, ok, mache ich schnell direkt im SSH. Ansible wirkte auch häufig zu nachdenklich, die Skripte liefen sehr lahm.

    Grundsätzlich ist das Problem aller dieser Tools das du eine Datenbank mit allen Servern-IPs, SSH Keys, Anwendungsports, Firewallzugängen etc. brauchst. Viele Leute haben schon solche Systeme am Start, und dann Ansible und Co darauf anzupassen kann unglaublich viel Arbeit sein.
    Da muss jemand ganz oben Mannmonate an Budget freigeben, damit es dann am Ende ganz easy ist. So ist es aber leider in vielen großen Firmen nicht.

    Bei Ansible hatten wir das Gefühl dass es Sinn für die Cloud/VM Leute macht, die 1000+ Server haben, die jedes mal wieder geplättet werden. Das ging bei uns gar nicht, da man aus Sicherheitsgründen bestimmte Sachen eben mit einem bestimmten Account nicht machen darf.
    Das mochte das Ansible nicht und mag das auch bis heute nicht, wenn ich bestimmte Bugs auf github anschaue. Manipulieren anstatt Plattmachen, das ist bei vielen älteren Firmen die Regel und da steigt auch die Tool-Konkurrenz gerne aus was ich so in Gesprächen gehört habe.

    Für bestimmte Themen ist Ansible wahrscheinlich eine der einfachste Lösungen, eine strukturierte und saubere Plattmach-Installation hinzubekommen, wenn man keine Agents/Clients verteilen will. In der Partnerfirma nutzen sie Puppet, aber auch da wollte man nicht wirklich eine Empfehlung aussprechen, die haben nur zu viel Zeit in das Tool versenkt und finden, ein Umstieg auf Ansible oder Salt würde nur zu ähnlichen Problemen führen.

  3. Re: Wie sind die Praxiserfahrungen mit den Tools?

    Autor: HeroFeat 09.09.20 - 14:03

    Und was macht ihr bzw. eure Partnerfirma nun? Ihr werdet ja wohl hoffentlich kaum alles von Hand machen?

  4. Re: Wie sind die Praxiserfahrungen mit den Tools?

    Autor: Dino13 09.09.20 - 14:07

    Genau dafür habe ich Ansible bis jetzt immer verwendet. Ich brauch mal mehr oder weniger AWS Instanzen die erstellt und gestartet werden müssen, etwas tun und dann wieder sterben. Das geht ganz wunderbar mit Ansible. Muss aber zugeben dass ich mich sonst überhaupt nicht damit auskenne und mein Wissen sehr begrenzt ist.

  5. Re: Wie sind die Praxiserfahrungen mit den Tools?

    Autor: tunnelblick 09.09.20 - 14:16

    Ich komme von Salt und muss nun ansible machen und bin erstaunt, wie umständlich manche Sachen sind.
    Beispiel: Konditionen.
    Salt:
    If <condition> then
    ..
    ..
    ..
    ..
    If

    Ansible:
    Mach was, dann "Register: variable". Und dann bei jedem Task, der davon abhängig ist, Task schreiben und am Ende immer: "when: variable is true" or whatever.
    Ansible ist wirklich stupides "führe folgende Dinge aus", da ist Salt eine ganz andere Hausnummer.

  6. Re: Wie sind die Praxiserfahrungen mit den Tools?

    Autor: tstrunk 09.09.20 - 14:21

    isaccdr schrieb:
    --------------------------------------------------------------------------------
    > Arbeite selbst seit 5 Jahren mit Puppet und in meinen Augen ist ein großes
    > Manko, dass der Aufwand sich da reinzuarbeiten sehr hoch ist. Das liegt
    > nicht daran das man bei custom Sachen Ruby können muss sondern daran, dass
    > man mit Puppet richtig viel Murks machen kann, wenn man sich nicht an
    > Patterns wie "Roles and Profiles" hält und Dinge wie Hiera nicht kennt.
    > Puppet ist da einfach historisch gewachsen und solche Sachen haben sich nur
    > aus best practices herausgebildet, ohne dass es zum eigenen Standard von
    > Puppet gehört nach dem die Codebase designt sein muss..
    >

    Wir nutzen auch Puppet für unsere Cluster und fahren damit bislang gut. Ich kann sämtliche deiner Erfahrungen bestätigen. Puppet hat für mich den großen Nachteil, dass es sehr viele ungeschriebene Gesetze gibt, die man einhalten muss, bevor man mit einem Repo Manager wie r10k endlich produktiv loslegen kann. Puppet würde sehr davon profitieren, wenn man die Flexibilität in dem Aufsetzen des Repos zurücknimmt und die Leute zwingen würde roles und profiles mit einer fixen Ordnerhierarchie zu nutzen.

  7. Re: Wie sind die Praxiserfahrungen mit den Tools?

    Autor: Tuxraxer007 09.09.20 - 14:35

    Ich nutze Ansible erst etwas über 1 Jahr und habe bisher nur gute Erfahrungen gemacht.

    Derzeit nutzen wir Ansible ausschließlich für Linux-System, werden den Kreis auf auf Netzwerk, Stroage und Windows-System nach und nach erweitern.
    Anwendung aktuell für die Basisinstallation von Linux-Server ( die immer gleich ist ) , Upgrades, Software-Installation usw.

    Es macht etwas Arbeit, neue Playbooks zu erstellen, aber wenn man diese Playbook wiederholt nutzen kann, erspart es viel Arbeit, die immer gleichen Installationen von Hand zu machen.

  8. Re: Wie sind die Praxiserfahrungen mit den Tools?

    Autor: Trockenobst 09.09.20 - 15:20

    HeroFeat schrieb:
    --------------------------------------------------------------------------------
    > Und was macht ihr bzw. eure Partnerfirma nun? Ihr werdet ja wohl
    > hoffentlich kaum alles von Hand machen?

    Die benutzten weiter Ansible, ist schon 18 Monate her das ich dort war. Soweit ich verstanden habe gibt es jetzt ein "Digital Infrastructure" Team das diese Infos die Ansible zum arbeiten braucht (oder jedes andere Tool) in irgendeiner Datenbank vorhält.

    Die Puppet Freunde haben wohl inzwischen - da in einem größeren Konzern - eine externe Firma die sich um alle Server kümmern. Die sind von Puppet auf Salt(stack) umgestiegen. Die haben sehr viel Erfahrung und viele Kunden, daher sind sie wohl sehr fit mit Salt und haben auch Tools/Skripte/Setups die optimal für Salt passen. D.h. wenn du dich für eine Serverkomponente entscheidest, wird erst geprüft ob sie überhaupt gut mit Salt zusammenarbeitet. Das gehört dann auch in diese Thematik hinein, das haben wir z.B. gar nicht gemacht und massive Handarbeit rein stecken müssen.

    Ich denke das Problem bei sehr vielen ist, das sie zwar irgendwie 50-200 Server betreiben/dürfen oder es ist da irgendwie hin gewachsen, aber es hat sich keiner Gedanken über Metathemen wie "Welche Rechte hat der User auf der Apache Instanz in Asien". Und das alles noch in einer Form zu dokumentieren, die von solchen Tools und Skripten nutzbar sind. Da steckt die große Arbeit drin.

    Eine Antwort für "Sind für das Projekt M3 tatsächlich alle User auf allen System eingerichtet" ist dann nicht im Skripting zu suchen, sondern ob M3 irgendwie auf der technischen Ebene mit allen Parametern definiert wird, sodass ein AddUser manuell oder per Massenskript tatsächlich funktioniert. Da muss ein anderes Team nur DNS Einträge ändern oder vergessen Zertifikate upzudaten und schon ist wieder viel Handarbeit angesagt weil nichts ineinander greift.

  9. Re: Wie sind die Praxiserfahrungen mit den Tools?

    Autor: flow77 09.09.20 - 21:01

    isaccdr schrieb:
    --------------------------------------------------------------------------------
    > Arbeite selbst seit 5 Jahren mit Puppet und in meinen Augen ist ein großes
    > Manko, dass der Aufwand sich da reinzuarbeiten sehr hoch ist. Das liegt
    > nicht daran das man bei custom Sachen Ruby können muss sondern daran, dass
    > man mit Puppet richtig viel Murks machen kann, wenn man sich nicht an
    > Patterns wie "Roles and Profiles" hält und Dinge wie Hiera nicht kennt.
    > Puppet ist da einfach historisch gewachsen und solche Sachen haben sich nur
    > aus best practices herausgebildet, ohne dass es zum eigenen Standard von
    > Puppet gehört nach dem die Codebase designt sein muss..
    >
    > Ich habe leider schon oft extrem schlechten und unperformanten Puppet Code
    > gesehen, einfach weil die Leute nicht geschult werden und einfach mal
    > anfangen. Und dadurch das man in Puppet praktisch alles machen kann, ist
    > das Resultat oft grauenhaft.
    >
    > Ist das bei Ansible & Co. auch so?

    Ansible ist relativ strikt, da alles mit z.B. yaml-Templates läuft.
    Aber letztendlich schützt das nicht davor dass man vor jedem playbook ein apt-get update ausführt.

    Der Aufwand sich mit Ansible zu beschäftigen und es zu verstehen ist sicher hoch, aber die Zeitersparnis ist um so höher.

  10. Re: Wie sind die Praxiserfahrungen mit den Tools?

    Autor: ixs 09.09.20 - 21:22

    Ich habe 2009 Puppet gemacht, 2013 bei einem anderen Arbeitgeber war dann Chef dran.
    Nach einem weiteren Wechsel 2016 war es dann Ansible. Und für ein Freelance-Projekt mache ich seit 2017 Salt... Jeweils täglich im Produktiveinsatz auf wichtigen Systemen.

    Generell würde ich heute von Puppet und Chef abraten. Diese Systeme sind ziemlich alt und unflexibel. Vor 10 Jahren waren sie toll, aber mittlerweile gibt es wesentlich besseres. Dies liegt auch an der Produktpolitik der Hersteller, die halt sagten, dass sie sich auf den Enterprise-Einsatz bei grossen und zahlenden Kunden konzentrieren. Dass Puppet 2011 rum sagte, dass sie keine neuen Module mehr in die Standard-Bibliothek übernehmen und man stattdessen bitte alles in der Forge abladen soll, fand ich auch nicht sehr hilfreich. Insbesondere wenn ich das mit den hunderten von Ansible Modulen und der noch grösseren Auswahl von Salt Execution und State Modules vergleiche. Da sind diese um Längen komfortabler.

    Ansible ist super, wenn man ein gewachsenes System langsam automatisieren will, weil es absolut leicht für Einzelaufgaben genutzt werden kann. z.B. kann ein einzelner Mitarbeiter ohne grosse Abstimmung anfangen, einen einzelnen Prozess zu automatisieren. Und dann den nächsten, und den nächsten. Und all das ohne gross Infrastruktur zu benötigen, weil alles lokal auf der eigenen Kiste läuft und SSH sowieso verfübar ist.
    Sowas geht mit Chef und Puppet praktisch nicht und mit Salt-SSH nur ein bisschen eingeschränkter.

    Für die meisten Aufgaben ist Ansible absolut ausreichend und fehlende Funktionen können im allgemeinein nachgerüstet werden. Die Lernkurve ist auch gut, man kann leicht anfangen und mit etwas Erfahrung auch komplexere Dinge lösen.
    Unschön ist, dass Ansible durch die verwendete YAML DSL manchmal sehr eingeschränkt ist und gerade Operationen wie "extrahiere bestimmte Daten aus einem mehrfach geschachtelten Dictionary und mach dann Sachen damit" sehr fiese Hacks werden. Einen custom Jinja Filter zu schreiben ist dann eine gute Idee...
    Das zweite Problem bei Ansible ist, dass die Ausführungsgeschwindigkeit nicht unbedingt sehr schnell ist. Wenn die Systeme in den USA sind, man selber aber in Europa, dann dauert alles lange. Wenn man tausende von Dingen macht, dann auch. Da sind Chef und Puppet und Salt wesentlich fixer.

    Salt ist das Ding der Wahl, wenn man es "richtig" machen will und komplexe Umgebungen verwalten will. Es ist unendlich flexibel und an kann alles machen. Und wenn es nicht reicht, dann erweitert man es einfach in Python. Aber diese Flexibilität erkauft man sich mit Anfangshürden. Mal eben schnell damit anfangen geht nicht, man braucht Infrastruktur. Aber dann geht einiges.
    Und sobald man erstmal weiss, wie man seine Daten organisiert, wo seine States und wo die Pillars hingehören, dann kann man einiges erreichen.
    Hier und da gibt es Nervigkeiten, z.B. ist Ansible mit register sehr geschickt um den Output eines Programms wo anders zu verwenden. Das ist bei Saltstack nicht so schön gelöst. Mittlerweile gibt es __slots, was ein guter Anfang ist, aber es ist noch nicht so weit...
    Andere Sachen sind bei Salt besser als bei Ansible, z.B. Loops und so...
    Ein ganz wichtiger Punkt bei Salt ist, dass cfgmgmt nicht die Hauptaufgabe ist. Angefangen hat es als remote execution tool und cfgmgmt ist erst später als "state"-Modul dazugekommen. Dies erlaubt unheimliche Flexibilität, z.B. brauche ich kein SSH mehr, das geht per Salt besser und schneller.

    Aber allgemein gilt: Selbst das schlechteste cfgmgmt is besser als gar keines.
    Und das nächste Entscheidungskriterium ist, was kennen die Leute. Wenn die Firma voller Ruby-Coder ist, dann wäre Puppet oder Chef z.B. eine gute Idee. Wenn die alle Python können, dann Ansible und Salt.
    Und wenn jemand im Team lange Erfahrung hat, dann ist es Sinnvoll diese zu nutzen und das bekannte System zu verwenden.

    Im Endeffekt können alle Tools ausreichend viel um auch zehntausende von Servern zu managen...



    1 mal bearbeitet, zuletzt am 09.09.20 21:22 durch ixs.

  11. Re: Wie sind die Praxiserfahrungen mit den Tools?

    Autor: club-mate 10.09.20 - 12:42

    tunnelblick schrieb:
    --------------------------------------------------------------------------------
    > Ansible:
    > Mach was, dann "Register: variable". Und dann bei jedem Task, der davon
    > abhängig ist, Task schreiben und am Ende immer: "when: variable is true" or
    > whatever.
    > Ansible ist wirklich stupides "führe folgende Dinge aus", da ist Salt eine
    > ganz andere Hausnummer.

    Blocks könnten hier vielleicht die Lösung sein:
    https://docs.ansible.com/ansible/latest/user_guide/playbooks_blocks.html

  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. Senatsverwaltung für Gesundheit, Pflege und Gleichstellung, Berlin
  2. KIRCHHOFF Automotive GmbH, Iserlohn
  3. TREND Service GmbH, Wuppertal
  4. Generali Deutschland AG, Aachen, Hamburg, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 299,90€
  2. täglich Hardware zu gewinnen
  3. (u. a. Cooler Master MasterCase H100 PC-Gehäuse für 44,72€, Taotronics Over-Ear-Kopfhörer für...
  4. (u. a. Laptop-Ständer für 13,99€, 4K-HDMI-Kabel für 5,21€, Mechanische Gaming-Tastatur für...


Haben wir etwas übersehen?

E-Mail an news@golem.de