linux:ansible:playbook_example_10

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung		 Vorhergehende Überarbeitung
linux:ansible:playbook_example_10 [23.09.2022 13:37. ] – [Ausgangssituation] djangolinux:ansible:playbook_example_10 [24.09.2022 13:50. ] (aktuell) – [Links] django
Zeile 166: Zeile 166:
  
 ===== Lösungsmöglichkeit ===== ===== Lösungsmöglichkeit =====
 +Grundsätzlich alle möglichen Konfigurationsoptionen zur SSH-Clientkonfiguration finden wir in der zugehörigen man-page.
 +   $ man ssh_config
  
-===== lorem ipsum dolor sit amet =====+Sehen wir uns unsere bisher manuell gepflegte SSH-Clientkonfigurationsdatei mal etwas genauer an und blenden mal ggf. besondere Fälle mal aus, so stellen wir zwei Dinge fest. 
 + 
 +==== Host-Beispiele ==== 
 +=== Direkt erreichbare Hosts === 
 +Wenn wir uns einmal folgendes Beispiel betrachten, dann sehen wir folgende Dinge. 
 +<code bash ~/.ssh/config>... 
 + 
 +Host pml010003 
 +  Hostname 10.10.10.3 
 +  User django 
 +  Port 22 
 +  Protocol 2 
 +  IdentityFile ~/.ssh/id_intranet 
 + 
 +... 
 +</code> 
 + 
 +Wir haben demnach in Summe sechs gesetzte Parameter: 
 +    * **''Host''**: Kurzname (alias) über den das Ziel erreichbar ist, 
 +    * **''Hostname''**: FQDN oder IP-Adresse des Ziels,  
 +    * **''User''**: User der zum Verbinden benötigt wird,  
 +    * **''Port''**: SSH-Port des Zielsystems, 
 +    * **''Protocol''**: verwendetes SSH-Protokoll sowie 
 +    * **''IdentityFile''**: Datei des SSH-Keys, der bei der Verbindung verwendet werden muss.  
 + 
 +=== Hosts erreichbar nur via Jump-Host === 
 +Bei einem Host, den wir nicht direkt erreichen können, sondern lediglich über einen Jump-Host stellen wir fest dass wir hier einen Parameter mehr haben. 
 +<code bash ~/.ssh/config>... 
 + 
 +Host fwi 
 +  Hostname 10.30.30.20 
 +  User django 
 +  Port 22 
 +  Protocol 2 
 +  IdentityFile ~/.ssh/id_idmz 
 +  ProxyCommand  ssh -q -W %h:%p vml030020 
 + 
 +Host fw3 
 +  Hostname 10.50.50.250 
 +  User django 
 +  Port 10022 
 +  Protocol 2 
 +  IdentityFile ~/.ssh/id_edmz 
 +  ProxyCommand  ssh -q -W %h:%p fwi 
 + 
 +... 
 +</code> 
 + 
 +Bei diesem Beispiel haben wir zwei Jumphost. Der erste Host **''fwi''** kann nicht direkt, sondern nur über den Jump-Host **''vml030020''** erreicht werden. Der zweite Jump-Host **''fw3''** wiederum ist nur über den ersten Jump-Host **''fwi''** erreichbar. Die entscheidende Konfigzeile mit  **''ProxyCommand''** ist dabei jeweils: 
 +  ProxyCommand  ssh -q -W %h:%p <-Sprung-Host-> 
 +Der Wert **''%%<-%%Sprung-Host%%->%%''** kennzeichnet nun, über welchen Jump-Host das Ziel erreichbar sein wird. 
 + 
 +Zusätzlich zu den Parametern eines Standardhosts haben wir hier eine weitere Option **''ProxyCommand''**, der Definition wie und über welchen Jump-Host das Ziel erreicht werden kann. Wie **[[#ausgangssituation|Eingangs]]** bereits erwähnt, werden wir nun die komplette SSH-Client-Konfigurationsdatei **__nicht__** manuell pflegen, sondern wir werden Ansible mit dieser Aufgabe betrauen, genauers hierzu finden wir in nachfolgenden Abschnitt dieses WIKI-Artikels. 
 + 
 + 
 + 
 + 
 +==== Ansible-Playbook zum Erstellen der SSH-Client-Konfigurationsdatei ==== 
 +=== Playbook: ssh_client_config.yml === 
 +Unser Playbook legen wir nun wie gewohnt in unserem Playbook-Verzeichnis  **''~/ansible/playbooks/''** an. 
 +   $ vim ~/ansible/playbooks/ssh_client_config.yml 
 +<file c++ ssh_client_config.yml>---                                         # YAML Start 
 +                                            # Ansible Playbook zum automatisierten Anlegen der 
 +                                            # SSH Client Konfigurationsdatei  ~/.ssh/config basierend 
 +                                            # auf den Inhalten des Inventories. 
 +                                            # 
 +                                            # Aufruf aus dem entsprechenden Arbeits-Verzeichnis via: 
 +                                            # ansible-playbook playbooks/ssh_client_config.yml 
 +                                            # 
 +- name: ssh_client_config.yml               # Name des Playbook 
 +  hosts: localhost                          # Host die zur Anwendung kommen sollen 
 +  vars:                                     # 
 +    ssh_user: "{{ lookup('env','USER') }}"  # aktuellen Bneutzer ermitteln und Variable übergeben 
 +                                            # 
 +                                            # 
 +  roles:                                    # Definition der zugehörigen Rollen 
 +    - ssh_client                            # Prometheus Server: Installation und Konfiguration 
 +...                                         # YML Ende</file> 
 + 
 +Dieses Playbook unterscheidet sich nun erst einmal gewaltig von denen der bisher hier gezeigten. Warum? Das werden wir uns nun im nachfolgendem Abschnitt ansehen. 
 +=== Rolle: ssh_client === 
 +Im Gegensatz zu den bisherigen Playbook-Beispielen werden wir nun dem nächstem **[[|Ansible Kapitel "Rollen"]]** hier etwas vorgreifen und das Playbook, welches zum Erzeugen der SSH-Client-Konfigurationsdatei verwendet wird, nicht mehr in einem flatfile schreiben, sondern dies entsprechend strukturiert aufbauen. 
 + 
 +Die Grundvoraussetzungen in Form der betreffenden Verzeichnisstruktur haben wir ja bereits bei der **[[playbook_example_07#become_pass_und_vault-password_aus_einem_ansible-vault|initialen Ansible-Konfiguration]]** erzeugt. 
 +   $ tree ~/ansible/roles/common/ -d 
 +<code>/home/django/ansible/roles/common/ 
 +├── defaults 
 +├── files 
 +├── handlers 
 +├── library 
 +├── lookup_plugins 
 +├── meta 
 +├── module_utils 
 +├── tasks 
 +├── templates 
 +└── vars 
 +</code> 
 + 
 +Dies nehmen wir nun als Kopiervorlage und erstellen eine neue Rolle **''ssh_client''**. 
 +   $ cp -avr ~/ansible/roles/common/ ~/ansible/roles/ssh_client 
 + 
 +In unserem **[[#playbookssh_client_configyml|Playbook]]** haben wir bereits auf diese **[[https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html|role]]** verwiesen. Im Verzeichnis **''tasks''** legen wir nun die YML-Dateien mit den Aufgaben ab, die abgearbeitet werden sollen. Standardmäßig wird Ansible dort die Datei **''main.yml''** suchen und den Anweisungen dort folgen. Wir legen nun diese Datei an. 
 +   $ vim ~/ansible/roles/ssh_client/tasks/main.yml 
 +<file c++ main.yml>---                                     # Playbook/Rollen zur Generierung der SSH Client-Config 
 +- include_tasks: client_config.yml      # SSH Client Configdatei erzeugen und kopieren. 
 +  tags: clientconfiguration             # 
 +...                                     # YML Ende</file> 
 + 
 +Wie wir sehen, wird hier erst einmal nur ein weiterer **task** inkludiert, dessen YML-Datei noch fehlt. Diese Datei legen wir nun gleich noch als nächstes an. 
 +   $ vim ~/ansible/roles/ssh_client/client_config.yml 
 +<file c++ client_config.yml>--- # YAML Start 
 +    # SSH Client Configdatei erzeugen und kopieren. 
 +- name: "Generieren und kopieren der SSH Client Konfiguration ~/.ssh/config." 
 +  ansible.builtin.template: 
 +    src: templates/ssh_client_config.j2 
 +    dest: /home/{{ ssh_user }}/.ssh/config 
 +    owner: '{{ ssh_user }}' 
 +    group: '{{ ssh_user }}' 
 +    mode: '0640' 
 +... # YML Ende</file> 
 + 
 +Mit Hilfe dieses Tasks wird nun, mit Hilfe des Ansible Modules **[[https://docs.ansible.com/ansible/latest/collections/ansible/builtin/template_module.html|template]]**, die Datei **''~/.ssh/config''** im **''$HOME''**-Verzeichnis des aktuellen Admins angelegt. Die Variable **''ssh_user''** haben wir im **[[#playbookssh_client_configyml|Playbook]]** definiert und füllen diese dann entsprechend beim Ausführen des Playbooks.  
 + 
 +<WRAP center round tip 80%> 
 +Man könte jetzt natürlich sagen, warum definiert man denn diesen Task nicht gleich direkt in der **''main.yml''**, ist doch eh' "nur eine" Aufgabe. Ja, das könnte man durchaus so sagen. Aber wir gewöhnen uns am Besten gleich von Haus aus an, und strukturieren unsere Rollen entsprechend. Denn so hat man es später einfacher, wenn man bestimmte Teile **nur** bei der Ausführung haben möchte oder wenn man bestimmte Schritte z.B. **ausschließen** möchte. 
 +</WRAP> 
 + 
 +=== Jinja2-Template: ssh_client_config.j2 === 
 +In dem Task  **''client_config''** hatten wir definiert, dass unsere SSH-Client-Konfiguration auf Basis eines **[[https://docs.ansible.com/ansible/latest/user_guide/playbooks_templating.html|Jinja2-Templates]]** erstellt werden soll. Diese Datei legen wir nun als nächstes an. 
 +   $ vim ~/ansible/roles/ssh_client/templates/ssh_client_config.j2 
 +<file c++ ssh_client_config.j2># Generiert mit Hilfe von Ansible am {{ ansible_date_time.date }} - diese Datei nicht manuell bearbeiten! 
 +# Clientkonfigurationsbeispiel für unterschiedliche Zielsysteme 
 + 
 +## statische Konfiguration 
 +# localhost 
 +Host localhost 
 +  Hostname  127.0.0.1 
 +  IdentityFile ~/.ssh/id_intra 
 + 
 +# externer Einwahl-Hosts 
 +Host example 
 +  Hostname 93.184.216.34 
 +  Port 12345 
 +  Protocol 2 
 +  ForwardX11 yes 
 +  ForwardAgent yes 
 +  IdentityFile ~/.ssh/id_example 
 + 
 +## dynamisch aus dem Inventory generierte Konfiguration 
 +# interne Systeme - DMZ 
 +{% for host in groups['DMZ'] %} 
 +Host {{ host }} 
 +  Hostname {{ hostvars[host]['host_ipv4'] }} 
 +  User {{ hostvars[host]['ssh_user'] }} 
 +  Port {{ hostvars[host]['ssh_port'] }} 
 +  Protocol {{ hostvars[host]['ssh_protocol'] }} 
 +  IdentityFile {{ hostvars[host]['ssh_keyfile'] }} 
 + 
 +Host {{ hostvars[host]['host_alias'] }} 
 +  Hostname {{ hostvars[host]['host_ipv4'] }} 
 +  User {{ hostvars[host]['ssh_user'] }} 
 +  Port {{ hostvars[host]['ssh_port'] }} 
 +  Protocol {{ hostvars[host]['ssh_protocol'] }} 
 +  IdentityFile {{ hostvars[host]['ssh_keyfile'] }} 
 + 
 +{% endfor %} 
 +# interne Systeme - Intranet 
 +{% for host in groups['intranet'] %} 
 +Host {{ host }} 
 +  Hostname {{ hostvars[host]['host_ipv4'] }} 
 +  User {{ hostvars[host]['ssh_user'] }} 
 +  Port {{ hostvars[host]['ssh_port'] }} 
 +  Protocol {{ hostvars[host]['ssh_protocol'] }} 
 +  IdentityFile {{ hostvars[host]['ssh_keyfile'] }} 
 + 
 +Host {{ hostvars[host]['host_alias'] }} 
 +  Hostname {{ hostvars[host]['host_ipv4'] }} 
 +  User {{ hostvars[host]['ssh_user'] }} 
 +  Port {{ hostvars[host]['ssh_port'] }} 
 +  Protocol {{ hostvars[host]['ssh_protocol'] }} 
 +  IdentityFile {{ hostvars[host]['ssh_keyfile'] }} 
 + 
 +{% endfor %} 
 +# externe System 
 +{% for host in groups['freifunk'] %} 
 +Host {{ host }} 
 +  Hostname [{{ hostvars[host]['host_ipv6'] }}] 
 +  User {{ hostvars[host]['ssh_user'] }} 
 +  Port {{ hostvars[host]['ssh_port'] }} 
 +  Protocol {{ hostvars[host]['ssh_protocol'] }} 
 +  IdentityFile {{ hostvars[host]['ssh_keyfile'] }} 
 +  ProxyCommand  ssh -q -W %h:%p {{ hostvars[host]['host_sshjump'] }} 
 + 
 +Host {{ host }}-extern 
 +  Hostname {{ hostvars[host]['host_ipv6'] }} 
 +  User {{ hostvars[host]['ssh_user'] }} 
 +  Port {{ hostvars[host]['ssh_port'] }} 
 +  Protocol {{ hostvars[host]['ssh_protocol'] }} 
 +  IdentityFile {{ hostvars[host]['ssh_keyfile'] }} 
 + 
 +{% endfor %} 
 +{% for host in groups['raspbian'] %} 
 +Host {{ host }} 
 +  Hostname {{ hostvars[host]['host_ipv4'] }} 
 +  User {{ hostvars[host]['ssh_user'] }} 
 +  Port {{ hostvars[host]['ssh_port'] }} 
 +  Protocol {{ hostvars[host]['ssh_protocol'] }} 
 +  IdentityFile {{ hostvars[host]['ssh_keyfile'] }} 
 +  ProxyCommand  ssh -q -W %h:%p {{ hostvars[host]['host_sshjump'] }} 
 + 
 +Host {{ host }}-intern 
 +  Hostname {{ hostvars[host]['host_ipv4'] }} 
 +  User {{ hostvars[host]['ssh_user'] }} 
 +  Port {{ hostvars[host]['ssh_port'] }} 
 +  Protocol {{ hostvars[host]['ssh_protocol'] }} 
 +  IdentityFile {{ hostvars[host]['ssh_keyfile'] }} 
 + 
 +{% endfor %} 
 +</file> 
 + 
 +Das Beispiel passen wir natürlich unserer Umgebung entsprechend an. Einzelne Netzsegmente haben wir in unserem **[[playbook_example_09#cmdb-basierte_professionelle_umgebungen|Inventory]]** in Hostgruppen unterteilt. Basierend auf den **Host**-Definitionen im Inventory werden die Variablen entsprechend mit den spezifischen Hostdaten gefüllt um damit dann beim Lauf des Playbooks die passende SSH-Client-Konfigurationsdatei zu schreiben. Mit Hilfe der Schleifen, welche jeweils durch **''{% for host in groups['<%%--%%HOST-GROUP-NAME%%--%%>'] %}''** und **''{% endfor %}''** eingeschlossen sind, werden beim Abarbeiten des Playbooks für jeden Host aus der spezifischen Gruppe (repräsentiert durch den Namen der Hostgruppe **''<%%--%%HOST-GROUP-NAME%%--%%>''**) Abschnitte in der **''~/.ssh/config''**-Datei hinterlegt. 
 + 
 +=== Inventory === 
 +Die **[[playbook_example_09#cmdb-basierte_professionelle_umgebungen|Konfigruationsdaten]]** unserer Host halten wir in unserem **Inventory** vor. Hierbei spielt es grundlegend keine Frage ob dies manuell gepflegt, oder scriptiert aus einer **CMBD** exportiert und aufbereitet wurde. 
 + 
 +Für unser Playbook-Beispiel hier greifen wir auf das exemplarische **[[playbook_example_09#cmdb-basierte_professionelle_umgebungen|Inventory]]**, mit welchem wir uns im Kapitel **[[playbook_example_09|Ansible - Erweiterte Konfigurationsbeispiel: Inventory]]** bereits intensiv beschäftigt hatten, zurück. Nachfolgend sehen wir, wie solch eine Inventory Datei aufgebaut und strukturiert sein könnte. Das exemplarische Beispiel ist hier entsprechend gekürzt und die Stellen mit Hilfe von **''%%...%%''** markiert wiedergegeben" 
 +   $ less ~/ansible/inventories/production/hosts 
 + 
 +<file bash hosts># Generiert mit Hilfe von Ansible am 2022-09-20 - diese Datei nicht manuell bearbeiten! 
 +# Inventory Datei für die System-Umgebung bei nausch.org 
 +# 
 +# Hinweise: 
 +#           Kommentare beginnen mit einem '#'-Zeichen 
 +#           leere Zeilen werden ignoriert 
 +#           Host- und Gruppendefinitionen werden mit [] abgegrenzt 
 +#           Hosts können über ihren Hostnamen, FQN oder ihrer IP-Adresse definiert 
 +#           übergeordnete Gruppen werden durch [:children] abgegrenzt 
 +# 
 +# Host-Definitionen 
 + 
 +# Hosts ohne Gruppenzuordnung 
 +localhost 
 + 
 +[intranet] 
 +pml010002 
 +pml010003 
 +pml010004 
 +... 
 +... 
 +pml010124 
 +pml010125 
 +pml010126 
 + 
 +[IDMZ] 
 +vml030010 
 +vml030020 
 +vml030030 
 +vml030040 
 +... 
 +... 
 +vml030230 
 +vml030240 
 +vml030250 
 + 
 +[EDMZ] 
 +vml050010 
 +vml050020 
 +vml050030 
 +vml050040 
 +vml050250 
 + 
 +[TKDMZ] 
 +vml070010 
 +vml070020 
 +vml070030 
 + 
 +[external] 
 +customer_no_001 
 +customer_no_002 
 +... 
 +... 
 +customer_no_042 
 + 
 +[gluon] 
 +ff_pliening_gbw__ug_ 
 +ff_pliening_gbw_egod 
 +ff_pliening_gbw_ogod 
 +ff_pliening_gbw_dgod 
 +ff_pliening_gbw_cpod 
 +ff_roding_fwg_nausch 
 + 
 +[raspbian] 
 +ff_pliening_rpb4_ol_v6 
 + 
 +# Host-Gruppen-Definitionen  
 +# (zu welcher Gruppe gehören Untergruppen bzw. Hosts) 
 + 
 +[freifunk:children] 
 +gluon 
 +raspbian 
 + 
 +[linux:children] 
 +intranet 
 +IDMZ 
 +EDMZ 
 +TKDMZ 
 +external 
 +</file> 
 + 
 +Die betreffenden Hostspezifischen Variablen halten wir hier in entsprechenden Dateien bzw. Unterverzeichnissen vor. Das nachfolgende Beispiel hier zeigt die Host-spezifischen Variablen eines Hosts im Intranet. 
 +   $ less ~/ansible/inventories/production/host_vars/pml111002 
 + 
 +<file c++ vml030010># Generated by Ansible on 2022-09-20, do not edit manually! 
 +host_alias: fw1 
 +host_mac: "84:3b:de:ad:be:ef" 
 +host_ipv4: "10.30.30.2" 
 +host_ipv6: "::1" 
 +ssh_port: 22 
 +ssh_protocol: 2 
 +ssh_keyfile: ~/.ssh/id_idmz"</file> 
 + 
 +Als Beispiel für einen externen Host, der nur via Jump-Host erreichbar ist sehen wir uns die Inventory-Host-Definition des Hosts **''ff_pliening_gbw%%__%%ug_''** näher an. 
 +   $ less ~/ansible/inventories/production/host_vars/ff_pliening_gbw__ug_  
 + 
 + 
 +<file c++ ff_pliening_gbw__ug_># Generated by Ansible on 2022-09-20, do not edit manually! 
 +host_alias:  
 +host_ipv4: 
 +host_ipv6: 2001:678:e68:102:32b5:c2ff:fe56:62b1 
 +ssh_user: root 
 +ssh_port: 22 
 +ssh_protocol: 2 
 +ssh_keyfile: ~/.ssh/id_freifunk 
 +host_sshjump: vml070010 
 + 
 +branch: "stable" 
 +domain: "ffmuc_muc_ost" 
 +director: "ffmuc_muc_ost" 
 +node_contact_address: "Django [BOfH] | django@nausch.org | chat: @django" 
 +node_hostname: "ff_pliening_gbw_antipode" 
 +node_latitude: "-48.19861319429455" 
 +node_longitude: "-168.2017571420684" 
 +node_model: "TP-Link TL-WDR4300 v1" 
 +node_share_location: "True" 
 +node_ghostmode: "False" 
 +node_release: "experimental" 
 +node_autoupdate: "False" 
 +</file> 
 + 
 +Hier sehen wir nun dass unter anderem ein anderer SSH-User, ein anderes SSH-Keyfile sowie ein Jump-Host benutzt wird. Ferner finden sich im Anschluß noch weitere Host-spezische Variablen, für die Konfiguration des betreffenden **[[https://map.ffmuc.net/#!/de/map/30b5c25662b1|Freifunk-Knotens]]**. 
 + 
 +=== Playbook-Lauf === 
 +Dank der **[[playbook_example_08#aufgabenstellung_2_-_erweiterte_grund-_basis-installation_fuer_ansible-vault|Vorkonfiguration]]** unseres Ansible-Controll-Nodes, welche wir im Kapitel **[[playbook_example_08|Ansible - erweiterte Konfigurationsbeispiele: Ansible mit Hilfe von Ansible einrichten]]** hier in Djangos WIKI vorgenommen hatten, reicht zum Starten des Playbooks folgender Befehlsaufruf: 
 +   $ ansible-playbook ~/ansible/playbooks/ssh_client_config.yml 
 + 
 +<html> 
 +<pre class="code"> 
 +<font style="color: rgb(0, 0, 0)"> 
 +PLAY [ssh_client_config.yml] ****************************************************************************************************** 
 + 
 +TASK [Gathering Facts] ************************************************************************************************************</font> 
 +<font style="color: rgb(25, 100, 5)">ok: [localhost]</font> 
 +<font style="color: rgb(0, 0, 0)"> 
 +TASK [ssh_client : include_tasks] *************************************************************************************************</font> 
 +<font style="color: rgb(43, 100, 164)">included: /home/django/ansible/roles/ssh_client/tasks/client_config.yml for localhost</font> 
 +<font style="color: rgb(0, 0, 0)"> 
 +TASK [ssh_client : Generieren und kopieren der SSH Client Konfiguration ~/.ssh/config.] *******************************************</font> 
 +<font style="color: rgb(25, 100, 5)">ok: [localhost]</font> 
 +<font style="color: rgb(0, 0, 0)"> 
 +PLAY RECAP *************************************************************************************************************************</font> 
 +<font style="color: rgb(25, 100, 5)">localhost                  </font><font style="color: rgb(0, 0, 0)">: </font><font style="color: rgb(25, 100, 5)">ok=3</font>    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0</font> 
 +</pre> 
 +</html> 
 +=== Ergebnis: ~/.ssh/config === 
 +Als Ergebnis erhalten wir dann quasi auf Knopfdruck immer eine aktuelle SSH-Client-Konfigurationsdatei **''~/.ssh/config''**, basierend auf den Konfigurationsdaten aus unsere Inventory. 
 + 
 +<file bash ~/.ssh/config># Generiert mit Hilfe von Ansible am 2022-09-24 - diese Datei nicht manuell bearbeiten! 
 +# Clientkonfigurationsbeispiel für unterschiedliche Zielsysteme 
 + 
 +## statische Konfiguration 
 +# localhost 
 +Host localhost 
 +  Hostname  127.0.0.1 
 +  IdentityFile ~/.ssh/id_intra 
 + 
 +# externer Einwahl-Hosts 
 +Host example 
 +  Hostname 93.184.216.34 
 +  Port 12345 
 +  Protocol 2 
 +  ForwardX11 yes 
 +  ForwardAgent yes 
 +  IdentityFile ~/.ssh/id_example 
 + 
 +## dynamisch aus dem Inventory generierte Konfiguration 
 +# interne Systeme - IDMZ 
 +Host vml030010 
 +  Hostname 10.30.30.10 
 +  User django 
 +  Port 22 
 +  Protocol 2 
 +  IdentityFile ~/.ssh/id_idmz 
 + 
 +Host fw1 
 +  Hostname 10.30.30.10 
 +  User django 
 +  Port 22 
 +  Protocol 2 
 +  IdentityFile ~/.ssh/id_idmz 
 + 
 +Host vml030020 
 +  Hostname 10.30.30.20 
 +  User django 
 +  Port 22 
 +  Protocol 2 
 +  IdentityFile ~/.ssh/id_idmz 
 + 
 +Host fw2 
 +  Hostname 10.30.30.2 
 +  User django 
 +  Port 22 
 +  Protocol 2 
 +  IdentityFile ~/.ssh/id_idmz 
 + 
 +Host vml030030 
 +  Hostname 10.30.30.30 
 +  User django 
 +  Port 22 
 +  Protocol 2 
 +  IdentityFile ~/.ssh/id_idmz 
 + 
 +Host  
 +  Hostname 10.30.30.30 
 +  User django 
 +  Port 22 
 +  Protocol 2 
 +  IdentityFile ~/.ssh/id_idmz 
 + 
 +... 
 +... 
 + 
 +Host vml030250 
 +  Hostname 10.30.30.250 
 +  User django 
 +  Port 22 
 +  Protocol 2 
 +  IdentityFile ~/.ssh/id_idmz 
 + 
 +Host db_clusternode_3 
 +  Hostname 10.30.30.250 
 +  User django 
 +  Port 22 
 +  Protocol 2 
 +  IdentityFile ~/.ssh/id_idmz 
 + 
 +# interne Systeme - Intranet 
 +Host pml010002 
 +  Hostname 10.10.10.2 
 +  User django 
 +  Port 22 
 +  Protocol 2 
 +  IdentityFile ~/.ssh/id_intra 
 + 
 +Host kvm_1 
 +  Hostname 10.10.10.2 
 +  User django 
 +  Port 22 
 +  Protocol 2 
 +  IdentityFile ~/.ssh/id_intra 
 + 
 +... 
 +... 
 + 
 +Host pml010126 
 +  Hostname 10.10.10.126 
 +  User django 
 +  Port 22 
 +  Protocol 2 
 +  IdentityFile ~/.ssh/id_intra 
 + 
 +Host feinstaubsensor 
 +  Hostname 10.10.10.126 
 +  User django 
 +  Port 22 
 +  Protocol 2 
 +  IdentityFile ~/.ssh/id_intra 
 + 
 +# externe System 
 +Host ff_pliening_gbw__ug_ 
 +  Hostname [2001:678:e68:102:32b5:c2ff:fe56:62b1] 
 +  User root 
 +  Port 22 
 +  Protocol 2 
 +  IdentityFile ~/.ssh/id_freifunk 
 +  ProxyCommand  ssh -q -W %h:%p vml070010 
 + 
 +Host ff_pliening_gbw__ug_-extern 
 +  Hostname 2001:678:e68:102:32b5:c2ff:fe56:62b1 
 +  User root 
 +  Port 22 
 +  Protocol 2 
 +  IdentityFile ~/.ssh/id_freifunk 
 + 
 +... 
 +... 
 + 
 +Host ff_roding_fwg_nausch 
 +  Hostname [2001:678:e68:109:8e3b:adff:feeb:f2a6] 
 +  User root 
 +  Port 22 
 +  Protocol 2 
 +  IdentityFile ~/.ssh/id_freifunk 
 +  ProxyCommand  ssh -q -W %h:%p vml070010 
 + 
 +Host ff_roding_fwg_nausch-extern 
 +  Hostname 2001:678:e68:109:8e3b:adff:feeb:f2a6 
 +  User root 
 +  Port 22 
 +  Protocol 2 
 +  IdentityFile ~/.ssh/id_freifunk 
 + 
 +</file> 
 + 
 +===== Fazit  und Ausblick ===== 
 +<WRAP center round info 80%> 
 + 
 +Die manuelle, zeitraubende und ggf. Fehlerbehaftete Pflege der SSH-Client-Konfigurations-Datei durch mehrere Admins auf verschiedenen Ansible-Kontroll-Knoten ist somit Geschichte. Ferner sind wir unabhängig und können so viele SSH-Jump-Hosts verwenden, die eben zum Erreichen der Zielhost von Nöten sind. 
 + 
 +Die initiale Fragestellung //Wie wird sicher gestellt, dass alle Ziele auch erreichbar sind?//, die wir bei unseren **[[detail#wo_laufen_die_ansible_scripte|Vorüberlegungen]]** angestellt hatten, können wir also auch als erfolgreich erledigt abhaken und wir sind bei unserem Ziel von **Automatisierung** und **Orchestrierung** einen wesentlichen Schritt weiter gekommen. :UP: 
 +</WRAP> 
 + 
 +====== Links ====== 
 +  * **[[detail|zurück zum Kapitel "Ansible - Erweiterte Konfigurationsbeispiele"]] <= ** 
 +  * **=> [[playbook_example_11|weiter zum Kapitel "Ansible - Erweiterte Konfigurationsbeispiel: Roles]]** 
 +  * **[[start|Zurück zur "Ansible"-Übersicht]]** 
 +  * **[[wiki:start|Zurück zu >>Projekte und Themenkapitel<<]]** 
 +  * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]**
  
-:KRIT: FIXME :KRIT: 
  
  • linux/ansible/playbook_example_10.1663940263.txt.gz
  • Zuletzt geändert: 23.09.2022 13:37.
  • von django