Skip to main content

Cette version de GitHub Enterprise Server n'est plus disponible depuis le 2024-03-26. Aucune publication de correctifs n’est effectuée, même pour les problèmes de sécurité critiques. Pour de meilleures performances, une sécurité améliorée et de nouvelles fonctionnalités, effectuez une mise à niveau vers la dernière version de GitHub Enterprise. Pour obtenir de l’aide sur la mise à niveau, contactez le support GitHub Enterprise.

À propos des conteneurs de service

Vous pouvez utiliser des conteneurs de services pour connecter des bases de données, des services web, des caches mémoire et d’autres outils à votre workflow.

Remarque : Les exécuteurs hébergés sur GitHub ne sont pas pris en charge sur GitHub Enterprise Server. Vous pouvez voir plus d’informations sur le support futur planifié dans la GitHub public roadmap.

À propos des conteneurs de service

Les conteneurs de service sont des conteneurs Docker qui fournissent un moyen simple et portable d’héberger des services dont vous pouvez avoir besoin pour tester ou utiliser votre application dans un workflow. Par exemple, votre workflow peut avoir besoin d’exécuter des tests d’intégration qui nécessitent un accès à une base de données et à un cache mémoire.

Vous pouvez configurer des conteneurs de service pour chaque travail d’un workflow. GitHub crée un nouveau conteneur Docker pour chaque service configuré dans le workflow et détruit le conteneur de service une fois le travail terminé. Les étapes d’un travail peuvent communiquer avec tous les conteneurs de service qui font partie du même travail. Toutefois, vous ne pouvez pas créer et utiliser des conteneurs de service à l’intérieur d’une action composite.

Remarque : Si vos workflows utilisent des actions de conteneur Docker, des conteneurs de travaux ou des conteneurs de services, vous devez utiliser un exécuteur Linux :

  • Si vous utilisez des exécuteurs hébergés sur GitHub, vous devez utiliser un exécuteur Ubuntu.
  • Si vous utilisez des exécuteurs autohébergés, vous devez utiliser une machine Linux en tant qu’exécuteur, et Docker doit être installé.

Communication avec des conteneurs de service

Vous pouvez configurer des travaux dans un workflow pour qu’ils s’exécutent directement sur une machine d’exécuteur ou dans un conteneur Docker. La communication entre un travail et ses conteneurs de service est différente selon qu’un travail s’exécute directement sur la machine de l’exécuteur ou dans un conteneur.

Exécution de travaux dans un conteneur

Lorsque vous exécutez des travaux dans un conteneur, GitHub connecte les conteneurs de service au travail à l’aide de réseaux de pont définis par l’utilisateur de Docker. Pour plus d’informations, consultez « Utiliser des réseaux de pont » dans la documentation Docker.

L’exécution du travail et des services dans un conteneur simplifie l’accès réseau. Vous pouvez accéder à un conteneur de service à l’aide de l’étiquette que vous configurez dans le workflow. Le nom d’hôte du conteneur de service est automatiquement mappé au nom de l’étiquette. Par exemple, si vous créez un conteneur de service avec l’étiquette redis, le nom d’hôte du conteneur de service est redis.

Vous n’avez pas besoin de configurer de ports pour les conteneurs de service. Par défaut, tous les conteneurs qui font partie du même réseau Docker s’exposent tous les ports entre eux et aucun port n’est exposé en dehors du réseau Docker.

Exécution de travaux sur la machine de l’exécuteur

Lorsque vous exécutez des travaux directement sur la machine de l’exécuteur, vous pouvez accéder aux conteneurs de service à l’aide de localhost:<port> ou de 127.0.0.1:<port>. GitHub configure le réseau de conteneurs pour permettre la communication entre le conteneur de service et l’hôte Docker.

Lorsqu’un travail s’exécute directement sur une machine d’exécuteur, par défaut, le service s’exécutant dans le conteneur Docker n’expose pas ses ports au travail sur l’exécuteur. Vous devez mapper les ports sur le conteneur de service à l’hôte Docker. Pour plus d’informations, consultez « À propos des conteneurs de service ».

Création de conteneurs de service

Vous pouvez utiliser le mot clé services pour créer des conteneurs de service qui font partie d’un travail dans votre workflow. Pour plus d’informations, consultez jobs.<job_id>.services.

Cet exemple crée un service appelé redis dans un travail appelé container-job. Dans cet exemple, l’hôte Docker est le conteneur node:16-bullseye.

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

Mappage des ports de conteneur de service et d’hôte Docker

Si votre travail s’exécute dans un conteneur Docker, vous n’avez pas besoin de mapper les ports sur l’hôte ou le conteneur de service. Si votre travail s’exécute directement sur la machine de l’exécuteur, vous devez mapper tous les ports de conteneur de service requis aux ports de la machine d’exécuteur hôte.

Vous pouvez mapper les ports de conteneurs de service à l’hôte Docker à l’aide du mot clé ports. Pour plus d’informations, consultez jobs.<job_id>.services.

Valeur de portsDescription
8080:80Mappe le port TCP 80 dans le conteneur au port 8080 sur l’hôte Docker.
8080:80/udpMappe le port UDP 80 dans le conteneur au port 8080 sur l’hôte Docker.
8080/udpMappe un port UDP choisi de façon aléatoire dans le conteneur au port UDP 8080 sur l’hôte Docker.

Lorsque vous mappez des ports à l’aide du mot clé ports, GitHub utilise la commande --publish pour publier les ports du conteneur sur l’hôte Docker. Pour plus d’informations, consultez « Mise en réseau de conteneurs Docker » dans la documentation Docker.

Lorsque vous spécifiez le port d’hôte Docker, mais pas le port du conteneur, le port du conteneur est attribué de manière aléatoire à un port libre. GitHub définit le port de conteneur affecté dans le contexte du conteneur de service. Par exemple, pour un conteneur de service redis, si vous avez configuré le port d’hôte Docker 5432, vous pouvez accéder au port de conteneur correspondant à l’aide du contexte job.services.redis.ports[5432]. Pour plus d’informations, consultez « Contextes ».

Exemple de mappage de ports Redis

Cet exemple mappe le port redis de conteneur de service 6379 au port d’hôte Docker 6379.

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

Authentification avec des registres d’images

Vous pouvez spécifier des identifiants pour vos conteneurs de service au cas où vous devez vous authentifier auprès d’un registre d’images. Cela vous permet d’utiliser des images à partir de registres privés ou d’augmenter votre limite de débit DockerHub.

Voici un exemple d’authentification auprès de Docker Hub et des données 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 }}

Pour aller plus loin