CI/CD Pipeline'da Proxy Entegrasyonu: GitHub Actions, GitLab ve Jenkins için Ayarlama

Dağıtım ve test otomasyonu sırasında, CI/CD süreçlerinde proxy sunucuları kullanma ihtiyacı sıkça ortaya çıkar. Bu, kurumsal güvenlik politikaları, coğrafi konum özelliklerinin test edilmesi veya bağımlılıkların indirilmesi sırasında rate-limiting aşmakla ilgili olabilir. Bu kılavuzda, popüler CI/CD platformları için proxy'nin pratik ayarlarını hazır yapılandırma örnekleri ile inceleyeceğiz.

CI/CD süreçlerinde proxy'ye neden ihtiyaç var

Otomatik dağıtım süreçlerinde proxy sunucularının kullanılması birkaç kritik sorunu çözer. Öncelikle, birçok kurumsal ağ, tüm çıkış trafiğinin güvenlik kontrolü ve günlükleme için kurumsal proxy üzerinden geçmesini gerektirir. Doğru yapılandırma olmadan, CI/CD pipeline bağımlılıkları yükleyemez veya dış hizmetlere bağlanamaz.

İkinci olarak, coğrafi konum mantığına sahip uygulamaların test edilmesi sırasında farklı ülkelerden çalışmayı kontrol etmek gerekir. Örneğin, bölgesel içerik veya fiyatlandırma ile bir hizmet geliştiriyorsanız, otomatik testler farklı konumlardan gelen kullanıcıları taklit etmelidir. Burada, gerekli bölgelerden IP adresleri ile rezidans proxy'leri yardımcı olur.

Üçüncü neden ise rate-limiting ve engelleri aşmaktır. Özellikle büyük ekiplerde pipeline'ların sık çalıştırılması durumunda, CI/CD sunucuları dış hizmetlerin API kısıtlamalarına takılabilir. Örneğin, GitHub API veya paket kayıtları, istek limitinin aşılması durumunda IP'yi geçici olarak engelleyebilir. Proxy rotasyonu, yükü dağıtmaya yardımcı olur.

GitHub Actions'da proxy ayarlama

GitHub Actions, CI/CD için en popüler platformlardan biridir. Burada proxy ayarı, workflow veya tüm organizasyon düzeyinde ayarlanabilen ortam değişkenleri aracılığıyla gerçekleştirilir. Entegrasyonun birkaç yolunu inceleyelim.

Ortam değişkenleri aracılığıyla temel ayar

En basit yol, job'un başında HTTP_PROXY ve HTTPS_PROXY ortam değişkenlerini ayarlamaktır. Çoğu araç (curl, wget, npm, pip) bu değişkenleri otomatik olarak kullanır:

name: Proxy ile CI

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    
    env:
      HTTP_PROXY: http://proxy.example.com:8080
      HTTPS_PROXY: http://proxy.example.com:8080
      NO_PROXY: localhost,127.0.0.1,.internal.domain
    
    steps:
      - uses: actions/checkout@v3
      
      - name: Node.js Kurulumu
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      
      - name: Bağımlılıkları Yükle
        run: npm install
      
      - name: Testleri Çalıştır
        run: npm test

NO_PROXY değişkeni kritik öneme sahiptir - bu, yerel adresleri ve iç hizmetleri proxy'den hariç tutar. Olmadan, localhost veya iç Docker konteynerlerine bağlanma sorunları ortaya çıkabilir.

GitHub Secrets aracılığıyla kimlik bilgilerini güvenli bir şekilde saklama

Eğer proxy kimlik doğrulama gerektiriyorsa, kullanıcı adı ve şifreyi workflow dosyasında açık bir şekilde saklamayın. GitHub Secrets kullanın:

name: Kimlik Doğrulamalı Proxy ile CI

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v3
      
      - name: Proxy'yi Yapılandır
        run: |
          echo "HTTP_PROXY=http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}" >> $GITHUB_ENV
          echo "HTTPS_PROXY=http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}" >> $GITHUB_ENV
          echo "NO_PROXY=localhost,127.0.0.1" >> $GITHUB_ENV
      
      - name: Proxy bağlantısını test et
        run: curl -I https://api.github.com
      
      - name: Bağımlılıkları Yükle
        run: npm ci

Depo ayarlarında secrets oluşturun: Ayarlar → Secrets ve değişkenler → Actions → Yeni depo sırrı. PROXY_USER, PROXY_PASS, PROXY_HOST ve PROXY_PORT ekleyin. Bu değerler şifrelenir ve günlüklerde görünmez.

Belirli adımlar için proxy ayarlama

Bazen proxy'yi yalnızca belirli işlemler için kullanmak gerekebilir, örneğin yalnızca bağımlılıkları yüklemek için, ancak dağıtım için değil. Değişkenleri belirli bir adım düzeyinde ayarlayın:

steps:
  - name: Proxy aracılığıyla bağımlılıkları indir
    env:
      HTTP_PROXY: http://proxy.example.com:8080
      HTTPS_PROXY: http://proxy.example.com:8080
    run: npm install
  
  - name: Proxy olmadan dağıtım
    run: ./deploy.sh

GitLab CI/CD ile proxy entegrasyonu

GitLab CI/CD, proxy ayarları için birkaç düzey sunar: runner düzeyinde, proje düzeyinde ve belirli bir job düzeyinde. Seçim, proxy'nin tüm projeler için mi yoksa yalnızca belirli projeler için mi gerektiğine bağlıdır.

GitLab Runner düzeyinde proxy ayarlama

Eğer kendi barındırdığınız GitLab Runner kullanıyorsanız ve tüm projelerin proxy üzerinden çalışması gerekiyorsa, bunu runner yapılandırmasında ayarlayın. /etc/gitlab-runner/config.toml dosyasını düzenleyin:

[[runners]]
  name = "docker-runner"
  url = "https://gitlab.com/"
  token = "YOUR_TOKEN"
  executor = "docker"
  
  [runners.docker]
    image = "alpine:latest"
    privileged = false
    
  [runners.docker.services_environment]
    HTTP_PROXY = "http://proxy.example.com:8080"
    HTTPS_PROXY = "http://proxy.example.com:8080"
    NO_PROXY = "localhost,127.0.0.1,.gitlab.com"

Yapılandırmayı değiştirdikten sonra runner'ı yeniden başlatın: sudo gitlab-runner restart. Artık bu runner üzerindeki tüm job'lar otomatik olarak proxy kullanacaktır.

.gitlab-ci.yml üzerinden ayarlama

Belirli bir proje düzeyinde proxy ayarlamak için .gitlab-ci.yml dosyasında değişkenler kullanın. Bu, farklı projelerin farklı proxy'ler kullanmasına olanak tanıyan daha esnek bir yaklaşımdır:

variables:
  HTTP_PROXY: "http://proxy.example.com:8080"
  HTTPS_PROXY: "http://proxy.example.com:8080"
  NO_PROXY: "localhost,127.0.0.1,.internal"

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script:
    - echo "Proxy yapılandırıldı: $HTTP_PROXY"
    - npm install
    - npm run build
  artifacts:
    paths:
      - dist/

test:
  stage: test
  script:
    - npm test
  dependencies:
    - build

Kimlik bilgileri için GitLab CI/CD Değişkenlerini kullanma

Hassas verileri saklamak için proje ayarlarında CI/CD Değişkenlerini kullanın: Ayarlar → CI/CD → Değişkenler. Korunan ve maske değişkenleri oluşturun:

• PROXY_URL — kimlik bilgileri ile tam URL (maske)
• PROXY_HOST — proxy sunucusunun ana bilgisayarı
• PROXY_PORT — port
• PROXY_USER ve PROXY_PASS — ayrı saklama için

Ardından bunları .gitlab-ci.yml dosyasında kullanın:

build:
  stage: build
  before_script:
    - export HTTP_PROXY="http://${PROXY_USER}:${PROXY_PASS}@${PROXY_HOST}:${PROXY_PORT}"
    - export HTTPS_PROXY="http://${PROXY_USER}:${PROXY_PASS}@${PROXY_HOST}:${PROXY_PORT}"
  script:
    - npm install
    - npm run build

Jenkins'te proxy yapılandırması

Jenkins, mimariye bağlı olarak proxy ayarlamak için birkaç yol sunar: Jenkins master için küresel ayarlar, belirli ajanlar için ayarlar veya belirli pipeline düzeyinde ayarlar.

Jenkins için küresel proxy ayarı

Jenkins'in eklenti güncellemeleri ve diğer iç işlemler için kullanacağı proxy'yi ayarlamak için, Manage Jenkins → Manage Plugins → Advanced bölümüne gidin. HTTP Proxy Configuration bölümünde şunları belirtin:

• Sunucu: proxy.example.com
• Port: 8080
• Kullanıcı adı ve Şifre (kimlik doğrulama gerekiyorsa)
• No Proxy Host: localhost,127.0.0.1,.internal

Bu ayar yalnızca Jenkins'i etkiler, ancak job'ları etkilemez. Job'lar için ayrı bir yapılandırma gereklidir.

Jenkins Pipeline için proxy ayarlama

Jenkinsfile'da tüm pipeline için veya belirli aşamalar için ortam değişkenleri belirtebilirsiniz:

pipeline {
    agent any
    
    environment {
        HTTP_PROXY = 'http://proxy.example.com:8080'
        HTTPS_PROXY = 'http://proxy.example.com:8080'
        NO_PROXY = 'localhost,127.0.0.1,.internal'
    }
    
    stages {
        stage('Build') {
            steps {
                sh 'npm install'
                sh 'npm run build'
            }
        }
        
        stage('Test') {
            steps {
                sh 'npm test'
            }
        }
    }
}

Proxy için Jenkins Kimlik Bilgileri kullanma

Proxy kimlik bilgilerini güvenli bir şekilde saklamak için Jenkins Credentials Store kullanın. Manage Jenkins → Manage Credentials bölümünde "Kullanıcı adı ve şifre" türünde kimlik bilgileri oluşturun, ardından bunları pipeline'da kullanın:

pipeline {
    agent any
    
    stages {
        stage('Kimlik Doğrulamalı Proxy ile Build') {
            steps {
                withCredentials([usernamePassword(
                    credentialsId: 'proxy-credentials',
                    usernameVariable: 'PROXY_USER',
                    passwordVariable: 'PROXY_PASS'
                )]) {
                    sh '''
                        export HTTP_PROXY="http://${PROXY_USER}:${PROXY_PASS}@proxy.example.com:8080"
                        export HTTPS_PROXY="http://${PROXY_USER}:${PROXY_PASS}@proxy.example.com:8080"
                        npm install
                    '''
                }
            }
        }
    }
}

Jenkins ajanları için proxy ayarlama

Eğer ayrı Jenkins ajanları (nodes) kullanıyorsanız, her ajan için proxy'yi ayrı ayrı ayarlayın. Ajan yapılandırmasında (Manage Jenkins → Manage Nodes → Configure) Ortam değişkenlerine şunları ekleyin:

HTTP_PROXY=http://proxy.example.com:8080
HTTPS_PROXY=http://proxy.example.com:8080
NO_PROXY=localhost,127.0.0.1

CI/CD'de Docker için proxy

Docker, modern CI/CD süreçlerinin ayrılmaz bir parçasıdır. Docker için proxy ayarlamak, hem Docker daemon'u hem de konteynerler için proxy ayarlamayı gerektirdiğinden kendine özgü özelliklere sahiptir.

Docker daemon için proxy ayarlama

Docker daemon'un proxy üzerinden görüntüleri indirebilmesi için bir systemd drop-in dosyası oluşturun. Linux sisteminde bir dizin ve dosya oluşturun:

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

Aşağıdaki içeriği ekleyin:

[Service]
Environment="HTTP_PROXY=http://proxy.example.com:8080"
Environment="HTTPS_PROXY=http://proxy.example.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1,.internal,docker.io"

Yapılandırmayı yeniden yükleyin ve Docker'ı yeniden başlatın:

sudo systemctl daemon-reload
sudo systemctl restart docker
sudo systemctl show --property=Environment docker

Konteynerler için inşa sırasında proxy

Eğer konteynerlerin inşa sırasında proxy üzerinden erişime ihtiyacı varsa (örneğin, paket yüklemek için), değişkenleri Dockerfile'da build args olarak geçirin:

FROM node:18-alpine

ARG HTTP_PROXY
ARG HTTPS_PROXY
ARG NO_PROXY

ENV HTTP_PROXY=${HTTP_PROXY}
ENV HTTPS_PROXY=${HTTPS_PROXY}
ENV NO_PROXY=${NO_PROXY}

WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .

# Runtime için proxy değişkenlerini kaldır
ENV HTTP_PROXY=
ENV HTTPS_PROXY=

CMD ["npm", "start"]

CI/CD pipeline'da build args'leri geçirin:

# GitHub Actions
- name: Proxy ile Docker görüntüsü oluştur
  run: |
    docker build \
      --build-arg HTTP_PROXY=${{ secrets.PROXY_URL }} \
      --build-arg HTTPS_PROXY=${{ secrets.PROXY_URL }} \
      --build-arg NO_PROXY=localhost,127.0.0.1 \
      -t myapp:latest .

# GitLab CI
docker build:
  script:
    - docker build 
        --build-arg HTTP_PROXY="${PROXY_URL}"
        --build-arg HTTPS_PROXY="${PROXY_URL}"
        -t myapp:latest .

Docker Compose ile proxy

CI/CD'de Docker Compose kullanıyorsanız, proxy'yi docker-compose.yml dosyasında environment aracılığıyla ayarlayın:

version: '3.8'

services:
  app:
    build:
      context: .
      args:
        - HTTP_PROXY=${HTTP_PROXY}
        - HTTPS_PROXY=${HTTPS_PROXY}
    environment:
      - HTTP_PROXY=${HTTP_PROXY}
      - HTTPS_PROXY=${HTTPS_PROXY}
      - NO_PROXY=localhost,127.0.0.1
    ports:
      - "3000:3000"

Paket yöneticileri için proxy ayarlama

Paket yöneticileri genellikle proxy ayarları için ek yapılandırma gerektirir, özellikle kendi yapılandırma dosyalarını kullanıyorlarsa. Popüler paket yöneticileri için ayarları inceleyelim.

NPM ve Yarn

NPM, hem HTTP_PROXY/HTTPS_PROXY ortam değişkenlerini hem de kendi yapılandırmasını kullanabilir. CI/CD'de açık bir ayar için:

# GitHub Actions veya GitLab CI'de
- name: npm proxy'yi yapılandır
  run: |
    npm config set proxy http://proxy.example.com:8080
    npm config set https-proxy http://proxy.example.com:8080
    npm config set noproxy "localhost,127.0.0.1"

- name: Bağımlılıkları Yükle
  run: npm install

# Yarn için
- name: yarn proxy'yi yapılandır
  run: |
    yarn config set proxy http://proxy.example.com:8080
    yarn config set https-proxy http://proxy.example.com:8080

Alternatif bir yol, projenin kökünde bir .npmrc dosyası oluşturmaktır (ancak kimlik bilgilerini commit etmeyin!):

# .npmrc (CI'de oluşturulur)
proxy=http://proxy.example.com:8080
https-proxy=http://proxy.example.com:8080
noproxy=localhost,127.0.0.1

Python pip ve Poetry

Pip, ortam değişkenlerini kullanır, ancak yapılandırma aracılığıyla da ayarlanabilir:

# Ortam değişkenleri aracılığıyla (CI için önerilir)
export HTTP_PROXY=http://proxy.example.com:8080
export HTTPS_PROXY=http://proxy.example.com:8080
pip install -r requirements.txt

# Veya pip parametreleri aracılığıyla
pip install --proxy http://proxy.example.com:8080 -r requirements.txt

# Poetry için
poetry config http-basic.proxy http://proxy.example.com:8080
poetry install

Maven ve Gradle

Java projeleri için proxy ayarlamak, yapılandırma dosyaları oluşturmayı gerektirir. Maven için CI pipeline'ında settings.xml oluşturun:

- name: Maven proxy'yi yapılandır
  run: |
    mkdir -p ~/.m2
    cat > ~/.m2/settings.xml << EOF
    <settings>
      <proxies>
        <proxy>
          <id>http-proxy</id>
          <active>true</active>
          <protocol>http</protocol>
          <host>proxy.example.com</host>
          <port>8080</port>
          <nonProxyHosts>localhost|127.0.0.1</nonProxyHosts>
        </proxy>
      </proxies>
    </settings>
    EOF

- name: Maven ile inşa et
  run: mvn clean install

Gradle için ayarları gradle.properties dosyasına ekleyin:

systemProp.http.proxyHost=proxy.example.com
systemProp.http.proxyPort=8080
systemProp.https.proxyHost=proxy.example.com
systemProp.https.proxyPort=8080
systemProp.http.nonProxyHosts=localhost|127.0.0.1

Proxy kimlik bilgilerini güvenli bir şekilde saklama

Proxy kimlik bilgilerini saklamak, CI/CD güvenliğinin kritik bir yönüdür. Bu verilerin sızması, proxy'nin yetkisiz kullanımına ve finansal kayıplara yol açabilir. Farklı platformlar için en iyi uygulamaları inceleyelim.

GitHub Actions Secrets

GitHub Actions, üç düzeyde gizli veri sunar: repository, environment ve organization. Proxy kimlik bilgileri için şunları kullanın:

• Repository secrets — proxy'nin yalnızca bir repoda gerekli olduğu projeler için
• Organization secrets — bir proxy'nin organizasyonun tüm projelerinde kullanıldığı durumlar için
• Environment secrets — staging/production ortamlarında farklı proxy'ler için

Önemli güvenlik kuralları:

• Gizli verileri asla günlüklerde göstermeyin: GitHub otomatik olarak bunları maskelemektedir, ancak echo kullanmaktan kaçının
• Farklı ortamlar için farklı kimlik bilgileri kullanın
• Proxy şifrelerini düzenli olarak döndürün (en az 90 günde bir)
• Gizli verilere erişimi branch protection kuralları ile sınırlayın

GitLab CI/CD Değişkenleri

GitLab, değişkenlerin korunması için ek seçenekler sunar:

• Protected — değişken yalnızca korunan branch'lerde (main, production) kullanılabilir
• Masked — değer otomatik olarak günlüklerde gizlenir
• Environment scope — belirli ortamlarla sınırlama

Proxy kimlik bilgileri için önerilen yapılandırma:

# Ayarlar → CI/CD → Değişkenler
PROXY_USER: myuser (Korunan: Evet, Maske: Evet)
PROXY_PASS: secret123 (Korunan: Evet, Maske: Evet)
PROXY_HOST: proxy.example.com (Korunan: Hayır, Maske: Hayır)
PROXY_PORT: 8080 (Korunan: Hayır, Maske: Hayır)

Jenkins Kimlik Bilgileri Deposu

Jenkins Kimlik Bilgileri Deposu, kimlik bilgilerini saklamak için birkaç tür destekler. Proxy için önerilen:

• Proxy için kullanıcı adı/şifre için "Kullanıcı adı ve şifre" kullanın
• Farklı ekipler/projeler için Klasör düzeyinde kimlik bilgileri ayarlayın
• Pipeline'da güvenli kullanım için Kimlik Bilgileri Bağlama Eklentisini etkinleştirin
• Kimlik bilgilerini kullanımı izlemek için denetim günlüğü ayarlayın

Dış gizlilik yönetim sistemleri

Kurumsal ortamlarda, HashiCorp Vault, AWS Secrets Manager, Azure Key Vault veya Google Secret Manager gibi özel gizlilik yönetim sistemlerinin kullanılması önerilir. GitHub Actions'da HashiCorp Vault ile entegrasyon örneği:

- name: Vault'tan Gizli Verileri İçe Aktar
  uses: hashicorp/vault-action@v2
  with:
    url: https://vault.example.com
    token: ${{ secrets.VAULT_TOKEN }}
    secrets: |
      secret/data/proxy proxy_user | PROXY_USER ;
      secret/data/proxy proxy_pass | PROXY_PASS ;
      secret/data/proxy proxy_host | PROXY_HOST

- name: Proxy'yi Yapılandır
  run: |
    export HTTP_PROXY="http://${PROXY_USER}:${PROXY_PASS}@${PROXY_HOST}:8080"
    npm install

Yaygın sorunların çözümü

CI/CD'de proxy entegrasyonu sırasında sıkça karşılaşılan sorunlar vardır. En yaygın olanları ve bunların çözüm yollarını inceleyelim.

Sorun: Bağımlılıkları yüklerken Bağlantı zaman aşımı

Belirtiler: npm install, pip install veya docker pull, 30-60 saniye sonra zaman aşımı hatası ile sona erer.

Nedenler:

• Proxy sunucusu erişilemez veya aşırı yüklenmiş
• Proxy URL'sinin yanlış formatı (başında http:// unutulmuş)
• Proxy kimlik doğrulama gerektiriyor, ancak kimlik bilgileri iletilmemiş
• Firewall, CI/CD runner'dan proxy'ye bağlantıyı engelliyor

Çözüm:

# 1. Proxy'nin erişilebilirliğini kontrol edin
- name: Proxy bağlantısını test et
  run: |
    curl -v -x http://proxy.example.com:8080 https://www.google.com
    echo "Proxy testi tamamlandı"

# 2. npm için zaman aşımını artırın
- name: Artırılmış zaman aşımı ile yükleme
  run: |
    npm config set fetch-timeout 300000
    npm install

# 3. URL formatını kontrol edin
- name: Proxy yapılandırmasını hata ayıklama
  run: |
    echo "HTTP_PROXY: $HTTP_PROXY"
    echo "HTTPS_PROXY: $HTTPS_PROXY"
    # Şu şekilde olmalı: http://user:pass@host:port

Sorun: SSL sertifika doğrulaması başarısız oldu

Belirtiler: "SSL sertifika sorunu: yerel verici sertifikasını alma başarısız" veya "CERT_UNTRUSTED" gibi hatalar.

Neden: Kurumsal proxy'ler genellikle SSL denetimi yaparak sertifikaları değiştirmektedir. CI/CD runner, kurumsal CA'ya güvenmiyor.

Çözüm:

# Seçenek 1: Kurumsal CA sertifikasını ekleyin
- name: Kurumsal CA sertifikasını yükle
  run: |
    sudo cp corporate-ca.crt /usr/local/share/ca-certificates/
    sudo update-ca-certificates

# Seçenek 2: SSL doğrulamasını devre dışı bırakın (ÜRETİM için önerilmez!)
- name: SSL doğrulaması devre dışı bırakılarak yükleme
  run: |
    npm config set strict-ssl false
    npm install
  env:
    NODE_TLS_REJECT_UNAUTHORIZED: 0

# Seçenek 3: Proxy'yi yalnızca HTTP için kullanın, HTTPS doğrudan
- name: Seçici proxy kullanımı
  run: npm install
  env:
    HTTP_PROXY: http://proxy.example.com:8080
    # HTTPS_PROXY'yi ayarlamıyoruz

Sorun: Proxy bazı komutlar için çalışıyor, ancak diğerleri için çalışmıyor

Belirtiler: npm install proxy üzerinden çalışıyor, ancak git clone veya docker pull proxy ayarlarını görmezden geliyor.

Neden: Farklı araçlar, proxy ayarları için farklı mekanizmalar kullanır. Git ve Docker kendi yapılandırma dosyalarına sahiptir.

Çözüm:

# Git proxy ayarlama
- name: Git proxy'yi yapılandır
  run: |
    git config --global http.proxy http://proxy.example.com:8080
    git config --global https.proxy http://proxy.example.com:8080

# Docker proxy ayarlama (yukarıdaki Docker bölümüne bakın)
# wget/curl için
- name: wget/curl'ı yapılandır
  run: |
    echo "use_proxy = on" >> ~/.wgetrc
    echo "http_proxy = http://proxy.example.com:8080" >> ~/.wgetrc
    echo "https_proxy = http://proxy.example.com:8080" >> ~/.wgetrc

Sorun: Proxy etkin olduğunda yerel hizmetler erişilemez

Belirtiler: Proxy ayarlandıktan sonra localhost, iç Docker konteynerlerine veya kurumsal hizmetlere bağlantılar çalışmamaktadır.

Neden: NO_PROXY değişkeni yanlış ayarlanmış, tüm istekler proxy üzerinden gidiyor, yerel olanlar dahil.

Çözüm:

# NO_PROXY'nin doğru ayarlanması
env:
  HTTP_PROXY: http://proxy.example.com:8080
  HTTPS_PROXY: http://proxy.example.com:8080
  NO_PROXY: |
    localhost,
    127.0.0.1,
    0.0.0.0,
    .internal,
    .local,
    .corp.example.com,
    docker.internal,
    host.docker.internal

# Docker Compose için de ekleyin
services:
  app:
    environment:
      - NO_PROXY=localhost,127.0.0.1,db,redis
      # db ve redis, compose'daki diğer hizmetlerin adlarıdır

Sorun: Proxy kimlik bilgileri günlüklerde görünüyor

Belirtiler: CI/CD günlüklerinde proxy şifreleri açık bir şekilde görünmektedir.

Neden: Ortam değişkenlerini echo ile yazdırmak veya komutların verbose modunu kullanmak.

Çözüm:

# ❌ KÖTÜ - günlüklerde kimlik bilgileri
- name: Proxy hata ayıklama
  run: |
    echo "Proxy: $HTTP_PROXY"  # http://user:pass@host:port gösterir
    curl -v ...  # Verbose mod kimlik bilgilerini gösterir

# ✅ İYİ - güvenli çıktı
- name: Proxy hata ayıklama (güvenli)
  run: |
    echo "Proxy ana bilgisayarı yapılandırıldı: $(echo $HTTP_PROXY | cut -d'@' -f2)"
    # Sadece host:port gösterir
    
# Maskeleme için gizli verileri kullanın
- name: Proxy'yi yapılandır
  env:
    PROXY_URL: ${{ secrets.PROXY_URL }}  # GitHub otomatik olarak maskeleyecektir
  run: |
    export HTTP_PROXY="$PROXY_URL"

Sonuç

CI/CD pipeline'ında proxy entegrasyonu, güvenliği sağlamak, kurumsal politikalara uyum sağlamak ve coğrafi konum özelliklerini test etme imkanı sunan önemli bir otomasyon unsurudur. Bu kılavuzda, GitHub Actions, GitLab CI, Jenkins, Docker ve popüler paket yöneticileri için proxy ayarlama yöntemlerini inceledik.

Proxy ayarlarken akılda tutulması gereken ana noktalar: her zaman platformların yerleşik gizlilik mekanizmaları aracılığıyla kimlik bilgilerini güvenli bir şekilde saklayın, yerel ve iç hizmetleri hariç tutmak için NO_PROXY'yi doğru ayarlayın, ana işlemlerden önce proxy bağlantısını test edin ve hassas verilerin sızması açısından günlükleri izleyin. Kritik üretim ortamları için HashiCorp Vault gibi dış gizlilik yönetim sistemlerinin kullanılması önerilir.

Proxy türü, ihtiyaçlarınıza bağlıdır: kurumsal ağlar genellikle mevcut HTTP/HTTPS proxy'leri kullanırken, coğrafi konum özelliklerini test etmek için gerekli ülkelerden IP'lere sahip rezidans proxy'leri uygundur, bağımlılıkların yüksek hızlı indirilmesi için ise veri merkezi proxy'leri kullanılabilir. Proxy sunucularının yüksek uptime'ını sağlamak önemlidir, çünkü erişilemez olmaları tüm derlemelerin düşmesine ve geliştirme ekibinin işinin engellenmesine neden olacaktır.

Sorunlarla karşılaştığınızda, önce proxy'nin temel erişilebilirliğini curl veya wget ile kontrol edin, ardından URL ve kimlik bilgileri formatını doğrulayın ve yalnızca daha sonra belirli araçların özel ayarlarına geçin. Çoğu sorun, HTTP_PROXY, HTTPS_PROXY ve NO_PROXY ortam değişkenlerinin doğru ayarlanması ile çözülmektedir.