Docker Proxy: Kurumsal Güvenlik Duvarlarının Arkasında Konteynerleri Çalıştırmak İçin Eksiksiz Rehber

Çoğu kurumsal ağ, internet trafiğini izlemek ve filtrelemek için proxy sunucuları kullanır. Bu durum, Docker’ın kayıt defterlerinden imaj çekmeye çalıştığında engellere yol açar. Ev ağınızda çalışan işlemler, bağlantı zaman aşımlarına, kimlik doğrulama hatalarına ve başarısız build’lere dönüşebilir. Bu proxy kaynaklı sorunlar, ihtiyaç duydukları temel imajlara erişemeyen geliştirme ekiplerini sekteye uğratabilir.

Docker proxy yapılandırması, bu bağlantı sorunlarını çözer; önbellekleme sayesinde performansı artırır ve kurumsal güvenlik gereksinimlerini karşılar. Yapılandırma tamamlandığında, konteynerleriniz ağ kısıtlamalarından bağımsız olarak imajları çekebilir.

Bu eğitimde, Docker daemon proxy ayarlarını yapmayı, konteyner ortam değişkenlerini tanımlamayı ve Docker Compose içinde proxy yapılandırmasını ele almayı adım adım göstereceğim.

Docker’a yeni misiniz ve tüm ağ kavramları gözünüzü mü korkutuyor? Docker temelleriyle başlayın ve özgüveninizi adım adım geliştirin.

Docker Proxy Mimarisi Anlama

Docker ekosisteminin farklı bölümleri, farklı katmanlarda proxy yapılandırmasına ihtiyaç duyar.

Proxy’ler, Docker bileşenleriniz ile harici ağlar arasında aracı olarak davranır. Docker imaj çektiğinde, konteynerlerin internete erişmesi gerektiğinde ya da build’ler harici kaynaklara ihtiyaç duyduğunda, bu bağlantıları proxy sunucuları kontrol eder ve izler. Konteynerleştirilmiş uygulamalarınız ile dış dünya arasına oturur, istek ve yanıtları filtreler.

Kuruluşlar Docker ile proxy’leri performans, güvenlik ve uyumluluk için kullanır.

Performans, temel imajlar gibi sık erişilen kaynakların önbelleğe alınmasıyla gelir; bu da ekip genelinde indirme sürelerini azaltır. Güvenlik faydaları arasında trafik filtreleme, kötü amaçlı yazılım taraması ve yetkisiz sitelere erişimi engelleme bulunur. Uyumluluk gereksinimleri ise tüm ağ trafiğinin uygun erişim kontrolleri ve denetim izleriyle izlenen kanallardan geçmesini zorunlu kılar.

Docker proxy yapılandırması dört katmanda gerçekleşir:

• İstemci proxy’si: docker pull ve docker push gibi Docker CLI komutlarını etkiler

• Daemon proxy’si: Docker daemon’ın harici kayıt defterlerine erişimini kontrol eder  

• Konteyner çalışma zamanı proxy’si: uygulamalar için konteyner içinde proxy değişkenlerini ayarlar

• Build zamanı proxy’si: Dockerfile’ların internet erişimine ihtiyaç duyduğu docker build işlemleri sırasında proxy ayarlarını yönetir

Her katman belirli bir amaca hizmet eder ve kendine özgü bir yapılandırma yaklaşımı gerektirir.

Docker ağlarını anlamak, konteynerlerin nasıl iletişim kurduğunu kavramakla başlar. 

Docker’ı Bir Proxy ile Kullanacak Şekilde Yapılandırma

Docker’ın kurumsal proxy’nizle çalışması için hem Docker daemon’ı hem de istemciyi yapılandırmanız gerekir.

Neden? Çünkü farklı türde ağ isteklerini ele alırlar. 

Daemon, imaj çekme/itme ve kayıt defteri kimlik doğrulamasını yönetirken, istemci CLI işlemlerini ve API çağrılarını yönetir. Her iki yapılandırmadan biri eksik olursa, Docker işlemlerinin bağlantı hatalarıyla başarısız olmasına yol açabilecek boşluklar oluşur.

Docker daemon nasıl yapılandırılır

Docker daemon, proxy ayarlarını /etc/docker/daemon.json dosyasından okur. Yoksa bu dosyayı oluşturun:

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

noProxy alanı, proxy’yi atlaması gereken adresleri listeler. Buraya dahili kayıt defteri alan adlarınızı ve localhost adreslerini ekleyin.

systemd servis geçersiz kılmaları (override) ayarlama

systemd tabanlı Linux sistemlerinde, Docker servisinin kendisini de proxy kullanacak şekilde yapılandırmanız gerekir. Geçersiz kılma dizinini ve yapılandırma dosyasını oluşturun:

sudo mkdir -p /etc/systemd/system/docker.service.d
sudo nano /etc/systemd/system/docker.service.d/http-proxy.confAltyapı:

Ardından, şu ortam değişkenlerini http-proxy.conf dosyasına ekleyin:

[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"Altyapı:

Bu, Docker daemon sürecinin proxy üzerinden harici servislere ulaşabilmesini sağlar.

Docker, daemon yeniden başlatılana kadar proxy değişikliklerini almaz. systemd’yi yeniden yüklemek ve Docker’ı yeniden başlatmak için şu komutları çalıştırın:

sudo systemctl daemon-reload
sudo systemctl restart dockerAltyapı:

Daemon’ın yeniden yüklenmesi, systemd’nin yeni servis yapılandırmasını okumasını sağlar; Docker’ın yeniden başlatılması ise daemon.json değişikliklerini uygular.

Platforma özgü hususlar

Docker Desktop, proxy yapılandırmasını sunucu kurulumlarından farklı şekilde ele alır. Windows ve macOS’ta, Kaynaklar - Proxies bölümünden Docker Desktop arayüzünü kullanarak proxy ayarlarını yapın. Bu ayarlar, daemon ve istemciyi otomatik olarak yapılandırır.

Docker Engine kullanan Linux ana makineleri, yukarıda açıklanan manuel yapılandırmaya ihtiyaç duyar. Bazı dağıtımlar Docker’ı farklı paketler; sisteminizin dockerd’ı doğrudan mı yoksa farklı bir servis yöneticisi aracılığıyla mı kullandığını kontrol edin.

Yapılandırmanızı doğrulama

Basit bir pull komutuyla Docker’ın harici kayıt defterlerine ulaşabildiğini test edin:

docker pull hello-worldAltyapı:

Daemon’ın etkin yapılandırmasını da kontrol edebilirsiniz:

docker system info | grep -i proxyAltyapı:

Bu çıktı, Docker’ın proxy ayarlarınızı algılayıp uygulayıp uygulamadığını gösterir.

Pull işlemleri hâlâ başarısızsa, Docker’ın istekleri doğru şekilde yönlendirdiğini doğrulamak için proxy sunucusu günlüklerinizi kontrol edin.

Ağ sorunlarıyla mı boğuşuyorsunuz? Docker portlarını doğru şekilde yayın ve bağlantı sıkıntılarından kaçının.

Proxy Ortam Değişkenlerini Ayarlama

Docker CLI komutlarının, daemon ayarlarından ayrı kendi proxy yapılandırmasına ihtiyacı vardır. Ortam değişkenleri, Docker istemcilerinin kurumsal proxy’ler üzerinden nasıl bağlandığını esnek biçimde kontrol etmenizi sağlar.

İstemci proxy’leri, docker pull, docker push ve docker login gibi Docker CLI işlemlerini kontrol eder. Bu komutları çalıştırdığınızda, Docker istemcisi kayıt defterlerine HTTP istekleri yapar ve hangi proxy sunucusunu kullanacağını bilmesi gerekir. İstemci proxy ayarları olmadan, daemon doğru yapılandırılmış olsa bile bu işlemler başarısız olur.

JSON yapılandırma yöntemi

En temiz yaklaşım, Docker’ın ~/.docker/config.json dosyasını kullanmaktır:

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

Bu yöntem, proxy ayarlarını Docker’ın yapılandırması içinde tutar ve sisteminizdeki diğer uygulamaları etkilemez.

Ortam değişkeni alternatifi

Docker’ın otomatik olarak algılayacağı standart proxy ortam değişkenlerini şu komutlarla da ayarlayabilirsiniz:

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.comAltyapı:

Bu değişkenler yalnızca Docker için değil, proxy standartlarına uyan tüm uygulamalar için çalışır.

Genel (global) ve kullanıcı başına yapılandırma

Sistem genelinde yapılandırma için, ortam değişkenlerini /etc/environment içine ekleyin veya /etc/profile.d/ altında bir betik oluşturun:

# /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.comAltyapı:

Kullanıcı başına yapılandırma için, kabuk profilinize (~/.bashrc, ~/.zshrc) ekleyin veya JSON yapılandırma yöntemini kullanın. Kullanıcı bazlı ayarlar, geliştiricilere farklı proxy’ler kullanma ya da test amaçlı tamamen atlama esnekliği sağlar.

Güvenlik hususları

Kullanıcı adı ve parolaları hiçbir zaman yapılandırma dosyalarına veya ortam değişkenlerine düz metin olarak yazmamalısınız. 

Düz metin proxy kimlik bilgileri, özellikle paylaşılan ortamlarda veya sürüm kontrol sistemlerinde güvenlik riski oluşturur.

Bunun yerine şu yaklaşımları kullanın:

• Mümkünse proxy sunucunuzu IP tabanlı kimlik doğrulamasına göre yapılandırın
• Kimlik doğrulama için kimlik bilgisi yardımcıları veya güvenli depolama sistemleri kullanın
• Docker işlemleri için asgari izinlere sahip hizmet hesapları ayarlayın

Kimlik bilgilerini eklemek zorundaysanız, http://username:[email protected]:8080 biçimini kullanın; ancak bunları, izinleri kısıtlanmış korumalı dosyalarda saklayın.

Build zamanı proxy yapılandırması

Docker build işlemleri, proxy ayarlarının build argümanlarıyla açıkça iletilmesini gerektirir:

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 .Altyapı:

Build argümanları, build bağlamı içinde ortam değişkenlerine dönüşür.

Bu sayede RUN talimatları paketleri ve bağımlılıkları proxy üzerinden indirebilir. Bu argümanlar olmadan, Dockerfile’lar yazılım kurmaya veya internetten kaynak çekmeye çalıştığında build işlemleri başarısız olur.

Build zamanı proxy ayarları, Dockerfile’ınızda ENV talimatlarıyla açıkça ayarlamadığınız sürece nihai imajda kalıcı olmaz.

Ortam değişkenleri, iş akışınıza uygun düzeyde proxy ayarlarını ele almanız için esneklik sağlar.

Build argümanları kafanızı mı karıştırıyor? Docker build argümanlarına gerçekten çalışan örneklerle hakim olun.

Konteyner ve Build Zamanı Proxy Enjeksiyonu

Sadece Docker istemcisini yapılandırmak yeterli değildir — konteynerlerinizin ve build’lerinizin kendi proxy ayarlarına ihtiyacı vardır. Bu bölümde, proxy yapılandırmasını çalışma zamanında ve build zamanında nasıl enjekte edeceğinizi göstereceğim.

Çalışma zamanı ortam değişkenleri

Konteynerler, ana makinenizin proxy ayarlarını devralmaz.

Konteynerleri başlatırken proxy değişkenlerini açıkça geçirmeniz gerekir. Tüm konteynerleri mi yoksa sadece belirli olanları mı yapılandırmak istediğinize bağlı olarak Docker size birden fazla yol sunar.

Tutarlı proxy ayarları için en temiz yaklaşım JSON yapılandırmasıdır — daha önce ele aldığımız gibi. Özetle, ~/.docker/config.json dosyanıza bunu ekleyin:

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

Docker bu değişkenleri başlattığınız her konteynere otomatik olarak enjekte eder. Ek bayraklara gerek yoktur.

CLI bayrakları, konteyner başına daha fazla kontrol sağlar:

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 \
  nginxAltyapı:

Ayrıca bir ortam dosyasının tamamını da geçebilirsiniz:

# 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 nginxAltyapı:

Mevcut konteynerlere, başlatıldıktan sonra docker exec kullanarak proxy değişkenleri enjekte edebilirsiniz:

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

Bu yaklaşım tek seferlik komutlar için işe yarar ancak konteyner yeniden başlatmalarında kalıcı olmaz.

Build zamanı proxy yapılandırması

Proxy ortamlarında, proxy ayarlarını açıkça iletmezseniz imaj build işlemleri başarısız olur.

Build argümanları, build sırasında proxy değişkenlerini enjekte etmenin standart yoludur:

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 .Altyapı:

Dockerfile’ınızın bunları kullanabilmesi için bu argümanları tanımlaması gerekir:

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 imageAltyapı:

Dockerfile deklarasyonları, varsayılan proxy değerleri belirlemenizi sağlar:

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 requestsAltyapı:

ENV talimatı, build’inizdeki sonraki tüm RUN komutlarında proxy değişkenlerini kullanılabilir kılar.

BuildKit sınırlamalarının, daha yeni Docker sürümlerinde proxy sorunlarına yol açabileceğini bilmelisiniz. BuildKit, build bağlamlarını agresif biçimde önbelleğe alır ve bazen proxy değişikliklerini göz ardı eder.

BuildKit’in proxy güncellemelerini tanımasını zorlayabilirsiniz:

DOCKER_BUILDKIT=1 docker build \
  --no-cache \
  --build-arg HTTP_PROXY=$HTTP_PROXY \
  --tag myapp .Altyapı:

Ya da, proxy’ye duyarlı build’ler için BuildKit’i tamamen devre dışı bırakabilirsiniz:

DOCKER_BUILDKIT=0 docker build --build-arg HTTP_PROXY=$HTTP_PROXY --tag myapp .Altyapı:

Konu çok aşamalı (multi-stage) build’lere geldiğinde, tüm aşamalar boyunca tutarlı proxy yapılandırmasına ihtiyaç duyarlar:

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=Altyapı:

Her aşama, build argümanlarını devralır; ancak önceki aşamalardaki ortam değişkenlerini devralmaz. İhtiyaç duyan her aşamada proxy değişkenlerini açıkça ayarlayın.

Kısacası — bir kez yapılandırın, her yerde enjekte edin.

Proxy etkin konteynerlerinizde ENTRYPOINT ve CMD arasındaki fark kafanızı mı karıştırıyor? Uygulamalı örneklerle eksiksiz açıklamayı alın.

Konteynerlerde Paket Yöneticilerini Proxy Kullanacak Şekilde Yapılandırma

Docker’ın proxy ayarları, konteynerlerinizin içindeki paket yöneticilerine otomatik olarak aktarılmaz. Kurumsal proxy üzerinden paket indirmek için her paket yöneticisini ayrı ayrı yapılandırmanız gerekir.

apt-get, yum ve apk gibi paket yöneticileri, paket depolarına doğrudan HTTP bağlantıları kurar. Kısıtlı ağ ortamlarında, paket yöneticisi proxy sunucunuzdan haberdar değilse bu bağlantılar başarısız olur.

Standart ortam değişkenleri yeterli değildir. Çoğu paket yöneticinin, sistem genelindeki proxy ayarlarını geçersiz kılan kendi yapılandırma dosyaları vardır.

Ubuntu/Debian: apt-get yapılandırması

apt-get’in paket kurulumu sırasında okuyacağı bir proxy yapılandırma dosyası oluşturun.

Bunu Dockerfile’ınıza ekleyin:

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 wgetAltyapı:

/etc/apt/apt.conf.d/proxy.conf dosyası, apt-get’e tüm paket indirmelerini proxy üzerinden yönlendirmesini söyler. Dosya, build’inizdeki RUN komutları arasında kalıcıdır.

Dahili depolar için proxy istisnaları da ayarlayabilirsiniz:

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

Alpine Linux: apk yapılandırması

Alpine, proxy ayarlarını /etc/apk/repositories ve ortam değişkenlerinden okuyan apk paket yöneticisini kullanır.

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 wgetAltyapı:

Alpine’in apk’si, standart HTTP proxy ortam değişkenlerine uyar; dolayısıyla ayrı yapılandırma dosyalarına gerek yoktur. Yine de daha fazla kontrol için bir dosya oluşturabilirsiniz:

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

CentOS/RHEL: yum yapılandırması

CentOS ve RHEL sistemleri, proxy ayarlarını /etc/yum.conf dosyasından okuyan yum veya dnf kullanır.

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 wgetAltyapı:

dnf kullanan daha yeni CentOS sürümleri için şunu kullanın:

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 wgetAltyapı:

Ayrıca şu komutla belirli alan adlarını proxy yönlendirmesinden hariç tutabilirsiniz:

RUN echo 'proxy_exclude=internal.company.com,localhost' >> /etc/yum.confAltyapı:

Proxy işlevselliğini test etme

Öncelikle, paket yöneticinizin proxy üzerinden depolara ulaşabildiğini doğrulamanız gerekir.

Dockerfile’ınıza test komutları ekleyin:

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-pipAltyapı:

--dry-run bayrağı, gerçekte hiçbir şey kurmadan paket çözümlemeyi test eder. Başarılı olursa, proxy yapılandırmanız çalışıyor demektir.

Bağlantı sorunlarını hata ayıklamak için ayrıntılı çıktı ile de test edebilirsiniz:

RUN apt-get -o Debug::Acquire::http=true updateAltyapı:

Bu çıktı, apt-get’in erişmeye çalıştığı URL’leri ve proxy bağlantılarının başarılı olup olmadığını tam olarak gösterir.

Alpine testi için şunları kullanın:

RUN apk update --verbose && \
    apk add --simulate curl && \
    echo "Alpine proxy test passed"Altyapı:

Özetle, her paket yöneticisini ayrı ayrı yapılandırın; build’leriniz her proxy’nin arkasında çalışır.

Proxy ile ilgili build artifaktlarını temizlemek mi istiyorsunuz? Docker prune komutları alan açar ve sisteminizi temiz tutar.

Gelişmiş Proxy Uygulamaları

Temel HTTP proxy’leri başlangıç için yeterlidir; ancak üretim ortamları, kayıt defteri erişimi ve imaj önbelleklemesi üzerinde daha fazla kontrole ihtiyaç duyar. Daha iyi performans ve güvenilirlik için önbellekleyen proxy’ler ve kayıt defteri aynalarını nasıl kuracağınız aşağıda açıklanmıştır.

Önbellekleyen proxy kayıt defterleri

Aynı temel imajları tekrar tekrar çekmek bant genişliğini boşa harcar ve build’leri yavaşlatır.

Önbellekleyen proxy’ler, Docker istemcileriniz ile Docker Hub gibi harici kayıt defterleri arasına oturur. Sık erişilen imajları yerel olarak saklar; böylece sonraki pull işlemleri internet yerine iç ağınızdan gelir.

Kurumsal ortamlar için en popüler seçenek Harbor’dır:

# 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.confAltyapı:

harbor.yml dosyasını düzenleyerek Harbor’ı bir proxy önbelleği olarak yapılandırabilirsiniz:

# 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-tokenAltyapı:

Daha basit bir önbellekleme alternatifi gerekirse Docker Registry Proxy kullanın. Şu şekilde:

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:2Altyapı:

Ardından, Docker istemcilerinizi önbellekleyen proxy’ye yönlendirin:

{
  "registry-mirrors": ["http://harbor.company.com"]
}Altyapı:

Önbellekleyen proxy’lerle elde edeceğiniz başlıca faydalar şunlardır:

• İlk indirmeden sonra daha hızlı imaj pull’ları
• İnternet bant genişliği kullanımında azalma
• Harici kayıt defterlerinde sorun olduğunda daha iyi build güvenilirliği
• Merkezi erişim kontrolü ve imaj taraması

Kayıt defteri aynaları ve BuildKit

Kayıt defteri aynaları, imaj pull’larını dahili ya da coğrafi olarak daha yakın kayıt defterlerine yönlendirmenizi sağlar.

Tek aynalı yapılandırma, tüm Docker Hub isteklerini bir ayna üzerinden geçirir:

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

Bunu /etc/docker/daemon.json dosyasına ekleyip Docker’ı yeniden başlatın. Tüm docker pull komutları önce aynayı dener; ayna kullanılamazsa Docker Hub’a geri döner.

Birden çok ayna yedeklilik sağlar:

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

Docker, başarıya ulaşana kadar aynaları sırayla dener.

BuildKit ayna kurulumu ayrı bir yapılandırma gerektirir; çünkü BuildKit bazı daemon ayarlarını atlar:

# buildkitd.toml
debug = true

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

[registry."mirror.company.com"]
  http = true
  insecure = trueAltyapı:

BuildKit’i özel yapılandırmayla başlatabilirsiniz:

buildkitd --config=/etc/buildkit/buildkitd.tomlAltyapı:

Ya da BuildKit’in satır içi ayna yapılandırmasını kullanın:

docker buildx create \
  --name mybuilder \
  --config /etc/buildkit/buildkitd.toml \
  --useAltyapı:

Son olarak, Docker Hub’dan çeken bir imajı build ederek ayna kurulumunuzu test edin:

FROM python:3.13-slim
RUN pip install requestsAltyapı:

docker build --progress=plain .Altyapı:

--progress=plain bayrağı, BuildKit’in gerçekte hangi kayıt defterine bağlandığını gösterir. Build çıktısında ayna URL’lerinizi görmelisiniz.

Hepsi bu!

Karmaşık çoklu konteyner proxy kurulumlarını mı yönetiyorsunuz? Docker Compose ağ ve servis keşfini kolaylaştırır.

Güvenliği Sıkılaştırma

Proxy yapılandırmaları, dikkatli ele alınması gereken yeni saldırı olasılıkları açar. İşte Docker soket erişimini kilitlemenin ve proxy kimlik bilgilerini ifşadan korumanın yolları.

Docker soket proxy’si

Docker soketini doğrudan açığa çıkarmak büyük bir güvenlik riski yaratır.

Docker soketi (/var/run/docker.sock), tüm ana sisteminize root düzeyinde erişim verir. Bu sokete yazabilen herhangi bir süreç, ana dosya sistemine erişimli konteynerler başlatabilir, ayrıcalık yükseltebilir veya konteyner izolasyonunu tamamen aşabilir.

Doğrudan soket bağlama tehlikelidir:

# DON'T DO THIS
docker run -v /var/run/docker.sock:/var/run/docker.sock myappAltyapı:

Bu desen Docker-içinde-Docker kurulumlarında ve CI/CD hatlarında görülür, ancak güvenlik kabusudur. Tehlikeye atılmış bir konteyner tüm Docker daemon’ını kontrol edebilir.

Soket proxy servisleri daha güvenli bir ara katman oluşturur. Docker API çağrılarını filtreler ve konteynerlerin gerçekte neler yapabileceğini kısıtlar.

Tecnativa’nın docker-socket-proxy’sini kullanın:

# 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"Altyapı:

Proxy yalnızca belirli Docker API uç noktalarını açığa çıkarır. İzin verilen işlemler için ortam değişkenlerini 1, engellenenler için 0 olarak ayarlayın.

Uygulamalarınız ham soket yerine proxy’ye bağlanır:

docker run --env DOCKER_HOST=tcp://docker-proxy:2375 myappAltyapı:

Uymanız gereken ek soket sıkılaştırma stratejileri:

• Soket proxy’sini ayrı bir ağ segmentinde çalıştırın
• İstemciler ile proxy arasında TLS kimlik doğrulaması kullanın
• Şüpheli API çağrıları için soket proxy günlüklerini izleyin
• Proxy erişim kimlik bilgilerini düzenli olarak döndürün

Kimlik bilgisi yönetimi

Düz metin URL’lerdeki proxy kimlik bilgileri her yerde görünür — günlüklerde, süreç listelerinde, ortam dökümlerinde.

Kimlik bilgilerini asla proxy URL’lerine gömmeyin:

# SECURITY RISK - credentials visible in process list
export HTTP_PROXY=http://admin:[email protected]:8080Altyapı:

ps aux ya da ortam değişkeni dökümlerine erişimi olan herkes proxy parolanızı görebilir. Buna uygulama günlükleri, konteyner incelemesi ve sistem izleme araçları dahildir.

Bunun yerine kimlik doğrulama dosyaları kullanın:

# Create credentials file with restricted permissions
echo "admin:password123" > ~/.proxy-creds
chmod 600 ~/.proxy-creds

# Configure proxy without embedded credentials
export HTTP_PROXY=http://proxy.company.com:8080Altyapı:

Proxy sunucunuzu dosyadan kimlik bilgisi okuyacak şekilde yapılandırın veya harici kimlik doğrulama sistemleri kullanın.

TLS proxy’ler, kimlik doğrulama el sıkışmaları dahil tüm proxy trafiğini şifreler:

# HTTPS proxy encrypts credentials in transit
export HTTPS_PROXY=https://proxy.company.com:8443Altyapı:

Proxy sunucunuzu, bir CA’den alınmış veya istemci makinelere dağıtılmış self-signed uygun TLS sertifikalarıyla kurun.

Sertifika tabanlı kimlik doğrulama parolaları tamamen ortadan kaldırır:

# Client certificate authentication
export HTTPS_PROXY=https://proxy.company.com:8443
curl --cert client.crt --key client.key --cacert proxy-ca.crt https://example.comAltyapı:

Proxy, kullanıcı adı/parola kombinasyonları yerine istemci sertifikalarını doğrular. Sertifikalar tehlikeye atılırsa tekil olarak iptal edilebilir.

Kubernetes secret yönetimi, proxy kimlik bilgilerini konteyner imajlarının dışında tutar:

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

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: passwordAltyapı:

Sırlar (secrets) beklemede şifreli kalır ve imaj katmanlarında görünmeden çalışma zamanında enjekte edilir.

Soket erişimini kilitleyin ve kimlik bilgilerinizi şifreleyin — gelecekteki siz minnettar olacaktır.

Proxy kurulumunuz için Docker alternatiflerini mi düşünüyorsunuz? Doğru konteynerleştirme aracını seçmek için Docker ve Podman karşılaştırmasını inceleyin.

Yaygın Sorunları Giderme

Proxy sorunları, zaman aşımları, bağlantı hataları ve ağınızın dışında sorunsuz çalışan esrarengiz build hataları olarak kendini gösterir. En yaygın Docker proxy problemlerini teşhis ve onarmak için sistematik bir yaklaşım aşağıdadır.

Yapılandırılmış tanılama yaklaşımı

Temelden başlayın ve yığın boyunca yukarı doğru ilerleyin.

Adım 1: Ana makinadan proxy bağlantısını doğrulayın

Proxy sunucunuzun erişilebilir olup olmadığını test edin:

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

Bu başarısız olursa, proxy yapılandırmanızda veya ağ yönlendirmenizde sorun vardır. Docker’ı sorun gidermeden önce ağ ekibinizle iletişime geçin.

Adım 2: Docker daemon proxy ayarlarını kontrol edin

Daemon’ın proxy yapılandırmanızı okuyup okumadığını doğrulayın:

docker info | grep -i proxyAltyapı:

Proxy URL’lerinizin listelendiğini görmelisiniz. Eksikse, /etc/docker/daemon.json dosyasını kontrol edin ve Docker servislerini yeniden başlatın.

Adım 3: Docker istemci işlemlerini test edin

Basit bir imaj çekmeyi deneyin:

docker pull hello-worldAltyapı:

Başarı, istemci proxy ayarlarınızın çalıştığını gösterir. Başarısızlık, daemon düzeyindeki proxy sorunlarına işaret eder.

Adım 4: Konteyner düzeyinde bağlantıyı test edin

Bir konteyner çalıştırın ve giden bağlantıları test edin:

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())"Altyapı:

Bu, sorunun Docker işlemlerinde mi yoksa konteyner ağında mı olduğunu izole eder.

Yaygın sorunlar ve çözümler

Sorun: docker pull zaman aşımına uğruyor

Docker harici kayıt defterlerine ulaşamadığında şu hatayı görebilirsiniz:

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

Sorunun nerede meydana geldiğini izole etmek için temel bağlantıyı test ederek başlayın:

# Check if DNS resolution works through proxy
nslookup registry-1.docker.io

# Test direct registry access
curl -I https://registry-1.docker.io/v2/

# Verify daemon proxy configuration
sudo journalctl -u docker.service | grep -i proxyAltyapı:

Bunu, DNS ve proxy yapılandırma sorunlarını gidererek düzeltin:

• /etc/docker/daemon.json dosyasına DNS sunucuları ekleyin

• Dahili DNS sunucuları için NO_PROXY yapılandırın

• Proxy’nizin HTTPS CONNECT yöntemini destekleyip desteklemediğini kontrol edin

Sorun: Build sırasında paket kurulumu başarısız

Konteyner içindeki paket yöneticileri depolara ulaşamaz ve şu gibi hatalar gösterir:

E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/jammy/ReleaseAltyapı:

Geçici bir konteynerde doğrudan paket yöneticisi bağlantısını test edin:

# Test package manager connectivity in a running container
docker run -it --rm python:3.13 bash
apt-get update -o Debug::Acquire::http=trueAltyapı:

Ayrıntılı çıktı, bağlantının tam olarak nerede başarısız olduğunu gösterir.

Bunu, paket yöneticilerini proxy kullanacak şekilde yapılandırarak çözün:

• Dockerfile’da paket yöneticisi proxy ayarlarını yapılandırın
• Docker build işlemine proxy build argümanları geçin
• Proxy’nizin paket deposu alan adlarını engelleyip engellemediğini kontrol edin

Sorun: BuildKit proxy ayarlarını yok sayıyor

BuildKit, eski builder’dan farklı proxy işleme kullanır ve şu gibi hatalara neden olabilir:

failed to solve: failed to fetch remote https://github.com/user/repo.gitAltyapı:

Builder yapılandırmanızı kontrol ederek sorunun BuildKit’e özgü olup olmadığını test edin:

# Check BuildKit configuration
docker buildx inspect

# Build with legacy builder
DOCKER_BUILDKIT=0 docker build .Altyapı:

Eski builder çalışıyorsa, BuildKit proxy yapılandırması sorununuz var demektir.

BuildKit proxy sorunlarını şu yaklaşımlarla giderin:

• buildkitd.toml içinde BuildKit’e özgü proxy ayarlarını yapılandırın
• --build-arg ile proxy değişkenlerini açıkça geçin
• Proxy’ye duyarlı build’ler için BuildKit’i devre dışı bırakın

Sorun: Konteyner harici servislere ulaşamıyor

Konteyner içindeki uygulamanız harici API’lere bağlanmakta başarısız oluyor:

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

Bunu, konteynerin içinden bağlantıyı test ederek hata ayıklayın:

# Test from inside the container
docker exec container_name curl -v https://api.example.com

# Check container environment variables
docker exec container_name env | grep -i proxyAltyapı:

Bu, proxy değişkenlerinin mevcut olup olmadığını ve bağlantı girişiminin başarılı olup olmadığını gösterir.

Konteyner bağlantı sorunlarını, doğru proxy yapılandırmasını sağlayarak çözün:

• Çalışma zamanında proxy ortam değişkenlerini geçin
• Uygulamaya özgü proxy ayarlarını yapılandırın
• Hedefi NO_PROXY listesine ekleyin

Günlük analizi ve bağlantı testi

Docker daemon günlükleri proxy müzakereleri ve hataların tam hikâyesini ortaya koyar.

systemd tabanlı sistemlerde, Docker servis günlüklerini gerçek zamanlı izlemek için journalctl kullanın:

# SystemD systems
sudo journalctl -u docker.service -fAltyapı:

Geleneksel günlük dosyalarını kullanan sistemlerde, Docker günlüğünü doğrudan kontrol edin:

# Direct log file
sudo tail -f /var/log/docker.logAltyapı:

Günlüklerde proxy ile ilgili belirli kalıplara bakın. Bağlantı reddedildi hataları, proxy sunucusunun erişilebilir olmadığını gösterir. Kimlik doğrulama hataları, "407 Proxy Authentication Required" ile görünür. Zaman aşımı hataları ise ağ yönlendirme problemlerini veya proxy sunucusu aşırı yükünü düşündürür.

Konteyner düzeyinde test için curl ve wget, proxy davranışı hakkında ayrıntılı içgörü sağlar.

El sıkışma sırasında tam olarak ne olduğunu görmek için proxy üzerinden HTTP bağlantılarını test edin:

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

Ayrıntılı çıktı, DNS çözümlemesini, proxy bağlantısının kurulmasını ve gerçek HTTP istek akışını gösterir. Proxy tüneli doğru çalışıyorsa "Connected to proxy.company.com" ve ardından "CONNECT httpbin.org:80" gibi satırlar görürsünüz.

HTTPS bağlantıları, proxy’nizin CONNECT yöntemini desteklemesini gerektirir:

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

Çıktıda "CONNECT httpbin.org:443 HTTP/1.1" ifadesini arayın. "Method not allowed" vb. hatalar görürseniz, proxy’niz HTTPS tünellemeyi desteklemiyor demektir.

Kimlik doğrulamayı proxy URL’sine kimlik bilgilerini gömerek test edin:

# Test with authentication
docker run --rm \
  -e HTTPS_PROXY=http://user:[email protected]:8080 \
  python:3.13-slim \
  wget -O- https://httpbin.org/ipAltyapı:

Kimlik doğrulama hataları "407 Proxy Authentication Required" yanıtları olarak görünür. Başarılı kimlik doğrulama doğrudan hedef isteğe ilerler.

Ağ düzeyinde hata ayıklama için tcpdump, Docker ile proxy sunucunuz arasındaki gerçek paketleri yakalar.

Proxy’nize akan tüm trafiği görmek için tcpdump’ı çalıştırın:

# Capture proxy traffic
sudo tcpdump -i any host proxy.company.com and port 8080Altyapı:

Bu ham paket yakalama, bağlantı girişimlerini, veri aktarımını ve bağlantı sonlandırmayı gösterir. TCP bağlantı kurulumu (SYN/ACK paketleri) ve ardından HTTP trafiğine bakın. Bağlantı zaman aşımları, yanıt gelmeyen yinelenen SYN paketleri olarak görünür.

DNS çözümleme testleri proxy karmaşasının yaygın bir kaynağını ortadan kaldırır.

Birçok proxy sorunu aslında kılık değiştirmiş DNS problemleridir. DNS çözümlemesini konteyner içinde test edin:

# Test DNS inside containers  
docker run --rm python:3.13-slim nslookup registry-1.docker.ioAltyapı:

Bu başarısız olursa, konteyner alan adlarını hiç çözemiyor demektir. Sorunu izole etmek için genel bir DNS sunucusu kullanmayı deneyin:

# Test with custom DNS
docker run --dns 8.8.8.8 --rm python:3.13-slim nslookup registry-1.docker.ioAltyapı:

Kurumsal ortamlarda genellikle yalnızca ağ içinden çalışan DNS sunucuları bulunur. Proxy’niz, HTTP trafiğinin yanı sıra DNS isteklerini de ele almak zorunda olabilir veya konteynerleri proxy’nizle çalışan belirli DNS sunucularıyla yapılandırmanız gerekebilir.

Her katmanda sistematik şekilde ilerleyin; kök nedeni bulacaksınız.

Proxy’leri farklı şekilde ele alabilecek seçenekleri mi arıyorsunuz? 2025’teki mevcut konteynerleştirme araçlarının tamamını keşfetmek için Docker alternatifleri rehberimize göz atın.

Sonuç

Docker proxy yapılandırması yalnızca imaj indirtebilmekten ibaret değildir — aynı zamanda kurumsal ortamlarda güvenilir ve güvenli konteynerleştirilmiş uygulamalar inşa etmektir.

Dört farklı katmanda proxy ayarlarının nasıl yapılandırılacağını gösterdim: istemci işlemleri, daemon süreçleri, konteyner çalışma zamanı ve build zamanı işlemleri. Her katman, JSON dosyaları ve ortam değişkenlerinden paket yöneticisi ayarlarına ve BuildKit yapılandırmalarına kadar belirli bir amaca hizmet eder ve kendi yapılandırma yaklaşımını gerektirir. Katmanlı bir proxy stratejisi, tek hata noktalarına karşı sizi korur.

Docker, konteynerleştirme ve güvenlik konularına daha derinlemesine bakmak ister misiniz? Özenle seçtiğimiz kurs listesine göz atın:

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