Überprüfen der Integrität von GitHub Actions
Du kannst die Integrität von GitHub Actions auf Ihre GitHub Enterprise Server-Instance mit dem Befehlszeilen-Hilfsprogramm ghe-actions-check
überprüfen. Weitere Informationen findest du unter Befehlszeilenprogramme und unter Auf die Verwaltungsshell (SSH) zugreifen.
Konfigurieren von selbstgehosteten Runnern bei Verwendung eines selbstsignierten Zertifikats für GitHub Enterprise Server
Es wird dringend empfohlen, TLS für GitHub Enterprise Server mit einem Zertifikat zu konfigurieren, das von einem vertrauenswürdigen Aussteller signiert ist. Ein selbst signiertes Zertifikat kann zwar funktionieren, erfordert jedoch zusätzliche Konfiguration für deine selbstgehosteten Runner und wird für Produktionsumgebungen nicht empfohlen. Weitere Informationen findest du unter TLS konfigurieren.
Installieren des Zertifikats auf dem Runnercomputer
Damit ein selbstgehosteter Runner mithilfe eines selbstsignierten Zertifikats eine Verbindung mit einem GitHub Enterprise Server herstellen kann, musst du das Zertifikat auf dem Runnercomputer installieren, damit die Verbindung gehärtet ist.
Die zur Installation eines Zertifikats erforderlichen Schritte findest du in der Dokumentation für das Betriebssystem des Runners.
Konfigurieren von Node.js für die Verwendung des Zertifikats
Die meisten Aktionen werden in JavaScript geschrieben und mithilfe von Node.js ausgeführt, wobei Node.js nicht den Zertifikatspeicher des Betriebssystems verwendet. Damit die selbstgehostete Runneranwendung das Zertifikat verwendet, musst du die Umgebungsvariable NODE_EXTRA_CA_CERTS
auf dem Runnercomputer festlegen.
Sie können die Umgebungsvariable als Systemumgebungsvariable festlegen oder sie in einer Datei namens .env
im selbstgehosteten Runner-Anwendungsverzeichnis deklarieren (d. h. dem Verzeichnis, in das Sie die Runner-Software heruntergeladen und entpackt haben).
Zum Beispiel:
NODE_EXTRA_CA_CERTS=/usr/share/ca-certificates/extra/mycertfile.crt
Umgebungsvariablen werden gelesen, wenn die selbstgehostete Runneranwendung gestartet wird. Daher musst du die Umgebungsvariable festlegen, bevor du die Runneranwendung konfigurierst oder startest. Wenn sich deine Zertifikatkonfiguration ändert, musst du die selbstgehostete Runneranwendung neu starten.
Konfigurieren von Docker-Containern für die Verwendung des Zertifikats
Wenn du Docker-Containeraktionen oder Dienstcontainer in deinen Workflows verwendest, musst du das Zertifikat möglicherweise auch in deinem Docker-Image installieren und zusätzlich die oben genannte Umgebungsvariable festlegen.
Konfigurieren von HTTP-Proxyeinstellungen für GitHub Actions
Wenn du einen HTTP-Proxyserver auf Ihre GitHub Enterprise Server-Instance konfiguriert hast:
- Sie müssen
.localhost
,127.0.0.1
und::1
zu der HTTP-Proxy-Ausschlussliste hinzufügen (in dieser Reihenfolge). - Wenn dein externer Speicherort nicht routingfähig ist, musst du der Ausschlussliste auch die URL zu deinem externen Speicher hinzufügen.
Weitere Informationen zum Ändern deiner Proxyeinstellungen findest du unter Konfigurieren eines ausgehenden Webproxyservers.
Wenn diese Einstellungen nicht ordnungsgemäß konfiguriert sind, erhältst du möglicherweise Fehler, z. B. Resource unexpectedly moved to https://IP-ADDRESS
beim Festlegen oder Ändern deiner GitHub Actions-Konfiguration.
Runner, die keine Verbindung zu GitHub Enterprise Server mit einem neuen Hostnamen herstellen
Warnung: Ändere den Hostnamen für GitHub Enterprise Server nach der Ersteinrichtung nicht mehr. Das Ändern des Hostnamens wird zu unerwartetem Verhalten führen, bis hin zu Instanzausfällen und der Ungültigkeit der Sicherheitsschlüssel der Benutzer. Wenn Sie den Hostnamen für Ihre Instanz geändert haben und Probleme auftreten, wenden Sie sich an GitHub Enterprise Support oder GitHub Premium-Support.
Wenn du GitHub Enterprise Server in deiner Umgebung mit einem neuen Hostnamen bereitstellst und der alte Hostname nicht mehr zu deiner Instanz aufgelöst wird, können selbstgehostete Runner keine Verbindung mit dem alten Hostnamen herstellen und keine Aufträge ausführen.
Du musst die Konfiguration deiner selbstgehosteten Runner auf den neuen Hostnamen für Ihre GitHub Enterprise Server-Instance aktualisieren. Jeder selbstgehostete Runner erfordert eine der folgenden Vorgehensweisen:
- Bearbeite im Verzeichnis der selbstgehosteten Anwendung die
.runner
- und.credentials
-Dateien, und ersetze alle Erwähnungen des alten Hostnamens durch den neuen. Starte anschließend die selbstgehostete Runneranwendung neu. - Entferne den Runner über die Benutzeroberfläche aus GitHub Enterprise Server, und füge ihn erneut hinzu. Weitere Informationen findest du unter Selbst-gehostete Runner entfernen und unter Selbst-gehostete Runner hinzufügen.
Nicht mehr reagierende Aufträge und Grenzwerte für GitHub Actions -Arbeitsspeicher und -CPU
GitHub Actions bestehen aus einer Vielzahl von Diensten, die auf Ihre GitHub Enterprise Server-Instance ausgeführt werden. Standardmäßig sind diese Dienste mit Standardgrenzwerten für CPU und Arbeitsspeicher konfiguriert, die für die meisten Instanzen funktionieren sollten. Wenn die Nutzung von GitHub Actions in deinem Unternehmen jedoch überdurchschnittlich hoch ausfällt, musst du diese Einstellungen möglicherweise anpassen.
Wenn du feststellst, dass Aufträge nicht gestartet werden (obwohl Runner im Leerlauf vorhanden sind), oder wenn der Fortschritt des Auftrags nicht aktualisiert bzw. nicht in der Benutzeroberfläche geändert wird, kann dies daran liegen, dass die CPU- oder Arbeitsspeichergrenzwerte erreicht sind.
1. Überprüfen der Gesamtauslastung von CPU und Arbeitsspeicher in der Verwaltungskonsole
Öffne auf die Verwaltungskonsole, und überprüfe die Diagramme zur Gesamtauslastung von CPU und Arbeitsspeicher im Überwachungsdashboard unter „Systemintegrität“. Weitere Informationen findest du unter Auf das Überwachungs-Dashboard zugreifen.
Wenn die allgemeine CPU-Gesamtauslastung „Systemintegrität“ bei nahezu 100 Prozent liegt oder kein freier Arbeitsspeicher übrig ist, wird Ihre GitHub Enterprise Server-Instance bei voller Kapazität ausgeführt und muss hochskaliert werden. Weitere Informationen findest du unter CPU- und Arbeitsspeicherressourcen erhöhen.
2. Überprüfen der CPU- und Arbeitsspeicherauslastung von Nomad-Aufträgen in der Verwaltungskonsole
Wenn die Gesamtauslastung von CPU und Arbeitsspeicher unter „Systemintegrität“ im annehmbaren Bereich liegt, scrolle im Überwachungsdashboard nach unten zum Abschnitt „Nomad-Aufträge“, und sieh dir die Diagramme „CPU-Prozentwert“ und „Arbeitsspeichernutzung“ an.
Jeder Plot in diesen Diagrammen entspricht einem Dienst. Suche für GitHub Actions -Dienste nach:
mps_frontend
mps_backend
token_frontend
token_backend
actions_frontend
actions_backend
Wenn einer dieser Dienste bei oder in der Nähe einer 100%igen CPU-Auslastung liegt oder der Speicher seinen Grenzwert fast erreicht hat (standardmäßig 2 GB), muss die Ressourcenzuordnung für diese Dienste möglicherweise erhöht werden. Notieren dir, welche der oben genannten Dienste ihren Grenzwert erreicht oder fast erreicht haben.
3. Erhöhen der Ressourcenzuordnung für Dienste, die ihre Grenzwerte erreicht haben
-
Melde dich mit SSH bei der Verwaltungsshell an. Weitere Informationen findest du unter Auf die Verwaltungsshell (SSH) zugreifen.
-
Führe den folgenden Befehl aus, um zu sehen, welche Ressourcen für die Zuordnung verfügbar sind:
nomad node status -self
Suche in der Ausgabe den Abschnitt „Allocated Resources“ (Zugeordnete Ressourcen). Er sieht etwa folgendermaßen aus:
Allocated Resources CPU Memory Disk 7740/49600 MHZ 23 GiB/32 GiB 4.4 GiB/7.9 GiB
Die Ausgabe zeigt, wie viel CPU und Arbeitsspeicher der Gesamtsumme aller Dienste zugeordnet bzw. belegt sind (linker Wert) und wie viel CPU und Arbeitsspeicher verfügbar ist (rechter Wert). Im obigen Beispiel sind 23 GiB von insgesamt 32 GiB Arbeitsspeicher bereits belegt. Dies bedeutet, dass 9 GiB Arbeitsspeicher noch belegt werden können.
Warnung: Achte darauf, nicht mehr als die verfügbaren Ressourcen zuzuordnen. Andernfalls können Dienste nicht mehr gestartet werden.
-
Wechsle in das Verzeichnis
/etc/consul-templates/etc/nomad-jobs/actions
:cd /etc/consul-templates/etc/nomad-jobs/actions
In diesem Verzeichnis gibt es drei Dateien, die zu den GitHub Actions -Diensten von oben gehören:
mps.hcl.ctmpl
token.hcl.ctmpl
actions.hcl.ctmpl
-
Öffne für die Dienste, für die du einen Anpassungsbedarf ermittelt hast, die entsprechende Datei, und suche die
resources
-Gruppe, die wie folgt aussieht:resources { cpu = 512 memory = 2048 network { port "http" { } } }
Die Werte sind für CPU-Ressourcen in MHz und für Arbeitsspeicherressourcen MB angegeben.
Um beispielsweise die Ressourcengrenzwerte im obigen Beispiel für die CPU auf 1 GHz und für den Arbeitsspeicher 4 GB zu erhöhen, musst du die Gruppe wie folgt ändern:
resources { cpu = 1024 memory = 4096 network { port "http" { } } }
-
Speicher und beende die Datei.
-
Führe
ghe-config-apply
aus, um die Änderung zu übernehmen.Wenn bei der Ausführung von
ghe-config-apply
eine Ausgabe wieFailed to run nomad job '/etc/nomad-jobs/<name>.hcl'
angezeigt wird, wurden CPU- oder Arbeitsspeicherressourcen durch die Änderung wahrscheinlich überbelegt. Wenn dies der Fall ist, bearbeite die Konfigurationsdateien erneut, und senke die CPU- oder Arbeitsspeicherbelegung herab. Führeghe-config-apply
anschließend erneut aus. -
Führe nach der Übernahme der Konfiguration
ghe-actions-check
aus, um zu überprüfen, ob die GitHub Actions -Dienste funktionsfähig sind.
Problembehandlung von Fehlern, wenn Dependabot bestehende Workflows auslöst
Nachdem du Dependabot für Ihre GitHub Enterprise Server-Instance eingerichtet hast, können Fehler angezeigt werden, wenn bestehende Workflows durch Dependabot-Ereignisse ausgelöst werden.
Standardmäßig werden Ausführungen von GitHub Actions-Workflows, die von Dependabot aufgrund von push
-, pull_request
-, pull_request_review
- oder pull_request_review_comment
-Ereignissen ausgelöst wurden, so behandelt, als wären sie in einem Repositoryfork geöffnet worden. Im Gegensatz zu Workflows, die von anderen Akteuren ausgelöst werden, erhalten sie ein schreibgeschütztes GitHub-Token (GITHUB_TOKEN
) und verfügen nicht über Zugriff auf Geheimnisse, die normalerweise verfügbar sind. Dies führt dazu, dass alle Workflows, die versuchen, in das Repository zu schreiben, fehlschlagen, wenn sie von Dependabot ausgelöst wurden.
Es gibt drei Möglichkeiten, dieses Problem zu beheben:
- Du kannst deine Workflows mit einem Ausdruck wie
if: github.actor != 'dependabot[bot]'
so aktualisieren, dass sie nicht mehr durch Dependabot ausgelöst werden. Weitere Informationen findest du unter Ausdrücke. - Du kannst deine Workflows so ändern, dass sie einen zweistufigen Prozess mit
pull_request_target
verwenden, das nicht diesen Einschränkungen unterliegt. Weitere Informationen findest du unter Automatisieren von Dependabot mit GitHub Actions. - Du kannst Workflows bereitstellen, die durch den Dependabot-Zugriff auf Geheimnisse ausgelöst werden, und es dem Term
permissions
erlauben, den Standardbereich vonGITHUB_TOKEN
zu erhöhen. Weitere Informationen sind im Abschnitt „Bereitstellen von Workflows, die durch den Dependabot-Zugriff auf Geheimnisse und erhöhte Berechtigungen ausgelöst werden“ zu finden.
Bereitstellen von Workflows, die durch den Dependabot-Zugriff auf Geheimnisse und erhöhte Berechtigungen ausgelöst werden
-
Melde dich mit SSH bei der Verwaltungsshell an. Weitere Informationen findest du unter Auf die Verwaltungsshell (SSH) zugreifen.
-
Um die Einschränkungen für Workflows aufzuheben, die von Dependabot für Ihre GitHub Enterprise Server-Instance ausgelöst werden, führe den folgenden Befehl aus.
ghe-config app.actions.disable-dependabot-enforcement true
-
Wende die Konfiguration an.
ghe-config-apply
-
Kehre zu GitHub Enterprise Server zurück.
Problembehandlung gebündelter Aktionen in GitHub Actions
Wenn beim Installieren von GitHub Actions in GitHub Enterprise Server der folgende Fehler zurückgegeben wird, kannst du das Problem beheben, indem du die offiziellen gebündelten Aktionen und Startworkflows installierst.
A part of the Actions setup had problems and needs an administrator to resolve.
Um die offiziellen gebündelten Aktionen und Startworkflows in einer bestimmten Organisation in GitHub Enterprise Server zu installieren, gehe wie folgt vor:
-
Ermittle eine Organisation, in der die offiziellen gebündelten Aktionen und Startworkflows gespeichert werden sollen. Du kannst eine neue Organisation erstellen oder eine vorhandene verwenden.
- Informationen zum Erstellen einer neuen Organisation findest du unter Eine neue Organisation von Grund auf erstellen.
- Unterstützung beim Auswählen eines Namens für diese Organisation findest du unter Erste Schritte mit GitHub Actions für GitHub Enterprise Server.
-
Melde dich mit SSH bei der Verwaltungsshell an. Weitere Informationen findest du unter Auf die Verwaltungsshell (SSH) zugreifen.
-
Um deine Organisation als Speicherort für gebündelte Aktionen festzulegen, verwende den Befehl
ghe-config
aus, indem duORGANIZATION
durch den Namen deiner Organisation ersetzt.ghe-config app.actions.actions-org ORGANIZATION
und:
ghe-config app.actions.github-org ORGANIZATION
-
Um die gebündelten Aktionen zu deiner Organisation hinzuzufügen, lösche den SHA-Wert.
ghe-config --unset 'app.actions.actions-repos-sha1sum'
-
Wende die Konfiguration an.
ghe-config-apply
Nachdem du diese Schritte ausgeführt hast, kannst du die Konfiguration von GitHub Actions unter Erste Schritte mit GitHub Actions für GitHub Enterprise Server fortsetzen.