从动作中按github动作中的主机名访问容器 [英] Access a container by hostname in github actions from within an action

问题描述

我在github动作中启动了一个docker容器，并尝试从一个动作中访问它.但是该操作无法解析主机名.如何将我的容器与操作添加到相同的docker网络，并通过操作的主机名访问该容器?

I start a docker container within my github action and try to access it from an action. But the action is not able to resolve the hostname. How do add my container to the same docker network as the action and let the action access it by its hostname?

steps:
  - name: Run Fuseki
    run: docker run -p 3030:3030 --name fuseki -d stain/jena-fuseki /jena-fuseki/fuseki-server --file=/staging/aksw.org.nt /aksw
  - name: curl
    uses: wei/curl@master
    with:
      args: https://fuseki:3030/aksw

完整文件为推荐答案

在shell步骤中混合使用服务，docker操作和简单的旧docker命令时，我的工作流程存在相同的问题.目前，我仅看到两种可能的解决方法:

I have the same issue in my workflows when working with a mix of services, docker actions and plain old docker commands in shell steps. At the moment, I only see two possible workarounds:

1. 在主机网络上运行所有内容.服务可以在主机上发布其端口.使用 ports 字段.例如:

1. Run everything on the host network. Services can publish their ports on the host. using the ports field. For example:

   services:
      redis:
        image: redis
        ports:
          - 6379:6379

在其他步骤和操作中，您可以将-network"host" 选项传递给docker.要访问任何容器，只需调用 localhost:port .这将从您的步骤的外壳以及容器内部开始.这是最简单的解决方案.不幸的是，服务之间可能会发生冲突，我真的不知道在github托管的运行器上是否有任何严重的安全隐患.

In your other steps and actions you can pass the --network "host" option to docker. To access any of the containers just call localhost:port. This will work from the shell of your steps and from within the containers. It's the simplest solution. Unfortunately, you might have collisions between services and I don't really know if there is any serious security implications doing this on github hosted runners.

1. 您可以使用-network $ {{job.container.network}} 在跑步者创建的网络中启动容器.通过传递-cidfile $ CID_FILE ，可以将容器的ID存储在文件 $ CID_FILE 中.在这里，您可以使用docker检查并输出容器IP地址.这样，即使容器名称无法解析，您仍然可以使用IP地址从一个容器连接到另一个容器.这是通过简单的操作即可实现的方式:

1. You can start your containers in the network created by the runner using --network ${{ job.container.network }}. By passing --cidfile $CID_FILE you can store the id of the container in a file $CID_FILE. From there you can use docker inspect and output the container IP address. By doing so, even if the names of the containers don't resolve you can still connect from one container to the other using IP addresses. Here is how it can be implemented in a simple action:

    name: Docker start container
    description: Start a detached container
    
    inputs:
      image:
        description: The image to use
        required: true
      name:
        description: The container name
        required: true
      options:
        description: Additional options to pass to docker run
        required: false
        default: ''
      command:
        description: The command to run
        required: false
        default: ''
    
    outputs:
      cid:
        description: Container ID
        value: ${{ steps.info.outputs.cid }}
      address:
        description: Container ID
        value: ${{ steps.info.outputs.address }}
    
    runs:
      using: composite
      steps:
        - name: Pull
          shell: bash
          run: docker pull ${{ inputs.image }}
    
        - name: Run
          env:
            CID_FILE: ${{ inputs.name }}.cid
          shell: bash
          run: >
            docker run -d
            --name ${{ inputs.name }}
            --network host
            --cidfile $CID_FILE
            ${{ inputs.options }}
            ${{ inputs.image }}
            ${{ inputs.command }}

        - name: Info
          id: info
          shell: bash
          run: |
            export CID=$(cat $CID_FILE)
            export ADDR=$(docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' $CID)
            echo "::set-output name=cid::$CID"
            echo "::set-output name=address::$ADDR"

这可能更安全，但除了增加的复杂性之外，它还有一个主要缺点:作业开始时不知道容器地址.这意味着您无法使用作业范围的环境变量将任何这些IP地址传递给其他容器.

This is probably safer but outside the added complexity, it has one major drawback: the container addresses are not known when the job starts. It means that you cannot pass any of these IP addresses to other containers using job-wide environment variables.

这篇关于从动作中按github动作中的主机名访问容器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！