GitLab-Backup – SouToub


GitLab sollte so oft gesichert werden, wie es Ihre Umgebung erfordert. Da der Prozess selbst aus mehreren Schritten besteht und enthält eine Reihe von nicht ganz offensichtlichen, aber sehr wichtigen Punkten, auf die ich in diesem Artikel näher eingehen möchte.


Wenn Sie an Debian und verwandten Anwendungen interessiert sind, empfehle ich, das Debian-Tag in meinem Blog zu lesen.


GitLab-Backup

Das betrachtete Sicherungsszenario ist nur für GitLab Omnibus relevant .

Vorbereitende Aufgaben

Der erste Schritt besteht darin, Änderungen an der Hauptkonfigurationsdatei von GitLab vorzunehmen, indem Informationen zum Sicherungsspeicher in den Einstellungen festgelegt werden. Öffnen Sie die Datei zur Bearbeitung:

Fügen Sie einen Code ein:

Wo

  • / mnt / backup01 – Einhängepunkt des Remotespeichers;
  • gitlab_backups – ein Unterordner, der im Stammverzeichnis erstellt wird;
  • backup_keep_time – Sicherungslebensdauer in Sekunden
Hinweis: Die Einstellungen setzen die Verwendung von lokalem Speicher voraus. “Lokal” in der GitLab-Terminologie bedeutet, dass es sich lokal auf dem Server befindet, aber niemand verbietet, dass es sich um ein bereitgestelltes Remote-Repository handelt. Dies ist genau die Option, die ich verwenden werde, aber die Möglichkeit der Sicherung auf Cloud-Speicher ist verfügbar .

Damit die Änderungen wirksam werden, konfigurieren wir GitLab neu:

Damit sind die vorläufigen Einstellungen abgeschlossen.

Skripterstellung

Erstellen wir einen Ordner mit Skripten (kompromissempfindliche Daten werden darin gespeichert, achten Sie auf die Zugriffsrechte):

Fügen wir zwei Dateien hinzu – gitlab_backup und gitlab_backup_credentials. Das erste ist das Skript selbst, das Sie herunterladen können. Die zweite ist eine Datei mit Anmeldeinformationen für den Zugriff auf den Speicher. Sie hat das folgende Format:

Diese Datei ist erforderlich, um Anmeldeinformationen nicht explizit in das Skript zu schreiben.

Vergessen Sie nicht, die erforderlichen Berechtigungen für jede Datei festzulegen:

Es sind noch einige Schritte erforderlich, damit das Skript funktioniert.

Das Skript in Betrieb nehmen

Lassen Sie uns die Aufgabe so konfigurieren, dass das Skript planmäßig ausgeführt wird. Öffnen Sie die Crontab-Datei zur Bearbeitung:

Hinweis: Das direkte Bearbeiten von / etc / crontab ist akzeptabel, wird jedoch nicht empfohlen. Es ist besser, den Scheduler mit crontab -e zu bearbeiten, aber die Syntax der Datei ist unterschiedlich. Weitere Informationen finden Sie im Debian-Artikel. Spickzettel des Systemadministrators. Taskmanager.

Fügen Sie die Zeile ganz am Ende ein:

Das Skript wird jeden Tag um 6 Uhr ausgeführt.

Arbeitsprinzip

Damit eine Sicherung vollständig ist, muss sie mindestens die folgenden Abschnitte enthalten:

  • Konfigurationsverzeichnis Archiv / etc / gitlab
  • Archiv der Anwendungsdaten, deren Speicherort im Parameter angegeben ist git_data_dirs Konfigurationsdatei (/etc/gitlab/gitlab.rb). Default / var / opt / gitlab / git-data.

Das Verzeichnis / etc / gitlab muss manuell gesichert werden. In der Minimalversion reicht hierfür nur ein Befehl aus, zum Beispiel:

Die Anwendungssicherung wird mit GitLab-Tools durchgeführt und noch einfacher:

Das heißt, Sie benötigen nur zwei Befehle, um eine vollständige Sicherung von GitLab zu erstellen. In Wirklichkeit ist jedoch alles etwas komplizierter und Sie haben möglicherweise andere Schritte:

  • Ein- und Aushängen eines Remote-Speichers;
  • Löschen alter Backups;
  • Senden eines Berichts über die Ausführung des Skripts.

Usw.

Hinweis: Mit Blick auf die Zukunft möchte ich darauf hinweisen, dass es sehr wichtig ist, die Version von GitLab auch im Skript anzuzeigen. Tatsache ist, dass Sie die Sicherung nur auf dem Server derselben Version wiederherstellen können, auf der diese Sicherung erstellt wurde. Sie können die Version mit dem Befehl herausfinden:

Eignung zeigen gitlab-ce | grep Версия | awk -F «:» ‘{print $ 2}’

In meiner Version des Skripts habe ich einen Befehlshandler hinzugefügt, der den Exit-Code überprüft. Wenn er sich vom Normalen unterscheidet, wird die Skriptausführung gestoppt. Ich habe auch den Ereignisbericht angepasst. Sie sehen so etwas im Bericht in Ihrer E-Mail:

Tatsächlich hängt alles nur von den Funktionen Ihrer Infrastruktur ab.

Kommentare bereitgestellt von HyperComments

Leave a Reply

Your email address will not be published. Required fields are marked *