# Orchestrierung Mit der Orchestrierung können Sie wiederkehrende Aufgaben bündeln und das Zusammenspiel von States und Minions definieren. In einer Orchestrierungsdatei bestimmen Sie, welcher Minion was machen, und in welcher Reihenfolge dies geschieht. {% code title="/srv/salt/orch/ping.sls" %} ```yaml # Super simple orchestration exmaple # /srv/salt/orch/ping.sls ping: salt.function: - name: test.ping - tgt: '*' # salt-run state.orchestrate orch.ping ``` {% endcode %} {% hint style="info" %} Orchestrierungsjobs werden mit `salt-run state.orchestrate` ausgeführt. Orchestrierungs-SLS-Dateien müssen sich im File-Root, i.d.R. `/srv/salt` befinden. Diese Orchestrierungsdateien in einem Unterordner z.B. `orch` zu sammeln, ist eine umvebrindliche Empfehlung, aber keine Bedingung, {% endhint %} ### Beispiel Webcluster {% code title="/srv/salt/orch/webcluster.sls" %} ```yaml # # Install caddy on all backends in paralell # install-backends: salt.state: - tgt: backends - tgt_type: nodegroup - sls: - caddy.backend # # Install the loadbalancer after the backends # install-loadbalancer: salt.state: - tgt: loadbalancers - tgt_type: nodegroup - sls: - caddy.loadbalancer - require: - salt: install-backends ``` {% endcode %} ```bash salt-run state.orchestrate orch.webcluster ``` #### Trageting Minions Ein Targeting per **Pillar** ist ebenfalls möglich. ```yaml install-backends: salt.state: - tgt: 'roles:php-backend' - tgt_type: pillar - sls: - caddy.php ``` Targeting über eine **Liste** mit Minions-IDs ```yaml install-backends: salt.state: - tgt: - minion1 - minion2 - tgt_type: list - sls: - caddy.backend ``` Beispiel Targeting per Minion-ID und **Regex**. ```yaml # # Install caddy on all backends in paralell # install-backends: salt.state: - tgt: webserver[2,3] - sls: - caddy.backend ``` {% code title="/srv/salt/orch/webcluster.sls" %} ```yaml # # Install caddy on all backends # but one after another # {% for minion in pillar['master']['nodegroups']['backends'] %} install-backend-{{ minion }}: salt.state: - tgt: {{ minion }} - sls: - caddy.backend - require_in: - salt: install-loadbalancer {% endfor %} # # Install the loadbalancer after the backends # install-loadbalancer: salt.state: - tgt: loadbalancers - tgt_type: nodegroup - sls: - caddy.loadbalancer ``` {% endcode %} {% hint style="info" %} Diese Variante erfordert die Einstellung `pillar_opts: True` in der Master-Konfiguration, damit Sie über alle Minions einer Nodegroup iterieren können, {% endhint %} ### Master local execute per Orchestrierung gibt es die Möglichkeit, Kommandos und Module direkt auf dem Master auszuführen. Diese werden *nicht* über den ggf. auf dem Master installieren Minion ausgeführt. ``` date>/tmp/master.txt: cmd.run: [] ``` ### Beispiel Rsync Backup Vorbereitungen auf dem Master ```bash mkdir /srv/salt/backup useradd -s /bin/sh -r -m -b /var/lib/ rsync mkdir /var/lib/rsync/.ssh chown -R rsync:rsync /var/lib/rsync/ chmod 0700 /var/lib/rsync/.ssh/ chsh -s /bin/bash salt echo 'salt ALL=(ALL) NOPASSWD:ALL' > /etc/sudoers.d/salt ``` {% hint style="info" %} Prüfen Sie, ob `sudo` Dateien aus dem Verzeichnis `/etc/sudoers.d` einliest.\ In der Datei `/etc/sudoers` muss die Zeile `@includedir /etc/sudoers.d` enthalten sein. {% endhint %} {% code title="/etc/sshd/sshd\_config" %} ``` ... snip Port 22 Port 2000 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: ... snap ``` {% endcode %} Ablauf der Orchestrierung 1. Auf einer Gruppe Minions wird per State ein Rsync Backup angestoßen 2. Die Minions bekommen temporär einen privaten SSH Key zur Verfügung gestellt 3. Mit dem Key "schieben" die Minions das Backup per Rsync+SSH zum Master 4. Der Private Key wird gelöscht 5. Der Master schließt nachdem alle Minions das Backup beendet haben den Port 2000 wieder. {% code title="/srv/salt/orch/backup.sls" %} ```yaml # # Create new ssh keys for each run of the backup # gen-tmp-keys: cmd.run: - name: | test -e id_ed25519 && rm -f id_ed25519 test -e id_ed25519.pub && rm -f id_ed25519.pub ssh-keygen -q -t ed25519 -N "" -f ./id_ed25519 sudo cp id_ed25519.pub /var/lib/rsync/.ssh/authorized_keys sudo chown rsync:rsync /var/lib/rsync/.ssh/authorized_keys sudo chmod 0600 /var/lib/rsync/.ssh/authorized_keys - cwd: /srv/salt/backup # # Open the firewall # open-ufw: cmd.run: - name: ufw allow 2000 - require: - cmd: gen-tmp-keys # # Perform the backup via a state # backup: salt.state: - tgt: minion* - sls: - backup - require: - cmd: open-ufw # # Close the firewall again # close-ufw: cmd.run: - name: ufw deny 2000 ``` {% endcode %} {% code title="/srv/salt/backup/init.sls" %} ```yaml # # Copy the private key # /root/.backup.key: file.managed: - source: salt://backup/id_ed25519 - mode: 0600 # # Execute the backup # backup: cmd.run: - name: > rsync -aq --numeric-ids -e "ssh -i .backup.key -o StrictHostKeyChecking=no -p 2000" /etc /root rsync@192.168.122.1:~/{{ grains['id'] }}/ - cwd: /root # # Destroy the key # destroy: cmd.run: - name: | shred -n1 /root/.backup.key rm -f /root/.backup.key ``` {% endcode %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://thorstenkramm.gitbook.io/saltstack/orchestrierung.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.