{"meta":{"title":"Comunicación con contenedores de servicios de Docker","intro":"Aprende a usar contenedores de servicios de Docker para conectar las bases de datos, los servicios Web, las memorias caché y otras herramientas a tu flujo de trabajo.","product":"GitHub Actions","breadcrumbs":[{"href":"/es/actions","title":"GitHub Actions"},{"href":"/es/actions/tutorials","title":"Tutoriales"},{"href":"/es/actions/tutorials/use-containerized-services","title":"Uso de servicios de contenedor"},{"href":"/es/actions/tutorials/use-containerized-services/use-docker-service-containers","title":"Uso de contenedores de servicios de Docker"}],"documentType":"article"},"body":"# Comunicación con contenedores de servicios de Docker\n\nAprende a usar contenedores de servicios de Docker para conectar las bases de datos, los servicios Web, las memorias caché y otras herramientas a tu flujo de trabajo.\n\n## Comunicación con contenedores de servicios de Docker\n\nLos contenedores de servicios son contenedores de Docker que ofrecen una manera sencilla y portátil de alojar servicios que probablemente necesites para probar o usar tu aplicación en un flujo de trabajo. Por ejemplo, es posible que tu flujo de trabajo tenga que ejecutar pruebas de integración que requieran acceso a una base de datos y a una memoria caché.\n\nPuedes configurar contenedores de servicios para cada trabajo en un flujo de trabajo.\nGitHub crea un contenedor de Docker nuevo para cada servicio configurado en el flujo de trabajo y destruye el contenedor de servicios cuando se completa el trabajo. Los pasos de un trabajo pueden comunicarse con todos los contenedores de servicios que son parte del mismo trabajo. Sin embargo, no se pueden crear y usar contenedores de servicio dentro de una acción compuesta.\n\n> \\[!NOTE]\n> Si en los flujos de trabajo se usan acciones de contenedor de Docker, contenedores de trabajos o contenedores de servicios, deberás usar un ejecutor de Linux:\n>\n> * Si estás utilizando ejecutores hospedados en GitHub, debes utilizar un ejecutor de Ubuntu.\n> * Si estás utilizando ejecutores auto-hospedados, debes utilizar una máquina Linux como tu ejecutor, y ésta debe tener Docker instalado.\n\nPuedes configurar trabajos en un flujo de trabajo para que se ejecuten directamente en una máquina del ejecutor o en un contenedor de Docker. La comunicación entre un trabajo y sus contenedores de servicios cambia en función de si un trabajo se ejecuta directamente en la máquina del ejecutor o en un contenedor.\n\n### Ejecutar trabajos en un contenedor\n\nAl ejecutar trabajos en un contenedor, GitHub conecta los contenedores de servicio al trabajo mediante las redes de puente definidas por el usuario de Docker. Para obtener más información, consulta [Driver de redes de puente](https://docs.docker.com/engine/network/drivers/bridge/) en la documentación de Docker.\n\nAl ejecutar el trabajo y los servicios en un contenedor, se simplifica el acceso a la red. Puedes acceder a un contenedor de servicios usando la etiqueta que configuraste en el flujo de trabajo. El nombre del host del contenedor de servicios se correlaciona automáticamente con el nombre de la etiqueta. Por ejemplo, si crea un contenedor de servicios con la etiqueta `redis`, el nombre de host del contenedor de servicios será `redis`.\n\nNo es necesario configurar ningún puerto para los contenedores de servicios. Por defecto, todos los contenedores que forman parte de la misma red de Docker se exponen los puertos entre sí, y no se exponen puertos por fuera de la red de Docker.\n\n### Ejecutar trabajos en la máquina del ejecutor\n\nAl ejecutar trabajos directamente en la máquina del ejecutor, puede acceder a los contenedores de servicios mediante `localhost:<port>` o `127.0.0.1:<port>`.\nGitHub configura la red de contenedor para habilitar la comunicación desde el contenedor de servicios al host de Docker.\n\nCuando un trabajo se ejecuta directamente en una máquina del ejecutor, el servicio que se ejecuta en el contenedor de Docker no expone sus puertos al trabajo del ejecutor por defecto. Debes asignar los puertos del contenedor de servicios al host de Docker. Para más información, consulta [Comunicación con contenedores de servicios de Docker](/es/actions/using-containerized-services/about-service-containers#mapping-docker-host-and-service-container-ports).\n\n## Crear contenedores de servicios\n\nPuede usar la palabra clave `services` para crear contenedores de servicios que formen parte de un trabajo en el flujo de trabajo. Para obtener más información, vea [`jobs.<job_id>.services`](/es/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idservices).\n\nEn este ejemplo se crea un servicio denominado `redis` en un trabajo denominado `container-job`. El host de Docker de este ejemplo es el contenedor `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## Mapeo de puertos del host de Docker y de contenedores de servicio\n\nSi tu trabajo se ejecuta en un contenedor de Docker, no necesitas asignar puertos en el host o en el contenedor de servicios. Si tu trabajo se ejecuta directamente en la máquina del ejecutor, tendrás que asignar cualquier puerto requerido del contenedor de servicios a los puertos de la máquina del ejecutor del host.\n\nPuede asignar puertos de contenedores de servicios al host de Docker mediante la palabra clave `ports`. Para obtener más información, vea [`jobs.<job_id>.services`](/es/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idservices).\n\n| Valor de `ports` | Descripción                                                                                       |\n| ---------------- | ------------------------------------------------------------------------------------------------- |\n| `8080:80`        | Asigna el puerto TCP 80 del contenedor al puerto 8080 del host de Docker.                         |\n| `8080:80/udp`    | Asigna el puerto UDP 80 del contenedor al puerto 8080 del host de Docker.                         |\n| `8080/udp`       | Asigna un puerto elegido aleatoriamente en el host de Docker al puerto UDP 8080 en el contenedor. |\n\nAl asignar puertos mediante la `ports` palabra clave , GitHub usa el `--publish` comando para publicar los puertos del contenedor en el host de Docker. Para obtener más información, consulta [Redes de contenedores de Docker](https://docs.docker.com/config/containers/container-networking/) en la documentación de Docker.\n\nCuando especificas el puerto del contenedor, pero no el puerto del host de Docker, el puerto del contenedor se asigna aleatoriamente a un puerto gratuito.\nGitHub establece el puerto de contenedor asignado en el contexto del contenedor de servicios. Por ejemplo, para un contenedor de servicios `redis`, si configuró el puerto de host de Docker 5432, podrá acceder al puerto de contenedor correspondiente mediante el contexto `job.services.redis.ports[5432]`. Para más información, consulta [Contextos de referencia](/es/actions/learn-github-actions/contexts#job-context).\n\n### Ejemplo de asignación de puertos Redis\n\nEn este ejemplo se asigna el puerto 6379 del contenedor `redis` de servicios al puerto de host 6379 de Docker.\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## Autenticación con registros de imágenes\n\nPuedes especificar credenciales para los contenedores de servicio si necesitas autenticarte con un registro de imágenes. Esto permite usar imágenes de registros privados o [aumentar el límite de velocidad de DockerHub](https://www.docker.com/increase-rate-limits/).\n\nEste es un ejemplo de autenticación con Docker Hub yGitHubContainer 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## Personalización de los puntos de entrada y comandos del contenedor de servicio\n\nDe forma predeterminada, los contenedores de servicio se ejecutan con el punto de entrada y el comando definidos en la imagen de Docker. Puede invalidar estas usando las teclas `entrypoint` y `command`. Esto resulta útil cuando necesita pasar marcas a un servicio (como una base de datos) o intercambiar completamente el punto de entrada de imagen, sin crear una imagen contenedora personalizada.\n\nLa `command` clave invalida el comando predeterminado de la imagen (`CMD`). La mayoría de los escenarios solo necesitan `command`: la imagen ya tiene el punto de entrada correcto, solo necesita pasar banderas.\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` sobrescribe la `ENTRYPOINT` de la imagen. Puede combinarlo con `command` para pasar argumentos al punto de entrada personalizado:\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\nLa nomenclatura y el comportamiento coinciden con Docker Compose. Para más información, vea [`jobs.<job_id>.services.<service_id>.command`](/es/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idservicesservice_idcommand) y [`jobs.<job_id>.services.<service_id>.entrypoint`](/es/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idservicesservice_identrypoint).\n\n## Información adicional\n\n* [Creación de contenedores de servicio de Redis](/es/actions/using-containerized-services/creating-redis-service-containers)\n* [Crear contenedores de servicios PostgreSQL](/es/actions/using-containerized-services/creating-postgresql-service-containers)"}