Ich habe ein Playbook, das verschiedene Rollen enthält und markiert:
%Vor%Die meisten Tasks verwenden while-Klauseln, um zu bestimmen, auf welchem Betriebssystem sie ausgeführt werden sollen, zum Beispiel:
%Vor% Wenn ich ansible-playbook base.yml ohne Angabe von Tags ausführen, werden alle Aufgaben ausgeführt. Wenn ich ein Tag festlege, z. B. ansible-playbook base.yml --tags='base' , werden nur die Rollen mit base run gekennzeichnet.
Standardmäßig (wenn keine Tags angegeben sind), möchte ich nur die mit 'base' gekennzeichneten Rollen und nicht die mit 'desktop' markierten Rollen ausführen.
Es wäre auch sehr schön, ein standardmäßiges "os" -Tag zu setzen, basierend auf dem aktuellen Betriebssystem, um zu vermeiden, dass alle Aufgaben für das ubuntu enthalten sind, wenn ich das Playbook auf OSX laufe (und umgekehrt).
Irgendwelche Ideen, wenn das möglich ist und wie ich es machen könnte?
Leider gibt es keine solche Funktion. Das Tag-Handling in Ansible ist derzeit sehr eingeschränkt. Sie können keine Standard-Tags festlegen und Sie können Tags nicht standardmäßig ausschließen.
Es gibt einige Threads in der Google-Nutzergruppe und Feature-Anfragen zu github diesbezüglich. Aber noch kein Ergebnis. Die übliche Antwort ist, dass Sie ein Shell-Skript erstellen und es vor Ihr Playbook stellen sollten. Dieses Skript kann die --tags und --skip-tags entsprechend Ihren Bedürfnissen anpassen. Sehr unangenehm, aber soweit ich weiß, die einzige Option im Moment.
Wenn ich ansible-playbook base.yml ohne Angabe von Tags ausführe, laufen alle Aufgaben.
Ja, das ist sehr gefährlich. Wenn Sie vergessen, '--tags = xxxxx' hinzuzufügen, kann es unerwünschte Aufgaben ausführen ...
Es gibt eine Problemumgehung, es ist unangenehm, aber es würde verhindern, dass Ihre Aufgaben ausgeführt werden, wenn sich keine Tags in der Befehlszeile befinden.
Sie können --extra-vars verwenden und in Ihrem Playbook verwenden und dann ausführen:
%Vor%Und in deinem Spielbuch:
%Vor%Das Ergebnis:
%Vor% Ich benutze Kommandozeilen-Überschreibungen ( -e ), um dies zu erreichen:
Anstatt desktop als Tag zu definieren, könnte es stattdessen als Variable mit einem Standardwert von false definiert werden. Dann ersetzen Sie für Rollen, bei denen desktop den Wert true hat, das Tag durch eine when -Klausel. Das in der Frage angegebene Playbook könnte folgendermaßen umgeschrieben werden:
Dies ist wahrscheinlich nur eine vereinfachte Version einer der vorhandenen Antworten. Wie bereits an anderer Stelle erwähnt, sind Tags zu diesem Zeitpunkt nicht die Antwort, um bestimmte Aktionen so zu verzögern, dass sie nicht ausgeführt werden, sofern nicht explizit etwas angegeben wird. Variablen dagegen sind dafür perfekt geeignet.
Es gibt noch 3 spezielle Schlüsselwörter für die Tags 'tagged', 'untagged' und 'all', die nur getaggt, nur unmarkiert und alle Aufgaben ausführen. Standardmäßig läuft ansible so, als ob '-tags all' angegeben wurde.
Sie können die Dokumente hier überprüfen: Ссылка
Der Grund für die Standardeinstellung ist: Ich möchte in meinem häufigsten Anwendungsfall so wenig wie möglich tippen. Also ich denke was OP eigentlich will ist:
Gibt es Möglichkeiten, Basisaufgaben mit möglichst wenigen Argumenten auszuführen.
Wie andere darauf hingewiesen haben, gibt es kein "Standard" -Tag in ansible. Aber es gibt immer Wege.
Der erste Weg ist einfach das Skript zu verwenden, um es zu umbrechen
Schreiben Sie eine run.sh wie folgt:
Es ist viel kürzer, ./run.sh anstelle des vollständigen Befehls einzugeben.
Der zweite Weg ist für die Menschen, die nach der reinen antwortbaren Lösung suchen. Sie können zwei Playbooks haben wie:
base.yml
desktop.yml
Führen Sie für Nur-Base-Aufgaben ansible-playbook base.yml ;
Führen Sie für Desktop-Aufgaben nur ansible-playbook desktop.yml ;
Führen Sie für alle Aufgaben ansible-playbook base.yml desktop.yml
aus
Es ist auch fehleranfälliger als das Definieren eines "Standard" -Tags.
OP möchte auch ein Standard-OS-Tag. Das ist mit when
mit when , Sie müssen nichts in der Befehlszeile eingeben, ansible erkennt den Typ und führt entsprechende Aufgaben für Sie aus.
Tags und Links ansible ansible-playbook tags