Informationen zu Service-Containern

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.

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.

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.

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 finden Sie unter „Kontexte“.

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 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

• "Redis-Service-Container erstellen"
• "PostgreSQL-Service-Container erstellen"