Informationen zu Staginginstanzen
GitHub empfiehlt, dass du eine separate Umgebung zum Testen von Sicherungen, Updates oder Änderungen an der Konfiguration für Ihre GitHub Enterprise Server-Instance einrichtest. Diese Umgebung, die du von deinen Produktionssystemen isolieren solltest, wird als „Stagingumgebung“ bezeichnet.
Beispielsweise kannst du zum Schutz vor Datenverlust die Sicherung deiner Produktionsinstanz regelmäßig überprüfen. Du kannst die Sicherung deiner Produktionsdaten in einer separaten GitHub Enterprise Server-Instanz in einer Stagingumgebung regelmäßig wiederherstellen. In dieser Staginginstanz könntest du auch das Upgrade auf das neueste Featurerelease von GitHub Enterprise Server testen.
Tipp: Du kannst deine vorhandene GitHub Enterprise-Lizenzdatei wiederverwenden, solange die Staginginstanz nicht in einer Produktionskapazität verwendet wird.
Überlegungen zu einer Stagingumgebung
Wenn du GitHub Enterprise Server gründlich testen und eine Umgebung neu erstellen möchtest, die deiner Produktionsumgebung möglichst ähnlich ist, berücksichtige die externen Systeme, die mit deiner Instanz interagieren. Du kannst beispielsweise in deiner Stagingumgebung Folgendes testen.
- Authentifizierung – insbesondere, wenn du einen externen Authentifizierungsanbieter wie SAML verwendest
- Integration in ein externes Ticketsystem,
- Integration in einen CI-Server,
- Externe Skripts oder Software, die die GitHub Enterprise Server APIs verwenden
- externer SMTP-Server für E-Mail-Benachrichtigungen.
Testinstanz einrichten
Du kannst eine Staginginstanz neu einrichten und so konfigurieren, wie du möchtest. Weitere Informationen findest du unter GitHub Enterprise Server-Instanz einrichten und unter Konfigurieren von GitHub Enterprise.
Alternativ kannst du eine Staginginstanz erstellen, die deine Produktionskonfiguration widerspiegelt, indem du eine Sicherung deiner Produktionsinstanz in die Staginginstanz wiederherstellst.
- Sichere deine Produktionsinstanz.
- Richte eine Staginginstanz ein.
- Konfiguriere GitHub Actions.
- Konfiguriere GitHub Packages.
- Stelle deine Produktionssicherung wieder her.
- Überprüfe die Konfiguration der Instanz.
- Wende die Konfiguration der Instanz an.
1. Sichern deiner Produktionsinstanz
Wenn du Änderungen an einer Instanz testen möchtest, die dieselbe Daten und Konfiguration wie deine Produktionsinstanz enthält, sichere die Daten und die Konfiguration aus der Produktionsinstanz mithilfe von GitHub Enterprise Server Backup Utilities. Weitere Informationen findest du unter Konfigurieren von Sicherungen auf einer Instanz.
Warnung: Wenn du GitHub Actions oder GitHub Packages in der Produktion verwendest, enthält deine Sicherung deine Produktionskonfiguration für den externen Speicher. Um potenziellen Datenverlust durch Schreiben in deinen Produktionsspeicher von deiner Staginginstanz zu vermeiden, musst du jedes Feature in den Schritten 3 und 4 konfigurieren, bevor du deine Sicherung wiederherstellst.
2. Einrichten einer Staginginstanz
Richte eine neue Instanz ein, die als deine Staging-Umgebung fungiert. Du kannst dieselben Leitfäden zum Bereitstellen und Installieren deiner Testinstanz verwendest, die du für deine Produktionsinstanz verwendest. Weitere Informationen findest du unter GitHub Enterprise Server-Instanz einrichten.
Wenn du eine Sicherung deiner Produktionsinstanz wiederherstellen möchtest, fahre mit dem nächsten Schritt fort. Alternativ kannst du die Instanz manuell konfigurieren und die folgenden Schritte überspringen.
3. Konfigurieren von GitHub Actions
Wenn du GitHub Actions auf deiner Produktionsinstanz verwendest, konfiguriere optional das Feature auf der Staginginstanz vor dem Wiederherstellen deiner Produktionssicherung. Wenn du GitHub Actions nicht verwendest, fahre mit 1. Konfigurieren von GitHub Packages fort.
Warnung: Wenn du GitHub Actions auf der Staginginstanz vor dem Wiederherstellen deiner Produktionssicherung nicht konfigurierst, verwendet deine Staginginstanz den externen Speicher deiner Produktionsinstanz. Dies kann zu Datenverlust führen. Es wird dringend empfohlen, einen anderen externen Speicher für deine Staginginstanz zu verwenden. Weitere Informationen findest du unter Verwenden einer Stagingumgebung.
-
Melde dich über SSH bei der Staginginstanz an. Weitere Informationen findest du unter Auf die Verwaltungsshell (SSH) zugreifen.
Shell ssh -p 122 admin@HOSTNAME
ssh -p 122 admin@HOSTNAME
-
Um die Staginginstanz zum Verwenden eines externen Speicheranbieters für GitHub Actions zu konfigurieren, gib einen der folgenden Befehlen ein.
-
Azure Blob Storage:
Shell ghe-config secrets.actions.storage.blob-provider "azure"
ghe-config secrets.actions.storage.blob-provider "azure"
-
Amazon S3:
Shell ghe-config secrets.actions.storage.blob-provider "s3"
ghe-config secrets.actions.storage.blob-provider "s3"
-
Google Cloud Storage:
Shell ghe-config secrets.actions.storage.blob-provider "gcs"
ghe-config secrets.actions.storage.blob-provider "gcs"
-
-
Konfiguriere die Verbindung mit dem externen Speicher, indem du die folgenden Befehle eingibst und dabei die Platzhalterwerte durch die tatsächlichen Werte für deine Verbindung ersetzt.
-
Azure Blob Storage:
Shell ghe-config secrets.actions.storage.azure.connection-string "CONNECTION STRING"
ghe-config secrets.actions.storage.azure.connection-string "CONNECTION STRING"
-
Amazon S3:
Shell ghe-config secrets.actions.storage.s3.bucket-name "S3 BUCKET NAME" ghe-config secrets.actions.storage.s3.service-url "S3 SERVICE URL" ghe-config secrets.actions.storage.s3.access-key-id "S3 ACCESS KEY ID" ghe-config secrets.actions.storage.s3.access-secret "S3 ACCESS SECRET"
ghe-config secrets.actions.storage.s3.bucket-name "S3 BUCKET NAME" ghe-config secrets.actions.storage.s3.service-url "S3 SERVICE URL" ghe-config secrets.actions.storage.s3.access-key-id "S3 ACCESS KEY ID" ghe-config secrets.actions.storage.s3.access-secret "S3 ACCESS SECRET"
Optional kannst du auch den folgenden Befehl eingeben, um die Adressierung von S3 im Pfadformat zu erzwingen.
Shell ghe-config secrets.actions.storage.s3.force-path-style true
ghe-config secrets.actions.storage.s3.force-path-style true
-
Google Cloud Storage:
Shell ghe-config secrets.actions.storage.gcs.service-url "SERVICE URL" ghe-config secrets.actions.storage.gcs.bucket-name "BUCKET NAME" ghe-config secrets.actions.storage.gcs.access-key-id "HMAC ACCESS ID" ghe-config secrets.actions.storage.gcs.access-secret "HMAC SECRET"
ghe-config secrets.actions.storage.gcs.service-url "SERVICE URL" ghe-config secrets.actions.storage.gcs.bucket-name "BUCKET NAME" ghe-config secrets.actions.storage.gcs.access-key-id "HMAC ACCESS ID" ghe-config secrets.actions.storage.gcs.access-secret "HMAC SECRET"
-
-
Gib den folgenden Befehl zum Vorbereiten auf das Aktivieren von GitHub Actions auf der Staginginstanz ein.
Shell ghe-config app.actions.enabled true
ghe-config app.actions.enabled true
4. Konfigurieren von GitHub Packages
Wenn du GitHub Packages auf deiner Produktionsinstanz verwendest, konfiguriere optional das Feature auf der Staginginstanz vor dem Wiederherstellen deiner Produktionssicherung. Wenn du GitHub Packages nicht verwendest, fahre mit 1. Wiederherstellen deiner Produktionssicherung fort.
Warnung: Wenn du GitHub Packages auf der Staginginstanz vor dem Wiederherstellen deiner Produktionssicherung nicht konfigurierst, verwendet deine Staginginstanz den externen Speicher deiner Produktionsinstanz. Dies kann zu Datenverlust führen. Es wird dringend empfohlen, einen anderen externen Speicher für deine Staginginstanz zu verwenden.
-
Überprüfe die Sicherung, die du in der Staginginstanz wiederherstellst.
- Wenn du die Sicherung mit GitHub Enterprise Server Backup Utilities 3.5 oder höher durchgeführt hast, enthält sie die Konfiguration für GitHub Packages. Fahre mit dem nächsten Schritt fort.
- Wenn du die Sicherung mit GitHub Enterprise Server Backup Utilities 3.4 oder früher durchgeführt hast, konfiguriere GitHub Packages auf der Staginginstanz. Weitere Informationen findest du unter Erste Schritte mit GitHub-Paketen für dein Unternehmen.
-
Melde dich über SSH bei der Staginginstanz an. Weitere Informationen findest du unter Auf die Verwaltungsshell (SSH) zugreifen.
Shell ssh -p 122 admin@HOSTNAME
ssh -p 122 admin@HOSTNAME
-
Konfiguriere die externe Speicherverbindung, indem du die folgenden Befehle eingibst und die Platzhalterwerte durch tatsächliche Werte für deine Verbindung ersetzt.
-
Azure Blob Storage:
Shell ghe-config secrets.packages.blob-storage-type "azure" ghe-config secrets.packages.azure-container-name "AZURE CONTAINER NAME" ghe-config secrets.packages.azure-connection-string "CONNECTION STRING"
ghe-config secrets.packages.blob-storage-type "azure" ghe-config secrets.packages.azure-container-name "AZURE CONTAINER NAME" ghe-config secrets.packages.azure-connection-string "CONNECTION STRING"
-
Amazon S3:
Shell ghe-config secrets.packages.blob-storage-type "s3" ghe-config secrets.packages.service-url "S3 SERVICE URL" ghe-config secrets.packages.s3-bucket "S3 BUCKET NAME" ghe-config secrets.packages.aws-access-key "S3 ACCESS KEY ID" ghe-config secrets.packages.aws-secret-key "S3 ACCESS SECRET"
ghe-config secrets.packages.blob-storage-type "s3" ghe-config secrets.packages.service-url "S3 SERVICE URL" ghe-config secrets.packages.s3-bucket "S3 BUCKET NAME" ghe-config secrets.packages.aws-access-key "S3 ACCESS KEY ID" ghe-config secrets.packages.aws-secret-key "S3 ACCESS SECRET"
-
-
Gib den folgenden Befehl zum Vorbereiten auf das Aktivieren von GitHub Packages auf der Staginginstanz ein.
Shell ghe-config app.packages.enabled true
ghe-config app.packages.enabled true
5. Wiederherstellen deiner Produktionssicherung
Verwende den Befehl ghe-restore
, um die restlichen Daten aus der Sicherung wiederherzustellen. Weitere Informationen findest du unter Konfigurieren von Sicherungen auf einer Instanz.
Wenn die Staginginstanz bereits konfiguriert ist und du Einstellungs-, Zertifikats- und Lizenzdaten überschreiben möchtest, füge dem Befehl die Option -c
hinzu. Weitere Informationen zu dieser Option findest du unter Verwenden der Sicherung und Wiederherstellen von Befehlen in der Dokumentation zu GitHub Enterprise Server Backup Utilities.
6. Überprüfen der Konfiguration der Instanz
Um mithilfe desselben Hostnamen auf die Staginginstanz zuzugreifen, aktualisiere deine lokale Hostdatei, um den Hostnamen der Staginginstanz nach IP-Adresse aufzulösen. Bearbeite dazu die Datei /etc/hosts
in macOS oder Linux oder die Datei C:\Windows\system32\drivers\etc
in Windows.
Hinweis: Zugriff auf deine Staginginstanz muss von demselben Hostnamen möglich sein wie auch auf deine Produktionsinstanz. Das Ändern des Hostnamens für Ihre GitHub Enterprise Server-Instance wird nicht unterstützt. Weitere Informationen findest du unter Konfigurieren des Hostnamens für deine Instanz.
Überprüfe dann die Konfiguration der Staginginstanz auf der Verwaltungskonsole. Weitere Informationen findest du unter Verwalten Ihrer Instanz über die Web-Benutzeroberfläche.
Warnung: Wenn du GitHub Actions oder GitHub Packages für die Staginginstanz konfiguriert hast, stelle sicher, dass die Konfiguration für den externen Speicher in der Verwaltungskonsole nicht mit deiner Produktionsinstanz übereinstimmt, sodass das Überschreiben von Produktionsdaten vermieden wird.
7. Anwenden der Konfiguration der Instanz
Zum Anwenden der Konfiguration aus der Verwaltungskonsole, klicke auf Einstellungen speichern.
Staginginstanz wieder online schalten
Sie können eine Staginginstanz ausschalten, um Kosten zu sparen, und sie bei Bedarf wieder einschalten.
Eine Instanz kann 7 Tage offline bleiben.
Wenn Sie die Instanz innerhalb des zulässigen Offlinezeitraums wieder online schalten, wird GitHub Enterprise Server erfolgreich instanziiert. Wenn die Instanz länger als der zulässige Zeitraum offline bleibt, wird GitHub Enterprise Server nicht erfolgreich instanziiert, und in den Systemprotokollen wird möglicherweise eine Fehlermeldung mit dem Text server has been offline for more than the configured server_rejoin_age_max
aufgeführt. Weitere Informationen finden Sie unter Informationen zu Systemprotokollen.
Wenn die Instanz im Fehlerzustand hängen bleibt, können Sie sie durch Ausführung dieser Befehle wiederherstellen.
sudo mv /data/user/consul/server_metadata.json /data/user/consul/server_metadata.json.bak
ghe-config-apply