Ansible: Automatisierung von Arbeitsabläufen – stellt wieder her

Ansible sollte auch verwendet werden, um den Support zu vereinfachen – wiederherstellen Prozess, regelmäßige Routinen jeden Tag.

Für die regelmäßige Backup-Restore-Automatisierung wurde Ansible ausgewählt und an den folgenden Workflow angepasst.

Der Inhalt des Servers1, der in die Cloud hochgeladen wurde, befindet sich auf einem dedizierten Server, dessen Betriebssystem ziemlich alt war und ein Upgrade auf das neueste ohne Ausfallzeiten von mehreren Stunden oder Tagen nicht möglich war. Backups wurden erstellt, nur ohne es zu beweisen, während der Live-Wiederherstellung.

Werkzeuge und Arbeitsablauf wurden in Abhängigkeit von Serverkomponenten, Netzwerkkanälen, Betriebssystem und angeschlossener Software ausgewählt.

Eingabe-Quelldaten:

• Bestimmter Server in der Cloud;
• OS: Ubuntu über LTS-Zeit – Upgrade und Bereitstellung neuer Pakete über apt Source System war nicht möglich;
• öffentlich zugänglich mit statischer IP;
• Verwendete Dienste: Jira, Fisheye, Apache Subversion, MySQL DB Server, Apache Tomcat, JDK7, SSL.

Zu tun:

• Regelmäßiges vollständiges und inkrementelles Backup des Servers1 alle 8 Stunden;
• Inhalte einen Monat lang verfügbar halten;
• Bereitstellung des neuesten Ubuntu LTS mit vordefinierten Systembenutzern, Berechtigungen, Apache Subversion, neuestem MySQL-Datenbankserver, Firewall, mit öffentlicher virtueller Maschine innerhalb von vSphere ESXi regelmäßig alle 8 Stunden;
• Wiederherstellen des Inhalts von Server1 auf Server2 regelmäßig alle 8 Stunden;
• Alle Prozesse zwischen den Servern sollten über die RSA-Passwortless-Authentifizierung erfolgen;
• Start und Ziel der Etappe müssen im Slack-Kanal gemeldet werden;
• Die Laufzeit von Server1 sollte während des Prozesses nicht unterbrochen werden.

Der inhaltliche Unterschied zwischen den Instanzen entspricht dem Speicherzeitraum.

Backup-Restore-Modell:

Für den Prozess wurde das folgende Modell mit Ansible und BackupPC gewählt. Auch Chef oder Puppet könnten für einen ähnlichen Workflow verwendet werden.
Folgende Komponenten wurden im Workflow verwendet

• backuppc (konfiguriert für regelmäßige Backups);
• vSphere ESXi als Hypervisor-Host für die Bereitstellung von wiederhergestellter Instanzen;
• Das vorkonfigurierte Ubuntu 16.04 LTS Image für den stillen Betrieb wird installiert;
• ansible, python, vsphere_guest Module;
• RSA-Passwordlosses Genehmigung zwischen den Instanzen;
• Slack.

Vor Beginn des Prozesses sollten zusätzliche Parameter definiert werden:

• Wenn das selbstsignierte SSL-Zertifikat standardmäßig auf vSphere ESXi verwendet wird, d. h. auf der Instanz, auf der Ansible Playbooks ausgeführt werden, um gelegentliche Ausnahmen bei den nächsten Änderungen an den Python-Quellen zu vermeiden, fügen Sie zu den Zeilen /usr/local/lib/python2.7/dist-packages/pysphere/vi_server.py Folgendes hinzu:

   ###============
   import ssl
   ssl._create_default_https_context = ssl._create_unverified_context
   ###============

• Wenn Sie die Überprüfung des SSH-Schlüssels bei der RSA-Authentifizierung nicht benötigen, nehmen Sie die Änderungen in der Konfigurationsdatei /etc/ansible/ansible.cfg vor:

    # uncomment this line to disable SSH key host checking
    host_key_checking = False

• Wenn es erforderlich ist, um Benutzer mit Passwort auf VM über Ansible zu erstellen, als Passwort Hash konnte mit dem Befehl erstellt werden:

  mkpasswd --method=sha-512

• Um eine Benachrichtigung in Slack zu versenden, muss ein Web-Hook im Admin-Panel erstellt werden, das Ansible-Modul angeschlossen und ein Shell-Skript verwendet werden.

In der Regel gibt es einen Ergebnis-Workflow mit den nächsten Schritten:

1. BackupPC – vor 15 min nach dem Start der Synchronisation, im Zeitplan – sendet die Nachricht an die Slack mit der Benachrichtigung über den Start des Backups;
2. BackupPC – vor 15 min nach dem Start der Synchronisation, im Zeitplan – sendet die Nachricht an die Slack mit der Benachrichtigung über den Start des Backups;
3. BackupPC – führt die vollständige/inkrementelle Synchronisation von Content Server1 durch und speichert sie einen Monat lang nach einem vordefinierten Zeitplan;
4. BackupPC – bereitet das Archiv für die Wiederherstellung vor und sendet alle Kopien an ein einziges aktuelles archiv_to_restore_date.tar.gz;
5. BackupPC – verwaltet das Ansible Playbook;
6. Ansible – auf vSphere-ЕСХi-host erstellt virtuelle Maschine mit vordefinierten Hardware-Konfiguration (CPU, RAM, HDD, Netzwerk-Schnittstellen (öffentlich / privat), Boot-Image). Als Boot-Image wird das vorbereitete Set der letzten automatisierten Ubuntu LTS Deployments verwendet;
7. Ansible – nach der Erstellung und Installation der VM wurde ihre IP-Adresse aus dem DHCP-Pool des Routers zugewiesen;
8. Ansible – SSH RSA Verbindung zu neu erstellter VM herstellen, Systembenutzer anlegen, archive_to_restore_date.tar.gz von BackupPC auf VM kopieren;
9. Ansible – Entpacken von Inhalten aus dem Archiv in seine Speicherorte;
10. Ansible – führt MySQL-Optimierungen durch, um strukturelle Unterschiede zwischen den MySQL-Servern von Server1 und Server2 zu beseitigen;
11. Ansible – führt Systemdämonen auf dem wiederhergestellten Server2 aus und löscht das ursprüngliche Archiv;
12. Ansible – sendet eine Benachrichtigung an den Slack-Kanal über den Abschluss der Wiederherstellung und zeigt die neue öffentliche IP-Adresse von Server2 an;
13. Die DNS-Einträge wurden im Alarmfall manuell vorgenommen, wobei gleichzeitig der BackupPC-Init-Synchronisationsprozess gestoppt wurde.

Das Ergebnis ist ein vollständiger Live-Workflow für den periodischen Backup-Restore-Prozess zwischen Server1 und Server2.