프록시를 CI/CD에 통합하기: GitHub Actions 및 GitLab 설정

```html

배포 및 테스트 자동화 과정에서 CI/CD 프로세스에서 프록시 서버를 사용하는 필요성이 자주 발생합니다. 이는 기업 보안 정책, 지리적 기능 테스트 또는 종속성 다운로드 시 속도 제한 우회를 위한 것일 수 있습니다. 이 가이드에서는 인기 있는 CI/CD 플랫폼에 대한 프록시 설정을 실제 예제와 함께 살펴보겠습니다.

CI/CD 프로세스에서 프록시가 필요한 이유

자동화된 배포 프로세스에서 프록시 서버를 사용하는 것은 여러 가지 중요한 문제를 해결합니다. 첫째, 많은 기업 네트워크는 보안 제어 및 로깅을 위해 모든 아웃바운드 트래픽이 기업 프록스를 통과하도록 요구합니다. 올바르게 설정하지 않으면 CI/CD 파이프라인이 종속성을 다운로드하거나 외부 서비스에 연결할 수 없습니다.

둘째, 지리적 로직이 포함된 애플리케이션을 테스트할 때는 다양한 국가에서의 작동을 확인해야 합니다. 예를 들어, 지역 콘텐츠나 가격 책정 서비스를 개발하는 경우 자동화된 테스트는 다양한 위치의 사용자를 시뮬레이션해야 합니다. 이때 주거용 프록시가 필요한 지역의 IP 주소를 제공합니다.

세 번째 이유는 속도 제한 및 차단 우회입니다. 특히 대규모 팀에서 파이프라인을 자주 실행할 경우 CI/CD 서버가 외부 서비스의 API 제한에 걸릴 수 있습니다. 예를 들어, GitHub API 또는 패키지 레지스트리는 요청 한도를 초과하면 IP를 일시적으로 차단할 수 있습니다. 프록시를 회전시키면 부하를 분산할 수 있습니다.

중요: CI/CD 프로세스에서는 연결의 안정성이 중요합니다. 가동 시간이 99.5% 이상이고 응답 시간이 200ms 이하인 프록시를 사용하세요. 불안정한 프록시는 빌드의 임의 중단과 팀의 조사 시간 손실을 초래할 수 있습니다.

GitHub Actions에서 프록시 설정

GitHub Actions는 CI/CD를 위한 가장 인기 있는 플랫폼 중 하나입니다. 여기서 프록시 설정은 워크플로우 또는 전체 조직 수준에서 설정할 수 있는 환경 변수를 통해 수행됩니다. 여러 가지 통합 방법을 살펴보겠습니다.

환경 변수를 통한 기본 설정

가장 간단한 방법은 job의 시작 부분에 HTTP_PROXY 및 HTTPS_PROXY 환경 변수를 설정하는 것입니다. 대부분의 도구(curl, wget, npm, pip)는 이러한 변수를 자동으로 사용합니다:

name: CI with Proxy

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: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      
      - name: Install dependencies
        run: npm install
      
      - name: Run tests
        run: npm test

NO_PROXY 변수는 매우 중요합니다. 이 변수는 로컬 주소와 내부 서비스를 프록시에서 제외합니다. 이 변수가 없으면 localhost 또는 내부 Docker 컨테이너에 연결하는 데 문제가 발생할 수 있습니다.

GitHub Secrets를 통한 자격 증명 안전한 저장

프록시가 인증을 요구하는 경우, 워크플로우 파일에 로그인 및 비밀번호를 노출된 형태로 저장하지 마세요. GitHub Secrets를 사용하세요:

name: CI with Authenticated Proxy

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v3
      
      - name: Configure Proxy
        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: Test proxy connection
        run: curl -I https://api.github.com
      
      - name: Install dependencies
        run: npm ci

레포지토리 설정에서 secrets를 생성하세요: Settings → Secrets and variables → Actions → New repository secret. PROXY_USER, PROXY_PASS, PROXY_HOST 및 PROXY_PORT를 추가하세요. 이러한 값은 암호화되어 로그에서 접근할 수 없습니다.

특정 단계에 대한 프록시 설정

때때로 특정 작업에 대해서만 프록시를 사용해야 할 수도 있습니다. 예를 들어, 종속성 다운로드에는 프록시를 사용하지만 배포에는 사용하지 않을 수 있습니다. 특정 step 수준에서 변수를 설정하세요:

steps:
  - name: Download dependencies via proxy
    env:
      HTTP_PROXY: http://proxy.example.com:8080
      HTTPS_PROXY: http://proxy.example.com:8080
    run: npm install
  
  - name: Deploy without proxy
    run: ./deploy.sh

GitLab CI/CD와 프록시 통합

GitLab CI/CD는 runner 수준, 프로젝트 수준 및 특정 job 수준에서 프록시 설정을 제공합니다. 선택은 모든 프로젝트에 프록시가 필요한지 아니면 특정 프로젝트에만 필요한지에 따라 다릅니다.

GitLab Runner 수준에서 프록시 설정

self-hosted GitLab Runner를 사용하고 모든 프로젝트가 프록스를 통해 작동해야 하는 경우, runner 구성에서 설정하세요. /etc/gitlab-runner/config.toml 파일을 편집하세요:

[[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"

구성을 변경한 후 runner를 재시작하세요: sudo gitlab-runner restart. 이제 이 runner의 모든 jobs는 자동으로 프록스를 사용합니다.

.gitlab-ci.yml을 통한 설정

특정 프로젝트 수준에서 프록시를 설정하려면 .gitlab-ci.yml 파일에서 변수를 사용하세요. 이는 다양한 프로젝트가 서로 다른 프록시를 사용할 수 있는 보다 유연한 접근 방식입니다:

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 configured: $HTTP_PROXY"
    - npm install
    - npm run build
  artifacts:
    paths:
      - dist/

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

자격 증명에 대한 GitLab CI/CD Variables 사용

민감한 데이터를 저장하려면 프로젝트 설정에서 CI/CD Variables를 사용하세요: Settings → CI/CD → Variables. protected 및 masked 변수를 생성하세요:

PROXY_URL — 자격 증명이 포함된 전체 URL (masked)
PROXY_HOST — 프록시 서버의 호스트
PROXY_PORT — 포트
PROXY_USER 및 PROXY_PASS — 별도의 저장을 위해

그런 다음 .gitlab-ci.yml에서 이를 사용하세요:

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에서 프록시 구성

Jenkins는 아키텍처에 따라 프록시를 설정하는 여러 가지 방법을 제공합니다: Jenkins 마스터에 대한 전역 설정, 특정 에이전트에 대한 설정 또는 개별 파이프라인 수준의 설정.

Jenkins에 대한 전역 프록시 설정

Jenkins가 플러그인 업데이트 및 기타 내부 작업에 사용할 프록시를 설정하려면 Manage Jenkins → Manage Plugins → Advanced로 이동하세요. HTTP Proxy Configuration 섹션에서 다음을 지정하세요:

서버: proxy.example.com
포트: 8080
사용자 이름 및 비밀번호 (인증이 필요한 경우)
No Proxy Host: localhost,127.0.0.1,.internal

이 설정은 Jenkins 자체에만 영향을 미치며 jobs에는 영향을 미치지 않습니다. jobs에는 별도의 구성이 필요합니다.

Jenkins Pipeline에 대한 프록시 설정

Jenkinsfile에서 전체 파이프라인 또는 특정 단계에 대한 환경 변수를 설정할 수 있습니다:

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'
            }
        }
    }
}

프록시 자격 증명에 대한 Jenkins Credentials 사용

프록시 자격 증명을 안전하게 저장하려면 Jenkins Credentials Store를 사용하세요. Manage Jenkins → Manage Credentials에서 "Username with password" 유형의 자격 증명을 생성한 다음 파이프라인에서 사용하세요:

pipeline {
    agent any
    
    stages {
        stage('Build with Authenticated Proxy') {
            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 에이전트에 대한 프록시 설정

별도의 Jenkins 에이전트(nodes)를 사용하는 경우 각 에이전트에 대해 프록시를 별도로 설정하세요. 에이전트 구성(Manage Jenkins → Manage Nodes → Configure)에서 환경 변수에 추가하세요:

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

CI/CD에서 Docker를 위한 프록시

Docker는 현대 CI/CD 프로세스의 필수 요소입니다. Docker에 대한 프록시 설정은 Docker daemon과 컨테이너 모두에 대해 설정해야 하므로 특별한 주의가 필요합니다.

Docker daemon에 대한 프록시 설정

Docker daemon이 프록스를 통해 이미지를 다운로드할 수 있도록 systemd drop-in 파일을 생성하세요. Linux 시스템에서 디렉토리와 파일을 생성하세요:

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

다음 내용을 추가하세요:

[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"

구성을 재로드하고 Docker를 재시작하세요:

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

빌드 중 컨테이너에 대한 프록시

컨테이너가 빌드 중에 프록스를 통해 접근해야 하는 경우(예: 패키지 설치), Dockerfile의 build args를 통해 변수를 전달하세요:

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 . .

# 런타임을 위한 프록시 변수 제거
ENV HTTP_PROXY=
ENV HTTPS_PROXY=

CMD ["npm", "start"]

CI/CD 파이프라인에서 build args를 전달하세요:

# GitHub Actions
- name: Build Docker image with proxy
  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

CI/CD에서 Docker Compose를 사용할 때는 docker-compose.yml에서 environment를 통해 프록시를 설정하세요:

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"

패키지 관리자용 프록시 설정

패키지 관리자는 종종 자체 구성 파일을 사용하는 경우 프록시 설정이 추가로 필요합니다. 인기 있는 패키지 관리자에 대한 설정을 살펴보겠습니다.

NPM 및 Yarn

NPM은 HTTP_PROXY/HTTPS_PROXY 환경 변수를 사용할 수 있으며, 자체 구성도 지원합니다. CI/CD에서 명시적으로 설정하려면:

# GitHub Actions 또는 GitLab CI에서
- name: Configure npm proxy
  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: Install dependencies
  run: npm install

# Yarn의 경우
- name: Configure yarn proxy
  run: |
    yarn config set proxy http://proxy.example.com:8080
    yarn config set https-proxy http://proxy.example.com:8080

대안으로는 프로젝트 루트에 .npmrc 파일을 생성하는 것입니다(그러나 자격 증명을 커밋하지 마세요!):

# .npmrc (CI에서 생성됨)
proxy=http://proxy.example.com:8080
https-proxy=http://proxy.example.com:8080
noproxy=localhost,127.0.0.1

Python pip 및 Poetry

Pip은 환경 변수를 사용하지만 구성 파일을 통해 설정할 수도 있습니다:

# 환경 변수를 통한 설정 (CI에 권장)
export HTTP_PROXY=http://proxy.example.com:8080
export HTTPS_PROXY=http://proxy.example.com:8080
pip install -r requirements.txt

# 또는 pip 매개변수를 통한 설정
pip install --proxy http://proxy.example.com:8080 -r requirements.txt

# Poetry의 경우
poetry config http-basic.proxy http://proxy.example.com:8080
poetry install

Maven 및 Gradle

Java 프로젝트의 경우 프록시 설정을 위해 구성 파일을 생성해야 합니다. Maven의 경우 CI 파이프라인에서 settings.xml을 생성하세요:

- name: Configure Maven proxy
  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: Build with Maven
  run: mvn clean install

Gradle의 경우 gradle.properties에 설정을 추가하세요:

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

프록시 자격 증명 안전하게 저장하기

프록시 자격 증명을 저장하는 것은 CI/CD 보안의 중요한 측면입니다. 이 데이터의 유출은 프록시의 무단 사용 및 재정적 손실로 이어질 수 있습니다. 다양한 플랫폼에 대한 모범 사례를 살펴보겠습니다.

GitHub Actions Secrets

GitHub Actions는 repository, environment 및 organization의 세 가지 수준의 비밀을 제공합니다. 프록시 자격 증명에는 다음을 사용하세요:

Repository secrets — 프록시가 단일 레포지토리에서만 필요한 프로젝트용
Organization secrets — 하나의 프록시가 조직의 모든 프로젝트에서 사용되는 경우
Environment secrets — staging/production 환경에서 서로 다른 프록시를 위한

중요한 보안 규칙:

비밀을 로그에 절대 출력하지 마세요: GitHub는 자동으로 이를 마스킹하지만 echo를 피하는 것이 좋습니다.
서로 다른 환경에 대해 서로 다른 자격 증명을 사용하세요.
프록시 비밀번호를 정기적으로 회전하세요 (최소 90일마다).
브랜치 보호 규칙을 통해 비밀에 대한 접근을 제한하세요.

GitLab CI/CD Variables

GitLab은 변수 보호를 위한 추가 옵션을 제공합니다:

Protected — protected branches(main, production)에서만 변수를 사용할 수 있습니다.
Masked — 값이 자동으로 로그에서 숨겨집니다.
Environment scope — 특정 환경에서만 사용 제한.

프록시 자격 증명에 대한 권장 구성:

# Settings → CI/CD → Variables
PROXY_USER: myuser (Protected: Yes, Masked: Yes)
PROXY_PASS: secret123 (Protected: Yes, Masked: Yes)
PROXY_HOST: proxy.example.com (Protected: No, Masked: No)
PROXY_PORT: 8080 (Protected: No, Masked: No)

Jenkins Credentials Store

Jenkins Credentials Store는 여러 유형의 자격 증명 저장을 지원합니다. 프록시의 경우 다음을 권장합니다:

프록시 로그인/비밀번호에 대해 "Username with password" 사용.
다른 팀/프로젝트를 위한 Folder-level credentials 설정.
Pipeline에서 안전하게 사용하기 위해 Credentials Binding Plugin 활성화.
자격 증명 사용 추적을 위한 감사 로깅 설정.

외부 비밀 관리 시스템

엔터프라이즈 환경에서는 HashiCorp Vault, AWS Secrets Manager, Azure Key Vault 또는 Google Secret Manager와 같은 전문 비밀 관리 시스템을 사용하는 것이 좋습니다. GitHub Actions에서 HashiCorp Vault와 통합하는 예:

- name: Import Secrets from Vault
  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: Configure Proxy
  run: |
    export HTTP_PROXY="http://${PROXY_USER}:${PROXY_PASS}@${PROXY_HOST}:8080"
    npm install

일반적인 문제 해결

CI/CD에 프록시를 통합할 때 자주 발생하는 문제들이 있습니다. 가장 일반적인 문제와 그 해결 방법을 살펴보겠습니다.

문제: 종속성 다운로드 시 연결 시간 초과

증상: npm install, pip install 또는 docker pull이 30-60초 후에 시간 초과 오류로 종료됩니다.

원인:

프록시 서버가 사용 불가능하거나 과부하 상태입니다.
프록시 URL 형식이 잘못되었습니다 (시작 부분에 http://가 누락됨).
프록시가 인증을 요구하지만 자격 증명이 전달되지 않았습니다.
방화벽이 CI/CD runner와 프록시 간의 연결을 차단합니다.

해결책:

# 1. 프록시 접근 가능성 확인
- name: Test proxy connectivity
  run: |
    curl -v -x http://proxy.example.com:8080 https://www.google.com
    echo "Proxy test completed"

# 2. npm의 시간 초과 증가
- name: Install with increased timeout
  run: |
    npm config set fetch-timeout 300000
    npm install

# 3. URL 형식 확인
- name: Debug proxy configuration
  run: |
    echo "HTTP_PROXY: $HTTP_PROXY"
    echo "HTTPS_PROXY: $HTTPS_PROXY"
    # 다음과 같아야 합니다: http://user:pass@host:port

문제: SSL 인증서 검증 실패

증상: "SSL certificate problem: unable to get local issuer certificate" 또는 "CERT_UNTRUSTED"와 같은 오류가 발생합니다.

원인: 기업 프록시는 종종 SSL 검사를 수행하여 인증서를 변경합니다. CI/CD runner는 기업 CA를 신뢰하지 않습니다.

해결책:

# 옵션 1: 기업 CA 인증서 추가
- name: Install corporate CA certificate
  run: |
    sudo cp corporate-ca.crt /usr/local/share/ca-certificates/
    sudo update-ca-certificates

# 옵션 2: SSL 검증 비활성화 (프로덕션에서는 권장하지 않음!)
- name: Install with SSL verification disabled
  run: |
    npm config set strict-ssl false
    npm install
  env:
    NODE_TLS_REJECT_UNAUTHORIZED: 0

# 옵션 3: HTTP에 대해서만 프록시 사용, HTTPS는 직접
- name: Selective proxy usage
  run: npm install
  env:
    HTTP_PROXY: http://proxy.example.com:8080
    # HTTPS_PROXY는 설정하지 않음

경고: SSL 인증서 검증을 비활성화하면 심각한 보안 위험이 발생합니다. 이 접근 방식은 내부 기업 네트워크에서만 사용하고 반드시 기업 CA를 신뢰할 수 있는 목록에 추가하세요.

문제: 일부 명령은 프록시가 작동하지만 다른 명령은 작동하지 않음

증상: npm install은 프록시를 통해 작동하지만 git clone 또는 docker pull은 프록시 설정을 무시합니다.

원인: 서로 다른 도구는 서로 다른 프록시 설정 메커니즘을 사용합니다. Git과 Docker는 자체 구성 파일을 가지고 있습니다.

해결책:

# Git 프록시 설정
- name: Configure Git proxy
  run: |
    git config --global http.proxy http://proxy.example.com:8080
    git config --global https.proxy http://proxy.example.com:8080

# Docker 프록시 설정 (위의 Docker 섹션 참조)
# wget/curl에 대한 설정
- name: Configure wget/curl
  run: |
    echo "use_proxy = on" >> ~/.wgetrc
    echo "http_proxy = http://proxy.example.com:8080" >> ~/.wgetrc
    echo "https_proxy = http://proxy.example.com:8080" >> ~/.wgetrc

문제: 프록시가 활성화된 상태에서 내부 서비스에 접근할 수 없음

증상: 프록시 설정 후 localhost, 내부 Docker 컨테이너 또는 기업 서비스에 대한 연결이 작동하지 않습니다.

원인: NO_PROXY 변수가 잘못 설정되어 모든 요청이 프록스를 통해 전달되고 있습니다. 로컬 요청도 포함됩니다.

해결책:

# NO_PROXY의 올바른 설정
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의 경우에도 추가하세요
services:
  app:
    environment:
      - NO_PROXY=localhost,127.0.0.1,db,redis
      # db 및 redis는 compose의 다른 서비스 이름입니다.

문제: 프록시 자격 증명이 로그에 나타남

증상: CI/CD 로그에 프록시 비밀번호가 노출되어 있습니다.

원인: echo 또는 명령의 verbose 모드에서 환경 변수를 출력하고 있습니다.

해결책:

# ❌ 나쁜 예 - 로그에 자격 증명 노출
- name: Debug proxy
  run: |
    echo "Proxy: $HTTP_PROXY"  # http://user:pass@host:port가 표시됩니다.
    curl -v ...  # Verbose 모드에서 자격 증명이 표시됩니다.

# ✅ 좋은 예 - 안전한 출력
- name: Debug proxy (safe)
  run: |
    echo "Proxy host configured: $(echo $HTTP_PROXY | cut -d'@' -f2)"
    # host:port만 표시됩니다.
    
# 마스킹을 위해 secrets 사용
- name: Configure proxy
  env:
    PROXY_URL: ${{ secrets.PROXY_URL }}  # GitHub가 자동으로 마스킹합니다.
  run: |
    export HTTP_PROXY="$PROXY_URL"

결론

CI/CD 파이프라인에 프록시를 통합하는 것은 보안, 기업 정책 준수 및 지리적 기능 테스트 가능성을 보장하는 중요한 자동화 측면입니다. 이 가이드에서는 GitHub Actions, GitLab CI, Jenkins, Docker 및 인기 있는 패키지 관리자에 대한 프록시 설정 방법을 살펴보았습니다.

CI/CD에서 프록시 설정 시 기억해야 할 주요 사항: 항상 플랫폼의 내장 비밀 메커니즘을 통해 자격 증명을 안전하게 저장하고, 로컬 및 내부 서비스를 제외하기 위해 NO_PROXY를 올바르게 설정하며, 주요 작업 전에 프록시 연결을 테스트하고, 민감한 데이터 유출 여부를 모니터링하세요. 중요한 프로덕션 환경에서는 HashiCorp Vault와 같은 외부 비밀 관리 시스템을 사용하는 것이 좋습니다.

프록시 유형 선택은 귀하의 요구 사항에 따라 다릅니다: 기업 네트워크에서는 일반적으로 기존 HTTP/HTTPS 프록시를 사용하고, 지리적 기능 테스트에는 필요한 국가의 IP를 가진 주거용 프록시가 적합하며, 종속성의 고속 다운로드를 위해 데이터 센터 프록시를 사용할 수 있습니다. 프록시 서버의 높은 가동 시간을 보장하는 것이 중요하며, 서버의 비가용성은 모든 빌드 실패와 개발 팀의 작업 차단으로 이어질 수 있습니다.

문제가 발생하면 curl 또는 wget을 통해 프록시의 기본 접근 가능성을 확인하고, URL 및 자격 증명 형식의 정확성을 확인한 후, 특정 도구의 세부 설정으로 넘어가세요. 대부분의 문제는 HTTP_PROXY, HTTPS_PROXY 및 NO_PROXY 환경 변수를 올바르게 설정하여 해결할 수 있습니다.

```

CI/CD 파이프라인에서 프록시 통합: GitHub Actions, GitLab 및 Jenkins 설정

CI/CD 프로세스에서 프록시가 필요한 이유

GitHub Actions에서 프록시 설정

환경 변수를 통한 기본 설정

GitHub Secrets를 통한 자격 증명 안전한 저장

특정 단계에 대한 프록시 설정

GitLab CI/CD와 프록시 통합

GitLab Runner 수준에서 프록시 설정

.gitlab-ci.yml을 통한 설정

자격 증명에 대한 GitLab CI/CD Variables 사용

Jenkins에서 프록시 구성

Jenkins에 대한 전역 프록시 설정

Jenkins Pipeline에 대한 프록시 설정

프록시 자격 증명에 대한 Jenkins Credentials 사용

Jenkins 에이전트에 대한 프록시 설정

CI/CD에서 Docker를 위한 프록시

Docker daemon에 대한 프록시 설정

빌드 중 컨테이너에 대한 프록시

프록시가 있는 Docker Compose

패키지 관리자용 프록시 설정

NPM 및 Yarn

Python pip 및 Poetry

Maven 및 Gradle

프록시 자격 증명 안전하게 저장하기

GitHub Actions Secrets

GitLab CI/CD Variables

Jenkins Credentials Store

외부 비밀 관리 시스템

일반적인 문제 해결

문제: 종속성 다운로드 시 연결 시간 초과

문제: SSL 인증서 검증 실패

문제: 일부 명령은 프록시가 작동하지만 다른 명령은 작동하지 않음

문제: 프록시가 활성화된 상태에서 내부 서비스에 접근할 수 없음

문제: 프록시 자격 증명이 로그에 나타남

결론