Proxy untuk Pipeline CI/CD: Mengatur GitHub Actions, GitLab CI, dan Jenkins untuk Akses ke Sumber Daya Tertutup

Apakah pipeline Anda gagal dengan kesalahan 403 Forbidden atau Connection refused saat mencoba mengakses API eksternal atau mengunduh dependensi? Kemungkinan besar, masalahnya adalah alamat IP server CI/CD Anda diblokir di sisi sumber daya. Proxy menyelesaikan masalah ini: Anda mengarahkan lalu lintas melalui IP yang diperlukan dan pipeline berjalan tanpa gangguan. Dalam artikel ini — instruksi langkah demi langkah untuk GitHub Actions, GitLab CI, dan Jenkins.

Mengapa proxy dalam CI/CD: skenario nyata

Pipeline CI/CD berjalan di server dengan alamat IP tetap — runner cloud GitHub, GitLab, atau agen Jenkins milik sendiri. IP ini dikenal dengan baik, dan banyak layanan eksternal baik memblokirnya atau membatasi jumlah permintaan. Berikut adalah situasi konkret di mana proxy sangat diperlukan:

Akses ke sumber daya yang dibatasi geo

Banyak registri npm perusahaan, repositori Maven, dan API internal hanya dapat diakses dari negara atau rentang IP tertentu. Jika runner GitHub Actions Anda berada di wilayah yang diblokir di tingkat firewall layanan target, pipeline tidak akan dapat mengunduh dependensi atau mengirim data. Proxy dengan geolokasi yang diperlukan menyelesaikan masalah ini tanpa mengubah infrastruktur.

Pembatasan laju dan pemblokiran IP

Runner cloud GitHub Actions menggunakan IP dari rentang Microsoft Azure. Banyak API publik mengetahui rentang ini dan menerapkan batasan ketat — atau memblokir sepenuhnya. Misalnya, pengambilan data publik, permintaan ke API pihak ketiga selama pengujian, mengunduh distribusi dari CDN terbatas — semua ini sering gagal karena IP dari runner cloud. Rotasi melalui proxy memungkinkan untuk menghindari pembatasan laju.

Pengujian integrasi dengan situs nyata

Jika pengujian integrasi Anda mengakses situs web nyata atau marketplace (Wildberries, Ozon, Avito, Amazon), situs-situs ini melihat IP yang sama dari runner setiap kali dijalankan dan dengan cepat memblokirnya. Proxy dengan rotasi IP memungkinkan pengujian berjalan stabil tanpa CAPTCHA dan pemblokiran.

Akses ke sumber daya internal perusahaan

Jaringan perusahaan sering kali tertutup dari dunia luar. Jika pipeline harus melakukan deploy ke server internal atau mengakses API tertutup, proxy (atau terowongan SOCKS5) di dalam jaringan perusahaan menjadi jembatan antara runner cloud dan infrastruktur tertutup.

Pengujian integrasi iklan dan pemasaran

Tim yang bekerja dengan Facebook Ads API, TikTok Ads API, atau Google Ads API sering kali mengotomatiskan pembuatan kampanye melalui CI/CD. Platform ini memiliki aturan ketat terkait IP: permintaan dari IP pusat data dapat diblokir atau memerlukan verifikasi tambahan. Proxy residensial dalam pipeline membuat permintaan terlihat seperti lalu lintas pengguna biasa.

Jenis proxy mana yang harus dipilih untuk pipeline

Pemilihan jenis proxy tergantung pada tugas. Untuk pipeline CI/CD, ada tiga opsi yang relevan — masing-masing memiliki kelebihan dan batasan:

Mengatur proxy di GitHub Actions

GitHub Actions adalah alat CI/CD yang paling populer saat ini. Pengaturan proxy di sini dilakukan melalui variabel lingkungan dan rahasia repositori. Mari kita bahas langkah demi langkah.

Langkah 1: Tambahkan data proxy ke rahasia repositori

Jangan pernah menuliskan login dan kata sandi proxy langsung di file YAML workflow. Gunakan Rahasia GitHub:

1. Buka repositori → Settings → Secrets and variables → Actions
2. Klik New repository secret
3. Buat rahasia PROXY_URL dengan nilai seperti http://user:[email protected]:port

Langkah 2: Gunakan variabel lingkungan dalam workflow

Kebanyakan alat (curl, wget, npm, pip, Maven) secara otomatis mengambil variabel lingkungan standar HTTP_PROXY, HTTPS_PROXY, dan NO_PROXY. Contoh workflow:

name: Build with Proxy

on: [push]

env:
  HTTP_PROXY: ${{ secrets.PROXY_URL }}
  HTTPS_PROXY: ${{ secrets.PROXY_URL }}
  NO_PROXY: localhost,127.0.0.1,internal.company.com

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install dependencies
        run: npm ci

      - name: Run integration tests
        run: npm test

      - name: Call external API
        run: |
          curl -v https://api.example.com/data

Langkah 3: Proxy SOCKS5 di GitHub Actions

Jika Anda menggunakan SOCKS5 (direkomendasikan untuk sebagian besar tugas), variabel lingkungan standar tidak cukup — diperlukan terowongan lokal. Gunakan utilitas proxychains atau atur microsocks:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Setup SOCKS5 proxy tunnel
        run: |
          sudo apt-get install -y proxychains4
          echo "socks5 proxy.host 1080 user password" >> /etc/proxychains4.conf

      - name: Run command through SOCKS5
        run: proxychains4 curl https://restricted-resource.com/api

Mengatur proxy untuk alat tertentu

Beberapa alat mengabaikan variabel sistem dan memerlukan pengaturan terpisah:

Mengatur proxy di GitLab CI

GitLab CI menyediakan beberapa tingkat untuk menetapkan variabel lingkungan: di tingkat proyek, grup, atau instance. Ini membuat pengelolaan proxy lebih fleksibel dibandingkan dengan GitHub Actions.

Langkah 1: Tambahkan variabel ke GitLab CI/CD Variables

1. Buka proyek → Settings → CI/CD → bagian Variables
2. Klik Add variable
3. Tambahkan variabel PROXY_URL dengan tipe Masked (menyembunyikan nilai di log)
4. Nilai: http://user:[email protected]:port

Langkah 2: Gunakan variabel di .gitlab-ci.yml

variables:
  HTTP_PROXY: $PROXY_URL
  HTTPS_PROXY: $PROXY_URL
  NO_PROXY: "localhost,127.0.0.1,.internal.company.com"

stages:
  - build
  - test
  - deploy

build:
  stage: build
  image: node:20-alpine
  script:
    - npm ci
    - npm run build

integration_tests:
  stage: test
  image: python:3.11
  script:
    - pip install -r requirements.txt
    - pytest tests/integration/

deploy:
  stage: deploy
  script:
    - curl -X POST https://api.external-service.com/deploy
      -H "Authorization: Bearer $DEPLOY_TOKEN"
      -d '{"version": "$CI_COMMIT_SHA"}'

Proxy hanya untuk pekerjaan tertentu

Jika proxy tidak diperlukan di semua tempat (misalnya, hanya untuk pengujian integrasi, tetapi tidak untuk build), tetapkan variabel di tingkat pekerjaan tertentu, bukan secara global:

integration_tests:
  stage: test
  variables:
    HTTP_PROXY: $PROXY_URL
    HTTPS_PROXY: $PROXY_URL
  script:
    - pytest tests/integration/

build:
  stage: build
  # Di sini proxy tidak ditetapkan — koneksi langsung
  script:
    - npm ci && npm run build

GitLab Runner yang di-host sendiri: mengatur proxy di tingkat runner

Jika Anda menggunakan GitLab Runner sendiri, Anda dapat menetapkan proxy secara global dalam konfigurasi runner. Buka file /etc/gitlab-runner/config.toml dan tambahkan di bagian [runners.env]:

[[runners]]
  name = "my-runner"
  url = "https://gitlab.com/"
  token = "TOKEN"
  executor = "docker"
  environment = [
    "HTTP_PROXY=http://user:[email protected]:port",
    "HTTPS_PROXY=http://user:[email protected]:port",
    "NO_PROXY=localhost,127.0.0.1"
  ]

Ini nyaman ketika semua pipeline di runner ini harus menggunakan proxy — tidak perlu menuliskannya di setiap .gitlab-ci.yml.

Mengatur proxy di Jenkins

Jenkins adalah yang paling fleksibel dari ketiga alat, tetapi juga yang paling sulit untuk diatur. Proxy di sini dapat ditetapkan di beberapa tingkat: secara global untuk seluruh Jenkins, untuk Pipeline tertentu, atau untuk langkah tertentu.

Metode 1: Pengaturan proxy global di Jenkins

1. Buka Manage Jenkins → System
2. Cari bagian HTTP Proxy Configuration
3. Isi kolom: Server, Port, Username, Password
4. Di kolom No Proxy Host sebutkan alamat internal dengan koma
5. Klik Test URL untuk memeriksa dan simpan

Pengaturan ini mempengaruhi pengunduhan plugin dan pembaruan Jenkins itu sendiri, tetapi tidak secara otomatis diteruskan ke lingkungan eksekusi pipeline. Untuk pipeline, konfigurasi terpisah diperlukan.

Metode 2: Proxy dalam Declarative Pipeline melalui environment

pipeline {
    agent any

    environment {
        HTTP_PROXY  = credentials('proxy-url-credential')
        HTTPS_PROXY = credentials('proxy-url-credential')
        NO_PROXY    = 'localhost,127.0.0.1,internal.company.com'
    }

    stages {
        stage('Build') {
            steps {
                sh 'npm ci'
                sh 'npm run build'
            }
        }

        stage('Integration Tests') {
            steps {
                sh 'pytest tests/integration/'
            }
        }

        stage('Deploy') {
            steps {
                sh '''
                    curl -X POST https://api.external-service.com/deploy \
                    -H "Authorization: Bearer ${DEPLOY_TOKEN}" \
                    -d "version=${GIT_COMMIT}"
                '''
            }
        }
    }
}

Langkah 3: Tambahkan kredensial proxy di Jenkins Credentials

1. Buka Manage Jenkins → Credentials → System → Global credentials
2. Klik Add Credentials
3. Tipe: Secret text
4. ID: proxy-url-credential
5. Secret: http://user:[email protected]:port

Metode 3: Proxy melalui parameter JVM untuk proyek Java

Jika pipeline Anda membangun proyek Java (Maven, Gradle), variabel lingkungan sistem mungkin tidak berfungsi — JVM menggunakan properti sistemnya sendiri. Tambahkan mereka di JAVA_OPTS:

environment {
    JAVA_OPTS = '-Dhttps.proxyHost=proxy.host -Dhttps.proxyPort=8080 -Dhttps.proxyUser=user -Dhttps.proxyPassword=password -Dhttp.nonProxyHosts=localhost|127.0.0.1|*.internal.com'
}

Proxy di dalam kontainer Docker dalam pipeline

Sebagian besar pipeline CI/CD modern menjalankan langkah-langkah di dalam kontainer Docker. Mengalihkan proxy ke dalam kontainer adalah tugas terpisah yang dapat diselesaikan dengan beberapa cara.

Mengalihkan proxy melalui --build-arg saat membangun image

Jika proxy hanya diperlukan selama proses pembuatan image Docker (misalnya, untuk menginstal paket di dalam Dockerfile), gunakan argumen build:

# Di .github/workflows/build.yml atau .gitlab-ci.yml
docker build \
  --build-arg HTTP_PROXY=$HTTP_PROXY \
  --build-arg HTTPS_PROXY=$HTTPS_PROXY \
  --build-arg NO_PROXY=$NO_PROXY \
  -t myapp:latest .

# Di Dockerfile
ARG HTTP_PROXY
ARG HTTPS_PROXY
ARG NO_PROXY
ENV HTTP_PROXY=$HTTP_PROXY
ENV HTTPS_PROXY=$HTTPS_PROXY
ENV NO_PROXY=$NO_PROXY

RUN apt-get update && apt-get install -y curl
RUN npm ci

Pengaturan global untuk Docker daemon untuk proxy

Di runner yang di-host sendiri, Anda dapat mengatur proxy untuk seluruh Docker daemon — maka semua kontainer secara otomatis akan mendapatkan proxy tanpa perubahan di Dockerfile:

# /etc/systemd/system/docker.service.d/http-proxy.conf
[Service]
Environment="HTTP_PROXY=http://user:[email protected]:port"
Environment="HTTPS_PROXY=http://user:[email protected]:port"
Environment="NO_PROXY=localhost,127.0.0.1,registry.internal.com"

# Terapkan perubahan:
# systemctl daemon-reload
# systemctl restart docker

Keamanan: cara menyimpan kredensial proxy

Kredensial proxy adalah rahasia yang sama seperti kunci API atau kata sandi basis data. Kebocoran mereka berarti siapa pun dapat menggunakan proxy Anda atas nama Anda. Berikut adalah aturan untuk penyimpanan yang aman:

Checklist keamanan

• ✅ Jangan pernah menuliskan login/kata sandi proxy langsung di file YAML pipeline
• ✅ Gunakan Masked variables di GitLab dan Encrypted secrets di GitHub — mereka disembunyikan di log
• ✅ Di Jenkins, gunakan tipe Secret text atau Username with password di Credentials Store
• ✅ Tambahkan NO_PROXY untuk alamat internal — lalu lintas ke infrastruktur Anda sendiri tidak boleh melalui proxy
• ✅ Secara teratur rotasi kata sandi proxy — perbarui hanya di penyimpanan rahasia, tanpa mengubah kode pipeline
• ✅ Gunakan otentikasi IP proxy (whitelist IP runner) di tempat yang didukung — ini lebih aman daripada kata sandi
• ✅ Periksa log proxy untuk aktivitas yang tidak biasa

Format URL proxy: apa yang harus dimasukkan ke mana

Kesalahan umum dan cara memperbaikinya

Bahkan setelah pengaturan yang benar, masalah dapat muncul. Berikut adalah kesalahan yang paling umum dan solusinya:

Kesalahan: Proxy Authentication Required (407)

Kesalahan: SSL Certificate Verification Failed

Kesalahan: Connection Timeout melalui proxy

Kesalahan: Alat mengabaikan variabel HTTP_PROXY

Kesalahan: Layanan internal juga melalui proxy

Kesimpulan

Mengatur proxy dalam pipeline CI/CD bukanlah tugas sekali saja, tetapi bagian dari arsitektur otomatisasi yang tepat. Kami telah membahas tiga alat utama: GitHub Actions (melalui Secrets dan variabel lingkungan), GitLab CI (melalui Variables dengan pemaskeran), dan Jenkins (melalui Credentials Store dan Declarative Pipeline). Prinsip kunci sama untuk semua: jangan pernah menyimpan kredensial dalam kode, gunakan NO_PROXY untuk alamat internal, dan pilih jenis proxy sesuai dengan tugas tertentu.

Memilih jenis proxy yang tepat sangat penting untuk stabilitas pipeline. Untuk mengunduh dependensi dan mengakses API standar, cukup gunakan proxy pusat data yang cepat. Namun, jika pipeline Anda melakukan pengujian integrasi di situs nyata, bekerja dengan platform iklan (Facebook Ads API, TikTok Ads API), atau mengakses marketplace — gunakan proxy residensial: IP mereka dianggap sebagai lalu lintas pengguna biasa dan sangat jarang terkena pemblokiran atau pembatasan laju.

Aturan utama: uji proxy sebagai langkah terpisah di awal pipeline — ini akan memungkinkan Anda untuk dengan cepat mendiagnosis masalah dan tidak membuang waktu untuk mencari kesalahan di akhir build yang panjang. Tambahkan langkah curl -v https://api.ipify.org segera setelah pengaturan proxy — ini akan menunjukkan IP dari mana permintaan dikirim dan mengkonfirmasi bahwa pemrosesan proxy berfungsi dengan benar.