Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- centos:ansible:ffmuc-rpb4-ol [31.08.2020 11:28. ] – django
+++ centos:ansible:ffmuc-rpb4-ol [05.09.2020 19:09. ] – [Download des auf Debian Buster basierenden Raspbian] django
@@ Zeile 69: / Zeile 69: @@
 Je nach verwendeter Systemumgebung installieren wir nun das vom Paketmaintainer zur Verfügung gestellte  **RPM** bzw. **DEB** Paket. Im Falle von RedHat basierenden Systemen wie **[[https://www.centos.org/|CentOS]]** oder **[[https://getfedora.org/|Fedora]]** benutzen wir das Paketverwaltungswerkzeug **YUM/DNF** oder im Falle von **[[https://www.debian.org/|Debian]]** und **[[https://ubuntu.com/|Ubuntu]]** das Werkzeug **APT**.
    * RPM basierende Systeme: <code> # dnf install ansible</code> bzw. <code> # yum install ansible</code>
-   * DEB basierende Systeme: <code> # apt install ansible</code>
+   * DEB basierende Systeme: <code> # apt install ansible</code> bzw. als eigeloggter User via **''sudo''** mit <code> $ sudo apt install ansible</code>
 ==== Einrichten der eigenen Ansible-Umgebung ====
@@ Zeile 83: / Zeile 83: @@
         └── Raspbian</code>
+:GO:
+/*
+Gemäß **[[http://docs.ansible.com/ansible/latest/playbooks_best_practices.html|Ansible's Best Practices]]** gibt es durchaus einige Möglichkeiten wie man seine Playbooks organisiert. In aller Regel wird man hier die eigenen individuellen Bedürfnisse (seiner Unternehmung) vornan stellen.
+<WRAP center round tip 90%>
+Jedoch empfiehlt es sich durchaus auf Empfohlenes zurückzugreifen! So empfiehlt es sich zum Beispiel auch, Rollen anstelle von Aufgaben zu verwenden, da dies wesentlich bei der Flexibilität und besseren Organisation der eigenen Playbooks/Codes helfen!
+</WRAP>
+Ansible bietet **[[https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html#content-organization|zwei Beispiele]]** für Verzeichnis-Layouts. Wir werden im folgen Beispiel uns eine Umgebung aufbauen, in der unser Inventory, also unsere Hosts und Nodes, in mehreren **''groups''** und **''childs''** aufteilen.
+Mit dieser Struktur sind wir dann in der Lage jede Inventardatei mit ihrer **''group_vars''** und **''host_vars''** in ein separates Verzeichnis zu packen. Fernen können wir so einfach neue Rollen **''roles''**erzeugen, in dem wir dann einfach die bereits vorgefertigte Rollenvorlage **''common''** kopieren.
+Werfen wir also einfach mal auf die beschrieben Verzeichnisstruktur einen genaueren Blick. Die entsprechende Verwendung der einzelnen Verzeichnisse und DAteien ist in der Aufstellung entsprechend angegeben.
+<code>ansible/
+├── filter_plugins                 # (optionales) Verzeichnis für individuelle filter plugins
+├── library                        # (optionales) Verzeichnis für benutzerdefinierte Module
+├── module_utils                   # (optionales) Verzeichnis für benutzerdefinierte module_utils zur Unterstützung von Modulen
+│
+├── inventories                    # Verzeichnis für die einzelnen (unterschiedlichen) Invenory
+│   ├── production                 # Verzeichnis für die Hosts aus der Gruppe production
+│   │   ├── hosts.yml              # YML-Datei mit den Host-Definitionen aus der Gruppe production
+│   │   ├── group_vars             # Verzeichnis für die Gruppenspezifischen Variablen der Gruppe production
+│   │   └── host_vars              # Verzeichnis für die Hostspezifischen Variablen der Gruppe production
+│   │
+│   └── staging                    # Verzeichnis für die Hosts aus der Gruppe staging
+│       ├── hosts.yml              # YML-Datei mit den Host-Definitionen aus der Gruppe production
+│       ├── group_vars             # Verzeichnis für die Gruppenspezifischen Variablen der Gruppe
+│       └── host_vars              # Verzeichnis für die Hostspezifischen Variablen der Gruppe production
+│
+├── roles                          # Verzeichnis für die einzelnen (unterschiedlichen) Rollen
+│   └── common                     # Verzeichnis "role" common mit seinen entsprechenden Definitionen - Vorlage zum Kopieren
+│       ├── defaults               # Verzeichnis "defaults"
+│       │   └── main.yml           # Standardvariablen mit niedrigerer Priorität für diese Rolle
+│       ├── files                  # Verzeichnis "files"
+│       │   └── main.yml           # (Skript-)Dateien zur Verwendung als Kopier- bzw. Script-Rressource
+│       ├── handlers               # Verzeichnis "handlers"
+│       │   └── main.yml           # Datei mit den Definitionen zu den rollenspezifischen "handlers"
+│       ├── library                # Verzeichnis für benutzerdefinierte Module einer der Rolle (role) "common"
+│       ├── lookup_plugin          # Verzeichnis für weitere Arten von Plugins, wie in diesem Fall "lookup"
+│       ├── meta                   # Verzeichnis "meta" für Rollenspezifische Definitionen/Abhängigkeiten
+│       │   └── main.yml           # Datei mit Rollenspezifischen Definitionen
+│       ├── module_utils           # Verzeichnis "module_utils", die benutzerdefinierte module_utils der Rollen enthalten könnte
+│       ├── tasks                  # Verzeichnis "tasks" für kleinere Aufgabendateien
+│       │   └── main.yml           # Datei für kleinere Aufgaben, falls diese benötigt werden würden
+│       ├── templates              # Verzeichnis mit den Templates
+│       │   └── main.j2            # Template-Datei mit dem Dateisuffix/-Ende .j2
+│       └── vars                   # Verzeichnis "vars", mit den zu dieser Rolle zugeordneten Variablen
+│           └── main.yml           # Datei mit den Rollenspezifischen Variablen
+│
+└── site.yml                       # master playbook
+</code>
+Um dieses Verzeichnis-Layout einfach und schnell auf den Weg zu bringen, verwenden wir die nachfolgend gezeigten zwei Befehle bzw. genauer gesagt die beiden Befehlskette:
+   $ mkdir -p ~/ansible/inventories/{production,staging}/{group_vars,host_vars} \
+              ~/ansible/{library,module_utils,filter_plugins} \
+              ~/ansible/roles/common/{tasks,handlers,templates,files,vars,defaults,meta,library,module_utils,lookup_plugin}
+   $ touch    ~/ansible/inventories/{production,staging}/hosts.yml \
+              ~/ansible/site.yml \
+              ~/ansible/roles/common/{tasks,handlers,templates,files,vars,defaults,meta}/main.yml
+*/
 === Ansible-Konfigurationsdatei ===
 Als nächstes kopieren wir uns die Vorlage-Konfiguratinsdatei aus dem Verzeichnis **''/etc/ansible/''** in unser Homeverzeichnis.
@@ Zeile 88: / Zeile 150: @@
 Unter dem Konfigurationsgruppe **[ defaults ]** setzen wir den Parameter **''inventory = ~/ansible/inventory/hosts''** und **''interpreter_python = auto_silent''**. Beim ersten Parameter zeigen wir Ansible, wo die Host-Definitionen zu finden sind. beim Parameter **''interpreter_python''** geben wir an, dass __keine__ Ausgabe zu den Angaben des Pfads zum Python-Interpreter auf dem Raspberry ausgegeben werden soll. Der Parameter **''connect_timeout''** definiert, wie lange eine persistente Verbindung bestehen darf, bevor diese hart getrennt wird. Weitere Information zu den Konfigurationsparametern finden sie in der **[[https://docs.ansible.com/ansible/latest/reference_appendices/config.html|Dokumentation der Konfigurationsoptionen]]** zu Ansible.
    $ vim ~/.ansible.cfg
@@ Zeile 107: / Zeile 170: @@
 </code>
+:GO:
+/*
+Als nächstes kopieren wir uns die Vorlage-Konfiguratinsdatei aus dem Verzeichnis **''/etc/ansible/''** in unser Homeverzeichnis.
+   $ cp /etc/ansible/ansible.cfg ~/.ansible.cfg
+Unter dem Konfigurationsgruppe **[ defaults ]** setzen wir den Parameter **''inventory = ~/ansible/inventories/production/hosts.yml''** und **''interpreter_python = auto_silent''**. Beim ersten Parameter zeigen wir Ansible, wo die Host-Definitionen zu finden sind. beim Parameter **''interpreter_python''** geben wir an, dass __keine__ Ausgabe zu den Angaben des Pfads zum Python-Interpreter auf dem Raspberry ausgegeben werden soll. Der Parameter **''connect_timeout''** definiert, wie lange eine persistente Verbindung bestehen darf, bevor diese hart getrennt wird. Weitere Information zu den Konfigurationsparametern finden sie in der **[[https://docs.ansible.com/ansible/latest/reference_appendices/config.html|Dokumentation der Konfigurationsoptionen]]** zu Ansible.
+   $ vim ~/.ansible.cfg
+Im Ganzen ergibt sich dann hier die doch überschaubare Konfigurationsdatei zu Ansible.
+   $ egrep -v '(^.*#|^$)' ~/.ansible.cfg
+<code>[defaults]
+inventory          = ~/ansible/inventories/production/hosts.yml
+interpreter_python = auto_silent
+[inventory]
+[privilege_escalation]
+[paramiko_connection]
+[ssh_connection]
+[persistent_connection]
+connect_timeout = 30
+[accelerate]
+[selinux]
+[colors]
+[diff]
+</code>
+*/
 === Host-Definitionsdatei ===
 Ähnlich wie bereits auch schon die Konfigurationsdatei zu Ansible wird auch die Datei zur Hostdefinition sehr überschaubar bleiben.
@@ Zeile 119: / Zeile 210: @@
   raspberry-ansible
+:GO:
+/*
+Ähnlich wie bereits auch schon die Konfigurationsdatei zu Ansible wird auch die Datei zur Hostdefinition sehr überschaubar bleiben.
+Auch hier kopieren wir uns die Vorlagedatei in unser Homeverzeichnis an Ort und Stelle.
+   $ cp /etc/ansible/hosts ~/ansible/inventories/production/
+Dort tragen wir den Namen ein, wie wir unseren Host später im Playbook ansprechen wollen. In diesem Konfigurationsbeispiel nutzen wir hier den Namen **''raspberry-ansible''**.
+   $ vim ~/ansible/inventories/production/hosts
+Somit ergibt sich auch hier eine sehr üersichtliche Konfigurationsdatei.
+   $ egrep -v '(^.*#|^$)' ~/ansible/inventories/production/hosts
+  raspberry-ansible
+*/
 === SSH Konfigurationsdatei ===
@@ Zeile 1599: / Zeile 1709: @@
    $ wget https://downloads.raspberrypi.org/raspbian_lite_latest
-Bevor wir nun das Archiv entpacken überprüfen wir noch die Integrität der heruntergeladenen Datei. Heirzu berechnen wir erst einmal die **SHA256**-Prüfsumme der Datei **raspbian_lite_latest**.
+Bevor wir nun das Archiv entpacken überprüfen wir noch die Integrität der heruntergeladenen Datei. Hierzu berechnen wir erst einmal die **SHA256**-Prüfsumme der Datei **raspbian_lite_latest**.
    $ sha256sum raspbian_lite_latest
@@ Zeile 1614: / Zeile 1724: @@
 </code>
+:GO:
+/*
+Nachdem es aktuell((Stand: September 2020)) noch kein fertiges Gluon Image für das **[[https://www.raspberrypi.org/products/raspberry-pi-4-model-b/|Raspberry PI 4B]]** gibt, holen wir uns nun das aktuelle **Raspberry Pi OS** (früher unter dem Namen //Raspbian// bekannt) auf unseren Rechner. Dies hat mitunter auch noch den Charme, dass wir bei Bedarf alle normalen Anwendungen wie Webserver, Chatserver oder z.B. den Unifi-Controller einfach installieren können.
+Eine Anleitung zur manuellen Installation findet man auf der **[[https://www.raspberrypi.org/documentation/installation/installing-images/README.md|offiziellen Raspbian Seite]]**.
+   $ wget https://downloads.raspberrypi.org/raspbian_lite_latest
+Bevor wir nun das Archiv entpacken überprüfen wir noch die Integrität der heruntergeladenen Datei. Hierzu berechnen wir erst einmal die **SHA256**-Prüfsumme der Datei **raspbian_lite_latest**.
+   $ sha256sum raspios_lite_armhf_latest
+df4a29f9aac4b0166fbfee9f599dab55a997c855702bfe35329c13334668  raspios_lite_armhf_latest
+Die Zeichenfolge überprüfen wir nun mit den Angaben auf der Seite: https://www.raspberrypi.org/downloads/raspbian/
+{{ :centos:ansible:raspberry-pi-os.png?nolink&625 |Bild: Bildschirmhardcopy der Seite www.raspberrypi.org/downloads/raspberry-pi-os/ (Stand: 05.09.2020)}}
+Da sich beide SHA-Werte **__nicht__** unterscheiden können wir das herunter geladene ZIP-Archiv nun entpacken.
+   $ unzip raspios_lite_armhf_latest
+<code>Archive:  raspios_lite_armhf_latest
+  inflating: 2020-08-20-raspios-buster-armhf-lite.img
+</code>
+*/
 ==== Kopieren des Raspbian Images auf die microSD-Karte ====
 Nun können wir das Image auf die MicroSD Karte, die wir später in den Raspberry 4B stecken kopieren. Wir werfen also am besten einmal einen Blick in das syslog unseres Arbeitsrechners und erkennen so das Device unserer Speicherkarte.