← ブログに戻る
RUENZHESARPTDEFRJAKOITTRIDVIFAHI

CI/CDパイプラインにおけるプロキシの統合：GitHub Actions、GitLab、Jenkinsの設定

開発者のためのCI/CDパイプラインへのプロキシ統合に関する完全ガイド：GitHub Actions、GitLab CI、Jenkinsの設定、コード例、一般的な問題の解決策。

📅2026年2月17日
```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プラットフォームの1つです。ここでのプロキシの設定は、ワークフローまたは組織全体のレベルで設定できる環境変数を通じて行われます。いくつかの統合方法を見てみましょう。

環境変数を使用した基本設定

最も簡単な方法は、ジョブの開始時にHTTP_PROXYおよびHTTPS_PROXY環境変数を設定することです。ほとんどのツール（curl、wget、npm、pip）は、これらの変数を自動的に使用します： 

name: プロキシを使用した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のセットアップ
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      
      - name: 依存関係のインストール
        run: npm install
      
      - name: テストの実行
        run: npm test

NO_PROXY変数は非常に重要です。これは、ローカルアドレスや内部サービスをプロキシから除外します。これがないと、localhostや内部Dockerコンテナへの接続に問題が発生する可能性があります。

GitHub Secretsを使用した資格情報の安全な保管

プロキシが認証を必要とする場合、ワークフローファイルにユーザー名とパスワードを平文で保存しないでください。GitHub Secretsを使用してください： 

name: 認証されたプロキシを使用したCI

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v3
      
      - name: プロキシの設定
        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: プロキシ接続のテスト
        run: curl -I https://api.github.com
      
      - name: 依存関係のインストール
        run: npm ci

リポジトリの設定でシークレットを作成します：Settings → Secrets and variables → Actions → New repository secret。PROXY_USER、PROXY_PASS、PROXY_HOST、およびPROXY_PORTを追加します。これらの値は暗号化され、ログには表示されません。

特定のステップ用のプロキシの設定

時には、依存関係のダウンロードのみにプロキシを使用し、デプロイには使用しない必要があります。特定のステップのレベルで変数を設定します： 

steps:
  - name: プロキシを介して依存関係をダウンロード
    env:
      HTTP_PROXY: http://proxy.example.com:8080
      HTTPS_PROXY: http://proxy.example.com:8080
    run: npm install
  
  - name: プロキシなしでデプロイ
    run: ./deploy.sh

GitLab CI/CDとのプロキシ統合

GitLab CI/CDは、プロキシの設定を行うためのいくつかのレベルを提供します：ランナーのレベル、プロジェクトのレベル、特定のジョブのレベル。どのプロキシがすべてのプロジェクトに必要か、特定のプロジェクトにのみ必要かによって選択が異なります。

GitLab Runnerのレベルでのプロキシの設定

自ホストのGitLab 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"

設定を変更した後、ランナーを再起動します：sudo gitlab-runner restart。これで、このランナー上のすべてのジョブは自動的にプロキシを使用します。

.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 "プロキシが設定されました: $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。保護されたマスクされた変数を作成します：

  • PROXY_URL — 資格情報を含む完全なURL（マスクされる）
  • 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自体にのみ影響し、ジョブには影響しません。ジョブには別の構成が必要です。

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('認証されたプロキシを使用したビルド') {
            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エージェント（ノード）を使用している場合は、各エージェントのためにプロキシを個別に設定します。エージェントの設定（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デーモンとコンテナの両方にプロキシを設定する必要があります。

Dockerデーモン用のプロキシの設定

Dockerデーモンがプロキシを介してイメージをダウンロードできるようにするには、systemdドロップインファイルを作成します。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のビルド引数を介して変数を渡します： 

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パイプラインでビルド引数を渡します： 

# GitHub Actions
- name: プロキシを使用してDockerイメージをビルド
  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で環境を介してプロキシを設定します： 

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: npmプロキシの設定
  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: 依存関係のインストール
  run: npm install

# Yarnの場合
- name: yarnプロキシの設定
  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: Mavenプロキシの設定
  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でビルド
  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は、リポジトリ、環境、組織の3つのレベルのシークレットを提供します。プロキシの資格情報には次のように使用します：

  • リポジトリシークレット — プロキシが1つのリポジトリでのみ必要なプロジェクト用
  • 組織シークレット — 1つのプロキシが組織内のすべてのプロジェクトで使用される場合
  • 環境シークレット — ステージング/プロダクション環境で異なるプロキシ用

重要なセキュリティルール：

  • シークレットをログに出力しないでください：GitHubは自動的にマスクしますが、echoを避ける方が良いです
  • 異なる環境に対して異なる資格情報を使用してください
  • プロキシのパスワードを定期的にローテーションしてください（最低90日ごと）
  • ブランチ保護ルールを通じてシークレットへのアクセスを制限してください

GitLab CI/CD Variables

GitLabは、変数の保護に関する追加オプションを提供します：

  • 保護された — 変数は保護されたブランチ（main、production）のみで利用可能
  • マスクされた — 値は自動的にログに隠される
  • 環境スコープ — 特定の環境での使用を制限

プロキシ資格情報の推奨設定： 

# 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: 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: プロキシの設定
  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ランナーからプロキシへの接続をブロックしている

解決策： 

# 1. プロキシの可用性を確認
- name: プロキシ接続のテスト
  run: |
    curl -v -x http://proxy.example.com:8080 https://www.google.com
    echo "プロキシテストが完了しました"

# 2. npmのタイムアウトを増やす
- name: タイムアウトを増やしてインストール
  run: |
    npm config set fetch-timeout 300000
    npm install

# 3. URL形式を確認
- name: プロキシ設定のデバッグ
  run: |
    echo "HTTP_PROXY: $HTTP_PROXY"
    echo "HTTPS_PROXY: $HTTPS_PROXY"
    # 形式は次のようになります: http://user:pass@host:port

問題: SSL証明書の検証に失敗しました

症状： "SSL証明書の問題: ローカル発行者証明書を取得できません" や "CERT_UNTRUSTED" のようなエラーが発生します。

原因： 企業のプロキシは、SSLインスペクションを実行し、証明書を置き換えることがよくあります。CI/CDランナーは企業のCAを信頼していません。

解決策： 

# オプション1: 企業CA証明書を追加
- name: 企業CA証明書のインストール
  run: |
    sudo cp corporate-ca.crt /usr/local/share/ca-certificates/
    sudo update-ca-certificates

# オプション2: SSL検証を無効にする（本番環境では推奨されません！）
- name: SSL検証を無効にしてインストール
  run: |
    npm config set strict-ssl false
    npm install
  env:
    NODE_TLS_REJECT_UNAUTHORIZED: 0

# オプション3: HTTP用のプロキシのみを使用し、HTTPSは直接
- name: 選択的プロキシ使用
  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: Gitプロキシの設定
  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: 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またはコマンドの詳細モードで出力すること。

解決策： 

# ❌ 悪い - ログに資格情報
- name: プロキシのデバッグ
  run: |
    echo "プロキシ: $HTTP_PROXY"  # http://user:pass@host:portが表示されます
    curl -v ...  # 詳細モードで資格情報が表示されます

# ✅ 良い - 安全な出力
- name: プロキシのデバッグ（安全）
  run: |
    echo "設定されたプロキシホスト: $(echo $HTTP_PROXY | cut -d'@' -f2)"
    # host:portのみ表示されます
    
# マスキングのためにシークレットを使用します
- name: プロキシの設定
  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の環境変数を正しく設定することで解決できます。

```