## 対象読者

- DockerComposeでセルフホストランナーを構築しようと思っている方
- DockerComposeでRootUserを使用していない方
- Docker in Dockerの挙動を知りたい方

## TL;DR

GithubActionsのセルフホストランナーのイメージは以下のものを使用することを前提とする。

> <https://hub.docker.com/r/myoung34/github-runner>

このイメージは、`runner`ユーザーで実行されるようになっている。
そのため、DockerComposeでセルフホストランナーを構築する際には、`runner`ユーザーで実行するように設定する必要がある。

上記のイメージを使用するには、`docker.sock`をマウントしてDocker in Dockerをする必要があるため、ホストのdockerのGIDとコンテナ内のGIDを合わせる必要がある。

そのため、DockerComposeとDockerfileは以下のように設定する。

```yaml title="docker-compose.yml"
services:
  runner:
    build:
      context: ./runner
      dockerfile: Dockerfile
      args:
        DOCKER_GID: $DOCKER_GID
        RUNNER_WORKDIR: $RUNNER_WORKDIR
    user: runner
    tty: true
    env_file:
      - .env
    volumes:
      - type: bind
        source: /var/run/docker.sock
        target: /var/run/docker.sock
      - type: volume
        source: runnerData
        target: /tmp/runner
```

```Dockerfile title="Dockerfile"
FROM myoung34/github-runner:latest

ARG DOCKER_GID
ARG RUNNER_WORKDIR

USER root

RUN groupmod -g ${DOCKER_GID} docker && \
    chown root:docker /usr/bin/docker && \
    chown runner:docker /usr/bin/docker && \
    chown -R runner:runner /actions-runner && \
    mkdir -p ${RUNNER_WORKDIR} && \
    chown -R runner:runner ${RUNNER_WORKDIR} /opt/hostedtoolcache

USER runner
```

## イメージを構築して躓いた点

私の環境では、runner以外に複数のサービスがあり、それらのサービスはRootUserでの実行をさけるために、ホストマシンのUIDとGIDをビルド時に渡して、新しくユーザーとグループを作成することで合わせるようにしていた。
そのため、runnerも同様に、ホストマシンのUIDとGIDで新しくユーザーとグループを作成しようとしたが、`docker.sock`の権限がないため、エラーが発生した。

ホストマシンのDocker環境はDockerDesktopを使用しており、これはRootlessではないため、`docker.sock`の権限が以下のものになっていた。

- User: Root
- Group: Docker

そのため、`docker.sock`をマウントするためには、コンテナ内の自作ユーザーにホストマシンのDockerのGIDを合わせる必要があったため、DockerfileのARGで渡すようにした。

ただ、これだと不十分でworkflow実行時に再度`docker.sock`のPermissionエラーが発生した。

この原因としては、**workflowはrunnerユーザーで実行される**ため、自作ユーザーに権限を設定しても意味がないということだった。
DockerComposeとDockerfileのuserの指定で自作ユーザーを指定していたので過信していたが、workflowはrunnerユーザーで実行される。

原因が分かったため、自作ユーザーの作成をやめて、`runner`ユーザーにホストマシンのDockerのGIDを合わせるように設定することで解決した。

## ワークフロー定義時に躓いた点

前述の通り、上記の方法だとDocker in Dockerになるため、ホストマシンのコンテナの起動状況とコンテナ内のコンテナの起動状況がバインドされている。

そのため、ワークフローが実行される際に、ホストマシンで開発用のコンテナなどが動いていると、コンテナが重複したり、コンテナを不用意に落としたりしてしまってエラーを吐くことがある。
具体的には、以下の2ケースが確認できた。

- ワークフローでのdocker compose up(これはrunnerのコンテナを2重起動させてしまうため、注意)
- ワークフローでのdocker compose down(これはrunnerのコンテナも落としてしまうため、注意)
- docker-compose.ymlに`container_name`を指定している場合

また、runnerにdepends_onで他のコンテナを指定している場合は、runnerの起動に他コンテナが引っ張られることがあるため、注意が必要である。

解決方としては、面倒ではあるが、以下のように個別でコンテナを起動するようにするか、docker-compose.ymlをdevやprodなどで分割することで解決できる。

```bash
docker compose rm -fsv db proxy back front; \
docker compose up -d db proxy back front
```


DockerComposeでセルフホストランナーを構築する際に、`docker.sock`のPermissionエラーが発生する問題について解決方法を記載する。

脱・人海戦術

Author

Ryo Arai

Jobs

AI Engineer

Full Stack Engineer

SNS

カテゴリ

タグ

PlayGround