News zu Tech Portfolio

Home → Tech Portfolio → Ansible und Outbound-Proxy: Ein Environment für alle Plays

Ansible und Outbound-Proxy: Ein Environment für alle Plays

Verfasst von Michael Decker
06 November 2026
10:57
Automatisierung, Cheat Sheet, DBA Tipp, Praxistipp

Ein Ansible-Playbook lässt sich mit wenig Aufwand so schreiben, dass es unabhängig von Betriebssystem, Version und einem vorhandenen HTTP-Proxy funktioniert. Es läuft in der Lab-Umgebung ohne Proxy und im Kundennetz mit Outbound-HTTP-Proxy, ohne dass du es anpassen musst. Eine naheliegende Lösung – das Proxy-Environment an jedem Task zu setzen – skaliert schlecht: Jeder neue Task braucht diese Angabe, und ein vergessener Task fällt erst im Netz mit Proxy auf.

Bisher haben wir in unseren Cheat Sheets Befehle und Tests unter die Lupe genommen. Diesmal geht es nicht um einen Befehl, sondern um ein Ansible-Muster, welches dir im Automatisierungs-Alltag helfen kann. Es gibt viele verschiede Möglichkeiten, ein Proxy-Environment mitzugeben, die wir hier nicht alle beleuchten können. Wir definieren in diesem Beitrag das Environment einmal als Variable und binden sie auf Play-Ebene ein. Ein Environment an jedem einzelnen Task entfällt damit. Einen naheliegenden Weg dorthin schauen wir uns zuerst an, denn er hat seine Tücken.

Der Weg: erst mit set_fact

Der naheliegende erste Schritt ist, das Environment in einem Task zusammenzubauen und als Fact abzulegen:

- name: Mein Play
  hosts: all
  environment: "{{ proxy_environment | default({}) }}"
  tasks:
    - name: Build proxy environment
      ansible.builtin.set_fact:
        proxy_environment: >-
          {{
            {
              'http_proxy': proxy_http | default('', true),
              'HTTP_PROXY': proxy_http | default('', true),
              'https_proxy': proxy_https | default('', true),
              'HTTPS_PROXY': proxy_https | default('', true),
              'no_proxy': proxy_no_proxy | default('', true),
              'NO_PROXY': proxy_no_proxy | default('', true)
            }
            | dict2items
            | selectattr('value', 'truthy')
            | items2dict
          }}

Die Lösung funktioniert, erzeugt aber eine unnötige Abhängigkeit zwischen der Initialisierung durch set_fact und der späteren Verwendung.

default('', true):
Behandelt neben undefinierten Variablen auch null und andere falsy Werte. Diese werden durch einen Leerstring ersetzt. Für die anschließende Filterung mit truthy ist das nicht zwingend erforderlich, da dieser Test auch null und andere falsy Werte entfernt.
selectattr('value', 'truthy'):
Entfernt alle Einträge mit falsy Werten aus dem Dictionary. Sind keine Proxy-Variablen definiert beziehungsweise enthalten diese keine gültigen Werte, entsteht ein leeres Dictionary {}. Damit werden keine zusätzlichen Proxy-Umgebungsvariablen gesetzt.
default({}) am Play:
Das Play-Keyword environment wird im Kontext der jeweiligen Task-Ausführung ausgewertet. Das gilt auch für das automatische gather_facts vor den eigentlichen Tasks. Solange proxy_environment durch set_fact noch nicht existiert, verhindert default({}) einen Fehler durch eine undefinierte Variable.
set_fact und mehrere Plays:
set_fact erzeugt eine hostspezifische Variable, die auch in nachfolgenden Plays desselben Playbook-Laufs verfügbar bleibt. Allerdings nur für Hosts, auf denen der Task tatsächlich ausgeführt wurde. Andere Hosts, übersprungene Initialisierungen oder ein direkter Einstieg in ein späteres Play können dazu führen, dass die Variable fehlt. Außerdem wird eine einmal erzeugte Variable nicht automatisch neu berechnet, wenn sich ihre Eingangsvariablen ändern.

Die Lösung: Environment als lazy Variable

Ansible wertet Variablen erst aus, wenn sie benutzt werden. Das nutzen wir: Das Environment wird als Ausdruck definiert, nicht als Task-Ergebnis. Die Definition kann z.B. in group_vars/all.yml oder im Play stehen:

proxy_environment: >-
  {{
    {
      'http_proxy': proxy_http | default('', true),
      'HTTP_PROXY': proxy_http | default('', true),
      'https_proxy': proxy_https | default('', true),
      'HTTPS_PROXY': proxy_https | default('', true),
      'no_proxy': proxy_no_proxy | default('', true),
      'NO_PROXY': proxy_no_proxy | default('', true)
    }
    | dict2items
    | selectattr('value', 'truthy')
    | items2dict
  }}

Im Play genügt dann eine Zeile:

- name: Prepare the hosts user
  hosts: all
  environment: "{{ proxy_environment }}"
  tasks:

    - name: Ausgehende IP ermitteln (Proxy-Test)
      ansible.builtin.uri:
        url: https://icanhazip.com
        return_content: true
      register: proxy_test


    - name: Ergebnis anzeigen
      ansible.builtin.debug:
        msg: "Ausgehende IP: {{ proxy_test.content | trim }}"

Vorteile:

Lazy Evaluation:
Ansible wertet den Jinja2-Ausdruck der Variable proxy_environment bei ihrer Verwendung aus. Die Variable muss daher nicht vorher durch einen Task erzeugt werden. Der Wert ergibt sich aus den zu diesem Zeitpunkt verfügbaren Eingangsvariablen.
Keine Initialisierung erforderlich:
Da proxy_environment bereits über die Variablendefinition verfügbar ist, entfällt der set_fact-Task vollständig. Ebenso ist kein default({}) am Play erforderlich, sofern die zentrale Variablendefinition für alle betroffenen Hosts geladen wird.
Unabhängigkeit von der Ausführungsreihenfolge:
Jedes Play kann proxy_environment unmittelbar verwenden. Es spielt keine Rolle, ob andere Plays zuvor ausgeführt wurden, ob das Playbook über import_playbook eingebunden oder einzeln gestartet wird.
Hostspezifische Auswertung:
Die Definition wird im jeweiligen Hostkontext ausgewertet. Unterschiedliche Hosts können damit unterschiedliche Proxy-Konfigurationen erhalten, ohne dass separate Initialisierungstasks notwendig sind.
Dynamische Auswertung:
Im Gegensatz zu set_fact wird kein einmalig berechnetes Ergebnis gespeichert. Ändern sich die zugrunde liegenden Variablen während des Playbook-Laufs, kann die nächste Auswertung von proxy_environment diese Änderungen berücksichtigen.
Zentrale Wartung:
Die Proxy-Logik existiert nur an einer Stelle. Jedes Play benötigt lediglich environment: "{{ proxy_environment }}". Änderungen an der Filterung oder den unterstützten Proxy-Variablen müssen deshalb nicht in mehreren Tasks gepflegt werden.

Fazit

Ein Keyword auf Play-Ebene und eine lazy Variable ersetzen die Task-Lösung. Du pflegst das Proxy-Environment an einer einzigen Stelle, jedes Play bindet es mit einer Zeile ein, und das Playbook läuft mit und ohne Proxy, ohne dass du etwas anpassen musst.

Der Vorteil zeigt sich vor allem im Alltag: Beim nächsten Playbook musst du nicht mehr überlegen, ob der Proxy schon gesetzt wurde. Und wenn du zwischen Lab und Kundennetz wechselst, bleibt die Proxy-Logik dort, wo sie hingehört.

Hier findest du weitere » Cheat Sheets die dir das Leben als Linux-Admin leichter machen.

Share this article

Ansible und Outbound-Proxy: Ein En­vi­ron­ment für alle Plays