Docker에서 프록시를 구성하는 방법

Methods-to-configure-proxies-in-Docker

컨테이너는 개발자가 마주하던 여러 문제를 해결하며 소프트웨어 개발에 혁신을 가져왔습니다. 컨테이너는 다양한 시스템과 기기에서 안정적이고 일관되게 작동하는 제품을 제공하도록 돕습니다. Docker는 컨테이너를 구축, 관리, 실행하는 일을 훨씬 쉽고 빠르게 만들어 컨테이너를 한 단계 더 발전시켰습니다. Docker는 타사 프록시 사용도 지원하며, 이를 위한 여러 방법을 제공합니다. 대체 IP와 함께 사용해야 하는 이유, 상황에 가장 적합한 방법, 그리고 정확한 단계별 절차를 알아보려면 계속 읽어 보십시오.

Docker에서 프록시를 사용하는 이유

안정적이고 안전하며 통제된 인터넷 액세스를 확보하기 위해서입니다. 때로는 접속 자체를 가능하게 하기 위해서이기도 합니다.

Docker는 이미지 풀링, 패키지 설치 등의 작업을 수행하려면 웹에 액세스해야 합니다. 하지만 많은 기업 네트워크는 일반적인 연결을 제공하지 않으며, 아웃바운드 트래픽이 통제되거나 제한됩니다. 보안상의 이유이지만 개발자의 작업을 방해하기도 합니다. 승인된 프록시는 때로 인터넷에 접속하고 “Connection timed out” 또는 “Unable to access www.example.com” 같은 메시지를 보지 않기 위한 유일한 방법입니다.

또한 경우에 따라 인터넷을 사용하려면 인증이 필요합니다. Docker 자체는 인증을 지원하지 않으므로 외부 프록시를 사용해야 합니다.

런타임 애플리케이션에도 외부 연결이 필요할 수 있습니다. 컨테이너가 클라우드 API, 데이터베이스, 타사 서비스 등에 연결해야 하는 경우가 있습니다. 방화벽으로 보호된 경우 대상 엔드포인트에 도달하려면 프록시가 필요합니다.

프록시를 사용하는 데는 다른 이유도 있습니다. 대체 서버를 통해 트래픽을 라우팅하면 속도 문제를 해결하고 로깅, 악성 코드, SSL 검사 등을 위한 트래픽 모니터링에 도움이 될 수 있습니다. 또한 서로 다른 유형의 서버와 머신 간 네트워크 일관성을 유지하고 IP 주소, 내부 DNS 요청, NAT 등의 내부 정보를 숨겨 보안을 강화하는 데도 도움이 됩니다.

Docker에서 프록시를 구성하는 방법

프록시를 구성할 수 있는 계층은 네 가지입니다. Docker Daemon, 다시 말해 Docker Engine, Docker Client, 컨테이너, OS 수준입니다. 각 계층에서 프록시를 설정하는 방법도 서로 다릅니다. 무엇을 선택하느냐에 따라 영향을 받는 부분도 달라집니다. 모든 옵션에는 장점이 있으므로 사용 사례에 맞게 선택해야 합니다. 각 방법이 어떤 용도에 가장 적합한지와 정확한 절차를 하나씩 살펴보겠습니다.

계층 1: Docker Daemon 구성

이 수준에서 구성한 프록시는 이미지 풀링 및 푸시, Docker Hub와 프라이빗 레지스트리 액세스를 제어합니다. Docker Swarm에 연결하는 역할도 합니다.

이 옵션을 선택할 때:

  • 모든 이미지 작업을 프록시를 통해 실행해야 합니다.
  • docker pull 또는 docker push 같은 명령이 실패합니다.
  • 머신의 모든 트래픽을 기업 프록시를 통해 라우팅해야 합니다.
  • 외부 네트워크 액세스가 프록시를 통해서만 가능합니다.
  • Docker Swarm을 사용합니다.

안정적이고 예측 가능하며, Desktop을 사용하면 그래픽 인터페이스로 프록시를 쉽게 구성할 수 있습니다. 반면 이전 버전(< 17.x)과 일부 드문 설정에서는 구성이 모든 컨테이너에 영향을 주어 인터넷을 사용하지 않는 컨테이너의 속도까지 느려질 수 있습니다. 최신 버전에서는 설정이 자동으로 상속되지 않으므로 Daemon 프록시가 컨테이너에 영향을 주지 않습니다.

Docker Daemon 프록시를 구성하는 방법은 네 가지입니다.

방법 1 – daemon.json 사용

이 방법은 Linux 전용이며 이 OS에 권장됩니다. 다음 daemon.json 파일에서 프록시 동작을 구성합니다:


{
 "proxies": {
   "http-proxy": "http://proxy.example.com:3128",
   "https-proxy": "https://proxy.example.com:3129",
   "no-proxy": "*.test.example.com,.example.org,127.0.0.0/8"
 }
}

파일을 변경한 후 변경 사항을 적용하려면 Docker를 재시작합니다:


sudo systemctl restart docker
방법 2 – systemd 드롭인 파일 사용

이 방법도 Linux에서만 작동합니다. 일반 모드와 rootless 모드에서 실행할 수 있습니다.

먼저 시스템 디렉터리를 만듭니다:


sudo mkdir -p /etc/systemd/system/docker.service.d

그런 다음 /etc/systemd/system/docker.service.d/http-proxy.conf 파일을 만들어 프록시 환경 변수를 추가합니다.


[Service]
Environment="HTTP_PROXY=http://proxy.example.com:3128"

HTTPS 서버를 사용한다면 변수를 “HTTPS_PROXY”로 변경합니다. 여러 변수를 설정할 수 있습니다. 그런 다음 저장하고 Docker를 재시작합니다.


sudo systemctl daemon-reload
sudo systemctl restart docker
방법 3 – dockerd용 환경 변수 사용

Docker Daemon은 실행 전에 환경 변수를 확인합니다. 하지만 이 방법은 보통 첫 번째 선택지는 아닙니다.


export HTTP_PROXY=...
dockerd
방법 4 – Docker Desktop

기술적으로 Docker Desktop은 경량 Linux Virtual Machine에 의존하며 이를 사용해 Docker를 구성합니다. Docker Desktop이 Windows/macOS에서만 사용할 수 있다고 들을 수 있습니다. 기술적으로는 Linux에서도 사용할 수 있지만 드물고 선택 사항이며, 네이티브 엔진이 아니라 VM 내부에서 Daemon을 관리하게 됩니다. 따라서 이 방법은 여전히 Windows/macOS에 더 적합합니다. 다음 경로로 이동합니다:

Docker Desktop > 설정 > 리소스 > 프록시.

계층 2: Docker Client(CLI) 프록시 구성

Docker Client는 요청을 수행할 때 프록시를 사용합니다. 이는 CLI가 수행하는 API 호출과 docker login, docker pull, docker push.

이 옵션을 선택할 때:

  • 클라이언트가 프록시를 통해 인증해야 합니다.
  • 기업의 아웃바운드 트래픽 제한이 있을 때입니다.
  • daemon이나 컨테이너에 영향을 주지 않아도 됩니다.

Client는 빠르고 쉽게 구성할 수 있으며 daemon을 재시작할 필요가 없습니다. 하지만 컨테이너 빌드 또는 실행 액세스 문제나 Daemon 푸시 및 풀 오류를 해결해야 한다면 이 방법은 작동하지 않습니다.

일반적으로 셸 환경 변수를 사용하여 Docker Client를 구성합니다.

Linux와 macOS에서는 다음과 같습니다:


export HTTP_PROXY=http://PROXY:PORT

또는


export HTTPS_PROXY=http://PROXY:PORT

Windows에서는 다음을 사용합니다:


setx HTTP_PROXY http://PROXY:PORT

참고: Windows에서 CMD를 사용하면 문제가 있을 수 있습니다. PowerShell은 작동합니다.

또 다른 방법도 있지만 거의 사용하지 않습니다. 명령별로 구성하는 방법입니다.


HTTP_PROXY=http://PROXY docker login

계층 3: 컨테이너 프록시

이 방법을 선택하면 컨테이너 내부 애플리케이션이 프록시를 사용합니다. 빌드용 프록시를 구성하거나 프록시와 함께 컨테이너를 실행할 수 있습니다.

이 옵션을 선택할 때:

  • 컨테이너에 외부 연결이 필요합니다.
  • 빌드에서 패키지 관리자를 실행하지 못합니다.
  • 컨테이너 내부 앱이 외부 프록시를 통해 API 요청을 라우팅해야 합니다.

컨테이너별로 쉽게 설정할 수 있고, 일부 컨테이너에는 프록시가 필요하지만 다른 컨테이너에는 필요하지 않은 혼합 환경에 적합합니다. OS 및 daemon 구성과도 깔끔하게 분리됩니다. 그러나 빌드와 실행마다 프록시를 수동으로 구성해야 합니다. 이 옵션은 대규모 배포에 가장 적합하지 않으며 프록시 자격 증명이 유출될 수 있어 보안 위험도 따릅니다.

방법 1 – 빌드별 프록시 구성

docker build \
 --build-arg HTTP_PROXY=http://PROXY:PORT \
 --build-arg HTTPS_PROXY=http://PROXY:PORT \
 -t myimage .
방법 2 – Dockerfile 사용

ENV Dockerfile 또는 환경 변수는 설정을 이미지에 포함합니다. 이 방법에는 보안 위험이 있으므로 빌드에는 사용하지 않아야 합니다.


ENV HTTP_PROXY=http://PROXY:PORT

      
        
      


ENV HTTPS_PROXY=http://PROXY:PORT
방법 3 – 실행별 프록시 구성

docker run \
 -e HTTP_PROXY=http://PROXY:PORT \
 -e HTTPS_PROXY=http://PROXY:PORT \
 image
방법 4 – Docker Compose 선택

안전하며 권장되는 옵션입니다:


environment:
 HTTP_PROXY: http://PROXY:PORT
 HTTPS_PROXY: http://PROXY:PORT
 NO_PROXY: "localhost,127.0.0.1"

참고: 공식 Docker 문서에서는 서로 다른 두 개념을 CLI라고 부르므로 혼동될 수 있습니다. 클라이언트 프로그램에 영향을 주는 Docker CLI 프록시가 있습니다. 컨테이너 내부에 프록시 설정을 주입하는 Docker CLI 플래그도 있습니다. 이는 클라이언트가 아니라 컨테이너에 영향을 줍니다. 하지만 두 경우 모두 명령줄 도구를 사용합니다.

계층 4: 운영 체제 프록시

기기의 모든 트래픽이 프록시 서버를 통하도록 설정할 수 있습니다. Docker Daemon과 Docker Client 모두에 영향을 주며, 때로는 컨테이너와 사용하는 다른 모든 앱에도 영향을 줄 수 있습니다.

이 옵션을 사용할 때:

  • 회사가 시스템 수준의 프록시 사용을 요구합니다.
  • Docker 외에도 프록시가 필요한 앱이 많습니다.

이 방법은 간단하고 빠릅니다. 프록시를 한 번 구성하면 해당 설정이 대부분의 구성 요소와 앱에서 작동합니다. 하지만 Docker 전용이 아니므로 디버깅이 더 어려워집니다. 또한 컨테이너가 그 설정을 자동으로 상속하는 경우는 매우 드무므로 별도로 구성해야 할 수도 있습니다.

여기에서 macOS 및 Windows.

또한 Docker가 제공하는 공식 문서에서 각 방법과 사용 가능한 모든 변수에 관한 자세한 내용을 확인할 수 있습니다.

Docker Daemon 프록시 구성

Docker Client를 구성하는 방법

Docker Desktop 프록시 변경 사항을 조정하는 방법

Docker에 내부 프록시가 있습니까?

Docker는 이미지 빌드 전용으로 이른바 내부 HTTP(S) 프록시를 제공하며, 외부 프록시가 필요하지 않다고 생각하는 사람이 있어 혼동을 일으킵니다.

BuildKit 내부 프록시는 빌드에만 사용되며 액세스 속도를 높이고 DNS 문제를 없애며 DNS 설정이 빌드에 유출되는 것을 방지합니다. 하지만 안전한 아웃바운드 연결을 설정하는 데는 도움이 되지 않습니다. 프록시 대신 사용할 수는 없습니다.

일반적인 구성 문제와 해결 방법

Docker는 여러 계층으로 이루어져 있어 프록시 관련 오류를 해결하기가 까다로울 수 있습니다. 가장 흔한 문제 다섯 가지와 해결 방법을 소개합니다.

오류 1: Docker pull/docker push 실패

프록시 풀링이 멈추거나 시간 초과되고, 연결이 거부되는 경우 Docker Daemon이 프록시를 인식하지 못한다는 뜻입니다. 해결하려면 엔진 수준에서 프록시를 구성합니다.

오류 2: Daemon이 작동해도 연결되지 않음

동시에 dicker pull은 작동하지만 컨테이너는 pip install 및 다른 종속 항목을 실행하지 못합니다. Temporary failure resolving 같은 오류가 발생할 수 있습니다. 최신 Docker 버전에서는 Daemon 프록시가 컨테이너 내부에 자동으로 적용되지 않기 때문에 이런 상황이 발생합니다. 해결하려면 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 프록시 설정을 무시함

Desktop을 사용해 프록시를 설정했는데 빌드가 실패하고 컨테이너가 연결을 설정하지 못한다면 다른 구성 옵션을 사용해야 한다는 신호일 수 있습니다. Desktop은 Daemon에 영향을 주지만 컨테이너에는 직접 영향을 주지 않습니다. 컨테이너 수준 프록시 설정을 시도하십시오.

정리

Docker와 프록시의 조합은 속도, 보안, 효율적인 배포를 제공합니다. 이를 최대한 활용하려면 적합한 구성을 선택하고, 물론 적법하게 확보한 고품질 프록시를 선택해야 합니다. DataImpulse는 이를 지원합니다. 윤리적으로 확보한 90+million 프록시와 개발 작업을 돕는 24/7 인력 지원을 제공합니다. [email protected]으로 문의하거나 “Try Now” 버튼을 눌러 시작하십시오. 시작하려면 “지금 사용해 보기” 또는 [email protected]로 문의하십시오.

Share article: