Tích hợp proxy vào CI/CD: cấu hình cho GitHub Actions và GitLab

```html

Khi tự động hóa việc triển khai và kiểm tra, thường có nhu cầu sử dụng máy chủ proxy trong các quy trình CI/CD. Điều này có thể liên quan đến chính sách bảo mật của công ty, kiểm tra các chức năng định vị địa lý hoặc vượt qua giới hạn tần suất khi tải xuống các phụ thuộc. Trong hướng dẫn này, chúng ta sẽ xem xét cách cấu hình proxy cho các nền tảng CI/CD phổ biến với các ví dụ cấu hình sẵn có.

Tại sao cần proxy trong các quy trình CI/CD

Việc sử dụng máy chủ proxy trong các quy trình triển khai tự động giải quyết một số nhiệm vụ quan trọng. Thứ nhất, nhiều mạng doanh nghiệp yêu cầu tất cả lưu lượng truy cập ra ngoài phải đi qua proxy doanh nghiệp để kiểm soát bảo mật và ghi lại. Nếu không có cấu hình đúng, pipeline CI/CD sẽ không thể tải xuống các phụ thuộc hoặc kết nối với các dịch vụ bên ngoài.

Thứ hai, khi kiểm tra các ứng dụng có logic định vị địa lý, cần phải kiểm tra hoạt động từ các quốc gia khác nhau. Ví dụ, nếu bạn phát triển một dịch vụ với nội dung hoặc định giá khu vực, các bài kiểm tra tự động phải mô phỏng người dùng từ các vị trí khác nhau. Tại đây, proxy cư trú với địa chỉ IP từ các khu vực cần thiết sẽ giúp ích.

Lý do thứ ba là vượt qua giới hạn tần suất và các chặn. Khi pipeline chạy thường xuyên, đặc biệt là trong các đội lớn, các máy chủ CI/CD có thể bị giới hạn bởi API của các dịch vụ bên ngoài. Ví dụ, API GitHub hoặc các kho gói có thể tạm thời chặn IP khi vượt quá giới hạn yêu cầu. Việc luân chuyển proxy giúp phân phối tải.

Quan trọng: Đối với các quy trình CI/CD, độ ổn định của kết nối là rất quan trọng. Sử dụng proxy có thời gian hoạt động không dưới 99.5% và phản hồi nhanh (dưới 200ms). Các proxy không ổn định sẽ dẫn đến việc xây dựng bị rớt ngẫu nhiên và mất thời gian của đội ngũ để điều tra.

Cấu hình proxy trong GitHub Actions

GitHub Actions là một trong những nền tảng phổ biến nhất cho CI/CD. Cấu hình proxy ở đây được thực hiện thông qua các biến môi trường, có thể được thiết lập ở cấp độ workflow hoặc toàn bộ tổ chức. Chúng ta sẽ xem xét một số cách tích hợp.

Cấu hình cơ bản qua các biến môi trường

Cách đơn giản nhất là thiết lập các biến môi trường HTTP_PROXY và HTTPS_PROXY ở đầu job. Hầu hết các công cụ (curl, wget, npm, pip) sẽ tự động sử dụng các biến này:

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

Biến NO_PROXY là rất quan trọng — nó loại trừ các địa chỉ cục bộ và các dịch vụ nội bộ khỏi việc sử dụng proxy. Nếu không có nó, có thể xảy ra vấn đề khi kết nối với localhost hoặc các container Docker nội bộ.

Lưu trữ an toàn thông tin xác thực qua GitHub Secrets

Nếu proxy yêu cầu xác thực, không bao giờ lưu trữ tên đăng nhập và mật khẩu ở dạng công khai trong tệp workflow. Sử dụng 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

Tạo secrets trong cài đặt của kho lưu trữ: Settings → Secrets and variables → Actions → New repository secret. Thêm PROXY_USER, PROXY_PASS, PROXY_HOST và PROXY_PORT. Những giá trị này sẽ được mã hóa và không có sẵn trong các log.

Cấu hình proxy cho các bước cụ thể

Đôi khi cần sử dụng proxy chỉ cho các thao tác cụ thể, chẳng hạn như chỉ để tải xuống các phụ thuộc, nhưng không cho việc triển khai. Thiết lập các biến ở cấp độ bước cụ thể:

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

Tích hợp proxy với GitLab CI/CD

GitLab CI/CD cung cấp một số cấp độ cấu hình proxy: ở cấp độ runner, ở cấp độ dự án và ở cấp độ job cụ thể. Việc lựa chọn phụ thuộc vào việc proxy có cần cho tất cả các dự án hay chỉ cho một số dự án cụ thể.

Cấu hình proxy ở cấp độ GitLab Runner

Nếu bạn sử dụng GitLab Runner tự host và tất cả các dự án cần hoạt động qua proxy, hãy cấu hình nó trong tệp cấu hình của runner. Chỉnh sửa tệp /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"

Sau khi thay đổi cấu hình, hãy khởi động lại runner: sudo gitlab-runner restart. Bây giờ tất cả các job trên runner này sẽ tự động sử dụng proxy.

Cấu hình qua .gitlab-ci.yml

Để cấu hình proxy ở cấp độ dự án cụ thể, hãy sử dụng các biến trong tệp .gitlab-ci.yml. Đây là một cách tiếp cận linh hoạt hơn, cho phép các dự án khác nhau sử dụng các proxy khác nhau:

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

Sử dụng GitLab CI/CD Variables cho thông tin xác thực

Để lưu trữ dữ liệu nhạy cảm, hãy sử dụng CI/CD Variables trong cài đặt dự án: Settings → CI/CD → Variables. Tạo các biến protected và masked:

PROXY_URL — URL đầy đủ với thông tin xác thực (masked)
PROXY_HOST — máy chủ proxy
PROXY_PORT — cổng
PROXY_USER và PROXY_PASS — để lưu trữ riêng biệt

Sau đó, hãy sử dụng chúng trong .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

Cấu hình proxy trong Jenkins

Jenkins cung cấp một số cách để cấu hình proxy tùy thuộc vào kiến trúc: cấu hình toàn cầu cho Jenkins master, cấu hình cho các agent cụ thể hoặc cấu hình ở cấp độ pipeline riêng lẻ.

Cấu hình proxy toàn cầu cho Jenkins

Để cấu hình proxy mà Jenkins sẽ sử dụng cho việc cập nhật plugin và các hoạt động nội bộ khác, hãy chuyển đến Manage Jenkins → Manage Plugins → Advanced. Trong phần Cấu hình Proxy HTTP, hãy chỉ định:

Máy chủ: proxy.example.com
Cổng: 8080
Tên người dùng và Mật khẩu (nếu yêu cầu xác thực)
Không có máy chủ proxy: localhost,127.0.0.1,.internal

Cấu hình này chỉ ảnh hưởng đến chính Jenkins, nhưng không ảnh hưởng đến các job. Các job cần một cấu hình riêng.

Cấu hình proxy cho Jenkins Pipeline

Trong Jenkinsfile, bạn có thể chỉ định các biến môi trường cho toàn bộ pipeline hoặc cho các stages cụ thể:

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

Sử dụng Jenkins Credentials cho proxy

Để lưu trữ an toàn thông tin xác thực proxy, hãy sử dụng Jenkins Credentials Store. Tạo thông tin xác thực loại "Tên người dùng với mật khẩu" trong Manage Jenkins → Manage Credentials, sau đó sử dụng chúng trong pipeline:

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

Cấu hình proxy cho các agent Jenkins

Nếu bạn sử dụng các agent Jenkins riêng biệt (nodes), hãy cấu hình proxy cho từng agent riêng lẻ. Trong cấu hình của agent (Manage Jenkins → Manage Nodes → Configure), thêm vào các biến môi trường:

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

Proxy cho Docker trong CI/CD

Docker là một phần không thể thiếu trong các quy trình CI/CD hiện đại. Cấu hình proxy cho Docker có những đặc điểm riêng, vì cần cấu hình proxy cho cả Docker daemon và các container.

Cấu hình proxy cho Docker daemon

Để Docker daemon có thể tải xuống các hình ảnh qua proxy, hãy tạo một tệp drop-in systemd. Trên hệ thống Linux, hãy tạo thư mục và tệp:

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

Thêm nội dung sau:

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

Khởi động lại cấu hình và Docker:

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

Proxy cho các container trong quá trình xây dựng

Nếu các container cần truy cập qua proxy trong quá trình xây dựng (ví dụ, để cài đặt các gói), hãy truyền các biến qua build args trong Dockerfile:

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

# Xóa các biến proxy cho runtime
ENV HTTP_PROXY=
ENV HTTPS_PROXY=

CMD ["npm", "start"]

Trong pipeline CI/CD, hãy truyền các 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 với proxy

Khi sử dụng Docker Compose trong CI/CD, hãy cấu hình proxy qua environment trong docker-compose.yml:

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"

Cấu hình proxy cho các trình quản lý gói

Các trình quản lý gói thường yêu cầu cấu hình proxy bổ sung, đặc biệt nếu sử dụng các tệp cấu hình riêng. Hãy xem xét cấu hình cho các trình quản lý gói phổ biến.

NPM và Yarn

NPM có thể sử dụng cả các biến môi trường HTTP_PROXY/HTTPS_PROXY và cấu hình riêng. Để cấu hình rõ ràng trong CI/CD:

# Trong GitHub Actions hoặc 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

# Đối với 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

Một cách thay thế là tạo tệp .npmrc ở thư mục gốc của dự án (nhưng không commit thông tin xác thực!):

# .npmrc (được tạo trong CI)
proxy=http://proxy.example.com:8080
https-proxy=http://proxy.example.com:8080
noproxy=localhost,127.0.0.1

Python pip và Poetry

Pip sử dụng các biến môi trường, nhưng cũng có thể cấu hình qua tệp cấu hình:

# Qua các biến môi trường (được khuyến nghị cho CI)
export HTTP_PROXY=http://proxy.example.com:8080
export HTTPS_PROXY=http://proxy.example.com:8080
pip install -r requirements.txt

# Hoặc qua các tham số pip
pip install --proxy http://proxy.example.com:8080 -r requirements.txt

# Đối với Poetry
poetry config http-basic.proxy http://proxy.example.com:8080
poetry install

Maven và Gradle

Đối với các dự án Java, việc cấu hình proxy yêu cầu tạo các tệp cấu hình. Đối với Maven, hãy tạo tệp settings.xml trong pipeline CI:

- 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

Đối với Gradle, hãy thêm cấu hình vào 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

Lưu trữ an toàn thông tin xác thực proxy

Việc lưu trữ thông tin xác thực proxy là một khía cạnh quan trọng của bảo mật CI/CD. Việc rò rỉ những dữ liệu này có thể dẫn đến việc sử dụng proxy trái phép và tổn thất tài chính. Hãy xem xét các best practices cho các nền tảng khác nhau.

GitHub Actions Secrets

GitHub Actions cung cấp ba cấp độ bí mật: repository, environment và organization. Đối với thông tin xác thực proxy, hãy sử dụng:

Bí mật kho lưu trữ — cho các dự án mà proxy chỉ cần trong một kho lưu trữ
Bí mật tổ chức — nếu một proxy được sử dụng trong tất cả các dự án của tổ chức
Bí mật môi trường — cho các proxy khác nhau trong các môi trường staging/production

Các quy tắc bảo mật quan trọng:

Không bao giờ xuất bí mật ra log: GitHub tự động che giấu chúng, nhưng tốt hơn là tránh echo
Sử dụng các thông tin xác thực khác nhau cho các môi trường khác nhau
Thường xuyên thay đổi mật khẩu proxy (ít nhất 90 ngày một lần)
Hạn chế quyền truy cập vào các bí mật thông qua các quy tắc bảo vệ nhánh

GitLab CI/CD Variables

GitLab cung cấp các tùy chọn bảo vệ bổ sung cho các biến:

Protected — biến chỉ có sẵn trong các nhánh được bảo vệ (main, production)
Masked — giá trị tự động được ẩn trong log
Phạm vi môi trường — giới hạn việc sử dụng cho các môi trường cụ thể

Cấu hình được khuyến nghị cho thông tin xác thực proxy:

# 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 hỗ trợ nhiều loại lưu trữ thông tin xác thực. Đối với proxy, được khuyến nghị:

Sử dụng "Tên người dùng với mật khẩu" cho tên đăng nhập/mật khẩu proxy
Cấu hình thông tin xác thực cấp Folder cho các đội/người dự án khác nhau
Bật Credentials Binding Plugin để sử dụng an toàn trong Pipeline
Cấu hình audit logging để theo dõi việc sử dụng thông tin xác thực

Hệ thống quản lý bí mật bên ngoài

Đối với các môi trường doanh nghiệp, được khuyến nghị sử dụng các hệ thống quản lý bí mật chuyên dụng: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault hoặc Google Secret Manager. Ví dụ về tích hợp với HashiCorp Vault trong GitHub Actions:

- 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

Giải quyết các vấn đề phổ biến

Khi tích hợp proxy vào CI/CD, thường xảy ra những vấn đề giống nhau. Hãy xem xét những vấn đề phổ biến nhất và cách giải quyết chúng.

Vấn đề: Connection timeout khi tải xuống các phụ thuộc

Triệu chứng: npm install, pip install hoặc docker pull kết thúc với lỗi timeout sau 30-60 giây.

Nguyên nhân:

Máy chủ proxy không khả dụng hoặc quá tải
Định dạng URL proxy không đúng (quên http:// ở đầu)
Proxy yêu cầu xác thực, nhưng thông tin xác thực không được truyền
Firewall chặn kết nối từ CI/CD runner đến proxy

Giải pháp:

# 1. Kiểm tra tính khả dụng của proxy
- name: Test proxy connectivity
  run: |
    curl -v -x http://proxy.example.com:8080 https://www.google.com
    echo "Proxy test completed"

# 2. Tăng timeout cho npm
- name: Install with increased timeout
  run: |
    npm config set fetch-timeout 300000
    npm install

# 3. Kiểm tra định dạng URL
- name: Debug proxy configuration
  run: |
    echo "HTTP_PROXY: $HTTP_PROXY"
    echo "HTTPS_PROXY: $HTTPS_PROXY"
    # Phải là: http://user:pass@host:port

Vấn đề: SSL certificate verification failed

Triệu chứng: Lỗi kiểu "SSL certificate problem: unable to get local issuer certificate" hoặc "CERT_UNTRUSTED".

Nguyên nhân: Các proxy doanh nghiệp thường thực hiện kiểm tra SSL, thay thế các chứng chỉ. CI/CD runner không tin tưởng CA doanh nghiệp.

Giải pháp:

# Tùy chọn 1: Thêm chứng chỉ CA doanh nghiệp
- name: Install corporate CA certificate
  run: |
    sudo cp corporate-ca.crt /usr/local/share/ca-certificates/
    sudo update-ca-certificates

# Tùy chọn 2: Tắt kiểm tra SSL (KHÔNG được khuyến nghị cho production!)
- name: Install with SSL verification disabled
  run: |
    npm config set strict-ssl false
    npm install
  env:
    NODE_TLS_REJECT_UNAUTHORIZED: 0

# Tùy chọn 3: Sử dụng proxy chỉ cho HTTP, HTTPS trực tiếp
- name: Selective proxy usage
  run: npm install
  env:
    HTTP_PROXY: http://proxy.example.com:8080
    # Không thiết lập HTTPS_PROXY

Cảnh báo: Tắt kiểm tra chứng chỉ SSL tạo ra rủi ro bảo mật nghiêm trọng. Chỉ sử dụng cách tiếp cận này cho các mạng doanh nghiệp nội bộ và nhất định phải thêm CA doanh nghiệp vào danh sách tin cậy.

Vấn đề: Proxy hoạt động cho một số lệnh nhưng không cho các lệnh khác

Triệu chứng: npm install hoạt động qua proxy, nhưng git clone hoặc docker pull bỏ qua cấu hình proxy.

Nguyên nhân: Các công cụ khác nhau sử dụng các cơ chế cấu hình proxy khác nhau. Git và Docker có các tệp cấu hình riêng.

Giải pháp:

# Cấu hình proxy cho 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

# Cấu hình proxy cho Docker (xem phần Docker ở trên)
# Đối với 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

Vấn đề: Các dịch vụ nội bộ không khả dụng khi proxy được bật

Triệu chứng: Sau khi cấu hình proxy, không thể kết nối với localhost, các container Docker nội bộ hoặc các dịch vụ doanh nghiệp.

Nguyên nhân: Biến NO_PROXY được cấu hình không đúng, tất cả các yêu cầu đều đi qua proxy, bao gồm cả các yêu cầu cục bộ.

Giải pháp:

# Cấu hình đúng 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

# Đối với Docker Compose cũng thêm
services:
  app:
    environment:
      - NO_PROXY=localhost,127.0.0.1,db,redis
      # db và redis — tên của các dịch vụ khác trong compose

Vấn đề: Thông tin xác thực proxy xuất hiện trong log

Triệu chứng: Trong log CI/CD có thể thấy mật khẩu proxy ở dạng công khai.

Nguyên nhân: Xuất các biến môi trường qua echo hoặc chế độ verbose của các lệnh.

Giải pháp:

# ❌ XẤU - thông tin xác thực trong log
- name: Debug proxy
  run: |
    echo "Proxy: $HTTP_PROXY"  # Sẽ hiển thị http://user:pass@host:port
    curl -v ...  # Chế độ Verbose hiển thị thông tin xác thực

# ✅ TỐT - xuất an toàn
- name: Debug proxy (safe)
  run: |
    echo "Proxy host configured: $(echo $HTTP_PROXY | cut -d'@' -f2)"
    # Chỉ hiển thị host:port
    
# Sử dụng secrets để che giấu
- name: Configure proxy
  env:
    PROXY_URL: ${{ secrets.PROXY_URL }}  # GitHub tự động che giấu
  run: |
    export HTTP_PROXY="$PROXY_URL"

Kết luận

Tích hợp proxy vào pipeline CI/CD là một khía cạnh quan trọng của tự động hóa, đảm bảo an toàn, tuân thủ các chính sách doanh nghiệp và khả năng kiểm tra các chức năng định vị địa lý. Trong hướng dẫn này, chúng ta đã xem xét các cách thực tiễn để cấu hình proxy cho GitHub Actions, GitLab CI, Jenkins, Docker và các trình quản lý gói phổ biến.

Những điểm chính cần nhớ khi cấu hình proxy trong CI/CD: luôn sử dụng lưu trữ an toàn thông tin xác thực thông qua các cơ chế bí mật tích hợp của nền tảng, cấu hình đúng NO_PROXY để loại trừ các dịch vụ cục bộ và nội bộ, kiểm tra kết nối với proxy trước các hoạt động chính và theo dõi log để phát hiện rò rỉ dữ liệu nhạy cảm. Đối với các môi trường production quan trọng, được khuyến nghị sử dụng các hệ thống quản lý bí mật bên ngoài như HashiCorp Vault.

Việc lựa chọn loại proxy phụ thuộc vào các nhiệm vụ của bạn: cho các mạng doanh nghiệp, thường sử dụng các proxy HTTP/HTTPS hiện có, cho việc kiểm tra các chức năng định vị địa lý, các proxy cư trú với IP từ các quốc gia cần thiết là phù hợp, và cho việc tải xuống các phụ thuộc nhanh chóng, có thể sử dụng proxy trung tâm dữ liệu. Quan trọng là đảm bảo thời gian hoạt động cao của các máy chủ proxy, vì sự không khả dụng của chúng sẽ dẫn đến việc tất cả các bản xây dựng bị rớt và chặn công việc của đội ngũ phát triển.

Khi gặp vấn đề, hãy bắt đầu bằng việc kiểm tra tính khả dụng cơ bản của proxy qua curl hoặc wget, sau đó kiểm tra định dạng URL và thông tin xác thực, và chỉ sau đó chuyển sang các cấu hình cụ thể của các công cụ. Hầu hết các vấn đề đều có thể được giải quyết bằng cách cấu hình đúng các biến môi trường HTTP_PROXY, HTTPS_PROXY và NO_PROXY.

```

Tích hợp proxy vào pipeline CI/CD: cấu hình cho GitHub Actions, GitLab và Jenkins

Tại sao cần proxy trong các quy trình CI/CD

Cấu hình proxy trong GitHub Actions

Cấu hình cơ bản qua các biến môi trường

Lưu trữ an toàn thông tin xác thực qua GitHub Secrets

Cấu hình proxy cho các bước cụ thể

Tích hợp proxy với GitLab CI/CD

Cấu hình proxy ở cấp độ GitLab Runner

Cấu hình qua .gitlab-ci.yml

Sử dụng GitLab CI/CD Variables cho thông tin xác thực

Cấu hình proxy trong Jenkins

Cấu hình proxy toàn cầu cho Jenkins

Cấu hình proxy cho Jenkins Pipeline

Sử dụng Jenkins Credentials cho proxy

Cấu hình proxy cho các agent Jenkins

Proxy cho Docker trong CI/CD

Cấu hình proxy cho Docker daemon

Proxy cho các container trong quá trình xây dựng

Docker Compose với proxy

Cấu hình proxy cho các trình quản lý gói

NPM và Yarn

Python pip và Poetry

Maven và Gradle

Lưu trữ an toàn thông tin xác thực proxy

GitHub Actions Secrets

GitLab CI/CD Variables

Jenkins Credentials Store

Hệ thống quản lý bí mật bên ngoài

Giải quyết các vấn đề phổ biến

Vấn đề: Connection timeout khi tải xuống các phụ thuộc

Vấn đề: SSL certificate verification failed

Vấn đề: Proxy hoạt động cho một số lệnh nhưng không cho các lệnh khác

Vấn đề: Các dịch vụ nội bộ không khả dụng khi proxy được bật

Vấn đề: Thông tin xác thực proxy xuất hiện trong log

Kết luận