Diese Version von GitHub Enterprise wurde eingestellt am 2021-09-23. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für eine bessere Leistung, verbesserte Sicherheit und neue Features nimm ein Upgrade auf die neueste Version von GitHub Enterprise vor. Wende Dich an den GitHub Enterprise-Support, um Hilfe beim Upgrade zu erhalten.

Informationen zu Service-Containern

Du kannst Service-Container verwenden, um Datenbanken, Webdienste, Speicher-Caches und andere Tools mit Deinem Workflow zu verbinden.

GitHub Actions ist verfügbar mit GitHub Free, GitHub Pro, GitHub Free für Organisationen, GitHub Team, GitHub Enterprise Cloud, und GitHub AE. GitHub Actions ist nicht verfügbar für private Repositorys, die im Besitz von Konten mit älteren Pro-Repository-Plänen sind.

Note: GitHub Actions was available for GitHub Enterprise Server 2.22 as a limited beta. The beta has ended. GitHub Actions is now generally available in GitHub Enterprise Server 3.0 or later. For more information, see the GitHub Enterprise Server 3.0 release notes.


Note: GitHub-hosted runners are not currently supported on GitHub Enterprise Server. You can see more information about planned future support on the GitHub public roadmap.

Informationen zu Service-Containern

Service-Container sind Docker-Container, die Dir eine einfache und portable Möglichkeit bieten, Dienste zu hosten, um Deine Anwendung in einem Workflow zu testen oder zu betreiben. Beispielsweise muss Dein Workflow möglicherweise Integrationstests ausführen, die Zugriff auf eine Datenbank und einen Speicher-Cache erfordern.

Du kannst Service-Container für jeden Job in einem Workflow konfigurieren. Für jeden Service, der im Workflow konfiguriert ist, erstellt GitHub einen neuen Docker-Container und löscht den Service Container, wenn der Auftrag abgeschlossen ist. Steps (Schritte) in einem Job können mit allen Service-Containern kommunizieren, die Teil des gleichen Jobs sind.

Hinweis: Wenn Deine Workflows Docker-Containeraktionen oder Dienstcontainer verwenden, musst Du einen Linux-Läufer verwenden:

  • If you are using GitHub-hosted runners, you must use an Ubuntu runner.
  • Wenn Du selbst gehostete Läufer verwendest, musst Du einen Linux-Rechner als Deinen Läufer verwenden und Docker muss installiert sein.

Mit Service-Containern kommunizieren

Du kannst Jobs in einem Workflow so konfigurieren, dass sie direkt auf einer Runner-Maschine oder in einem Docker-Container laufen. Die Kommunikation zwischen einem Job und seinen Service-Containern ist unterscherschiedlich, je nachdem, ob ein Job direkt auf der Runner-Maschine oder in einem Container läuft.

Jobs in einem Container ausführen

Wenn Du Jobs in einem Container ausführst, verbindet GitHub die Service-Container mit dem Job über die benutzerdefinierten Bridge-Netzwerke von Docker. Weitere Informationen findest Du unter "Bridge-Netzwerke verwenden" in der Docker-Dokumentation.

Jobs und der Services in einem Container laufen zu lassen, vereinfacht den Netzwerkzugriff. Du kannst auf einen Service-Container mittels des Labels (Bezeichnung) zugreifen, den Du im Workflow konfigurierst. Der Hostname des Service-Containers wird automatisch dem Labelnamen zugeordnet. Wenn Du z.B. einen Service-Container mit der Bezeichnung Redis erstellst, ist auch der Hostname des Service-Containers Redis.

Du brauchst für Service-Container keine Ports zu konfigurieren. Standardmäßig machen alle Container, die Teil desselben Docker-Netzwerks sind, alle Ports füreinander verfügbar, und außerhalb des Docker-Netzwerks werden keine Ports verfügbar gemacht.

Jobs auf der Runner-Maschine ausführen

Wenn Du Jobs direkt auf der Runner-Maschine ausführst, kannst Du auf Service-Container mit localhost:<port> oder 127.0.0.1:<port> zugreifen. GitHub konfiguriert das Container-Netzwerk, um die Kommunikation vom Service-Container zum Docker-Host zu ermöglichen.

Wenn ein Job direkt auf einer Runner-Maschine läuft, macht der im Docker-Container laufende Dienst seine Ports nicht standardmäßig dem Job auf dem Runner verfügbar. Du musst Ports auf dem Service-Container dem Docker Host zuordnen. Weitere Informationen findest Du unter "Ports auf Docker-Host und Service-Container zuordnen."

Service-Container erstellen

Du kannst das Schlüsselwort Services verwenden, um Service-Container zu erstellen, die Teil eines Jobs in Deinem Workflow sind. Weitere Informationen findest Du unter jobs.<job_id>.services.

Dieses Beispiel erstellt einen Dienst namens redis in einem Job namens container-job. Der Docker-Host in diesem Beispiel ist der Container node:10.18-jessie.

YAML
name: Redis container example
on: push

jobs:
  # Label des Container-Jobs
  container-job:
    # Container müssen in Linux-basierten Betriebssystemen laufen
    runs-on: ubuntu-latest
    # Docker-Hub-Image in dem `container-job` laeuft
    container: node:10.18-jessie

    # Service-Container, mit denen `container-job` laeuft
    services:
      # Label zum Zugriff auf den Service--Container
      redis:
        # Docker-Hub-Image
        image: redis

Ports von Docker-Host und Service-Container zuordnen

Wenn Dein Job in einem Docker-Container läuft, brauchst Du keine Ports auf dem Host oder dem Service-Container zuzuordnen. Wenn Dein Job direkt auf der Runner-Maschine läuft, musst Du alle benötigten Service-Container-Ports zu Ports der Host-Runner-Maschine zuordnen.

Du kannst Service-Container-Ports mit Hilfe des Schlüsseworts ports dem Docker-Host zuordnen. Weitere Informationen findest Du unter jobs.<job_id>.services.

Wert von portsBeschreibung
8080:80Ordnet TCP-Port 80 im Container dem Port 8080 auf dem Docker-Host zu.
8080:80/udpOrdnet UDP-Port 80 im Container dem Port 8080 auf dem Docker-Host zu.
8080/udpOrdnet einen zufällig gewählten UDP-Port im Container dem UDP-Port 8080 auf dem Docker-Host zu.

Wenn Du Ports mittels ports zuordnest, publiziert GitHub die Ports des Containers auf dem Docker-Host mit dem Befehl --publish. Weitere Informationen findest Du unter "Vernetzung von Docker-Containern" in der Docker Dokumentation.

Wenn Du den Port des Docker-Hosts angibst, aber nicht den des Containers, dann wird der Container-Port zufällig einem freien Port zugewiesen. GitHub setzt den zugewiesenen Container-Port im Kontext des Service-Containers. Wenn Du beispielsweise den Port 5432 für den Docker-Host konfiguriert hast, kannst Du für einen Service Container redis mit dem Kontext code>job.services.redis.ports[5432] auf den entsprechenden Port des Containers zugreifen. Weitere Informationen findest Du unter "Kontext- und Ausdrucks-Syntax für GitHub Actions."

Beispiel zur Zuordnung von Redis-Ports

Dieses Beispiel ordnet den Port 6379 des Service-Containers redis dem Port 6379 des Docker-Hosts zu.

YAML
name: Redis Service Example
on: push

jobs:
  # Label des Container-Jobs
  runner-job:
    # Fuer Service-Containers oder Container-Jobs musst Du eine Linux-Umgebung benutzen
    runs-on: ubuntu-latest

    # Service-Container, die mit `runner-job` laufen sollen
    services:
      # Label zum Zugriff auf den Service-Container
      redis:
        # Docker-Hub-Image
        image: redis
        #
        ports:
          # Oeffnet TCP-Port 6379 auf dem Host und Service-Container
          - 6379:6379

Weiterführende Informationen