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. Du kannst jedoch keine Service-Container innerhalb einer zusammengesetzten Aktion erstellen und verwenden.

Note

Wenn bei deinen Workflows Docker-Containeraktionen, Auftragscontainer oder Dienstcontainer verwendet werden, musst du einen Linux-Runner nutzen:

Wenn du GitHub-gehostete Runner verwendest, musst du einen Ubuntu-Runner verwenden.
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 finden Sie in der Docker-Dokumentation unter Bridge-Netzwerktreiber.

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 Aufträge direkt auf dem Runnercomputer ausführst, kannst du mit localhost:<port> oder 127.0.0.1:<port> auf Service-Container 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 Informationen zu Service-Containern.

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.

In diesem Beispiel wird ein Dienst namens redis in einem Auftrag namens container-job erstellt. Der Docker-Host ist in diesem Beispiel der node:16-bullseye-Container.

YAML

name: Redis container example
on: push

jobs:
  # Label of the container job
  container-job:
    # Containers must run in Linux based operating systems
    runs-on: ubuntu-latest
    # Docker Hub image that `container-job` executes in
    container: node:16-bullseye

    # Service containers to run with `container-job`
    services:
      # Label used to access the service container
      redis:
        # Docker Hub image
        image: redis

name: Redis container example
on: push

jobs:
  # Label of the container job
  container-job:
    # Containers must run in Linux based operating systems
    runs-on: ubuntu-latest
    # Docker Hub image that `container-job` executes in
    container: node:16-bullseye

    # Service containers to run with `container-job`
    services:
      # Label used to access the 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 `ports`	BESCHREIBUNG
`8080:80`	Ordnet TCP-Port 80 im Container dem Port 8080 auf dem Docker-Host zu.
`8080:80/udp`	Ordnet UDP-Port 80 im Container dem Port 8080 auf dem Docker-Host zu.
`8080/udp`	Ordnet einen zufällig gewählten Port auf dem Docker-Host dem UDP-Port 8080 im Container zu.

Wenn du Ports mit dem Schlüsselwort ports zuordnest, veröffentlicht GitHub die Ports des Containers mit dem Befehl --publish auf dem Docker-Host. Weitere Informationen findest du in der Docker-Dokumentation unter Docker-Containernetzwerke.

Wenn Du den Port des Containers angibst, aber nicht den des Docker-Hosts, 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 job.services.redis.ports[5432] auf den entsprechenden Port des Containers zugreifen. Weitere Informationen findest du unter Zugreifen auf kontextbezogene Informationen zu Workflowausführungen.

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 of the container job
  runner-job:
    # You must use a Linux environment when using service containers or container jobs
    runs-on: ubuntu-latest

    # Service containers to run with `runner-job`
    services:
      # Label used to access the service container
      redis:
        # Docker Hub image
        image: redis
        #
        ports:
          # Opens tcp port 6379 on the host and service container
          - 6379:6379

name: Redis Service Example
on: push

jobs:
  # Label of the container job
  runner-job:
    # You must use a Linux environment when using service containers or container jobs
    runs-on: ubuntu-latest

    # Service containers to run with `runner-job`
    services:
      # Label used to access the service container
      redis:
        # Docker Hub image
        image: redis
        #
        ports:
          # Opens tcp port 6379 on the host and service container
          - 6379:6379

Authentifizieren mit Bildregistrierungen

Du kannst Anmeldeinformationen für deine Dienstcontainer angeben, falls du dich bei einer Bildregistrierung authentifizieren musst. So kannst du Bilder aus privaten Registrierungen verwenden oder deine DockerHub-Ratenbegrenzung erhöhen.

Hier ist ein Beispiel für die Authentifizierung mit Docker Hub und GitHub Container registry:

YAML

jobs:
  build:
    services:
      redis:
        # Docker Hub image
        image: redis
        ports:
          - 6379:6379
        credentials:
          username: ${{ secrets.dockerhub_username }}
          password: ${{ secrets.dockerhub_password }}
      db:
        # Private registry image
        image: ghcr.io/octocat/testdb:latest
        credentials:
          username: ${{ github.repository_owner }}
          password: ${{ secrets.ghcr_password }}

jobs:
  build:
    services:
      redis:
        # Docker Hub image
        image: redis
        ports:
          - 6379:6379
        credentials:
          username: ${{ secrets.dockerhub_username }}
          password: ${{ secrets.dockerhub_password }}
      db:
        # Private registry image
        image: ghcr.io/octocat/testdb:latest
        credentials:
          username: ${{ github.repository_owner }}
          password: ${{ secrets.ghcr_password }}

Informationen zu Service-Containern

In diesem Artikel