Verwenden Sie GitHub Actions mit einem privaten Runner zur Bereitstellung auf IIS

Beispiel

Um dies zu testen, habe ich eine Beispielanwendung in dieser Repo (Sie können die Aktionen auch dort finden). Es basiert auf dem folgenden dotnet-Befehl:

dotnet new webapp

Fluss

Da es sich um eine .NET Core-Anwendung handelt, umfasst der Workflow für GitHub Actions diese Schritte:

1. Prüfen Sie das Repo
2. Stellen Sie die richtige .NET Core Version ein
3. Dotnet-Entwicklung
4. dotnet veröffentlichen
5. für den IIS bereitstellen
6. Führen Sie einen Smoketest durch
7. Führen Sie die Webtests aus (als zusätzliches Beispiel hinzugefügt, lesen Sie weiter für weitere Informationen)

Sie finden diesen Workflow hier. Wenn Sie den Arbeitsablauf zum Verschieben der Anwendung in ein Azure App Service, überprüfen Sie die dotnetcore.yml Datei daneben.

Einrichtung

Für die Ausführung der IIS-Befehle habe ich das einfachste Beispiel verwendet, andere Befehlszeilenoptionen funktionieren jedoch auch:

1. Stoppen Sie die Website (oder in diesem Fall den gesamten Webserver)
2. Alle Dateien überschreiben
3. Starten Sie die Website erneut mit WebDeploy oder einem Remote PowerShell Sitzung wird ebenfalls funktionieren. Weitere Erklärungen zum Thema Remoting finden Sie in diesem Blogpost ebenfalls.

Aktion

Die eigentlichen Aktionen, mit denen die Anwendung 'bereitgestellt' wird, sind wie folgt.

- name: Deploy to IIS
      run: |
        iisreset /stop
        Copy-Item ./dotnetcorewebapp/* C:/inetpub/wwwroot/dotnetcore-webapp -Recurse -Force
        iisreset /start

Hinweis: Für die Ausführung dieser Schritte sind Zugriffsrechte der Stufe Admin erforderlich. Sie müssen also den selbst gehosteten Runner mit dieser Zugriffsstufe ausführen. Dies ergibt sich aus der AppExec Befehle, die er abfeuert und die diese Zugriffsebene erfordern (was immer noch bedauerlich ist).

Privater GitHub Action Runner

Um die Bereitstellung der Anwendung auf einer Windows-Box zu ermöglichen, müssen Sie ein privater GitHub Action Runner da die in der Cloud gehosteten Runner keinen Zugriff auf diesen Rechner haben (sollten sie auch nicht!). Sie können sie wie einen normalen Runner installieren, wie zum Beispiel Azure DevOps. Glücklicherweise ist die Liste der URLs, die Sie zu Ihrer Proxy-/Zulassungsliste hinzufügen müssen, viel kürzer als die Azure DevOps Liste.

Der Runner läuft bei Bedarf oder als Windows-Dienst und öffnet in regelmäßigen Abständen eine lange Polling-Verbindung zu GitHub und fragt, ob es etwas zu tun gibt. Die Verbindung ist immer ausgehend und auf Port 443.

Die Installation eines Läufers kann von der Website aus auf Repository-, Team- oder Organisationsebene erfolgen. Gehen Sie zu "Einstellungen" -> Aktionen und scrollen Sie nach unten zu Selbstgehostete Läufer:

Das Hinzufügen eines Läufers ist sehr einfach. Alle Schritte sind direkt auf dem Bildschirm aufgeführt, sogar das temporäre Token, das für eine einmalige Authentifizierung verwendet wird:

Bonus

Die nächste Frage, die sich stellte, war, ob Sie einen Selenium WebTest (wie ich diese Art von End-to-End-Test nenne) mit einem solchen Runner ausführen können und ob das auch mit einem gehosteten Runner funktioniert. Lange Rede, kurzer Sinn: Es funktioniert einfach.

In beiden Arbeitsabläufe Ich habe den letzten Schritt 'Run Web Test' hinzugefügt, der die Unit-Tests in der WebTest Projekt, das einen Selenium-Treiber verwendet, um mit der installierten Chrome-Instanz auf dem Runner zu kommunizieren. Sie finden die gesamte vorinstallierte Software auf dem gehosteten Runner hier.