Proxy Docker: Panduan Lengkap Agar Kontainer Berfungsi di Balik Firewall Perusahaan

Sebagian besar jaringan perusahaan menggunakan server proxy untuk memantau dan menyaring lalu lintas internet. Ini menciptakan hambatan saat Docker mencoba menarik image dari registry. Anda akan mengalami timeout koneksi, kesalahan autentikasi, dan build yang gagal padahal berhasil di jaringan rumah. Masalah terkait proxy ini dapat mengganggu tim pengembang yang tidak dapat mengakses image dasar yang mereka butuhkan.

Konfigurasi proxy Docker menyelesaikan masalah konektivitas ini sekaligus memberikan peningkatan kinerja melalui caching dan memenuhi persyaratan keamanan perusahaan. Setelah dikonfigurasi, kontainer Anda akan menarik image terlepas dari pembatasan jaringan.

Dalam tutorial ini, saya akan memandu Anda menyiapkan pengaturan proxy daemon Docker, mengonfigurasi variabel lingkungan kontainer, dan menangani konfigurasi proxy di Docker Compose.

Baru mengenal Docker dan merasa kewalahan dengan semua konsep jaringan? Mulai dari dasar-dasar Docker dan bangun kepercayaan diri Anda selangkah demi selangkah.

Memahami Arsitektur Proxy Docker

Bagian-bagian berbeda dari ekosistem Docker memerlukan konfigurasi proxy di lapisan yang berbeda.

Proxy bertindak sebagai perantara antara komponen Docker Anda dan jaringan eksternal. Ketika Docker perlu menarik image, kontainer memerlukan akses internet, atau build membutuhkan sumber daya eksternal, server proxy mengendalikan dan memantau koneksi ini. Mereka berada di antara aplikasi berkontainer Anda dan dunia luar, menyaring permintaan dan respons.

Organisasi menggunakan proxy dengan Docker untuk kinerja, keamanan, dan kepatuhan.

Kinerja didapat dari caching sumber daya yang sering diakses seperti image dasar, mengurangi waktu unduh di seluruh tim Anda. Manfaat keamanan mencakup penyaringan lalu lintas, pemindaian malware, dan memblokir akses ke situs yang tidak sah. Persyaratan kepatuhan mewajibkan semua lalu lintas jaringan melewati saluran yang dipantau dengan kontrol akses dan jejak audit yang tepat.

Konfigurasi proxy Docker terjadi pada empat lapisan:

• Proxy klien: memengaruhi perintah Docker CLI seperti docker pull dan docker push

• Proxy daemon: mengontrol bagaimana daemon Docker mengakses registry eksternal  

• Proxy saat runtime kontainer: menetapkan variabel proxy untuk aplikasi di dalam kontainer

• Proxy saat build: menangani pengaturan proxy selama operasi docker build saat Dockerfile memerlukan akses internet

Setiap lapisan memiliki tujuan dan memerlukan pendekatan konfigurasi tersendiri.

Memahami jaringan Docker dimulai dengan memahami cara kontainer berkomunikasi. 

Mengonfigurasi Docker untuk Menggunakan Proxy

Agar Docker berfungsi dengan proxy perusahaan Anda, Anda perlu menyiapkan daemon dan klien Docker.

Mengapa? Karena keduanya menangani jenis permintaan jaringan yang berbeda. 

Daemon mengelola penarikan image, push, dan autentikasi registry, sementara klien menangani operasi CLI dan panggilan API. Melewatkan salah satu konfigurasi akan meninggalkan celah di mana operasi Docker dapat gagal dengan kesalahan koneksi.

Cara mengonfigurasi daemon Docker

Daemon Docker membaca pengaturan proxy dari /etc/docker/daemon.json. Buat file ini jika belum ada:

{
  "proxies": {
    "default": {
      "httpProxy": "http://proxy.company.com:8080",
      "httpsProxy": "http://proxy.company.com:8080",
      "noProxy": "localhost,127.0.0.1,.company.com"
    }
  }
}Didukung oleh

Kolom noProxy mencantumkan alamat yang harus melewati proxy. Sertakan domain registry internal dan alamat localhost Anda di sini.

Menyiapkan override layanan systemd

Di sistem Linux berbasis systemd, Anda juga perlu mengonfigurasi layanan Docker itu sendiri untuk menggunakan proxy. Buat direktori override dan file konfigurasinya:

sudo mkdir -p /etc/systemd/system/docker.service.d
sudo nano /etc/systemd/system/docker.service.d/http-proxy.confDidukung oleh

Lalu, tambahkan variabel lingkungan ini ke file http-proxy.conf:

[Service]
Environment="HTTP_PROXY=http://proxy.company.com:8080"
Environment="HTTPS_PROXY=http://proxy.company.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1,.company.com"Didukung oleh

Ini memastikan proses daemon Docker itu sendiri dapat menjangkau layanan eksternal melalui proxy Anda.

Docker tidak akan mengambil perubahan proxy sampai Anda memulai ulang daemon. Jalankan perintah ini untuk memuat ulang systemd dan memulai ulang Docker:

sudo systemctl daemon-reload
sudo systemctl restart dockerDidukung oleh

Reload daemon memberi tahu systemd untuk membaca konfigurasi layanan baru, sementara restart Docker menerapkan perubahan daemon.json.

Pertimbangan khusus platform

Docker Desktop menangani konfigurasi proxy berbeda dari instalasi server. Di Windows dan macOS, gunakan GUI Docker Desktop untuk mengatur proxy di bagian Resources - Proxies. Pengaturan ini otomatis mengonfigurasi daemon dan klien.

Host Linux yang menggunakan Docker Engine memerlukan konfigurasi manual seperti dijelaskan di atas. Beberapa distribusi mengemas Docker secara berbeda, jadi periksa apakah sistem Anda menggunakan dockerd secara langsung atau melalui manajer layanan yang berbeda.

Memverifikasi konfigurasi Anda

Uji bahwa Docker dapat menjangkau registry eksternal dengan perintah pull sederhana:

docker pull hello-worldDidukung oleh

Anda juga dapat memeriksa konfigurasi efektif daemon:

docker system info | grep -i proxyDidukung oleh

Ini akan menampilkan apakah Docker mendeteksi dan menerapkan pengaturan proxy Anda.

Jika pull masih gagal, periksa log server proxy Anda untuk memastikan Docker merutekan permintaan dengan benar.

Masalah jaringan membuat Anda buntu? Buka port Docker dengan benar untuk menghindari sakit kepala konektivitas.

Menetapkan Variabel Lingkungan Proxy

Perintah Docker CLI memerlukan konfigurasi proxy tersendiri terpisah dari pengaturan daemon. Variabel lingkungan memberi Anda kontrol fleksibel atas bagaimana klien Docker terhubung melalui proxy perusahaan.

Proxy klien mengontrol operasi Docker CLI seperti docker pull, docker push, dan docker login. Saat Anda menjalankan perintah ini, klien Docker membuat permintaan HTTP ke registry dan perlu tahu server proxy mana yang digunakan. Tanpa pengaturan proxy klien, operasi ini akan gagal meskipun daemon telah dikonfigurasi dengan benar.

Metode konfigurasi JSON

Pendekatan terbersih menggunakan file konfigurasi Docker di ~/.docker/config.json:

{
  "proxies": {
    "default": {
      "httpProxy": "http://proxy.company.com:8080",
      "httpsProxy": "http://proxy.company.com:8080",
      "noProxy": "localhost,127.0.0.1,.company.com"
    }
  }
}Didukung oleh

Metode ini menjaga pengaturan proxy tetap berada dalam konfigurasi Docker dan tidak memengaruhi aplikasi lain di sistem Anda.

Alternatif variabel lingkungan

Anda juga dapat menetapkan variabel lingkungan proxy standar yang akan dideteksi otomatis oleh Docker dengan menggunakan perintah ini:

export HTTP_PROXY=http://proxy.company.com:8080
export HTTPS_PROXY=http://proxy.company.com:8080
export NO_PROXY=localhost,127.0.0.1,.company.comDidukung oleh

Variabel ini berfungsi untuk aplikasi apa pun yang mematuhi standar proxy - bukan hanya Docker.

Konfigurasi global vs per pengguna

Untuk konfigurasi seluruh sistem, tambahkan variabel lingkungan ke /etc/environment atau buat skrip di /etc/profile.d/:

# /etc/profile.d/proxy.sh
export HTTP_PROXY=http://proxy.company.com:8080
export HTTPS_PROXY=http://proxy.company.com:8080
export NO_PROXY=localhost,127.0.0.1,.company.comDidukung oleh

Untuk konfigurasi per pengguna, tambahkan ke profil shell Anda (~/.bashrc, ~/.zshrc) atau gunakan metode konfigurasi JSON. Pengaturan per pengguna memberi pengembang fleksibilitas untuk menggunakan proxy berbeda atau melewatinya sepenuhnya untuk pengujian.

Pertimbangan keamanan

Jangan pernah menanamkan nama pengguna dan kata sandi secara hardcode di file konfigurasi atau variabel lingkungan. 

Kredensial proxy dalam teks biasa menimbulkan risiko keamanan, terutama di lingkungan bersama atau sistem kontrol versi.

Sebagai gantinya, gunakan pendekatan berikut:

• Konfigurasikan server proxy Anda untuk autentikasi berbasis IP bila memungkinkan
• Gunakan credential helper atau sistem penyimpanan aman untuk autentikasi
• Siapkan akun layanan dengan izin minimal untuk operasi Docker

Jika Anda harus menyertakan kredensial, gunakan format http://username:[email protected]:8080, namun simpan ini di file yang dilindungi dengan izin terbatas.

Konfigurasi proxy saat build

Build Docker memerlukan pengaturan proxy yang diteruskan secara eksplisit melalui argumen build:

docker build \
  --build-arg HTTP_PROXY=http://proxy.company.com:8080 \
  --build-arg HTTPS_PROXY=http://proxy.company.com:8080 \
  --build-arg NO_PROXY=localhost,127.0.0.1 \
  -t myapp .Didukung oleh

Argumen build menjadi variabel lingkungan di dalam konteks build.

Ini memungkinkan instruksi RUN mengunduh paket dan dependensi melalui proxy Anda. Tanpa argumen ini, build akan gagal saat Dockerfile mencoba memasang perangkat lunak atau mengambil sumber daya dari internet.

Pengaturan proxy saat build tidak bertahan di image final kecuali Anda secara eksplisit menetapkannya dengan instruksi ENV di Dockerfile Anda.

Variabel lingkungan memberi Anda fleksibilitas untuk menangani pengaturan proxy pada tingkat yang tepat untuk alur kerja Anda.

Apakah Anda merasa argumen build membingungkan? Kuasai build args Docker dengan contoh nyata yang benar-benar berfungsi.

Injeksi Proxy pada Kontainer dan Saat Build

Konfigurasi klien Docker baru setengah jalan — kontainer dan build Anda memerlukan pengaturan proxy sendiri. Di bagian ini, saya akan menunjukkan cara menyuntikkan konfigurasi proxy saat runtime dan saat build.

Variabel lingkungan saat runtime

Kontainer tidak mewarisi pengaturan proxy host Anda.

Anda perlu meneruskan variabel proxy secara eksplisit saat memulai kontainer. Docker memberi Anda beberapa cara untuk melakukan ini, bergantung pada apakah Anda ingin mengonfigurasi semua kontainer atau hanya yang spesifik.

Konfigurasi JSON adalah pendekatan terbersih untuk pengaturan proxy yang konsisten — seperti dibahas sebelumnya. Ringkasnya, tambahkan ini ke ~/.docker/config.json Anda:

{
  "proxies": {
    "default": {
      "httpProxy": "http://proxy.company.com:8080",
      "httpsProxy": "http://proxy.company.com:8080",
      "noProxy": "localhost,127.0.0.1,.company.com"
    }
  }
}Didukung oleh

Docker secara otomatis menyuntikkan variabel ini ke setiap kontainer yang Anda mulai. Tidak perlu flag tambahan.

Flag CLI memberi Anda kontrol lebih per kontainer:

docker run \
  --env HTTP_PROXY=http://proxy.company.com:8080 \
  --env HTTPS_PROXY=http://proxy.company.com:8080 \
  --env NO_PROXY=localhost,127.0.0.1 \
  nginxDidukung oleh

Anda juga dapat meneruskan seluruh file lingkungan:

# proxy.env
HTTP_PROXY=http://proxy.company.com:8080
HTTPS_PROXY=http://proxy.company.com:8080
NO_PROXY=localhost,127.0.0.1

docker run --env-file proxy.env nginxDidukung oleh

Kontainer yang sudah ada dapat menerima variabel proxy yang disuntikkan setelah startup menggunakan docker exec:

docker exec -e HTTP_PROXY=http://proxy.company.com:8080 container_name curl google.comDidukung oleh

Pendekatan ini cocok untuk perintah satu kali tetapi tidak bertahan saat kontainer dimulai ulang.

Konfigurasi proxy saat build

Build image akan gagal di lingkungan proxy kecuali Anda secara eksplisit meneruskan pengaturan proxy.

Argumen build adalah cara standar untuk menyuntikkan variabel proxy selama build:

docker build \
  --build-arg HTTP_PROXY=http://proxy.company.com:8080 \
  --build-arg HTTPS_PROXY=http://proxy.company.com:8080 \
  --build-arg NO_PROXY=localhost,127.0.0.1 \
  --tag myapp .Didukung oleh

Dockerfile Anda perlu mendeklarasikan argumen ini untuk menggunakannya:

ARG HTTP_PROXY
ARG HTTPS_PROXY
ARG NO_PROXY

# Use proxy for package installation
RUN apt-get update && apt-get install -y curl

# Don't persist proxy in final imageDidukung oleh

Deklarasi Dockerfile memungkinkan Anda menetapkan nilai default proxy:

ARG HTTP_PROXY=http://proxy.company.com:8080
ARG HTTPS_PROXY=http://proxy.company.com:8080

ENV HTTP_PROXY=$HTTP_PROXY
ENV HTTPS_PROXY=$HTTPS_PROXY

RUN pip install requestsDidukung oleh

Instruksi ENV membuat variabel proxy tersedia untuk semua perintah RUN berikutnya dalam build Anda.

Perlu diketahui bahwa keterbatasan BuildKit dapat menyebabkan masalah proxy pada versi Docker yang lebih baru. BuildKit menyimpan cache konteks build secara agresif, yang kadang-kadang mengabaikan perubahan proxy.

Anda dapat memaksa BuildKit mengenali pembaruan proxy:

DOCKER_BUILDKIT=1 docker build \
  --no-cache \
  --build-arg HTTP_PROXY=$HTTP_PROXY \
  --tag myapp .Didukung oleh

Atau, Anda dapat menonaktifkan BuildKit sepenuhnya untuk build yang sensitif terhadap proxy:

DOCKER_BUILDKIT=0 docker build --build-arg HTTP_PROXY=$HTTP_PROXY --tag myapp .Didukung oleh

Untuk multi-stage build, mereka memerlukan konfigurasi proxy yang konsisten di semua stage:

ARG HTTP_PROXY
ARG HTTPS_PROXY
ARG NO_PROXY

# Build stage
FROM python:3.13 AS builder
ENV HTTP_PROXY=$HTTP_PROXY
ENV HTTPS_PROXY=$HTTPS_PROXY
ENV NO_PROXY=$NO_PROXY

COPY requirements.txt .
RUN pip install -r requirements.txt

# Runtime stage
FROM python:3.13-slim AS runtime
ENV HTTP_PROXY=$HTTP_PROXY
ENV HTTPS_PROXY=$HTTPS_PROXY
ENV NO_PROXY=$NO_PROXY

COPY --from=builder /usr/local/lib/python*/site-packages /usr/local/lib/python*/site-packages
RUN apt-get update && apt-get install -y curl

# Clear proxy variables for final image
ENV HTTP_PROXY=
ENV HTTPS_PROXY=
ENV NO_PROXY=Didukung oleh

Setiap stage mewarisi argumen build tetapi tidak mewarisi variabel lingkungan dari stage sebelumnya. Tetapkan variabel proxy secara eksplisit di setiap stage yang membutuhkannya.

Singkatnya — konfigurasikan sekali, suntikkan di mana-mana.

Bingung tentang ENTRYPOINT versus CMD di kontainer Anda yang menggunakan proxy? Dapatkan penjelasan lengkap dengan contoh praktis.

Mengonfigurasi Package Manager untuk Menggunakan Proxy di Dalam Kontainer

Pengaturan proxy Docker tidak otomatis diterapkan ke package manager di dalam kontainer Anda. Anda perlu mengonfigurasi setiap package manager secara terpisah untuk mengunduh paket melalui proxy perusahaan Anda.

Package manager seperti apt-get, yum, dan apk membuat koneksi HTTP langsung ke repositori paket. Di lingkungan jaringan yang dibatasi, koneksi ini akan gagal kecuali package manager mengetahui server proxy Anda.

Variabel lingkungan standar tidak cukup. Sebagian besar package manager memiliki file konfigurasi sendiri yang menimpa pengaturan proxy tingkat sistem.

Ubuntu/Debian: konfigurasi apt-get

Buat file konfigurasi proxy yang akan dibaca apt-get selama pemasangan paket.

Tambahkan ini ke Dockerfile Anda:

FROM python:3.13

# Configure apt proxy
RUN echo 'Acquire::http::Proxy "http://proxy.company.com:8080";' > /etc/apt/apt.conf.d/proxy.conf && \
    echo 'Acquire::https::Proxy "http://proxy.company.com:8080";' >> /etc/apt/apt.conf.d/proxy.conf

RUN apt-get update && apt-get install -y curl wgetDidukung oleh

File /etc/apt/apt.conf.d/proxy.conf memberi tahu apt-get untuk merutekan semua unduhan paket melalui proxy Anda. File ini bertahan di seluruh perintah RUN dalam build Anda.

Anda juga dapat menetapkan pengecualian proxy untuk repositori internal:

RUN echo 'Acquire::http::Proxy::internal.company.com "DIRECT";' >> /etc/apt/apt.conf.d/proxy.confDidukung oleh

Alpine Linux: konfigurasi apk

Alpine menggunakan package manager apk, yang membaca pengaturan proxy dari /etc/apk/repositories dan variabel lingkungan.

FROM python:3.13-alpine

# Configure apk proxy
ENV HTTP_PROXY=http://proxy.company.com:8080
ENV HTTPS_PROXY=http://proxy.company.com:8080

RUN apk add --no-cache curl wgetDidukung oleh

apk milik Alpine mematuhi variabel lingkungan proxy HTTP standar, jadi Anda tidak memerlukan file konfigurasi terpisah. Namun Anda dapat membuatnya untuk kontrol lebih lanjut:

RUN echo 'http_proxy=http://proxy.company.com:8080' > /etc/environment && \
    echo 'https_proxy=http://proxy.company.com:8080' >> /etc/environmentDidukung oleh

CentOS/RHEL: konfigurasi yum

Sistem CentOS dan RHEL menggunakan yum atau dnf, yang membaca pengaturan proxy dari /etc/yum.conf.

FROM centos:8

# Configure yum proxy
RUN echo 'proxy=http://proxy.company.com:8080' >> /etc/yum.conf

RUN yum update -y && yum install -y curl wgetDidukung oleh

Untuk versi CentOS yang lebih baru yang menggunakan dnf, gunakan berikut ini:

FROM centos:stream9

# Configure dnf proxy
RUN echo 'proxy=http://proxy.company.com:8080' >> /etc/dnf/dnf.conf

RUN dnf update -y && dnf install -y curl wgetDidukung oleh

Anda juga dapat mengecualikan domain tertentu dari perutean proxy dengan menambahkan perintah ini:

RUN echo 'proxy_exclude=internal.company.com,localhost' >> /etc/yum.confDidukung oleh

Menguji fungsionalitas proxy

Pertama, Anda perlu memverifikasi bahwa package manager Anda dapat menjangkau repositori melalui proxy.

Tambahkan perintah uji ke Dockerfile Anda:

FROM python:3.13

# Configure proxy
RUN echo 'Acquire::http::Proxy "http://proxy.company.com:8080";' > /etc/apt/apt.conf.d/proxy.conf

# Test package manager connectivity
RUN apt-get update && \
    apt-get install -y --dry-run curl && \
    echo "Package manager proxy test passed"

# Install actual packages
RUN apt-get install -y curl python3-pipDidukung oleh

Flag --dry-run menguji resolusi paket tanpa benar-benar memasang apa pun. Jika berhasil, konfigurasi proxy Anda berfungsi.

Anda juga dapat menguji dengan output verbose untuk debug masalah koneksi:

RUN apt-get -o Debug::Acquire::http=true updateDidukung oleh

Ini menunjukkan tepatnya URL mana yang coba diakses oleh apt-get dan apakah koneksi proxy berhasil.

Untuk pengujian Alpine, gunakan berikut ini:

RUN apk update --verbose && \
    apk add --simulate curl && \
    echo "Alpine proxy test passed"Didukung oleh

Sebagai rangkuman, konfigurasikan setiap package manager secara individual, dan build Anda akan berfungsi di balik proxy apa pun.

Perlu membersihkan artefak build terkait proxy? Perintah docker prune akan mengosongkan ruang dan menjaga sistem Anda tetap bersih.

Implementasi Proxy Lanjutan

Proxy HTTP dasar membantu Anda memulai, tetapi lingkungan produksi memerlukan kontrol lebih atas akses registry dan caching image. Berikut cara menyiapkan proxy caching dan mirror registry untuk kinerja dan keandalan yang lebih baik.

Registry proxy dengan caching

Menarik image dasar yang sama berulang kali membuang bandwidth dan memperlambat build.

Proxy caching berada di antara klien Docker Anda dan registry eksternal seperti Docker Hub. Mereka menyimpan image yang sering diakses secara lokal, sehingga penarikan berikutnya berasal dari jaringan internal Anda, bukan internet.

Pilihan paling populer untuk lingkungan enterprise adalah Harbor:

# docker-compose.yml for Harbor
version: '3.8'
services:
  harbor-core:
    image: goharbor/harbor-core:v2.8.0
    environment:
      - CORE_SECRET=your-secret-key
      - JOBSERVICE_SECRET=your-job-secret
    ports:
      - "80:8080"
    volumes:
      - ./harbor.yml:/etc/core/app.confDidukung oleh

Anda dapat mengonfigurasi Harbor sebagai proxy cache dengan mengedit harbor.yml:

# harbor.yml
hostname: harbor.company.com
http:
  port: 80

database:
  password: harbor-db-password

data_volume: /data

proxy_cache:
  - endpoint: https://registry-1.docker.io
    username: your-dockerhub-username
    password: your-dockerhub-tokenDidukung oleh

Jika Anda memerlukan alternatif yang lebih sederhana untuk caching dasar, gunakan Docker Registry Proxy. Berikut caranya:

docker run -d \
  --name registry-proxy \
  -p 5000:5000 \
  -e REGISTRY_PROXY_REMOTEURL=https://registry-1.docker.io \
  -v registry-cache:/var/lib/registry \
  registry:2Didukung oleh

Lalu, arahkan klien Docker Anda ke proxy caching:

{
  "registry-mirrors": ["http://harbor.company.com"]
}Didukung oleh

Berikut semua manfaat yang Anda dapatkan dengan proxy caching:

• Penarikan image lebih cepat setelah unduhan pertama
• Penggunaan bandwidth internet berkurang
• Keandalan build lebih baik saat registry eksternal bermasalah
• Kontrol akses terpusat dan pemindaian image

Mirror registry dan BuildKit

Mirror registry memungkinkan Anda mengalihkan penarikan image ke registry internal atau yang secara geografis lebih dekat.

Konfigurasi mirror tunggal merutekan semua permintaan Docker Hub melalui satu mirror:

{
  "registry-mirrors": ["https://mirror.company.com"],
  "insecure-registries": ["harbor.company.com:5000"]
}Didukung oleh

Tambahkan ini ke /etc/docker/daemon.json dan mulai ulang Docker. Semua perintah docker pull akan mencoba mirror terlebih dahulu, lalu kembali ke Docker Hub jika mirror tidak tersedia.

Beberapa mirror memberikan redundansi:

{
  "registry-mirrors": [
    "https://mirror1.company.com",
    "https://mirror2.company.com",
    "https://registry-1.docker.io"
  ]
}Didukung oleh

Docker akan mencoba mirror secara berurutan hingga salah satunya berhasil.

Penyiapan mirror untuk BuildKit memerlukan konfigurasi terpisah karena BuildKit melewati beberapa pengaturan daemon:

# buildkitd.toml
debug = true

[registry."docker.io"]
  mirrors = ["mirror.company.com"]

[registry."mirror.company.com"]
  http = true
  insecure = trueDidukung oleh

Anda dapat menjalankan BuildKit dengan konfigurasi kustom:

buildkitd --config=/etc/buildkit/buildkitd.tomlDidukung oleh

Atau, gunakan konfigurasi mirror inline milik BuildKit:

docker buildx create \
  --name mybuilder \
  --config /etc/buildkit/buildkitd.toml \
  --useDidukung oleh

Terakhir, uji penyiapan mirror Anda dengan membangun image yang menarik dari Docker Hub:

FROM python:3.13-slim
RUN pip install requestsDidukung oleh

docker build --progress=plain .Didukung oleh

Flag --progress=plain menampilkan registry mana yang sebenarnya dihubungi BuildKit. Anda seharusnya melihat URL mirror Anda di output build.

Selesai!

Mengelola penyiapan proxy multi-kontainer yang kompleks? Docker Compose menyederhanakan jaringan dan penemuan layanan.

Penguatan Keamanan

Konfigurasi proxy membuka kemungkinan serangan baru yang perlu diperhatikan dengan saksama. Berikut cara mengunci akses soket Docker dan melindungi kredensial proxy dari paparannya.

Proxy soket Docker

Mengekspos soket Docker secara langsung menciptakan risiko keamanan besar.

Soket Docker (/var/run/docker.sock) memberikan akses setara root ke seluruh sistem host Anda. Proses apa pun yang dapat menulis ke soket ini dapat menjalankan kontainer dengan akses filesystem host, meningkatkan hak istimewa, atau sepenuhnya keluar dari isolasi kontainer.

Mount soket secara langsung itu berbahaya:

# JANGAN LAKUKAN INI
docker run -v /var/run/docker.sock:/var/run/docker.sock myappDidukung oleh

Pola ini muncul dalam penyiapan Docker-in-Docker dan pipeline CI/CD, tetapi ini mimpi buruk keamanan. Kontainer yang terkompromi dapat mengendalikan seluruh daemon Docker.

Layanan proxy soket menciptakan lapisan perantara yang lebih aman. Mereka menyaring panggilan API Docker dan membatasi apa yang sebenarnya dapat dilakukan kontainer.

Gunakan docker-socket-proxy dari Tecnativa:

# docker-compose.yml
version: '3.8'
services:
  docker-proxy:
    image: tecnativa/docker-socket-proxy
    environment:
      - CONTAINERS=1
      - IMAGES=1
      - NETWORKS=1
      - VOLUMES=1
      - BUILD=0
      - COMMIT=0
      - CONFIGS=0
      - SECRETS=0
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    ports:
      - "2375:2375"Didukung oleh

Proxy mengekspos hanya endpoint API Docker tertentu. Atur variabel lingkungan ke 1 untuk operasi yang diizinkan dan 0 untuk yang diblokir.

Aplikasi Anda terhubung ke proxy alih-alih soket mentah:

docker run --env DOCKER_HOST=tcp://docker-proxy:2375 myappDidukung oleh

Berikut beberapa strategi penguatan soket tambahan yang perlu diikuti:

• Jalankan proxy soket pada segmen jaringan terpisah
• Gunakan autentikasi TLS antara klien dan proxy
• Pantau log proxy soket untuk panggilan API yang mencurigakan
• Putar kredensial akses proxy secara berkala

Manajemen kredensial

Kredensial proxy dalam URL teks biasa muncul di mana-mana — log, daftar proses, dump lingkungan.

Jangan pernah menanamkan kredensial dalam URL proxy:

# RISIKO KEAMANAN - kredensial terlihat di daftar proses
export HTTP_PROXY=http://admin:[email protected]:8080Didukung oleh

Siapa pun yang memiliki akses ke ps aux atau dump variabel lingkungan dapat melihat kata sandi proxy Anda. Ini termasuk log aplikasi, inspeksi kontainer, dan alat pemantauan sistem.

Sebagai gantinya, gunakan file autentikasi:

# Buat file kredensial dengan izin terbatas
echo "admin:password123" > ~/.proxy-creds
chmod 600 ~/.proxy-creds

# Konfigurasikan proxy tanpa menanamkan kredensial
export HTTP_PROXY=http://proxy.company.com:8080Didukung oleh

Konfigurasikan server proxy Anda untuk membaca kredensial dari file atau gunakan sistem autentikasi eksternal.

Proxy TLS mengenkripsi semua lalu lintas proxy termasuk jabat tangan autentikasi:

# Proxy HTTPS mengenkripsi kredensial saat transit
export HTTPS_PROXY=https://proxy.company.com:8443Didukung oleh

Siapkan server proxy Anda dengan sertifikat TLS yang tepat — baik dari CA atau sertifikat self-signed yang didistribusikan ke mesin klien.

Autentikasi berbasis sertifikat menghilangkan kata sandi sepenuhnya:

# Autentikasi sertifikat klien
export HTTPS_PROXY=https://proxy.company.com:8443
curl --cert client.crt --key client.key --cacert proxy-ca.crt https://example.comDidukung oleh

Proxy memvalidasi sertifikat klien alih-alih kombinasi nama pengguna/kata sandi. Sertifikat dapat dicabut secara individual jika terkompromi.

Manajemen secret Kubernetes menjaga kredensial proxy tetap berada di luar image kontainer:

apiVersion: v1
kind: Secret
metadata:
  name: proxy-credentials
type: Opaque
data:
  username: YWRtaW4=  # base64 encoded
  password: cGFzc3dvcmQxMjM=  # base64 encodedDidukung oleh

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: myapp
        env:
        - name: PROXY_USER
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: username
        - name: PROXY_PASS
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: passwordDidukung oleh

Secret tetap terenkripsi saat disimpan dan disuntikkan saat runtime tanpa muncul di layer image.

Kunci akses soket dan enkripsi kredensial Anda — diri Anda di masa depan akan berterima kasih.

Mempertimbangkan alternatif Docker untuk penyiapan proxy Anda? Bandingkan Docker versus Podman untuk memilih alat kontainerisasi yang tepat.

Pemecahan Masalah Umum

Masalah proxy muncul sebagai timeout, kegagalan koneksi, dan kesalahan build yang misterius yang berjalan baik-baik saja di luar jaringan Anda. Berikut pendekatan sistematis untuk mendiagnosis dan memperbaiki masalah proxy Docker paling umum.

Pendekatan diagnostik terstruktur

Mulailah dari dasar dan naik secara bertahap.

Langkah 1: Verifikasi konektivitas proxy dari host

Uji apakah server proxy Anda dapat dijangkau:

curl -x http://proxy.company.com:8080 https://registry-1.docker.io/v2/Didukung oleh

Jika ini gagal, konfigurasi proxy atau perutean jaringan Anda bermasalah. Hubungi tim jaringan Anda sebelum menelusuri masalah Docker.

Langkah 2: Periksa pengaturan proxy daemon Docker

Verifikasi bahwa daemon membaca konfigurasi proxy Anda:

docker info | grep -i proxyDidukung oleh

Anda harus melihat URL proxy Anda terdaftar. Jika tidak ada, periksa /etc/docker/daemon.json dan mulai ulang layanan Docker.

Langkah 3: Uji operasi klien Docker

Coba tarik image sederhana:

docker pull hello-worldDidukung oleh

Jika berhasil, berarti pengaturan proxy klien Anda berfungsi. Kegagalan mengarah ke masalah proxy tingkat daemon.

Langkah 4: Uji konektivitas tingkat kontainer

Jalankan kontainer dan uji koneksi keluar:

docker run --rm \
  -e HTTP_PROXY=http://proxy.company.com:8080 \
  -e HTTPS_PROXY=http://proxy.company.com:8080 \
  python:3.13-slim \
  python -c "import urllib.request; print(urllib.request.urlopen('https://pypi.org').getcode())"Didukung oleh

Ini mengisolasi apakah masalahnya ada pada operasi Docker atau jaringan kontainer.

Masalah umum dan solusinya

Masalah: docker pull timeout

Anda akan melihat kesalahan ini saat Docker tidak dapat menjangkau registry eksternal:

Error response from daemon: Get "https://registry-1.docker.io/v2/": dial tcp: lookup registry-1.docker.io: no such hostDidukung oleh

Mulailah dengan menguji konektivitas dasar untuk mengisolasi di mana masalah terjadi:

# Periksa apakah resolusi DNS berfungsi melalui proxy
nslookup registry-1.docker.io

# Uji akses langsung ke registry
curl -I https://registry-1.docker.io/v2/

# Verifikasi konfigurasi proxy daemon
sudo journalctl -u docker.service | grep -i proxyDidukung oleh

Perbaiki ini dengan mengatasi masalah DNS dan konfigurasi proxy:

• Tambahkan server DNS ke /etc/docker/daemon.json

• Konfigurasikan NO_PROXY untuk server DNS internal

• Periksa apakah proxy mendukung metode HTTPS CONNECT

Masalah: Instalasi paket gagal saat build

Package manager di dalam kontainer tidak dapat menjangkau repositori, menampilkan kesalahan seperti ini:

E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/jammy/ReleaseDidukung oleh

Uji konektivitas package manager langsung di kontainer sementara:

# Uji konektivitas package manager di kontainer yang berjalan
docker run -it --rm python:3.13 bash
apt-get update -o Debug::Acquire::http=trueDidukung oleh

Output verbose menunjukkan tepatnya di mana koneksi gagal.

Atasi ini dengan mengonfigurasi package manager untuk menggunakan proxy Anda:

• Konfigurasi pengaturan proxy package manager di Dockerfile
• Teruskan argumen build proxy ke Docker build
• Periksa apakah proxy memblokir domain repositori paket

Masalah: BuildKit mengabaikan pengaturan proxy

BuildKit menggunakan penanganan proxy yang berbeda dari builder legacy, menyebabkan kesalahan seperti ini:

failed to solve: failed to fetch remote https://github.com/user/repo.gitDidukung oleh

Uji apakah masalahnya spesifik BuildKit dengan memeriksa konfigurasi builder Anda:

# Periksa konfigurasi BuildKit
docker buildx inspect

# Build dengan builder legacy
DOCKER_BUILDKIT=0 docker build .Didukung oleh

Jika builder legacy berfungsi, Anda memiliki masalah konfigurasi proxy BuildKit.

Perbaiki masalah proxy BuildKit dengan pendekatan ini:

• Konfigurasikan pengaturan proxy khusus BuildKit di buildkitd.toml
• Gunakan --build-arg untuk meneruskan variabel proxy secara eksplisit
• Nonaktifkan BuildKit untuk build yang sensitif terhadap proxy

Masalah: Kontainer tidak dapat menjangkau layanan eksternal

Aplikasi Anda di dalam kontainer gagal terhubung ke API eksternal:

requests.exceptions.ConnectionError: HTTPSConnectionPool(host='api.example.com', port=443)Didukung oleh

Debug ini dengan menguji konektivitas dari dalam kontainer:

# Uji dari dalam kontainer
docker exec container_name curl -v https://api.example.com

# Periksa variabel lingkungan kontainer
docker exec container_name env | grep -i proxyDidukung oleh

Ini menunjukkan apakah variabel proxy ada dan apakah percobaan koneksi berhasil.

Selesaikan masalah konektivitas kontainer dengan memastikan konfigurasi proxy yang tepat:

• Teruskan variabel lingkungan proxy saat runtime
• Konfigurasikan pengaturan proxy khusus aplikasi
• Tambahkan tujuan ke daftar NO_PROXY

Analisis log dan pengujian konektivitas

Log daemon Docker mengungkap cerita lengkap negosiasi proxy dan kegagalannya.

Di sistem berbasis systemd, gunakan journalctl untuk mengikuti log layanan Docker secara real-time:

# Sistem SystemD
sudo journalctl -u docker.service -fDidukung oleh

Untuk sistem yang menggunakan file log tradisional, periksa log Docker secara langsung:

# File log langsung
sudo tail -f /var/log/docker.logDidukung oleh

Cari pola spesifik terkait proxy di log. Kesalahan connection refused menunjukkan server proxy tidak dapat diakses. Kegagalan autentikasi muncul sebagai pesan "407 Proxy Authentication Required". Kesalahan timeout menunjukkan masalah perutean jaringan atau beban berlebih pada server proxy.

Pengujian tingkat kontainer dengan curl dan wget memberi Anda wawasan mendetail tentang perilaku proxy.

Uji koneksi HTTP melalui proxy Anda untuk melihat apa yang terjadi saat handshake:

# Uji proxy HTTP
docker run --rm \
  -e HTTP_PROXY=http://proxy.company.com:8080 \
  python:3.13-slim \
  curl -v http://httpbin.org/ipDidukung oleh

Output verbose menunjukkan resolusi DNS, pendirian koneksi proxy, dan alur permintaan HTTP yang sebenarnya. Anda akan melihat baris seperti "Connected to proxy.company.com" diikuti "CONNECT httpbin.org:80" jika terowongan proxy berfungsi dengan benar.

Koneksi HTTPS memerlukan proxy yang mendukung metode CONNECT:

# Uji proxy HTTPS
docker run --rm \
  -e HTTPS_PROXY=http://proxy.company.com:8080 \
  python:3.13-slim \
  curl -v https://httpbin.org/ipDidukung oleh

Perhatikan "CONNECT httpbin.org:443 HTTP/1.1" di output. Jika Anda melihat "Method not allowed" atau kesalahan serupa, proxy Anda tidak mendukung tunneling HTTPS.

Uji autentikasi dengan menanamkan kredensial dalam URL proxy:

# Uji dengan autentikasi
docker run --rm \
  -e HTTPS_PROXY=http://user:[email protected]:8080 \
  python:3.13-slim \
  wget -O- https://httpbin.org/ipDidukung oleh

Kegagalan autentikasi muncul sebagai respons "407 Proxy Authentication Required". Autentikasi yang berhasil akan langsung dilanjutkan ke permintaan target.

Debugging tingkat jaringan dengan tcpdump menangkap paket sebenarnya antara Docker dan server proxy Anda.

Jalankan tcpdump untuk melihat semua lalu lintas yang mengalir ke proxy Anda:

# Tangkap lalu lintas proxy
sudo tcpdump -i any host proxy.company.com and port 8080Didukung oleh

Tangkap paket mentah ini menunjukkan upaya koneksi, transfer data, dan terminasi koneksi. Cari pendirian koneksi TCP (paket SYN/ACK) diikuti lalu lintas HTTP. Timeout koneksi muncul sebagai paket SYN berulang tanpa respons.

Pengujian resolusi DNS menghilangkan sumber kebingungan proxy yang umum.

Banyak masalah proxy sebenarnya adalah masalah DNS yang menyamar. Uji resolusi DNS di dalam kontainer:

# Uji DNS di dalam kontainer  
docker run --rm python:3.13-slim nslookup registry-1.docker.ioDidukung oleh

Jika ini gagal, kontainer tidak dapat menyelesaikan nama domain sama sekali. Coba gunakan server DNS publik untuk mengisolasi masalah:

# Uji dengan DNS kustom
docker run --dns 8.8.8.8 --rm python:3.13-slim nslookup registry-1.docker.ioDidukung oleh

Lingkungan perusahaan sering kali memiliki server DNS yang hanya berfungsi dari dalam jaringan. Proxy Anda mungkin perlu menangani permintaan DNS serta lalu lintas HTTP, atau Anda mungkin perlu mengonfigurasi kontainer dengan server DNS tertentu yang berfungsi melalui proxy Anda.

Kerjakan setiap lapisan secara sistematis, dan Anda akan menemukan akar masalahnya.

Mencari opsi yang mungkin menangani proxy secara berbeda? Kami memiliki panduan tentang alternatif Docker agar Anda dapat menjelajahi lanskap lengkap alat kontainerisasi pada 2025.

Kesimpulan

Konfigurasi proxy Docker bukan hanya soal membuat image dapat diunduh — ini juga tentang membangun aplikasi berkontainer yang andal dan aman di lingkungan enterprise.

Saya telah menunjukkan cara mengonfigurasi pengaturan proxy pada empat lapisan berbeda: operasi klien, proses daemon, runtime kontainer, dan operasi saat build. Setiap lapisan memiliki tujuan spesifik dan memerlukan pendekatan konfigurasi sendiri, mulai dari file JSON dan variabel lingkungan hingga pengaturan package manager dan konfigurasi BuildKit. Strategi proxy berlapis melindungi Anda dari satu titik kegagalan.

Ingin menyelami lebih dalam Docker, kontainerisasi, dan keamanan? Lihat daftar kursus pilihan kami:

• Introduction to Docker
• Intermediate Docker
• Containerization and Virtualization Concepts
• Containerization and Virtualization with Docker and Kubernetes
• DevOps Concepts
• Introduction to Kubernetes