Inwiefern unterscheidet sich Ansible davon, einfach eine Bash-Shell für die Bereitstellung in Vagrant auszuführen?

38

Ein Team von IT-Systemadministratoren, die Erfahrung mit der Verwendung von Shell-Skripten zur Lösung ihrer Probleme haben, erwägt, stattdessen Ansible zu verwenden.

Gibt es wesentliche Unterschiede und gute Gründe, Ansible zu verwenden oder weiterhin Shell-Skripte zu schreiben?

Evgeny
quelle

Antworten:

29

Ich habe Ansible nie benutzt, aber seit ein paar Wochen versuche ich herauszufinden, wie gut Ansible im Vergleich zu Shell-Scripten sein kann - was zumindest in meinem Fall beweist, dass die eindringlichen Werbekampagnen, die sie durchführen, effektiv sind! Nach vielen erfolglosen Versuchen, die beweisen, dass ihre Dokumentation eine der offensichtlichsten Fragen nicht beantworten kann, glaube ich, dass ich es endlich verstanden habe:

Schauen wir uns nun das Einführungsvideo an und gehen wir als potenzieller neuer Benutzer das Einführungsmaterial zu Ansible durch und vergleichen es mit dem, was ein erfahrener Shell-Programmierer von Anfang an produzieren kann.

Meine Schlussfolgerung ist, dass Ansible im Vergleich zu Shell-Skripten im Wesentlichen Folgendes bietet: 1. Die Möglichkeit, zu überprüfen, ob ein System mit einem gewünschten Status übereinstimmt. 2. Die Fähigkeit, sich in Ansible Tower zu integrieren. In einigen wichtigen Fällen, wie bei der Implementierung des Musters für unveränderliche Server, ist der Punkt 1 wahrscheinlich nicht sehr nützlich, daher ist die Liste eher dünn.

Mein Fazit ist, dass die Vorteile von Ansible gegenüber Shell-Scripting, wie sie in der Dokumentation dargestellt werden, in einigen wenigen optimistischen Fällen sinnvoll sein könnten, die von den verfügbaren Modulen gut abgedeckt werden, aber im Allgemeinen klein oder sogar hypothetisch sind. Für einen erfahrenen Shell-Programmierer werden diese Vorteile höchstwahrscheinlich durch andere Aspekte des Kompromisses ausgeglichen.

Aber das beweist vielleicht nur, wie schlecht das Einführungsmaterial ist!

Das Schnellstart-Video:

Es gibt ein Schnellstartvideo . Es beginnt mit einer Seite, die behauptet, dass ... nun, das sind keine wirklichen Behauptungen, das sind Aufzählungslisten, ein Artefakt, das häufig verwendet wird, um die kritische Beurteilung in Präsentationen auszusetzen (da die Logik nicht gezeigt wird, kann es nicht kritisiert werden!).

1. Ansible ist einfach:

1.1 Vom Menschen lesbare Automatisierung - Spezifikationen sind technische Dokumente, wie könnte

  name: upgrade all packages
  yum:
    name: '*'
    state: latest

einfacher zu lesen als der entsprechende yum- Aufruf in einem Shell-Skript? Darüber hinaus stirbt jeder, der Kontakt zu AppleScript hatte, lachend, wenn er „lesbare Automatisierung“ liest.

1.2 Keine besonderen Codierungskenntnisse erforderlich - Was ist Codierung, wenn keine formalen Spezifikationen geschrieben werden? Sie haben Bedingungen, Variablen, also, wie codiert es nicht? Und warum brauche ich etwas, das ich nicht programmieren kann, das von nun an unflexibel ist? Die Aussage ist zum Glück ungenau!

1.3 Aufgaben, die in der richtigen Reihenfolge ausgeführt werden - Nun, vielleicht kennen einige Codegolf-Liebhaber Sprachen, die Aufgaben in einer falschen Reihenfolge ausführen, aber die Ausführung von Aufgaben in der richtigen Reihenfolge sieht kaum außergewöhnlich aus.

1.4 Schnell produktiv werden - Erfahrene Shell-Programmierer sind jetzt produktiv. Dieses Gegenargument ist genauso ernst wie das ursprüngliche Argument.

2. Ansible ist mächtig

Ein beliebter Trick für Verkäufer, um Artefakte zu verkaufen, besteht darin, die Menschen zu täuschen, sie würden die "Macht" dieser Artefakte erlangen. Die Geschichte der Werbung für Autos oder isotonische Getränke sollte eine überzeugende Liste von Beispielen liefern.

Hier kann Ansible "App-Bereitstellung" durchführen - Shell-Skripte jedoch sicherlich, "Konfigurationsverwaltung", aber dies ist lediglich eine Aussage über den Zweck des Tools, keine Funktion, und "Workflow-Orchestrierung", die ein bisschen anspruchsvoll aussieht, aber kein Beispiel dafür enthält jenseits dessen, was GNU Parallel kann.

3. Ansible ist ohne Agent

Um die Spalte zu füllen, haben sie auf drei verschiedene Arten geschrieben, dass dies nur ssh benötigt , was, wie jeder weiß, ein Daemon ist und nichts mit diesen Agenten zu tun hat, die das weltweite Konfigurationsmanagement durchdringen!

Der Rest des Videos

Der Rest des Videos enthält eine Einführung in die Bestandsliste, bei der es sich um eine statische Liste von Ressourcen (z. B. Servern) handelt, und zeigt, wie Apache auf drei Servern gleichzeitig bereitgestellt wird. Dies passt nicht zu meiner Arbeitsweise, bei der Ressourcen hochdynamisch sind und mithilfe der Befehlszeilentools, die von meinem Cloud-Anbieter bereitgestellt und von meinen Shell-Funktionen mithilfe des Pipe- |Operators verwendet werden, aufgelistet werden können. Außerdem stelle ich Apache nicht gleichzeitig auf drei Servern bereit, sondern erstelle ein Master-Instanz-Image, mit dem ich dann drei Instanzen starte, die exakte Replikate einer der anderen sind. Der „orchestrierende“ Teil der Argumentation sieht also nicht sehr relevant aus.

Zufällige Dokumentation Schritt 1: Integration mit EC2

EC2 ist der Computerdienst von Amazon. Die Interaktion mit diesem Dienst wird von einigen Ansible-Modulen unterstützt . (Andere beliebte Cloud-Computing-Anbieter sind ebenfalls verfügbar):

# demo_setup.yml

- hosts: localhost
  connection: local
  gather_facts: False

  tasks:

    - name: Provision a set of instances
      ec2:
         key_name: my_key
         group: test
         instance_type: t2.micro
         image: "{{ ami_id }}"
         wait: true
         exact_count: 5
         count_tag:
            Name: Demo
         instance_tags:
            Name: Demo
      register: ec2

Das entsprechende Shell-Skript wäre im Wesentlichen identisch mit YAML, ersetzt durch JSON:

provision_a_set_of_instances()
{
  aws --output=text ec2 run-instances --image-id …   
}

oder die JSON-Version

provision_a_set_of_instances()
{
  aws --output=text ec2 run-instances --cli-input-json "$(provision_a_set_of_instances__json)"  
}

provision_a_set_of_instances__json()
{
  cat <<EOF
{
    "ImageId": … 
}
EOF
}

Beide Versionen sind im Wesentlichen identisch, der Hauptteil der Nutzlast besteht aus der Aufzählung der Initialisierungswerte in einer YAML- oder JSON-Struktur.

Zufällige Dokumentation Schritt 2: Kontinuierliche Lieferung und fortlaufende Upgrades

Der größte Teil dieses Handbuchs enthält keine wirklich interessanten Funktionen: Es werden Variablen eingeführt (IIRC, Shell-Skripte haben auch Variablen) und ein Ansible-Modul behandelt MySQL mit Privilegien auf XY “und enden mit so etwas wie

# Create Application DB User
mysql --host "${mysql_host}" --user "${mysql_user}" --password "${mysql_password}" "${mysql_table}" <<EOF
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%';
EOF

Sie suchen nach "Wie erstelle ich einen MySQL-Benutzer mit Rechten auf XY in Ansible " und am Ende mit

- name: Create Application DB User
  mysql_user: name={{ dbuser }} password={{ upassword }}
              priv=*.*:ALL host='%' state=present

Der Unterschied ist wahrscheinlich immer noch nicht sehr bedeutsam. Auf dieser Seite entdecken wir auch, dass Ansible eine Template-Meta-Programmiersprache hat

{% for host in groups['monitoring'] %}
-A INPUT -p tcp -s {{ hostvars[host].ansible_default_ipv4.address }} --dport 5666 -j ACCEPT
{% endfor %}

Wenn ich das sehe, bin ich wirklich in meiner Komfortzone. Diese Art der einfachen Metaprogrammierung für deklarative Sprachen ist genau das gleiche theoretische Paradigma wie BSD-Makefiles! Was ich zufällig ausgiebig programmiert habe Dieser Auszug zeigt uns, dass das Versprechen, mit YAML-Dateien zu arbeiten, gebrochen ist (daher kann ich meine Playbooks nicht über einen YAML-Parser ausführen, z . B. ). Es zeigt uns auch, dass Ansible die subtile Kunst der Bewertungsreihenfolge diskutieren muss: Wir müssen entscheiden, ob Variablen im „deklarativen Teil“ der Sprache oder im „imperativen“ Metateil der Sprache erweitert werden. Hier ist die Shell-Programmierung einfacher, es gibt keine Metaprogrammierung, abgesehen von explizitem eval oder externem Script-Sourcing. Der hypothetische äquivalente Shell-Auszug wäre

enumerate_group 'monitoring' | {
  while read host; do
    …
  done
}

deren Komplexität im Vergleich zur Ansible-Variante wahrscheinlich erträglich ist: Es werden nur die einfachen, regelmäßigen, langweiligen Konstrukte aus der Sprache verwendet.

Zufällige Dokumentation Schritt 3: Teststrategien

Zuletzt treffen wir auf das, was sich als das erste wirklich interessante Merkmal von Ansible herausstellt : „Ansible-Ressourcen sind Modelle des gewünschten Zustands. Aus diesem Grund sollte es nicht erforderlich sein, zu testen, ob Dienste gestartet, Pakete installiert oder dergleichen sind. Ansible ist das System, das sicherstellt, dass diese Dinge deklarativ wahr sind. Behaupten Sie diese Dinge stattdessen in Ihren Spielbüchern. “Jetzt wird es ein bisschen interessant, aber:

  1. Abgesehen von einigen Standardsituationen, die von verfügbaren Modulen leicht implementiert werden können, muss ich die Bits, die den Test implementieren, selbst eingeben, was sehr wahrscheinlich einige Shell-Befehle beinhalten wird.

  2. Die Überprüfung der Konformität von Installationen ist in dem Kontext, in dem das unveränderliche Servermuster implementiert ist, möglicherweise nicht sehr relevant: In der Regel werden alle ausgeführten Systeme von einem Master-Image (z. B. Instanz-Image oder Docker-Image) erstellt und nie aktualisiert. Sie werden durch ersetzt stattdessen neu.

Unadressiertes Anliegen: die Wartbarkeit

Das Einführungsmaterial von Ansible ignoriert die Frage der Wartbarkeit. Shell-Scripting ist so wartungsfreundlich wie JavaScript, Lisp oder Python. Umfangreiche Umgestaltungen können nur mit Hilfe einer umfangreichen automatisierten Testsuite erfolgreich durchgeführt werden - oder zumindest mit Designs, die ein einfaches interaktives Testen ermöglichen. Dass die genannten, während die Shell - Skripten sind Verkehrssprache von Systemkonfiguration und Wartung, fast jeder Programmiersprache eine Schnittstelle zu der Schale hat. Es ist daher durchaus machbar, den Vorteil der Wartbarkeit erweiterter Sprachen zu nutzen, indem sie zum Zusammenkleben der verschiedenen Bits der Shell-Konfigurationsbits verwendet werden. Für OCaml habe ich Rashell geschrieben Dies bietet im Wesentlichen eine Reihe von gängigen Interaktionsmustern für Unterprozesse, was die Übersetzung von Konfigurationsskripten in OCaml im Wesentlichen trivial macht.

Abgesehen von Ansible machen die sehr schwache Struktur der Playbooks und das Vorhandensein eines Meta-Programmierfeatures die Situation im Wesentlichen so schlecht wie für Shell-Skripte, mit den Minuspunkten, dass es nicht offensichtlich ist, wie Unit-Tests für Ansible geschrieben werden sollen und das Argument der Einführung einer Ad-hoc-Sprache auf höherer Ebene kann nicht nachgeahmt werden.

Idempotenz von Konfigurationsschritten

Die Dokumentation von Ansible macht darauf aufmerksam, dass idempotente Konfigurationsschritte geschrieben werden müssen. Genauer gesagt, geschrieben werden Konfigurationsschritte so sollte , dass die Schrittfolge aba kann vereinfacht werden , ab , dh wir zu wiederholen Konfigurationsschritt nicht brauchen. Dies ist eine stärkere Bedingung als die Idempotenz. Da Ansible es Playbooks ermöglicht, beliebige Shell-Befehle zu verwenden, kann Ansible selbst nicht garantieren, dass diese stärkere Bedingung eingehalten wird. Dies hängt nur von der Disziplin des Programmierers ab.

Michael Le Barbier Grünewald
quelle
Dies scheint wie ein Handbuch ... beeindruckend!
Pierre.Vriens
4
Ich konnte nicht mehr zustimmen. Wir haben Ansible über 1 Jahr lang verwendet und verwenden nun Docker-Container, die mit guten, einfachen alten Bash-Skripten erstellt wurden. Die Definition des Status ist meiner Meinung nach auch das mit Abstand interessanteste Feature, aber wie Sie bereits erwähnt haben - es gibt so viele Dienste, die kein entsprechendes Ansible-Modul haben, dass Sie sowieso immer auf bash-Befehle zurückgreifen müssen. Und ja, wir stellen auch nur unveränderliche Container auf Servern bereit, sodass das Definieren des Status in diesem Fall keinen wirklichen Vorteil darstellt.
Andreas
1
Nachdem ich ansible gründlich benutzt habe, kann ich alle Punkte bestätigen, die ich a priori gemacht habe. Idempotenz ist möglich, wird aber von Ansible nicht erzwungen (siehe Modul vmware_guest für einen schlechten Bürger), die Arbeit mit ihrem Makrosystem ist ein echtes Problem und es ist zunehmend schwierig, selbst die grundlegendsten Behandlungen für strukturierte Daten durchzuführen, einige grundlegende Dinge tun einfach etwas Falsches (das Playbook-Format kann einen Unix-Dateimodus ohne Therapie nicht essen) und das einzig wirklich Gute ist das Laden von nützlichen Funktionen, die für ansible geschrieben wurden. Wenn Red Hat dieses Produkt nicht vorgestellt hätte, könnte ich die breite Akzeptanz nicht nachvollziehen.
Michael Le Barbier Grünewald
1
@Andreas Ich stimme dir zu, dass es immer noch viele Fälle gibt, in denen du auf die Shell oder Befehlsmodule zurückgreifen musst, die nicht bedeuten, dass dein ansibles Spiel nicht idempotent sein kann. Die Kernmodule selbst behalten ihre Idempotenz bei, indem sie nur prüfen, ob die Aktion durchgeführt werden soll. Sie können dasselbe selbst mit der Shell oder dem Befehlsmodul tun, indem Sie zuerst eine Task ausführen, die prüft, ob etwas ausgeführt werden soll, und die Ausgabe registriert. Anschließend können Sie eine Bedingung für die zweite Task basierend auf der Ausgabe der ersten Task ausführen.
Levi
1
@ MichaelLeBarbierGrünewald, ich muss insgesamt zustimmen, als ich mit Ansible zusammengearbeitet habe, war es ein echtes Problem, ans Laufen zu kommen, und es dauert Wochen, bis ein Playbook zusammengestellt ist, um eine Verbindung zur Infrastruktur meines ehemaligen Cloud-basierten Unternehmens herzustellen und das Linux bereitzustellen LAMP / LEMP oder was auch immer installieren. Als es fertig war, haben wir Zeit gespart, aber es dauerte ungefähr einen Monat, um es in Betrieb zu nehmen. Keiner von uns war ein Meister der Bash-Skripte, das war also keine Alternative.
Daniel
22

Wenn Sie es so ausdrücken, müssen die Vorteile der Verwendung vertrauter Tools (in diesem Fall Shell-Scripting) überwiegen, auch wenn Ansible einige inhärente Vorteile aufweist. Ich glaube nicht, dass es eine eindeutige Antwort darauf gibt.

Wenn das Team die Dinge, die Ansible bietet, mit Shell erreichen kann:

  1. Deklaratives, idempotentes Konfigurationsmanagement
  2. Zugriff auf wiederverwendbare Snippets (z. B. Playbooks) für branchenweit beliebte Dienste.
  3. Zuverlässige Verwaltung der Remote-Ausführung mit erneutem Versuch, fortlaufender Logik usw.

dann könnten sie sich wahrscheinlich an das halten, was sie wissen.

Schließlich können Sie "Wachen" in BASH implementieren. Dort finden Sie eine Vielzahl vorhandener BASH-Aufgaben zur Lösung einer Vielzahl von Serverkonfigurationsaufgaben (im Grunde genommen handelt es sich bei jeder Docker-Datei um 90% Bash-Installationscode). Sie können dem, was Ansible / Salt / Chef-Zero Ihnen bietet, ziemlich nahe kommen, ohne Ihre gesamte vorhandene Lösung auf diese Tools portieren zu müssen.

Es ist ein Balanceakt zwischen NIH-Tendenzen (hier nicht erfunden) und der Herausgabe bewährter Skripte zugunsten einer stabileren Lösung.

Eine letzte Überlegung, die Sie berücksichtigen sollten: Wie sieht es mit Ihrem Technologiestapel aus, wenn Sie versuchen, mehr Mitarbeiter für das Team zu gewinnen? Das Auffinden von Personen mit Ansible-Erfahrung ist viel einfacher als das Auffinden von Personen mit Erfahrung in Ihrem speziellen selbst entwickelten CM-Tool für Skripterstellung. Dies ist keine rein technische, sondern eher eine kulturelle Überlegung. Möchten Sie die seltsame Organisation sein, die ihren eigenen Ansible erfindet, oder möchten Sie die vernünftige Organisation sein, die das richtige Werkzeug für den Job findet? Diese Entscheidung wirkt sich auf Ihre Fähigkeit aus, Talente zu gewinnen.

Assaf Lavie
quelle
4
Hat deine Antwort gefallen; Ich würde auch erwähnen, dass, wenn das Bash-Team Idempotenz, Ausführungsmanagement und Wiederverwendung anstrebt und im Grunde ein eigenes Konfigurationsmanagement-Framework erstellt, dies mit Kosten verbunden ist und wir alle wissen, dass dies für interne Projekte sehr unangenehm sein kann .
5.
Ich abonniere auch Ihre Antwort, insbesondere nachdem ich die verfügbaren Erfahrungen in die Waage gebracht habe. Ich habe zwei kleine Kritikpunkte: Erstens die Idempotenz. Dies ist natürlich ein wichtiger Aspekt von Konfigurationssystemen. Da es jedoch möglich ist, alle möglichen Shell-Befehle in Ansible-Playbooks zu verwenden, kann das System bestenfalls dazu anregen , Idempotenz zu verwenden. (Wir wollen tatsächlich etwas Stärkeres als idempotency aba = ab .) Zweitens ist die zuverlässige Verwaltung der Remoteausführung in einigen wichtigen Fällen möglicherweise völlig irrelevant, z. B. wenn das unveränderliche Servermuster mithilfe von Instanzimages implementiert wird.
Michael Le Barbier Grünewald
13

Die obige Antwort deckt einen Teil davon ab, übersieht jedoch eines der wichtigen Elemente: konvergierendes Design. Ich habe vor einiger Zeit einige Worte darüber im Kontext von Chef unter https://coderanger.net/thinking/ geschrieben, aber die Kurzversion besagt, dass ein Bash-Skript eine Reihe von Anweisungen ist, während ein Ansible-Spielbuch (oder Kochrezept, Salt state, etc) ist eine Beschreibung des gewünschten Zustands. Indem Sie den gewünschten Status dokumentieren und nicht die Schritte, die Sie unternehmen möchten, um dorthin zu gelangen, können Sie mit viel mehr Startstatus fertig werden. Dies war das Herzstück der Promise-Theorie, wie es in CFEngine vor langer Zeit beschrieben wurde, und ein Design, das wir (die Konfigurationsverwaltungstools) seitdem alle kopiert haben.

Ansible-Code sagt, was Sie wollen, bash-Code sagt, wie man etwas macht.

coderanger
quelle
2
Können Sie auch einen Verweis auf "Versprechungstheorie" wie Bücher oder Artikel und anderes wertvolles Material hinzufügen, wenn jemand mehr darüber erfahren möchte?
Evgeny
1
Darauf habe ich angedeutet, als ich sagte, dass Sie idempotenten Bash-Code schreiben können (dh der kann an jedem beliebigen Punkt beginnen, mehrmals ausgeführt werden und sich dem gewünschten Status annähern). Aber Ihre Antwort hat es viel klarer gemacht.
Assaf Lavie
Ja, Idempotenz ist eine wichtige Eigenschaft von konvergenten Systemen, aber die beiden sind nicht immer direkt miteinander verbunden :) In Bezug auf Materialien zur Promise Theory hat Mark Burgess (Schöpfer von CFEngine) ein paar Bücher, ich kann Links finden, wenn ich wieder bei a bin Laptop.
Coderanger
1
@Evgeny, markburgess.org/TIpromises.html
Wildcard
3

Beachten Sie, dass Sie weniger Probleme haben werden, wenn Sie Ihre anonymen Wiedergabelisten auch auf Remote-Hosts ausführen. Da ist es der Hauptgrund für ansible Laufen. Wenn Sie Shell-Skripte verwenden, müssen Sie immer noch eine Möglichkeit haben, die Skripte für den Remote-Host zu erstellen.

Rudy Gevaert
quelle
Ist Ansible in diesem Sinne nicht nur ein Wrapper um ssh?
Evgeny
Im Wesentlichen ja. Es führt ssh aus, kopiert Python-Skripte aus der Ferne und führt sie aus. Das bedeutet übrigens, dass, wenn Ihr ansibles Modul von einer Python-Bibliothek abhängt, diese Bibliothek unter bestimmten Umständen auf dem Remote-Computer vorhanden sein sollte.
Assaf Lavie
1
Und wenn Sie die ssh-Konfiguration durcheinander bringen, sind Sie von Ihrem Computer ausgeschlossen - der übliche Nachteil von Push vs. Pull.
Tensibai
0

Wir schreiben das Jahr 2019 und ich habe gerade ein paar Tage mit einer Lernkurve verbracht, und hier ist die absolute Wahrheit: Ansible ist die Mühe nicht wert.

Es ist noch nicht fertig, läuft nicht unter Windows und die Kombination aus YAML-Konfiguration und irreführenden Fehlermeldungen lässt Ihre Augen bluten. Es scheint fast absichtlich schrecklich und das meine ich ernst. Es ist eindeutig das Produkt eines frustrierten Projekts auf Entwicklerseite. Wahrscheinlich ein Hipster.

Wenn Sie über die Bereitstellung hinaus keine seiner Funktionen benötigen und immer nur auf einem bestimmten Betriebssystem bereitstellen. Aus Mitleid schreiben Sie ein anständiges shell.script.

Ab sofort erinnert mich das ganze Projekt an frühe Linux-Foren, in denen RTFM keine Ahnung hatte, warum jemand keine GUI zum Konfigurieren der Grafikeinstellungen schreiben konnte. Sie verstehen es einfach nicht, oder? Du solltest bei den Fenstern bleiben ... vielleicht werde ich mich paaren ... glücklich VI-ing.

Verwenden Sie Docker. Vor allem. Docker ist unglaublich einfach und leistungsstark.

Aber was ist, wenn Sie unbedingt auf vorhandene Dose zurückgreifen müssen? Was sind die wirklichen Alternativen?

Nun ... es gibt noch keine. Aber ich werde dir das versprechen, wenn es nicht besser wird, wird es bald soweit sein. Denn egal wie stark die Fanboys drängen und verzeihen, dass es versagt ... es ist eine 5 von 10 für Mühe.

Erstellen Sie ein Bash-Skript, und sparen Sie sich die Mühe.

Richard
quelle
Zunächst funktioniert es unter Windows über Win_RM oder SSH. Zweitens ist die yaml-Syntax sehr schön und kann programmgesteuert generiert werden, und während einige der Fehler irreführend sein können, ist es nicht anders als Java oder Python, das während einer Ausnahme seine Eingeweide kotzt. Drittens ist der Gedanke, nur ein Skript an einen Server zu senden, in hochdynamischen Cloud-Umgebungen nicht anwendbar. Welcher Server? Die Server können sich jeden Tag ändern. Ansible ermöglicht leicht konfigurierbare Inventar-Plugins mit einfachen Möglichkeiten, Server zu gruppieren und ihnen Variablen zuzuweisen. Ansible ist es nicht wert. Ich denke, es ist übertrieben für Ihre Umwelt.
Levi
@ Levi ja. Es ist alles meine Schuld, dass Ansible nicht unter Windows läuft, eine Konfiguration ohne Schema hat und eine längere Einarbeitungszeit und höhere Wartungskosten als jede maßgeschneiderte Methode zur Erreichung derselben Aufgabe hat.
Richard
Für Cloud-Umgebungen gibt es andere Ansätze für Großunternehmen, die die Lernkurve rechtfertigen könnten. Ich verstehe, was ansible macht. Ich sehe nur keine Nische.
Richard
Die Nische ist ein benutzerfreundliches Automatisierungsframework für mehrere Maschinen. Es ist nicht so toll für Windows wie für Linux. Weder ist es großartig für MSDOS und NetWare. Es ist 2019, Windows Server sind heutzutage die kleine nutzlose Nische.
dyasny