{"id":1686,"date":"2018-03-30T17:00:23","date_gmt":"2018-03-30T16:00:23","guid":{"rendered":"https:\/\/www.my-it-brain.de\/wordpress\/?p=1686"},"modified":"2020-06-21T13:27:13","modified_gmt":"2020-06-21T11:27:13","slug":"konzept-zum-deployment-meines-blogs-mit-ansible","status":"publish","type":"post","link":"https:\/\/www.my-it-brain.de\/wordpress\/konzept-zum-deployment-meines-blogs-mit-ansible\/","title":{"rendered":"Konzept zum Deployment meines Blogs mit Ansible"},"content":{"rendered":"

An dieser Stelle m\u00f6chte ich ein Konzept erarbeiten, um meinen Blog mit Hilfe von Ansible[1. Ansible – IT-Automation f\u00fcr Jedermann – My-IT-Brain<\/a>] [2. Ansible – Wikipedia<\/a>] auf einem Ubuntu-Server ausbringen zu k\u00f6nnen.<\/p>\n

Dabei hoffe ich auch ein wenig auf eure Unterst\u00fctzung. Habt ihr Anregungen, konkrete Verbesserungsvorschl\u00e4ge oder auch Fragen, freue ich mich \u00fcber eure Kommentare. Denn ich selbst bin kein Ansible-Experte und f\u00fchre dieses Projekt zum Selbststudium und zu \u00dcbungszwecken durch.<\/p>\n

Die Testumgebung<\/h2>\n

Die Testumgebung besteht aus der Ansible Control Machine<\/em>, basierend auf RHEL 7[3. Red Hat Enterprise Linux – Wikipedia<\/a>] und dem Zielsystem, basierend auf Ubuntu Bionic Beaver[4. Bionic Beaver – wiki.ubuntuusers.de<\/a>]. Zum Zeitpunkt der Erstellung dieses Artikels nutze ich Ansible in Version 2.4.2.<\/p>\n

Zwar wurde bereits die Ansible-Version 2.5 ver\u00f6ffentlicht, in den RHEL-7-Paketquellen ist jedoch noch die Version 2.4.2 enthalten. Ich verwende diese Version auch auf der Arbeit und erhoffe mir so, Erkenntnisse aus diesem Projekt in meine dienstliche T\u00e4tigkeit einflie\u00dfen lassen zu k\u00f6nnen.<\/p>\n

Auf dem Zielsystem existiert ein Benutzer, welcher \u00fcber volle sudo<\/code>-Berechtigung verf\u00fcgt. Dieser Benutzer muss sich mit seinem Passwort authentisieren, wenn er sudo<\/code> verwendet.<\/p>\n

Auf der Ansible Control Machine<\/em> wird ein SSH-Schl\u00fcsselpaar[5. Authentifizierung \u00fcber Public-Keys – wiki.ubuntuusers.de<\/a>] generiert, dessen privater Schl\u00fcssel nicht mit einer Passphrase gesch\u00fctzt ist. Der \u00f6ffentliche Schl\u00fcssel wird auf dem Zielsystem abgelegt. Damit wird sichergestellt, dass die Ansible Control Machine<\/em> SSH-Zugriff auf das Zielsystem hat.<\/p>\n

Die Konfiguration von Ansible (\/etc\/ansible\/ansible.cfg) wird so angepasst, dass standardm\u00e4\u00dfig das oben erzeugte SSH-Private-Key-File beim Verbindungsaufbau genutzt wird.<\/p>\n

Die Installation der ben\u00f6tigten Betriebssysteme und Ansible sind nicht Gegenstand dieses Artikels.<\/p>\n

Geplante Vorgehensweise<\/h2>\n

Um eine Vorgehensweise zu erarbeiten, orientiere ich mich an dem Artikel Testinstanz f\u00fcr einen WordPress-Blog erstellen<\/a>. In diesem habe ich bereits beschrieben, wie ein Blog auf einem weiteren System als Testsystem aufgesetzt werden kann. Die Vorgehensweise ist \u00e4hnlich, mit dem Unterschied, dass s\u00e4mtliche Schritte nun durch Ansible orchestriert werden sollen.<\/p>\n

Danach ergibt sich folgende (vorl\u00e4ufige) Reihenfolge:<\/p>\n

    \n
  1. Vom Produktivsystem ben\u00f6tigte Dateien holen<\/li>\n
  2. Sicherstellen, das alle ben\u00f6tigten Pakete auf dem Zielsystem installiert sind<\/li>\n
  3. VirtualHost erstellen<\/li>\n
  4. DocumentRoot aus Backup-Datei erstellen<\/li>\n
  5. Datei-Attribute und Zugriffsrechte korrekt setzen<\/li>\n
  6. Eine .httpasswd<\/code>-Datei erzeugen\/ausbringen<\/li>\n
  7. Datenbank aus Backup wiederherstellen<\/li>\n
  8. Datenbankbenutzer erstellen<\/li>\n
  9. Troubleshooting<\/li>\n<\/ol>\n

    Mit hoher Wahrscheinlichkeit ist die obige Liste noch nicht vollst\u00e4ndig. Daher werde ich diese im Laufe des Projekts anpassen, sobald weitere Erkenntnisse vorliegen.<\/p>\n

    Als Quelldaten f\u00fcr den Blog liegen das DocumentRoot meines Blogs als Tarball[6. tar – Wikipedia<\/a>] vor. Von der Datenbank wurde ein logisches Backup[7. Logisches Backup – wiki.ubuntuusers.de<\/a>] erstellt. Auf diese Datensicherung wird zur\u00fcckgegriffen, um den Blog auf einem neuen Ubuntu-Server auszubringen bzw. wiederherzustellen.<\/p>\n

    Der erste Versuch<\/h2>\n

    Im ersten Anlauf habe ich eine Ansible-Rolle[8. Directory Layout — Ansible Best Practices<\/a>] mit folgendem Aufbau erstellt:<\/p>\n

    \/etc\/ansible\/roles\/\n\u2514\u2500\u2500 deploy-my-blog\n    \u251c\u2500\u2500 files\n    \u2502\u00a0\u00a0 \u251c\u2500\u2500 backup-documentroot.tar.bz2\n    \u2502\u00a0\u00a0 \u251c\u2500\u2500 dh_params.pem\n    \u2502\u00a0\u00a0 \u251c\u2500\u2500 db_dump.sql.bz2\n    \u2502\u00a0\u00a0 \u251c\u2500\u2500 my-it-brain.vhost\n    \u2502\u00a0\u00a0 \u2514\u2500\u2500 php-fpm-pool.conf\n    \u251c\u2500\u2500 handlers\n    \u2502\u00a0\u00a0 \u2514\u2500\u2500 main.yml\n    \u251c\u2500\u2500 tasks\n    \u2502\u00a0\u00a0 \u2514\u2500\u2500 main.yml\n    \u2514\u2500\u2500 vars\n        \u2514\u2500\u2500 main.yml\n\n5 directories, 8 files\n<\/pre>\n
    Unterhalb von files<\/em> wurden Dateien abgelegt, welche vom aktuellen Produktivsystem stammen und f\u00fcr das Deployment auf einem neuen Server ben\u00f6tigt werden.<\/p>\n
    Im folgenden werde ich zuerst auf die eingesetzten Module eingehen und anschlie\u00dfend das Playbook zum Deployment des Blogs vorstellen.<\/p>\n
    Verwendete Module<\/h3>\n\n\n\n\n\t\n\n\t\n\t\n\t\n\t\n\t\n\t
    Modul<\/th>Status<\/th>Verwendung<\/th>\n<\/tr>\n<\/thead>\n
    apt<\/a><\/td>stableinterface<\/td>Verwaltet APT-Pakete<\/td>\n<\/tr>\n
    unarchive<\/a><\/td>preview<\/td>Entpackt Archiv-Dateien und kopiert sie ggf. vorher auf das Zielsystem<\/td>\n<\/tr>\n
    copy<\/a><\/td>stableinterface<\/td>Kopiert Dateien auf entfernte Rechner<\/td>\n<\/tr>\n
    file<\/a><\/td>stableinterface<\/td>Erstellt Dateien, Verzeichnisse, symbolische Links und setzt deren Attribute<\/td>\n<\/tr>\n
    mysql_db<\/a><\/td>preview<\/td>Hinzuf\u00fcgen von MySQL-Datenbanken (aus Backup)<\/td>\n<\/tr>\n
    mysql_user<\/a><\/td>preview<\/td>Hinzuf\u00fcgen (und Entfernen) von Benutzern in MySQL-Datenbanken<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n
    Die in der Spalte Status angegebenen Werte stableinterface<\/strong> und preview<\/strong> lassen R\u00fcckschl\u00fcsse auf die Stabilit\u00e4t der Schnittstellen eines Moduls zu.<\/p>\n
    So garantieren die Entwickler bei einem stableinterface<\/strong>, dass es in Zukunft keine \u00c4nderungen geben wird, die nicht abw\u00e4rtskompatibel sind. Auch wenn sich keine explizite Angabe findet, wie lange diese Garantie gilt, kann man davon ausgehen, dass man seine Playbooks bei Verwendung dieser Module nicht so schnell aufgrund von Updates anpassen muss. F\u00fcr Module mit dem Status preview<\/strong> wird genau dies hingegen nicht garantiert. Hier kann es von Version zu Version \u00c4nderungen geben, welche Anpassungen an Playbooks erforderlich machen, welche diese Module verwenden. Dadurch entsteht ggf. ein erh\u00f6hter Testaufwand, bevor man seine Ansible-Installation aktualisieren kann.<\/p>\n
    Das Playbook<\/h3>\n
    Den Inhalt der Datei \/etc\/ansible\/roles\/deploy-my-blog\/tasks\/main.yml<\/em> habe ich unter dem Namen deploy-blog-playbook.yml<\/em> als Gist<\/a> ver\u00f6ffentlicht. Um es in diesem Artikel anzeigen zu k\u00f6nnen, m\u00fcsst ihr JavaScript in eurem Webbrowser aktiveren.<\/p>\n