{"meta":{"title":"Communication avec les conteneurs de service Docker","intro":"Découvrez comment utiliser les conteneurs de service Docker pour connecter des bases de données, des services Web, des caches mémoire et d’autres outils à votre flux de travail.","product":"GitHub Actions","breadcrumbs":[{"href":"/fr/actions","title":"GitHub Actions"},{"href":"/fr/actions/tutorials","title":"Tutoriels"},{"href":"/fr/actions/tutorials/use-containerized-services","title":"Utilisez des services conteneurisés"},{"href":"/fr/actions/tutorials/use-containerized-services/use-docker-service-containers","title":"Utiliser des conteneurs de service Docker"}],"documentType":"article"},"body":"# Communication avec les conteneurs de service Docker\n\nDécouvrez comment utiliser les conteneurs de service Docker pour connecter des bases de données, des services Web, des caches mémoire et d’autres outils à votre flux de travail.\n\n## Communication avec les conteneurs de service Docker\n\nLes 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.\n\nVous pouvez configurer des conteneurs de service pour chaque travail d’un workflow.\nGitHub crée un nouveau conteneur Docker pour chaque service configuré dans le flux de travail 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.\n\n> \\[!NOTE]\n> Si vos flux de travail utilisent des actions de conteneurs Docker, des conteneurs de tâches ou des conteneurs de services, vous devez utiliser un programme d'exécution Linux :\n>\n> * Si vous utilisez des exécuteurs hébergés sur GitHub, vous devez utiliser un exécuteur Ubuntu.\n> * 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é.\n\nVous 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.\n\n### Exécution de travaux dans un conteneur\n\nLorsque vous exécutez des travaux dans un conteneur, GitHub connecte des conteneurs de service à la tâche à l’aide des réseaux de pont définis par l’utilisateur de Docker. Pour plus d’informations, consultez « [Gestionnaire des réseaux de pont](https://docs.docker.com/engine/network/drivers/bridge/) » dans la documentation Docker.\n\nL’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`.\n\nVous 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.\n\n### Exécution de travaux sur la machine de l’exécuteur\n\nLorsque 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>`.\nGitHub configure le réseau de conteneurs pour activer la communication entre le conteneur de service et l’hôte Docker.\n\nLorsqu’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 « [Communication avec les conteneurs de service Docker](/fr/actions/tutorials/use-containerized-services/use-docker-service-containers#mapping-docker-host-and-service-container-ports) ».\n\n## Création de conteneurs de service\n\nVous 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`](/fr/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idservices).\n\nCet 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`.\n\n```yaml copy\nname: Redis container example\non: push\n\njobs:\n  # Label of the container job\n  container-job:\n    # Containers must run in Linux based operating systems\n    runs-on: ubuntu-latest\n    # Docker Hub image that `container-job` executes in\n    container: node:16-bullseye\n\n    # Service containers to run with `container-job`\n    services:\n      # Label used to access the service container\n      redis:\n        # Docker Hub image\n        image: redis\n```\n\n## Mappage des ports de conteneur de service et d’hôte Docker\n\nSi 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.\n\nVous 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`](/fr/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idservices).\n\n| Valeur de `ports` | Description                                                                                       |\n| ----------------- | ------------------------------------------------------------------------------------------------- |\n| `8080:80`         | Mappe le port TCP 80 dans le conteneur au port 8080 sur l’hôte Docker.                            |\n| `8080:80/udp`     | Mappe le port UDP 80 dans le conteneur au port 8080 sur l’hôte Docker.                            |\n| `8080/udp`        | Mappe un port UDP choisi de façon aléatoire sur l’hôte Docker au port UDP 8080 dans le conteneur. |\n\nLorsque vous mappez des ports à l’aide du `ports` mot clé, GitHub utilise la `--publish` commande pour publier les ports du conteneur sur l’hôte Docker. Pour plus d’informations, consultez « [Mise en réseau de conteneurs Docker](https://docs.docker.com/config/containers/container-networking/) » dans la documentation Docker.\n\nLorsque vous spécifiez le port de conteneur, mais pas le port d’hôte Docker, le port du conteneur est attribué de manière aléatoire à un port libre.\nGitHub 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 « [Référence des contextes](/fr/actions/reference/workflows-and-actions/contexts#job-context) ».\n\n### Exemple de mappage de ports Redis\n\nCet exemple mappe le port `redis` de conteneur de service 6379 au port d’hôte Docker 6379.\n\n```yaml copy\nname: Redis Service Example\non: push\n\njobs:\n  # Label of the container job\n  runner-job:\n    # You must use a Linux environment when using service containers or container jobs\n    runs-on: ubuntu-latest\n\n    # Service containers to run with `runner-job`\n    services:\n      # Label used to access the service container\n      redis:\n        # Docker Hub image\n        image: redis\n        #\n        ports:\n          # Opens tcp port 6379 on the host and service container\n          - 6379:6379\n```\n\n## Authentification avec des registres d’images\n\nVous 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](https://www.docker.com/increase-rate-limits/).\n\nVoici un exemple d’authentification avec Docker Hub et le GitHubContainer registry:\n\n```yaml copy\njobs:\n  build:\n    services:\n      redis:\n        # Docker Hub image\n        image: redis\n        ports:\n          - 6379:6379\n        credentials:\n          username: ${{ secrets.dockerhub_username }}\n          password: ${{ secrets.dockerhub_password }}\n      db:\n        # Private registry image\n        image: ghcr.io/octocat/testdb:latest\n        credentials:\n          username: ${{ github.repository_owner }}\n          password: ${{ secrets.ghcr_password }}\n```\n\n## Personnalisation des points d’entrée et des commandes de conteneur de service\n\nPar défaut, les conteneurs de service s’exécutent avec le point d’entrée et la commande définis dans l’image Docker. Vous pouvez les remplacer à l’aide des touches `entrypoint` et `command`. Cela est utile lorsque vous devez passer des indicateurs à un service (par exemple, une base de données) ou échanger entièrement le point d’entrée d’image, sans générer d’image wrapper personnalisée.\n\nLa `command` clé remplace la commande par défaut de l’image (`CMD`). La plupart des scénarios ont uniquement besoin de `command`. L’image a déjà le bon point d’entrée, il vous suffit de passer des indicateurs.\n\n```yaml copy\nservices:\n  mysql:\n    image: mysql:8\n    command: --sql_mode=STRICT_TRANS_TABLES --max_allowed_packet=512M\n    env:\n      MYSQL_ROOT_PASSWORD: test\n    ports:\n      - 3306:3306\n```\n\nLa `entrypoint` clé remplace celle de l’image `ENTRYPOINT`. Vous pouvez le combiner avec `command` pour passer des arguments au point d'entrée personnalisé :\n\n```yaml copy\nservices:\n  etcd:\n    image: quay.io/coreos/etcd:v3.5.17\n    entrypoint: etcd\n    command: >-\n      --listen-client-urls http://0.0.0.0:2379\n      --advertise-client-urls http://0.0.0.0:2379\n    ports:\n      - 2379:2379\n```\n\nLe nommage et le comportement correspondent à Docker Compose. Pour plus d’informations, consultez [`jobs.<job_id>.services.<service_id>.command`](/fr/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idservicesservice_idcommand) et [`jobs.<job_id>.services.<service_id>.entrypoint`](/fr/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idservicesservice_identrypoint).\n\n## Pour aller plus loin\n\n* [Création de conteneurs de service Redis](/fr/actions/tutorials/use-containerized-services/create-redis-service-containers)\n* [Création de conteneurs de service PostgreSQL](/fr/actions/tutorials/use-containerized-services/create-postgresql-service-containers)"}