プロキシの背後でRunnerを実行

プラン: Free、Premium、Ultimate
提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

このガイドは、プロキシの背後でDocker executorを使用するGitLab Runnerを機能させることを特に目的としています。

続ける前に、同じマシンにすでにDockerがインストールされていること、およびGitLab Runnerがインストールされていることを確認してください。

`cntlm`の設定

認証なしでプロキシをすでに使用している場合、このセクションはオプションであり、Dockerの設定に直接スキップできます。cntlmの設定は、認証付きプロキシの背後にいる場合にのみ必要ですが、どの場合でも使用することをお勧めします。

cntlmはローカルプロキシとして使用できるLinuxプロキシであり、プロキシの詳細をどこでも手動で追加する場合と比較して、2つの主な利点があります:

認証情報を変更する必要がある単一のソース
認証情報はDocker Runnerからアクセスできません

cntlmがインストール済みであることを前提として、まず設定する必要があります。

`cntlm`を`docker0`インターフェースでリッスンさせる

セキュリティとインターネットからの保護を強化するために、cntlmをdocker0インターフェースにバインドしてリッスンさせます。このインターフェースは、コンテナがアクセスできるIPアドレスを持っています。Dockerホスト上のcntlmにこのアドレスのみにバインドするように指示すると、Dockerコンテナはアクセスできますが、外部の世界からはアクセスできません。

Dockerが使用しているIPを見つける:
```
ip -4 -oneline addr show dev docker0
```
IPアドレスは通常172.17.0.1です。これをdocker0_interface_ipと呼びましょう。
cntlmの設定ファイル (/etc/cntlm.conf) を開きます。前のステップで見つけたユーザー名、パスワード、ドメイン、プロキシホストを入力し、Listen IPアドレスを設定します。次のようになるはずです:
```
Username     testuser
Domain       corp-uk
Password     password
Proxy        10.0.0.41:8080
Proxy        10.0.0.42:8080
Listen       172.17.0.1:3128 # Change to your docker0 interface IP
```
変更を保存し、サービスを再起動します:
```
sudo systemctl restart cntlm
```

Dockerのイメージダウンロードの設定

systemdをサポートするOSに以下の内容が適用されます。

プロキシの使用方法については、Dockerのドキュメントを参照してください。

サービスファイルは次のようになります:

[Service]
Environment="HTTP_PROXY=http://docker0_interface_ip:3128/"
Environment="HTTPS_PROXY=http://docker0_interface_ip:3128/"

GitLab Runnerの設定にプロキシ変数を追加する

プロキシ変数は、GitLab Runnerの設定にも追加する必要があります。これにより、プロキシの背後からGitLab.comに接続できるようになります。

このアクションは、上記のDockerサービスにプロキシを追加するのと同じです:

gitlab-runnerサービス用のsystemdドロップインディレクトリを作成します:
```
mkdir /etc/systemd/system/gitlab-runner.service.d
```

HTTP_PROXY環境変数を追加する/etc/systemd/system/gitlab-runner.service.d/http-proxy.confというファイルを作成します:

[Service]
Environment="HTTP_PROXY=http://docker0_interface_ip:3128/"
Environment="HTTPS_PROXY=http://docker0_interface_ip:3128/"

GitLab RunnerをGitLab Self-Managedインスタンスのような内部URLに接続するには、NO_PROXY環境変数の値を設定します。

[Service]
Environment="HTTP_PROXY=http://docker0_interface_ip:3128/"
Environment="HTTPS_PROXY=http://docker0_interface_ip:3128/"
Environment="NO_PROXY=gitlab.example.com"

ファイルを保存し、変更をフラッシュします:
```
systemctl daemon-reload
```
GitLab Runnerを再起動します:
```
sudo systemctl restart gitlab-runner
```

設定が読み込まれたことを確認します:

systemctl show --property=Environment gitlab-runner

次のように表示されます:

Environment=HTTP_PROXY=http://docker0_interface_ip:3128/ HTTPS_PROXY=http://docker0_interface_ip:3128/

Dockerコンテナにプロキシを追加する

Runnerを登録した後、プロキシ設定をDockerコンテナに伝播させたい場合があります (たとえば、git cloneの場合)。

これを行うには、/etc/gitlab-runner/config.tomlを編集し、[[runners]]セクションに次を追加する必要があります:

pre_get_sources_script = "git config --global http.proxy $HTTP_PROXY; git config --global https.proxy $HTTPS_PROXY"
environment = ["https_proxy=http://docker0_interface_ip:3128", "http_proxy=http://docker0_interface_ip:3128", "HTTPS_PROXY=docker0_interface_ip:3128", "HTTP_PROXY=docker0_interface_ip:3128"]

ここでdocker0_interface_ipは、docker0インターフェースのIPアドレスです。

例では、特定のプログラムがHTTP_PROXYを、別のプログラムがhttp_proxyを想定しているため、小文字と大文字の両方の変数を設定しています。残念ながら、これらの種類の環境変数に関する標準はありません。

`dind`サービスを使用する場合のプロキシ設定

Docker-in-Docker executor (dind) を使用する場合、docker:2375,docker:2376をNO_PROXY環境変数に指定する必要がある場合があります。ポートは必須です。そうしないとdocker pushがブロックされます。

dindからのdockerdとローカルdockerクライアント (こちらで説明されています: https://hub.docker.com/_/docker/) との間の通信には、rootのDocker設定で保持されているプロキシ変数が使用されます。

これを設定するには、完全なプロキシ設定を含めるように/root/.docker/config.jsonを編集する必要があります。例:

{
    "proxies": {
        "default": {
            "httpProxy": "http://proxy:8080",
            "httpsProxy": "http://proxy:8080",
            "noProxy": "docker:2375,docker:2376"
        }
    }
}

設定をDocker executorのコンテナに渡すには、$HOME/.docker/config.jsonもコンテナ内に作成する必要があります。これは、たとえば.gitlab-ci.ymlのbefore_scriptとしてスクリプト化できます:

before_script:
  - mkdir -p $HOME/.docker/
  - 'echo "{ \"proxies\": { \"default\": { \"httpProxy\": \"$HTTP_PROXY\", \"httpsProxy\": \"$HTTPS_PROXY\", \"noProxy\": \"$NO_PROXY\" } } }" > $HOME/.docker/config.json'

または、影響を受けるgitlab-runner (/etc/gitlab-runner/config.toml) の設定で、次のようにします:

[[runners]]
  pre_build_script = "mkdir -p $HOME/.docker/ && echo \"{ \\\"proxies\\\": { \\\"default\\\": { \\\"httpProxy\\\": \\\"$HTTP_PROXY\\\", \\\"httpsProxy\\\": \\\"$HTTPS_PROXY\\\", \\\"noProxy\\\": \\\"$NO_PROXY\\\" } } }\" > $HOME/.docker/config.json"

これは、TOMLファイル内で単一の文字列として指定されたシェルを持つJSONファイルを作成するため、"を追加でエスケープする必要があります。これはYAMLではないため、:をエスケープしないでください。

NO_PROXYリストを拡張する必要がある場合、ワイルドカード*はサフィックスにのみ機能し、プレフィックスやCIDR表記には機能しません。詳細については、https://github.com/moby/moby/issues/9145およびhttps://unix.stackexchange.com/questions/23452/set-a-network-range-in-the-no-proxy-environment-variableを参照してください。

レート制限されたリクエストの処理

GitLabインスタンスは、乱用を防ぐためにAPIリクエストに対してレート制限のあるリバースプロキシの背後にある場合があります。GitLab RunnerはAPIに複数のリクエストを送信するため、これらのレート制限を超える可能性があります。

結果として、GitLab Runnerは以下の再試行ロジックを使用して、レート制限されたシナリオを処理します:

再試行ロジック

GitLab Runnerが429 Too Many Requests応答を受け取ると、この再試行シーケンスに従います:

RunnerはRateLimit-ResetTimeヘッダーを応答のヘッダーで確認します。
- RateLimit-ResetTimeヘッダーは、Wed, 21 Oct 2015 07:28:00 GMTのような有効なHTTP日付 (RFC1123) の値を持つ必要があります。
- ヘッダーが存在し、有効な値を持つ場合、Runnerは指定された時間まで待機し、別のリクエストを発行します。
RateLimit-ResetTimeヘッダーが無効または欠落している場合、Runnerは応答のヘッダーでRetry-Afterヘッダーを確認します。
- Retry-Afterヘッダーは、Retry-After: 30のような秒単位の値を持つ必要があります。
- ヘッダー形式が存在し、有効な値を持つ場合、Runnerは指定された時間まで待機し、別のリクエストを発行します。
両方のヘッダーが欠落しているか無効な場合、Runnerはデフォルトの間隔まで待機し、別のリクエストを発行します。

Runnerは失敗したリクエストを最大5回再試行します。すべての再試行が失敗した場合、Runnerは最終応答からのエラーをログに記録します。

サポートされるヘッダー形式

ヘッダー	形式	例
`RateLimit-ResetTime`	HTTP日付 (RFC1123)	`Wed, 21 Oct 2015 07:28:00 GMT`
`Retry-After`	秒	`30`

RateLimit-ResetTimeヘッダーは、すべてのヘッダーキーがhttp.CanonicalHeaderKey関数によって実行されるため、大文字と小文字を区別しません。