Spiegel und ein zweiter Standort

Ein Spiegel ist ein Repository auf einer Arkvory-Installation, das eine schreibgeschützte Kopie eines Repositorys auf einer anderen Installation ist, der Quelle. Die Spiegel-Installation zieht Änderungen über HTTPS von der Quelle. Sie behält ihre eigene Datenbank, ihren eigenen Speicher, ihre eigenen Konten und ihre eigenen Schlüssel.

Verwenden Sie einen Spiegel, um Downloads von einem zweiten Standort auszuliefern und einen zweiten Standort zu halten, der übernehmen kann, wenn die Quelle verloren geht. Ein Spiegel ist kein Backup der Quelle und keine automatische Hochverfügbarkeit. Das Umschalten erledigen Sie selbst. Zu anderen Schutzmaßnahmen siehe Backups und Lese-Gateways.

Was ein Spiegel ist

Für ein gespiegeltes Repository kopiert die Spiegel-Installation:

• Die veröffentlichten Dateien, mit ihren Bytes und den gleichen Artefakt-IDs wie auf der Quelle.
• Labels, Metadaten und Sammlungen.
• Die UPack-Registrierung, die Stufen und die aktuellen Dateipfade.
• Container-Images, Git-LFS-Objekte und npm-Pakete des Repositorys.
• Löschungen. Eine auf der Quelle gelöschte Datei wird auf dem Spiegel gelöscht.

Downloads nach ID, nach Paket (Version, Bereich, Stufe) und nach Dateipfad antworten auf dem Spiegel so wie auf der Quelle bei der letzten Synchronisierung. Sie funktionieren weiter, wenn die Quelle ausgefallen ist.

Ein Spiegel kopiert nicht:

• Konten, Gruppen, Schlüssel und Berechtigungen. Der Spiegel hat eigene, und sie sind unabhängig: Das Widerrufen eines Schlüssels auf der Quelle betrifft den Spiegel nicht.
• Referenzen, die Dateien vor der Bereinigung schützen, Anhänge von Builds, Audit-Trails und Speicherrichtlinien.
• Den Verlauf der Dateipfade von vor der ersten Synchronisierung. Revisionsnummern von Labels und Pfaden auf dem Spiegel sind seine eigenen.

Clients können nicht in ein gespiegeltes Repository schreiben. Uploads, Label-Änderungen, Dateipfade, Stufen, Löschung und Hochstufung hinein erhalten HTTP 409 mit dem Grund mirror_read_only. Andere Repositorys der Spiegel-Installation funktionieren wie gewohnt. Speicherrichtlinien laufen in einem gespiegelten Repository nicht, und nur die Synchronisierung löscht dort.

Einen Spiegel einrichten

Sie brauchen einen Schlüssel auf der Quelle und einen Befehl auf dem Spiegel.

Einen Schlüssel auf der Quelle erstellen

Der Spiegel braucht einen Schlüssel, der das Quellrepository nur lesen kann. Ein Schreibschlüssel ist nicht nötig.

1. Öffnen Sie auf der Quelle Dienstzugriff mit dem Wiederherstellungsschlüssel oder einem Operator-Schlüssel.
2. Wählen Sie Dienstkonto erstellen und fügen Sie in Repository-Berechtigungen das Repository hinzu. Wählen Sie Vorlage: Lesen, um die Berechtigungen zu füllen, die ein Spiegel braucht. Dazu gehören artifact.list, artifact.read, content.read, annotation.read, asset.read und package.read.
3. Wählen Sie Schlüssel ausstellen, kopieren Sie das Geheimnis, bestätigen Sie Ich habe das Geheimnis gespeichert und wählen Sie Schlüssel aktivieren. Ein nicht aktivierter Schlüssel läuft nach 15 Minuten ab.
4. Speichern Sie das Geheimnis in einer Datei auf dem Spiegel-Server. Die Datei enthält nur den Schlüssel, in einer Zeile, 16 bis 4000 druckbare Zeichen. Nur root oder die Gruppe der Administratoren darf sie lesen.

Die Quelle muss ein Release mit dem Change-Feed sein. Der Befehl im nächsten Schritt prüft dies.

Das Repository auf dem Spiegel anhängen

Verwenden Sie einen neuen, leeren Repository-Namen auf dem Spiegel. Die Synchronisierung macht das Repository gleich der Quelle, löscht aber nie, was die Quelle nie hatte.

sudo arkvory configure --root /opt/proanima-arkvory \
  --mirror releases \
  --mirror-upstream https://arkvory.example \
  --mirror-token-file /root/mirror-releases.key

$root = 'C:\ProgramData\ProAnima\Arkvory'
& 'C:\Program Files\ProAnima\Arkvory\arkvory.ps1' configure --root $root `
  --mirror releases --mirror-upstream https://arkvory.example `
  --mirror-token-file C:\secure\mirror-releases.key

Option	Bedeutung
--mirror NAME	Das Repository auf dieser Installation. 1–64 Zeichen: Kleinbuchstaben, Ziffern, _ und -, beginnend mit einem Buchstaben oder einer Ziffer
--mirror-upstream URL	Der Ursprung der Quelle: https://host, ohne Pfad, ohne Anmeldedaten und ohne Query. Einfaches http:// wird nur für localhost, 127.0.0.1 und [::1] akzeptiert
--mirror-token-file FILE	Ein absoluter Pfad zur Schlüsseldatei
--mirror-source NAME	Das Repository auf der Quelle. Standard: derselbe Name wie --mirror
--mirror-ca-file FILE	Eine PEM-Datei mit der Zertifizierungsstelle der Quelle. Siehe HTTPS mit eigener Zertifizierungsstelle

Geben Sie einer Kommandozeile ein Repository. Sie können eine Spiegel-Änderung nicht mit Änderungen an HTTPS, dem Backup-Speicher oder Updates im selben Aufruf kombinieren.

1. Der Befehl prüft die Quelle mit dem Schlüssel, bevor er etwas ändert. Die Quelle muss den Change-Feed für Spiegel melden, und der Feed des Quellrepositorys muss antworten.
2. Er speichert den Schlüssel in config/mirrors/NAME.token, schreibt config/mirrors/mirrors.json und setzt ARKVORY_MIRRORS_FILE in config/runtime.json.
3. Er startet die API und den Worker neu und wartet, bis sie bereit sind. Wenn etwas fehlschlägt, stellt er die vorherigen Dateien wieder her und startet erneut.

In Docker Compose schreibt der Befehl außerdem config/compose.mirrors.yml, das die Spiegeldateien in die API- und Worker-Container einbindet. Fügen Sie es Compose-Befehlen hinzu, die Sie selbst ausführen.

Um den Schlüssel eines Repositorys zu ersetzen, wiederholen Sie den Befehl nur mit --mirror und der neuen --mirror-token-file. Die Quelle, die Stufen und die Zertifizierungsstellen bleiben unverändert, und ein Spiegel wird durch einen wiederholten Befehl nie zu einem Import. Der Befehl startet die API und den Worker neu. Der Worker liest die Schlüsseldatei außerdem nach jedem Fehler erneut, eine von Hand ersetzte Schlüsseldatei funktioniert also ohne Neustart.

sudo arkvory configure --root /opt/proanima-arkvory \
  --mirror releases --mirror-token-file /root/new-mirror-releases.key

Lehnt die Quelle den Schlüssel ab, bricht der Befehl ab, bevor er etwas ändert, und nennt den Grund: Der Schlüssel wird nicht akzeptiert (401), er darf das Repository nicht lesen (403), oder das Repository existiert auf der Quelle nicht (404). Ein Repository, das bereits eine Quelle spiegelt, lehnt eine andere Quelle mit der Meldung NAME mirrors another source; detach it first ab.

Geben Sie auf der Spiegel-Installation Personen und Werkzeugen Zugriff auf das Repository. Ein Repository existiert, sobald eine Berechtigung oder eine Dienstrichtlinie es nennt. Verwenden Sie Repository-Zugriff verwalten in Benutzer und Zugriff für Personen und eine Dienstrichtlinie für Werkzeuge. Die Berechtigungen der Quelle werden nicht übernommen.

HTTPS mit eigener Zertifizierungsstelle

Wenn die Quelle ein Zertifikat einer Unternehmens- oder selbstsignierten Zertifizierungsstelle verwendet, fügen Sie --mirror-ca-file /path/ca.pem zum --mirror-Befehl hinzu. Der Befehl prüft, dass jedes Zertifikat gelesen werden kann und nicht abgelaufen ist, und speichert 1 bis 64 Zertifikate in config/mirrors/ca.pem (die Datei darf 1 MiB nicht überschreiten). Der Worker vertraut ihnen dann zusätzlich zu den Standardzertifikaten.

• Die Datei dient jedem Spiegel der Installation. Eine neue --mirror-ca-file ergänzt sie, und ein bereits vorhandenes Zertifikat wird einmal behalten. Das Trennen des letzten Spiegels entfernt die Datei.
• Der Worker vertraut dem ganzen Satz für alle seine Verbindungen, nicht nur für einen Spiegel.
• Die Zertifikatsprüfung wird nie ausgeschaltet.

Was und wie oft kopiert wird

Der Worker der Spiegel-Installation führt die Synchronisierung aus. Es gibt keinen separaten Dienst. Für jedes gespiegelte Repository führt er diese Schritte aus:

1. Erstbefüllung. Der Worker merkt sich die aktuelle Position des Change-Feeds der Quelle. Dann liest er die Liste der Artefakte, Pakete und Dateipfade Seite für Seite und macht den Spiegel gleich dieser Liste.
2. Mitlaufen. Der Worker liest den Feed der Quelle. Wenn er aufgeholt hat, prüft er alle 10 Sekunden erneut. Er speichert seine Position nach jeder Änderung, die er angewendet hat.
3. Dateien kopieren. Eine Datei wird in Teilen kopiert. Der Worker prüft den SHA-256 jedes Teils und der ganzen Datei. Nach einer Unterbrechung setzt er mit dem ersten fehlenden Teil fort. Ein Teil wartet in mirror-staging im Speicherverzeichnis des Spiegels.
4. Nach einem Fehler. Der Worker wiederholt den Schritt nach einer Pause, die bei 2 Sekunden beginnt und sich bis auf 5 Minuten verdoppelt. Ein fehlschlagender Spiegel stoppt die anderen nicht.

Eine Installation kann bis zu 64 gespiegelte Repositorys haben. Die Kopien zählen gegen die Kapazitätsgrenze und den Datenträger des Spiegels, planen Sie also denselben Speicherplatz ein, den das Quellrepository braucht. Siehe Speicher.

Wenn der Quellschlüssel widerrufen wird oder die Quelle nicht erreichbar ist, liefert der Spiegel weiter aus, was er bereits hat, und zeigt den Fehler in seinem Status.

Den Synchronisierungsstatus prüfen

In der Konsole

Spiegel im Menü listet jeden Spiegel und jeden Import auf, deren Repository Sie lesen dürfen, mit Quelle, Zustand, letzter Synchronisierung und dem, was kopiert wurde. Administratoren sehen die Seite immer; solange es keinen Spiegel gibt, erklärt sie, wie man einen einrichtet. Die Seite aktualisiert sich alle 20 Sekunden von selbst.

Zustand	Bedeutung
Synchron	Hat mit der Quelle aufgeholt
Holt auf	Kopiert Änderungen, die die Quelle seit der letzten Prüfung vorgenommen hat
Wird gestartet	Konfiguriert, und der Worker hat ihn noch nicht erreicht
Erste Kopie	Die Erstbefüllung, oder eine neue, nachdem die Quelle wiederhergestellt wurde
Sync-Fehler	Der letzte Versuch ist fehlgeschlagen. Downloads funktionieren weiter, und der Worker versucht es von selbst erneut

Wenn die Synchronisierung gestoppt ist, nennt die Seite den Grund und den nächsten Schritt und zeigt den Befehl, der das Problem behebt, sofern es einen gibt, zum Beispiel einen neuen Schlüssel, nachdem die Quelle den alten abgelehnt hat. Die Texte folgen den Fehlercodes.

Mit einem gespiegelten Repository verbunden, zeigt die Konsole außerdem ein Badge über dem Katalog: Spiegel, Spiegel · wird synchronisiert oder Spiegel · Sync-Fehler. Solange die Synchronisierung gestoppt ist, erscheinen darunter der Grund und der nächste Schritt, und das Badge folgt dem Server ohne Neuladen. Öffnen Sie die Hilfe des Badges (Über diesen Spiegel), um die Quelle und die Zeit der letzten Synchronisierung zu sehen. Die Konsole verbirgt die Upload- und Änderungsschaltflächen in einem gespiegelten Repository.

Mit der API

getRepositoryMirror gibt den Status eines Repositorys zurück. Es braucht das Recht, das Repository zu lesen. Für ein gewöhnliches Repository lautet die Antwort 404.

Feld	Bedeutung
mode	mirror oder import
phase	pending (der Worker hat nicht begonnen), seeding (Erstbefüllung) oder following
caughtUp	true, wenn die gespeicherte Position der neuesten Position der Quelle entspricht. null, bevor die Erstbefüllung endet
checkedAt, syncedAt	Wann der Worker den Feed zuletzt gelesen hat und wann er zuletzt aufgeholt hat
copiedArtifacts, copiedBytes	Bisher kopierte Summen (copiedBytes ist eine Dezimalzeichenkette)
conflicts	Zurückgestellte Einträge der Quelle: count, oldestAt und bis zu 10 Einträge in sample. Siehe Zurückgestellte Einträge
errorCode, errorAt	Der letzte Fehler eines Schritts oder null

Fehlercodes

errorCode	Bedeutung und was zu tun ist
mirror_mismatch	Dieselbe Artefakt-ID hat auf der Quelle anderen Inhalt. Der Spiegel behält seine Datei. Untersuchen Sie das Artefakt; löschen Sie keine der beiden Kopien, bevor Sie die Ursache kennen
mirror_source_changed	Das Repository enthält bereits eine Kopie einer anderen Quelle. Trennen Sie es, oder spiegeln Sie die neue Quelle in ein neues Repository
mirror_source_behind	Die Quelle wurde wiederhergestellt oder neu installiert: Die Änderung an der Position des Spiegels ist nicht die, die er dort angewendet hat. Der Spiegel liest die Quelle erneut, und der Code verschwindet, wenn er aufgeholt hat. Dateien, die der wiederhergestellten Quelle fehlen, bleiben auf dem Spiegel
mirror_delete_blocked	Die Quelle hat eine Datei gelöscht, die der Spiegel nicht löschen kann, weil hier noch etwas sie verwendet, etwa eine Referenz oder ein Dateipfadverlauf
mirror_detached	Das Repository wurde getrennt und hat eigene Änderungen. Es wird nie wieder synchronisiert. Spiegeln Sie die Quelle in ein neues Repository
mirror_package_conflict	Eine Version der Quelle hat eine Paketversion, die dieses Repository mit anderen Bytes hält. Der Eintrag wird zurückgestellt und die Synchronisierung läuft weiter: siehe Zurückgestellte Einträge. Frühere Releases stoppten hier
mirror_id_taken	Ein Artefakt der Quelle wird von einem anderen Repository dieser Installation gehalten. Der Eintrag wird zurückgestellt, siehe Zurückgestellte Einträge; in einer Änderung von Image-Tags, Git-LFS-Objekten oder npm-Paketen stoppt er die Synchronisierung. Ein Quell-Repository kann hier nur ein Repository füllen
mirror_unreachable	Die Quelle ist nicht erreichbar: Die Verbindung wird abgelehnt oder läuft in eine Zeitüberschreitung, oder der Name wird nicht aufgelöst. Der Worker versucht es von selbst erneut. Prüfen Sie das Netzwerk, die Firewall und ob die Quelle läuft
mirror_certificate	Das Zertifikat der Quelle ist nicht vertrauenswürdig, abgelaufen oder passt nicht zu ihrem Namen. Fügen Sie seine Zertifizierungsstelle mit --mirror-ca-file hinzu (siehe HTTPS mit eigener Zertifizierungsstelle)
mirror_failed	Ein Fehler ohne spezifischeren Code. Lesen Sie das Worker-Log
andere Codes	Der Code der fehlgeschlagenen Anfrage: unauthorized, wenn die Quelle den Schlüssel nicht mehr akzeptiert (geben Sie dem Spiegel einen neuen), forbidden, wenn der Schlüssel das Repository nicht lesen darf, not_found, wenn das Quell-Repository nicht mehr existiert, capacity_exceeded, wenn der Spiegel voll ist

Das Worker-Log (component ist mirror) enthält mirror.started, mirror.step_failed mit errorCode und attempts, mirror.recovered und mirror.stopped.

Zurückgestellte Einträge

Manche Änderungen der Quelle lassen sich hier nicht anwenden, ohne den Bestand hier zu beschädigen. Der Worker stellt einen solchen Eintrag zurück und setzt die übrigen Änderungen fort, sodass eine Version nicht alle späteren aufhält. Nichts wird stillschweigend übersprungen: Jeder zurückgestellte Eintrag bleibt sichtbar, bis er aufgelöst ist.

Code	Bedeutung	Was zu tun ist
mirror_package_conflict	Die Version hat eine Paketversion (Gruppe, Name und Version), die dieses Repository mit anderen Bytes hält. Clients erhalten weiterhin die Version, die hier ist; die kopierte Datei bleibt ohne Paketregistrierung	Entfernen Sie die Stufe oder die Version auf der Quelle, oder veröffentlichen Sie sie unter einer anderen Version. Bei einem Import können Sie die Version auch hier löschen
mirror_id_taken	Ein anderes Repository dieser Installation hält die Artefakt-ID	Ein Quell-Repository füllt hier ein Repository. Trennen Sie den anderen Spiegel oder Import, oder löschen Sie die andere Kopie

• Der Worker versucht jeden Eintrag 10 Minuten nach seinem letzten Versuch erneut, bis zu 8 Einträge, wann immer er aufgeholt hat. Ein Eintrag wird entfernt, wenn er sich anwenden lässt oder die Quelle ihn nicht mehr hat: Die Version wurde dort gelöscht oder, bei einem Import, ihre Stufe entfernt.
• Der Status zeigt conflicts: wie viele Einträge zurückgestellt sind, wann der älteste zurückgestellt wurde, und bis zu 10 davon mit Artefakt-ID, Änderung (action und detail), Code, erstem und letztem Versuch und Anzahl der Versuche.
• Die Konsole zeigt die Anzahl unter Spiegel und unter dem Badge des Repositorys. Der Zustand bleibt, wie er ist, weil der Rest weiter synchronisiert wird.
• Das Worker-Log enthält mirror.conflict_set_aside (warning, mit artifactId, action, errorCode und attempts) für jeden fehlgeschlagenen Versuch und mirror.conflict_resolved, wenn ein Eintrag entfernt wird.
• Die Metrik arkvory_mirror_conflicts zählt sie, und die Regel ArkvoryMirrorConflicts warnt, wenn es 30 Minuten lang welche gibt.

Änderungen von Image-Tags und -Manifesten, Git-LFS-Objekten und npm-Paketen werden nie zurückgestellt: Ihre Reihenfolge zählt, und eine später angewendete Änderung könnte eine neuere rückgängig machen. Ein Konflikt darin stoppt die Synchronisierung mit seinem Code, bis er aufgelöst ist.

Spiegel überwachen

Die API der Spiegel-Installation stellt vier Metriken für jedes gespiegelte Repository bereit, mit den Labels repository und mode:

• arkvory_mirror_last_sync_timestamp_seconds: wann der Spiegel zuletzt aufgeholt hat.
• arkvory_mirror_last_check_timestamp_seconds: wann er zuletzt den Feed gelesen hat.
• arkvory_mirror_failing: 1, solange der letzte Versuch fehlgeschlagen ist; nicht, während der Spiegel eine wiederhergestellte Quelle erneut liest (mirror_source_behind).
• arkvory_mirror_conflicts: die Anzahl der zurückgestellten Einträge.

Die fertigen Prometheus-Regeln sind ArkvoryMirrorStale (länger als eine Stunde nicht aufgeholt, 15 Minuten lang) und ArkvoryMirrorFailing (der Fehler dauert 15 Minuten). Siehe Monitoring. Ein Spiegel, den der Worker noch nicht erreicht hat, hat keine Synchronisierungszeit, die Stale-Regel schlägt also vor seiner ersten Synchronisierung nicht an. ArkvoryMirrorConflicts warnt, wenn Einträge 30 Minuten lang zurückgestellt bleiben.

Import nach Stufe

Mit --mirror-stages ist das Repository auf der zweiten Installation kein Spiegel. Es ist ein gewöhnliches beschreibbares Repository, das die Versionen übernimmt, die eine der Stufen auf der Quelle tragen. Verwenden Sie es, um Builds von einem Entwicklungsserver auf einen Produktionsserver zu verschieben.

sudo arkvory configure --root /opt/proanima-arkvory \
  --mirror releases --mirror-upstream https://dev.example \
  --mirror-token-file /root/dev.key --mirror-stages release

• Sie listen 1 bis 16 verschiedene Stufennamen auf, durch Kommas getrennt.
• Eine Version wird einmal kopiert, mit derselben ID, denselben Bytes, Labels und derselben UPack-Registrierung sowie mit den passenden Stufen.
• Danach gehört sie dieser Installation. Änderungen, Stufenentfernung und Löschung auf der Quelle erreichen sie nicht. Eine Version, die Sie hier löschen, wird nie wieder importiert. Eine Stufe, die Sie hier entfernen, bleibt entfernt. Wenn die Quelle der Version später eine andere konfigurierte Stufe gibt, wird nur diese Stufe hinzugefügt.
• Uploads und die Speicherrichtlinie des Repositorys funktionieren wie gewohnt.
• Container-Image-, Git-LFS- und npm-Registry-Daten werden nicht übernommen.
• Eine Änderung der Stufen startet eine neue Erstbefüllung. Sie bringt nur Versionen, die noch nicht hier sind, und lässt die vorhandenen unverändert.
• Eine Version der Quelle, deren Paketversion dieses Repository bereits mit anderen Bytes hält, wird mit mirror_package_conflict zurückgestellt, und der Import fährt mit den nächsten Versionen fort. Clients erhalten weiterhin die Version, die hier ist. Siehe Zurückgestellte Einträge.

Zwei Installationen können voneinander importieren. Zum Beispiel übernimmt die Produktion release vom Staging, und das Staging übernimmt hotfix von der Produktion. Eine Version behält auf beiden Seiten ihre ID, daher wird nichts doppelt kopiert oder im Kreis geschickt:

• Eine auf dem Staging erstellte Version, die von der Produktion zurückkommt, erhält nur die neue Stufe.
• Eine auf einer Seite gelöschte Version wird nie wieder von der anderen importiert, auch wenn die andere Seite ihr später eine Stufe gibt.
• Eine Löschung wird nie weitergegeben: Die andere Seite behält ihre Kopie, bis Sie sie auch dort löschen.

Verwenden Sie für die beiden Richtungen unterschiedliche Stufen. Mit derselben Stufe in beiden Richtungen kehrt eine Stufe, die Sie auf einer Seite entfernen, zurück, wenn die andere Seite der Version die Stufe erneut gibt.

Die Konsole zeigt das Badge Import oder Import · Sync-Fehler, wenn der letzte Versuch fehlgeschlagen ist. Der Schlüssel auf der Quelle braucht dieselben schreibgeschützten Berechtigungen wie für einen Spiegel.

Umschalten, wenn die Quelle verloren geht

Dies ist ein manuelles Umschalten für zwei unabhängige Installationen an zwei Standorten. Es ist nicht automatisch. Änderungen, die der Spiegel noch nicht gezogen hat, gehen verloren.

Im Voraus vorbereiten

1. Installieren Sie den zweiten Standort nach Möglichkeit mit demselben Release wie die Quelle, mit eigenem PostgreSQL und eigenem Datenträger. Die beiden Standorte teilen nichts.
2. Erstellen Sie einen schreibgeschützten Schlüssel auf der Quelle und hängen Sie jedes Repository als Spiegel an. Ein später auf der Quelle erstelltes Repository erscheint nicht von selbst auf dem Spiegel, hängen Sie es also auf dieselbe Weise an.
3. Stellen Sie auf dem Spiegel die Schlüssel aus, die Ihre Konsumenten verwenden werden, einschließlich Schlüsseln, die nach dem Umschalten schreiben können. Die Berechtigungen der Quelle werden nicht übernommen, eine kompromittierte Quelle gewährt also keinen Zugriff auf den Spiegel.
4. Richten Sie die Konsumenten (CI, Deployment-Agents) mit der Adresse des Spiegels als Ausweichlösung für Downloads ein. Das entlastet auch die Verbindung zur Quelle.
5. Sichern Sie die Quelle in einen Backup-Speicher außerhalb ihres Standorts. Siehe Backups. Ein Spiegel ersetzt dies nicht.
6. Überwachen Sie den Spiegel mit den obigen Regeln.

Umschalten

1. Stellen Sie sicher, dass die Quelle für Clients wirklich nicht verfügbar ist und nicht von selbst zurückkehrt. Zwei Standorte, die beide Schreibzugriffe auf ein logisches Repository akzeptieren, können später nicht zusammengeführt werden. Wenn die Quelle teilweise erreichbar ist, stoppen Sie ihre Dienste oder schließen Sie ihren Port.

2. Lesen Sie auf dem Spiegel syncedAt jedes Repositorys. Änderungen auf der Quelle nach diesem Zeitpunkt sind nicht auf dem Spiegel.

3. Trennen Sie jedes gespiegelte Repository auf dem Spiegel. Es wird ein gewöhnliches beschreibbares Repository mit denselben Artefakt-IDs und allen seinen Daten.

   sudo arkvory configure --root /opt/proanima-arkvory --mirror-detach releases,prod

   Nennen Sie mehrere Repositorys durch Kommas getrennt, oder all für jeden Spiegel und jeden Import. Der Befehl startet die API und den Worker einmal neu, rechnen Sie also mit einer kurzen Unterbrechung.

4. Richten Sie die schreibenden Clients über DNS oder die Konfiguration Ihrer CI auf den Spiegel.

5. Laden Sie eine Kontrolldatei auf den Spiegel hoch und wieder herunter.

Was Clients sehen:

• Vor dem Umschalten funktionieren Downloads vom Spiegel, und Schreibzugriffe erhalten 409 mirror_read_only.
• Nach dem Trennen funktionieren Schreibzugriffe. Das Badge verschwindet.
• Die Schlüssel und Passwörter der Quelle funktionieren auf dem Spiegel nicht, es sei denn, Sie haben dort dieselben Konten erstellt.

Es gibt keinen Weg zurück. Ein getrenntes Repository kann nicht wieder als Spiegel angehängt werden: Seine Synchronisierung stoppt mit mirror_detached. Um die alte Quelle zurückzubringen, leeren Sie sie, oder installieren Sie sie neu und hängen Sie die Repositorys des neuen Primärsystems als Spiegel an. Betreiben Sie die alte Quelle und das neue Primärsystem niemals gleichzeitig mit aktivierten Schreibzugriffen.

Üben

Üben Sie das Umschalten jedes Quartal und nach Updates. Trennen Sie ein Repository auf einer Ersatzkopie, prüfen Sie syncedAt, einen Download und einen Upload und notieren Sie Datum und Ergebnis. Testen Sie die Wiederherstellung eines Backups der Quelle in eine leere Installation getrennt. Siehe Testen Sie eine Wiederherstellung regelmäßig.

Grenzen

• Ein Spiegel ist schreibgeschützt, bis Sie ihn trennen. Ein getrenntes Repository kann nicht wieder zu einem Spiegel werden.
• Der Spiegel ist kein Backup. Er hat keine Kopie von Konten, Schlüsseln oder Berechtigungen und kopiert keine Referenzen, Anhänge, Audit-Trails oder Speicherrichtlinien.
• Der Importmodus kopiert keine Container-Images, Git-LFS- oder npm-Daten.
• Eine neue Erstbefüllung fügt nur hinzu und aktualisiert: Nach einer Wiederherstellung der Quelle bleiben Dateien, die die Quelle verloren hat, auf dem Spiegel.
• Ein Quell-Repository füllt ein Repository einer Installation: Die Artefakt-IDs sind auf beiden Seiten gleich, daher wird ein zweiter Spiegel oder Import davon bei der Konfiguration abgelehnt. Aus demselben Grund müssen zwei Installationen, die voneinander importieren, auf beiden Seiten denselben Repository-Namen verwenden: Eine Version, die von der anderen Seite kam, kann hier nicht in ein anderes Repository übernommen werden, und sie wird mit mirror_id_taken zurückgestellt.
• Eine Version, deren Paketversion hier bereits mit anderen Bytes gehalten wird, wird kopiert und dann mit mirror_package_conflict zurückgestellt. Die Kopie bleibt ohne Paketregistrierung im Repository, bis Sie sie löschen.
• Ein zurückgestellter Eintrag ist hier nicht vorhanden, bis er aufgelöst ist. Ein Konflikt in einer Änderung von Image-Tags, Git-LFS-Objekten oder npm-Paketen stoppt die Synchronisierung weiterhin.
• Nach einer Wiederherstellung der Spiegel-Installation aus einem Backup können Versionen, die nach dem Erstellen des Backups importiert und gelöscht wurden, erneut importiert werden.
• Beide Installationen werden eigenständig aktualisiert. Die Quelle muss den Change-Feed für Spiegel anbieten.
• Der Satz vertrauenswürdiger Zertifizierungsstellen der Quelle gilt für den ganzen Worker.
• Es gibt kein automatisches Failover, kein Fencing der alten Quelle und keine Rücksynchronisierung.

Verwandte Seiten

• Backups
• Lese-Gateways
• Speicher
• Monitoring
• Umgebungsvariablen
• Konten und Zugriff