GitHub Enterprise Server auf AWS installieren

Zum Installieren von GitHub Enterprise Server in Amazon Web Services (AWS) musst du eine Amazon Elastic Compute Cloud-Instanz (EC2) starten und ein separates Amazon Elastic Block Store-Datenvolume (EBS) erstellen und anfügen.

In diesem Artikel

Voraussetzungen

In diesem Leitfaden wird davon ausgegangen, dass du mit den folgenden AWS-Konzepten vertraut bist:

Ein Diagramm, das eine Architekturübersicht bietet, findest du unter AWS-Architekturdiagramm für die Bereitstellung von GitHub Enterprise Server.

Dieser Leitfaden empfiehlt das Prinzip der geringsten Rechte beim Einrichten von Ihre GitHub Enterprise Server-Instance in AWS. Weitere Informationen findest du in der Dokumentation zu AWS Identity and Access Management (IAM).

Hardwareaspekte

Empfohlene Mindestanforderungen

Basierend auf der Anzahl der Benutzerlizenzen für Ihre GitHub Enterprise Server-Instance werden verschiedene Hardwarekonfigurationen empfohlen. Wenn Sie mehr Ressourcen bereitstellen als für die empfohlenen Mindestanforderungen erforderlich, werden dadurch die Leistung und die Skalierung Ihrer Instanz verbessert.

Benutzerlizenzenx86-64 vCPUsArbeitsspeicherStammspeicherAngefügter Speicher (Datenspeicher)
Test, Demo oder 10 Benutzer mit eingeschränkten Funktionen432 GB200 GB150 GB
10–3000848 GB200 GB300 GB
3000–50001264 GB200 GB500 GB
5000–80001696 GB200 GB750 GB
8000–10000+20160 GB200 GB1000 GB

Wenn GitHub Actions oder GitHub Advanced Security für die Benutzer Ihrer Instanz aktiviert werden soll, sind weitere Ressourcen erforderlich.

  • GitHub Actions – Erhöhen von sowohl CPU als auch Arbeitsspeicher um mindestens 25 %
  • GitHub Advanced Security – Erhöhen von sowohl CPU als auch Arbeitsspeicher um mindestens 25 %

Diese Anpassungen sollten auf die Basisanforderungen für jede Benutzerebene angewendet werden. Es wird empfohlen, alle Änderungen an deinen Ressourcen zu überwachen, da möglicherweise weitere Erhöhungen erforderlich sind.

Weitere Informationen zu diesen Anforderungen findest du unter Erste Schritte mit GitHub Actions für GitHub Enterprise Server.

Wenn Container registry für die Benutzer*innen deiner Instanz aktiviert werden soll, sind weitere Ressourcen erforderlich. Weitere Informationen zu diesen Anforderungen findest du unter Erste Schritte mit GitHub-Paketen für dein Unternehmen.

Weitere Informationen zum Anpassen von Ressourcen für eine vorhandene Instanz findest du unter Speicherkapazität erhöhen und CPU- und Arbeitsspeicherressourcen erhöhen.

Storage

Wir empfehlen ein Hochleistungs-SSD mit hoher Eingabe-/Ausgaberate pro Sekunde (IOPS) und niedriger Latenz für GitHub Enterprise Server. Workloads sind E/A-intensiv. Wenn du einen Bare-Metal-Hypervisor verwendest, empfehlen wir, den Datenträger direkt anzufügen oder einen Datenträger aus einem Storage Area Network (SAN) zu verwenden.

Deine Instanz erfordert einen beständigen Datenträger, der vom Stammdatenträger getrennt ist. Weitere Informationen findest du unter Systemübersicht.

Warning

Der Stammspeicher bezieht sich auf die Gesamtgröße des Stammdatenträgers deiner Instanz. Wenn die Instanz gestartet wird, sehen Sie, dass auf dem Stammdateisystem 100 GB sind auf dem Stammdateisystem verfügbar. Die verbleibenden 100 GB sind für Upgrades reserviert. Weitere Informationen findest du unter Systemübersicht.

Zum Konfigurieren von GitHub Actions musst du externen Blobspeicher bereitstellen. Weitere Informationen findest du unter Erste Schritte mit GitHub Actions für GitHub Enterprise Server.

Der verfügbare Speicherplatz im Stammdateisystem beträgt 50 % der Gesamtdatenträgergröße. Du kannst die Größe des Stammdatenträgers deiner Instanz ändern, indem du eine neue Instanz erstellst oder eine vorhandene Instanz verwendest. Weitere Informationen findest du unter Systemübersicht und unter Speicherkapazität erhöhen.

CPU und Arbeitsspeicher

Die für GitHub Enterprise Server erforderlichen CPU- und Arbeitsspeicherressourcen hängen vom Aktivitätsgrad für Benutzer, Automatisierungen und Integrationen ab.

Alle VMs, die du für Ihre GitHub Enterprise Server-Instance bereitstellst, müssen die x86-64-CPU-Architektur aufweisen. Andere Architekturen (z. B. AArch64 oder arm64) werden nicht unterstützt.

Wenn du beabsichtigst, GitHub Actions für die Benutzer deiner GitHub Enterprise Server-Instanz zu aktivieren, musst du möglicherweise zusätzliche CPU- und Arbeitsspeicherressourcen für deine Instanz bereitstellen. Weitere Informationen findest du unter Erste Schritte mit GitHub Actions für GitHub Enterprise Server.

Wenn Sie CPU-Ressourcen erhöhen, empfiehlt GitHub mindestens 6,5 GB Arbeitsspeicher für jede vCPU (bis zu 16 vCPUs) hinzuzufügen, die Sie für die Instance bereitstellen. Wenn du mehr als 16 vCPUs verwendest, musst du keine 6,5 GB Arbeitsspeicher für jede vCPU hinzufügen. Du solltest deine Instanz jedoch überwachen, um sicherzustellen, dass genügend Arbeitsspeicher vorhanden ist.

Warning

Benutzern wird empfohlen, Webhookereignisse so zu konfigurieren, dass externe Systeme über Aktivität auf GitHub Enterprise Server benachrichtigt werden. Automatisierte Überprüfungen auf Änderungen, oder auch Abrufe, wirken sich negativ auf die Leistung und Skalierbarkeit deiner Instanz aus. Weitere Informationen findest du unter Informationen zu Webhooks.

Weitere Informationen zum Überwachen der Kapazität und Leistung von GitHub Enterprise Server findest du unter Überwachen Ihrer Instanz.

Du kannst die CPU- oder Arbeitsspeicherressourcen deiner Instanz erhöhen. Weitere Informationen findest du unter CPU- und Arbeitsspeicherressourcen erhöhen.

Instanztyp bestimmen

Bevor du Ihre GitHub Enterprise Server-Instance in AWS startest, musst du den Computertyp ermitteln, der den Anforderungen deiner Organisation am besten entspricht. Informationen zu den empfohlenen Mindestanforderungen für GitHub Enterprise Server finden Sie unter „Empfohlene Mindestanforderungen“.

Sie können Ihre CPU oder Ihren Speicher jederzeit hochskalieren, indem Sie die Größe Ihrer Instance anpasst. Die Änderung der für Ihre Instance verfügbaren Ressourcen erfordert Downtime für Ihre Benutzer, daher empfiehlt GitHub eine Bereitstellung mit Ressourcen, um die Skalierung zu berücksichtigen.

GitHub empfiehlt eine speicheroptimierte Instanz für GitHub Enterprise Server. Weitere Informationen findest du unter Amazon EC2-Instanztypen auf der Amazon EC2-Website.

AMI für GitHub Enterprise Server auswählen

Mithilfe des GitHub Enterprise Server-Portals oder der AWS CLI kannst du ein Amazon Machine Image (AMI) für GitHub Enterprise Server auswählen.

AMIs für GitHub Enterprise Server sind in der AWS-Region „GovCloud“ („US-East“ und „US-West“) verfügbar. Dadurch können US-Kunden mit bestimmten gesetzlichen Anforderungen GitHub Enterprise Server in einer föderal konformen Cloud-Umgebung betreiben. Weitere Informationen zur Einhaltung von behördlichen und anderen Standards durch AWS findest du auf der AWS-Seite zur GovCloud (US) und auf der Complianceseite von AWS.

GitHub Enterprise Server-Portl zur AMI-Auswahl verwenden

  1. Navigiere zu dem Bild, das für die neue Instanz verwendet werden soll.

    • Navigiere zu Release notes (Versionshinweise).
    • Klicke in der rechten Seitenleiste auf die Version, die heruntergeladen werden soll.
    • Klicke auf GitHub Enterprise Server X.X.X herunterladen.

  2. Wähle unter „GitHub in der Cloud“ das Dropdownmenü „Plattform auswählen“ aus, und klicke auf Amazon Web Services.

  3. Klicke im Dropdownmenü „AWS-Region auswählen“ auf die gewünschte Region.

  4. Notiere dich die angezeigte AMI-ID.

AWS CLI zur AMI-Auswahl verwenden

  1. Rufe mithilfe der AWS CLI eine Liste der GitHub Enterprise Server-Images ab, die von den AWS-Inhaber-IDs (025577942450 für GovCloud und 895557238572 für andere Regionen) von GitHub veröffentlicht wurden. Weitere Informationen findest du in der AWS-Dokumentation unter describe-images.

    aws ec2 describe-images \
--owners OWNER_ID \
--query 'sort_by(Images,&Name)[*].{Name:Name,ImageID:ImageId}' \
--output=text

  2. Notiere dich die AMI-ID für das neueste GitHub Enterprise Server-Image.

Erstellen einer Sicherheitsgruppe

Bei der ersten AMI-Verwendung musst du eine Sicherheitsgruppe erstellen und für jeden in der folgenden Tabelle angegebenen Port eine neue Sicherheitsgruppenregel hinzufügen. Weitere Informationen findest du im AWS-Leitfaden zum Verwenden von Sicherheitsgruppen.

  1. Erstelle an der AWS CLI eine neue Sicherheitsgruppe. Weitere Informationen findest du in der AWS-Dokumentation unter create-security-group.

    aws ec2 create-security-group --group-name SECURITY_GROUP_NAME --description "SECURITY GROUP DESCRIPTION"

  2. Notiere dir die Sicherheitsgruppen-ID (sg-xxxxxxxx) deiner neu erstellten Sicherheitsgruppe.

  3. Erstelle eine Sicherheitsgruppenregel für jeden der Ports in der folgenden Tabelle. Es wird empfohlen, Netzwerkports basierend auf den Netzwerkdiensten, die du für Verwaltungs- und Benutzerzwecke verfügbar machen musst, selektiv zu öffnen. Weitere Informationen findest du in der AWS-Dokumentation unter Netzwerkports und unter authorize-security-group-ingress.

    aws ec2 authorize-security-group-ingress --group-id SECURITY_GROUP_ID --protocol PROTOCOL --port PORT_NUMBER --cidr SOURCE IP RANGE

    Diese Tabelle zeigt, wofür jeder Port verwendet wird.

    PortDienstBeschreibung
    22SSHGit über SSH-Zugriff. Unterstützt das Klonen, Abrufen und Übertragen von Vorgängen an öffentliche/private Repositorys.
    25SMTPSMTP mit Verschlüsselung (STARTTLS) wird unterstützt.
    80HTTPWebanwendungszugriff. Alle Anforderungen werden an den HTTPS-Port weitergeleitet, wenn SSL aktiviert ist.
    122SSHShellzugriff auf die Instanz. Der standardmäßige SSH-Port (22) ist für den Git- und SSH-Netzwerkdatenverkehr der Anwendung vorgesehen.
    161/UDPSNMPFür Netzwerküberwachungs-Protokollvorgänge erforderlich.
    443HTTPSWebanwendung und Git über HTTPS-Zugriff.
    1194/UDPVPNSicherer Replikationsnetzwerktunnel in einer hochverfügbaren Konfiguration. Verschlüsselt mit WireGuard.
    8080HTTPWebbasierte Verwaltungskonsole in Nur-Text. Nur erforderlich, wenn SSL manuell deaktiviert wird.
    8443HTTPSSichere webbasierte Verwaltungskonsole. Für die grundlegende Installation und Konfiguration erforderlich.
    9418GitEinfacher Git-Protokollport. Nur Klon- und Abrufvorgänge zu öffentlichen Repositorys. Unverschlüsselte Netzwerkkommunikation. Wenn du den privaten Modus in deiner Instanz aktiviert hast, ist das Öffnen dieses Ports nur erforderlich, wenn du auch anonymen Git-Lesezugriff aktiviert hast. Weitere Informationen findest du unter Erzwingen von Repositoryverwaltungsrichtlinien in einem Unternehmen.

GitHub Enterprise Server-Instanz erstellen

Zum Erstellen der Instanz musst du eine EC-Instanz mit deinem GitHub Enterprise Server-AMI starten und ein zusätzliches Storage-Volume für deine Instanzdaten anhängen. Weitere Informationen findest du unter Grundlegendes zur Hardware.

Note

Du kannst den Datenträger für mehr Sicherheit verschlüsseln und um zu gewährleisten, dass die Daten geschützt sind, die du in deine Instanz schreibst. Die Verwendung verschlüsselter Disks wirkt sich geringfügig auf die Leistung aus. Wenn du dein Volume verschlüsseln möchtest, wird dringend empfohlen, dies zu erledigen, bevor du deine Instanz erstmals startest. Weitere Informationen findest du im Amazon-Leitfaden zur EBS-Verschlüsselung.

Warning

Wenn du die Verschlüsselung nach dem Konfigurieren deiner Instanz aktivierst, musst du deine Daten zum verschlüsselten Volume migrieren, was Downtime für deine Benutzer zur Folge hat.

EC-Instanz starten

Starte an der AWS-CLI eine EC2-Instanz mit deinem AMI und der von dir erstellten Sicherheitsgruppe. Hänge ein neues Blockgerät an, das als ein Speicher-Volume für deine Instanzdaten verwendet werden soll, und konfiguriere die Größe anhand der Anzahl deiner Benutzerlizenzen. Weitere Informationen findest du in der AWS-Dokumentation unter run-instances.

aws ec2 run-instances \
  --security-group-ids SECURITY_GROUP_ID \
  --instance-type INSTANCE_TYPE \
  --image-id AMI_ID \
  --block-device-mappings '[{"DeviceName":"/dev/xvdf","Ebs":{"VolumeSize":SIZE,"VolumeType":"TYPE"}}]' \
  --region REGION \
  --ebs-optimized

Elastic IP zuordnen und mit der Instanz verknüpfen

Wenn es sich hierbei um eine Produktionsinstanz handelt, wird dringend empfohlen, eine Elastic IP (EIP) zuzuordnen und sie mit der Instanz zu verknüpfen, bevor du zur GitHub Enterprise Server-Konfiguration weitergehst. Andernfalls wird die öffentliche IP-Adresse der Instanz nach dem Neustart der Instanz nicht beibehalten. Weitere Informationen findest du in der Amazon-Dokumentation unter Zuordnen einer elastischen IP-Adresse und unter Zuordnen einer elastischen IP-Adresse zu einer ausgeführten Instanz.

Den primären und Replikatinstanzen sollten in Hochverfügbarkeitskonfigurationen in der Produktion separate EIPs zugewiesen werden. Weitere Informationen findest du unter Konfigurieren von Hochverfügbarkeit.

GitHub Enterprise Server-Instanz konfigurieren

Zum Konfigurieren der Instanz musst du eine Lizenzdatei hochladen, das Stammkennwort für die Verwaltungskonsole festlegen, die Einstellungen der Instanz konfigurieren und die Instanz neu starten.

Warning

Um zu verhindern, dass ein Angreifer die neue Instanz gefährdet, lege unbedingt persönlich das Stammkennwort für die Verwaltungskonsole fest, und erstelle den ersten Benutzer so schnell wie möglich.

  1. Kopiere den Namen des öffentlichen DNS der virtuellen Maschine, und füge ihn in einen Webbrowser ein.
  2. Lade an der Eingabeaufforderung Deine Lizenzdatei hoch, und lege das Passwort für die Managementkonsole fest. Weitere Informationen findest du unter Verwalten deiner Lizenz für GitHub Enterprise.
  3. Konfiguriere und speichere deine gewünschten Einstellungen in der Verwaltungskonsole. Weitere Informationen findest du unter Konfigurieren von GitHub Enterprise.
  4. Die Instanz wird automatisch neu gestartet.
  5. Klicke auf Instanz aufrufen.

Weiterführende Themen