Hinweis: GitHub-gehostete Runner werden auf GitHub Enterprise Server derzeit nicht unterstützt. Weitere Informationen zur geplanten zukünftigen Unterstützung findest Du in der 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. Du kannst jedoch keine Service-Container innerhalb einer zusammengesetzten Aktion erstellen und verwenden.
Hinweis: Wenn deine Workflows Docker-Containeraktionen, Auftragscontainer oder Dienstcontainer verwenden, musst du einen Linux-Runner verwenden:
- 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.
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.
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:
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 }}