Dockerでプロキシを設定する方法

コンテナは、開発者が直面してきた多くの課題を解決し、ソフトウェア開発を大きく変えました。さまざまなシステムやデバイスで確実かつ一貫して動作するアプリケーションを提供できます。Docker はコンテナをさらに進化させ、構築、管理、実行を大幅に簡単かつ高速にしました。Docker ではサードパーティ製プロキシも利用でき、設定方法も複数あります。代替 IP と組み合わせる理由、用途に合う方法、具体的な設定手順を見ていきましょう。

Docker でプロキシを使う理由

安定性と安全性を備え、管理しやすいインターネットアクセスを確保するためです。場合によっては、そもそもインターネットに接続するために必要になります。

Docker は、イメージの取得やパッケージのインストールなどの処理を行うためにウェブへのアクセスを必要とします。しかし、多くの企業ネットワークでは直接接続が許可されず、外向きトラフィックが管理または制限されています。こうした制限はセキュリティ上必要ですが、開発作業の妨げにもなります。承認済みプロキシを使えばインターネットに接続でき、”Connection timed out” や “Unable to access www.example.com” といったエラーを回避できます。

また、ネットワークの利用に認証が必要な場合もあります。Docker 単体では必要な認証を処理できないため、外部プロキシを使用します。

実行中のアプリケーションで外部接続が必要になることもあります。たとえば、コンテナからクラウド API、データベース、サードパーティサービスに接続する場合です。ファイアウォールで保護された環境では、目的のエンドポイントに到達するためにプロキシが必要になることがあります。

プロキシにはほかにも利点があります。中継サーバー経由でトラフィックをルーティングすることで速度の問題が改善する場合があり、ログ記録、マルウェア対策、SSL インスペクションのためのトラフィック監視にも役立ちます。さらに、異なるサーバーやマシン間でネットワーク設定の一貫性を保ち、IP アドレス、内部 DNS リクエスト、NAT などの内部情報を隠すことでセキュリティを高められます。

Docker でプロキシを設定する方法

プロキシは 4 つのレイヤーで設定できます。Docker デーモン、すなわち Docker Engine、Docker クライアント、コンテナ、OS レベルです。各レイヤーには複数の設定方法があり、選択した方法によって影響範囲も異なります。用途に合った方法を選びましょう。ここからは、それぞれの用途と設定手順を順に説明します。

レイヤー 1: Docker デーモンを設定する

このレベルで設定したプロキシは、イメージの pull と push、Docker Hub やプライベートレジストリへのアクセスに使われます。Docker Swarm への接続にも使用されます。

このオプションを選ぶべき場合:

• すべてのイメージ操作をプロキシ経由で実行したい;
• docker pull や docker push などのコマンドが失敗する;
• マシンからのすべてのトラフィックを社内プロキシ経由でルーティングする必要がある;
• 外部ネットワークへのアクセスがプロキシ経由でしかできない;
• Docker Swarm を使う場合。

この方法は安定しており、動作を予測しやすいのが利点です。Docker Desktop を使っていれば、グラフィカルインターフェースから簡単にプロキシを設定できます。一方、古いバージョン(< 17.x)やまれな構成では、設定がすべてのコンテナに影響し、インターネットを使わないコンテナの動作が遅くなることがあります。最近のバージョンでは設定は自動継承されないため、デーモンのプロキシがコンテナに影響することはありません。

Docker デーモンのプロキシを設定する方法は 4 つあります。

方法 1 – daemon.json を使う

この方法は Linux 専用で、Linux では推奨される設定方法です。daemon.json ファイルでプロキシの動作を設定します:

ファイルを変更したら、変更を有効にするために Docker を再起動します:

方法 2 – systemd のドロップインファイルを使う

これも Linux でのみ動作します。通常モードと rootless モードのどちらでも実行できます。

いずれの場合も、まずシステムディレクトリを作成します:

次に、/etc/systemd/system/docker.service.d/http-proxy.conf という名前のファイルを作成し、プロキシの環境変数を追加します。

HTTPS サーバーを使う場合は、変数を “HTTPS_PROXY” に変更してください。変数は複数設定できます。その後、保存して Docker を再起動します。

方法 3 – dockerd に環境変数を使う

Docker デーモンは起動前に環境変数を確認します。ただし、通常はこの方法を最初の選択肢にはしません。

方法 4 – Docker Desktop

Docker Desktop は軽量な Linux 仮想マシン上で Docker を動作させます。Docker Desktop は Windows/macOS 専用と思われがちですが、Linux でも利用できます。ただし Linux では一般的ではなく、ネイティブエンジンではなく VM 内のデーモンを管理することになります。そのため、この方法は Windows/macOS に適しています。次のパスを開いてください:

Docker Desktop > Settings > Resources > Proxies.

レイヤー 2: Docker クライアント(CLI)のプロキシを設定する

Docker クライアントは、リクエスト時にプロキシを使用します。これは CLI による API 呼び出しや、次のコマンドに適用されます: docker login, docker pull, docker push.

このオプションを選ぶべき場合:

• クライアントをプロキシ経由で認証させる必要がある;
• 外向きトラフィックに会社の制限がある;
• デーモンやコンテナに影響を与えたくない。

クライアントはすばやく簡単に設定でき、デーモンを再起動する必要もありません。ただし、コンテナのビルド時・実行時のアクセス問題や、デーモンによる push・pull のエラーは解決できません。

通常、Docker クライアントはシェルの環境変数を使って設定します。

Linux と macOS では次のようになります:

または

Windows ではこちらを使います:

注意: Windows で CMD を使うと問題が発生することがあります。PowerShell なら動作します。

もう 1 つ、めったに使われない方法もあります。コマンドごとに設定するやり方です。

レイヤー 3: コンテナのプロキシ

この方法では、コンテナ内のアプリケーションでプロキシを使用します。ビルド用にプロキシを設定することも、プロキシを指定してコンテナを実行することもできます。

このオプションを選ぶべき場合:

• コンテナが外部接続を必要としている;
• ビルドでパッケージマネージャーの実行に失敗する;
• コンテナ内のアプリが API リクエストを外部プロキシ経由でルーティングする必要がある。

コンテナごとに簡単に設定でき、一部のコンテナだけでプロキシが必要な混在環境に適しています。OS やデーモンの設定から分離できる点も利点です。ただし、ビルドや実行のたびに手動でプロキシを設定する必要があります。また、大規模なデプロイには向かず、プロキシの認証情報が漏洩するおそれもあるため、セキュリティ上のリスクを伴います。

方法 1 – ビルドごとにプロキシを設定する

方法 2 – Dockerfile を使う

Dockerfile の ENV で設定した環境変数はイメージに埋め込まれます。この方法にはセキュリティ上のリスクがあるため、本番ビルドには使用しないでください。

方法 3 – 実行ごとにプロキシを設定する

方法 4 – Docker Compose を選ぶ

これは安全で推奨される方法です:

注意: Docker の公式ドキュメントでは、2 つの異なる概念がどちらも CLI と呼ばれており、混乱するかもしれません。クライアントプログラムに影響する Docker CLI プロキシがあります。さらに Docker CLI フラグもあり、こちらはプロキシ設定をコンテナ内に注入します。影響を受けるのはコンテナであってクライアントではありません。ただし、どちらの場合もコマンドラインツールを使うことに変わりはありません。

レイヤー 4: オペレーティングシステムのプロキシ

デバイスからのすべてのトラフィックがプロキシサーバーを経由するように設定できます。この設定は Docker デーモンと Docker クライアントの両方に影響し、場合によってはコンテナや他のアプリケーションにも影響します。

このオプションを使うべき場合:

• 会社がシステムレベルでのプロキシ利用を求めている;
• Docker 以外にもプロキシを必要とするアプリがたくさんある。

この方法はシンプルで手早く、一度プロキシを設定すれば大半のコンポーネントやアプリケーションに適用されます。ただし Docker 専用の設定ではないため、問題の切り分けが難しくなります。また、コンテナがこれらの設定を自動的に継承することはほとんどないため、別途設定が必要になる場合があります。

こちらでは、さまざまな OS でプロキシを設定するステップバイステップのチュートリアルをご覧いただけます。対象には macOS や Windows.

また、Docker が提供する公式ドキュメントを参照すれば、各方法や利用可能なすべての変数について、より詳しい情報が得られます。

Docker デーモンのプロキシ設定

Docker クライアントの設定方法

Docker Desktop のプロキシ変更を調整する方法

Docker に内部プロキシはあるのか

Docker にはイメージのビルド専用として、いわゆる内部 HTTP(S) プロキシがあります。このため、外部プロキシは不要だと誤解されることがあります。

BuildKit の内部プロキシはビルド時にのみ使用され、アクセスの高速化、DNS の問題の解消、DNS 設定がビルドに漏れることの防止に役立ちます。ただし、安全な外向き接続の確立には使えず、外部プロキシの代わりにはなりません。

よくある設定の問題とそのトラブルシューティング

Docker のプロキシ関連エラーは、設定レイヤーが複数あるため解決が難しいことがあります。ここでは、特に多い 5 つの問題と対処法を紹介します。

エラー 1: docker pull/docker push が失敗する

プロキシ経由の pull が停止する、タイムアウトする、または接続を拒否される場合は、Docker デーモンがプロキシを認識していない可能性があります。Docker Engine レベルでプロキシを設定してください。

エラー 2: デーモンは動いているのに接続できない

docker pull は実行できるのに、コンテナ内で pip install などにより依存関係をインストールできない場合です。Temporary failure resolving のようなエラーが出ることがあります。最近の Docker では、デーモンのプロキシ設定がコンテナに自動適用されないために起こります。Dockerfile または Docker Compose でコンテナレベルのプロキシを設定してください。

エラー 3: NO_PROXY 変数が機能しない

設定したにもかかわらず Docker がトラフィックをプロキシ経由にしようとする、コンテナ間で通信できない、レジストリミラーが失敗するといった場合は、構文の誤りが原因かもしれません。エントリはカンマで区切り、ドメインを指定する際はプロトコルを付けないでください。

NO_PROXY=localhost,127.0.0.1,.corp.example.com,registry.internal

エラー 4: プロキシの認証情報に未対応の記号が含まれている

この場合、Docker の起動に失敗したり、プロキシ経由でトラフィックをルーティングできなかったりします。解決するには、次の記号を URL エンコードする必要があります: @, #, %, :

次のようになります:

Environment=”HTTP_PROXY=http://user:Pa%%23ss@proxy:8080″

エラー 5: Docker が Desktop のプロキシ設定を無視する

Docker Desktop でプロキシを設定してもビルドが失敗し、コンテナが接続できない場合は、別の設定方法が必要かもしれません。Docker Desktop の設定はデーモンには影響しますが、コンテナには直接適用されません。コンテナレベルでプロキシを設定してください。

まとめ

Docker とプロキシを組み合わせれば、速度、セキュリティ、効率的なデプロイを向上できます。効果を最大限に引き出すには、適切な設定方法と、合法的に調達された高品質なプロキシを選ぶことが重要です。DataImpulse は、倫理的に調達された 9,000 万以上のプロキシと、開発作業を支援する 24/7 の有人サポートを提供しています。[email protected] までお気軽にお問い合わせいただくか、”Try Now” ボタンから始めてください。 開始するには、“Try now” をクリックするか、[email protected] までご連絡ください。