Integração de proxy em CI/CD: configuração para GitHub Actions e GitLab

```html

Ao automatizar a implantação e os testes, muitas vezes surge a necessidade de usar servidores proxy em processos de CI/CD. Isso pode estar relacionado a políticas de segurança corporativa, teste de funcionalidades de geolocalização ou contorno de rate-limiting ao baixar dependências. Neste guia, vamos explorar a configuração prática de proxy para plataformas populares de CI/CD com exemplos prontos de configurações.

Por que usar proxies em processos de CI/CD

O uso de servidores proxy em processos de implantação automatizados resolve várias tarefas críticas. Em primeiro lugar, muitas redes corporativas exigem que todo o tráfego de saída passe por proxies corporativos para controle de segurança e registro. Sem a configuração adequada, o pipeline de CI/CD simplesmente não conseguirá baixar dependências ou se conectar a serviços externos.

Em segundo lugar, ao testar aplicativos com lógica de geolocalização, é necessário verificar o funcionamento a partir de diferentes países. Por exemplo, se você está desenvolvendo um serviço com conteúdo ou precificação regional, os testes automatizados devem simular usuários de diferentes locais. Aqui, os proxies residenciais com endereços IP das regiões necessárias são úteis.

A terceira razão é contornar rate-limiting e bloqueios. Com execuções frequentes do pipeline, especialmente em grandes equipes, os servidores de CI/CD podem ser submetidos a limitações de API de serviços externos. Por exemplo, a API do GitHub ou repositórios de pacotes podem temporariamente bloquear o IP ao exceder o limite de solicitações. A rotação de proxies ajuda a distribuir a carga.

Importante: Para processos de CI/CD, a estabilidade da conexão é crítica. Use proxies com uptime de pelo menos 99,5% e resposta rápida (menos de 200ms). Proxies instáveis levarão a falhas aleatórias nas compilações e perda de tempo da equipe na investigação.

Configuração de proxy no GitHub Actions

O GitHub Actions é uma das plataformas mais populares para CI/CD. A configuração de proxy aqui é feita através de variáveis de ambiente, que podem ser definidas no nível do workflow ou em toda a organização. Vamos considerar algumas maneiras de integração.

Configuração básica através de variáveis de ambiente

A maneira mais simples é definir as variáveis de ambiente HTTP_PROXY e HTTPS_PROXY no início do job. A maioria das ferramentas (curl, wget, npm, pip) usa automaticamente essas variáveis:

name: CI com 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: Configurar Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      
      - name: Instalar dependências
        run: npm install
      
      - name: Executar testes
        run: npm test

A variável NO_PROXY é crítica — ela exclui endereços locais e serviços internos da proxy. Sem ela, podem ocorrer problemas de conexão com localhost ou contêineres Docker internos.

Armazenamento seguro de credenciais através do GitHub Secrets

Se o proxy requer autenticação, nunca armazene o login e a senha em texto claro no arquivo do workflow. Use o GitHub Secrets:

name: CI com Proxy Autenticado

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v3
      
      - name: Configurar 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: Testar conexão do proxy
        run: curl -I https://api.github.com
      
      - name: Instalar dependências
        run: npm ci

Crie secrets nas configurações do repositório: Configurações → Secrets e variáveis → Ações → Novo segredo do repositório. Adicione PROXY_USER, PROXY_PASS, PROXY_HOST e PROXY_PORT. Esses valores serão criptografados e não estarão disponíveis nos logs.

Configuração de proxy para etapas específicas

Às vezes, é necessário usar o proxy apenas para operações específicas, por exemplo, apenas para baixar dependências, mas não para a implantação. Defina as variáveis no nível de uma etapa específica:

steps:
  - name: Baixar dependências via proxy
    env:
      HTTP_PROXY: http://proxy.example.com:8080
      HTTPS_PROXY: http://proxy.example.com:8080
    run: npm install
  
  - name: Implantar sem proxy
    run: ./deploy.sh

Integração de proxy com GitLab CI/CD

O GitLab CI/CD oferece vários níveis de configuração de proxy: no nível do runner, no nível do projeto e no nível de um job específico. A escolha depende se o proxy é necessário para todos os projetos ou apenas para específicos.

Configuração de proxy no nível do GitLab Runner

Se você estiver usando um GitLab Runner auto-hospedado e todos os projetos devem funcionar através do proxy, configure-o na configuração do runner. Edite o arquivo /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"

Após alterar a configuração, reinicie o runner: sudo gitlab-runner restart. Agora todos os jobs nesse runner usarão automaticamente o proxy.

Configuração através do .gitlab-ci.yml

Para configurar o proxy no nível de um projeto específico, use variáveis no arquivo .gitlab-ci.yml. Esta é uma abordagem mais flexível, permitindo que diferentes projetos usem proxies diferentes:

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

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

Uso de Variáveis do GitLab CI/CD para credenciais

Para armazenar dados sensíveis, use Variáveis do CI/CD nas configurações do projeto: Configurações → CI/CD → Variáveis. Crie variáveis protegidas e mascaradas:

PROXY_URL — URL completa com credenciais (mascarada)
PROXY_HOST — host do servidor proxy
PROXY_PORT — porta
PROXY_USER e PROXY_PASS — para armazenamento separado

Em seguida, use-os no .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

Configuração de proxy no Jenkins

O Jenkins oferece várias maneiras de configurar proxies, dependendo da arquitetura: configurações globais para o Jenkins master, configurações para agentes específicos ou configurações no nível de pipelines individuais.

Configuração global de proxy para Jenkins

Para configurar o proxy que será usado pelo Jenkins para atualizações de plugins e outras operações internas, vá para Gerenciar Jenkins → Gerenciar Plugins → Avançado. Na seção Configuração do Proxy HTTP, especifique:

Servidor: proxy.example.com
Porta: 8080
Nome de usuário e Senha (se a autenticação for necessária)
Host sem Proxy: localhost,127.0.0.1,.internal

Esta configuração afeta apenas o próprio Jenkins, mas não os jobs. Para jobs, uma configuração separada é necessária.

Configuração de proxy para Jenkins Pipeline

No Jenkinsfile, você pode definir variáveis de ambiente para todo o pipeline ou para estágios específicos:

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

Uso de Credenciais do Jenkins para proxy

Para armazenar credenciais de proxy de forma segura, use o Armazenamento de Credenciais do Jenkins. Crie credenciais do tipo "Nome de usuário com senha" em Gerenciar Jenkins → Gerenciar Credenciais, e depois use-as no pipeline:

pipeline {
    agent any
    
    stages {
        stage('Build com Proxy Autenticado') {
            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
                    '''
                }
            }
        }
    }
}

Configuração de proxy para agentes do Jenkins

Se você estiver usando agentes do Jenkins separados (nodes), configure o proxy para cada agente individualmente. Na configuração do agente (Gerenciar Jenkins → Gerenciar Nós → Configurar), adicione nas variáveis de ambiente:

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

Proxy para Docker em CI/CD

O Docker é uma parte essencial dos modernos processos de CI/CD. A configuração de proxy para o Docker tem suas particularidades, pois é necessário configurar o proxy tanto para o daemon do Docker quanto para os contêineres.

Configuração de proxy para o daemon do Docker

Para que o daemon do Docker possa baixar imagens através do proxy, crie um arquivo drop-in do systemd. Em um sistema Linux, crie um diretório e um arquivo:

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

Adicione o seguinte conteúdo:

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

Reinicie a configuração e o Docker:

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

Proxy para contêineres durante a construção

Se os contêineres precisarem de acesso através do proxy durante a construção (por exemplo, para instalar pacotes), passe as variáveis através de build args no 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 . .

# Remove as variáveis de proxy para runtime
ENV HTTP_PROXY=
ENV HTTPS_PROXY=

CMD ["npm", "start"]

No pipeline de CI/CD, passe os build args:

# GitHub Actions
- name: Construir imagem Docker com 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 com proxy

Ao usar o Docker Compose em CI/CD, configure o proxy através de environment no 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"

Configuração de proxy para gerenciadores de pacotes

Os gerenciadores de pacotes frequentemente requerem configuração adicional de proxy, especialmente se utilizarem seus próprios arquivos de configuração. Vamos considerar a configuração para gerenciadores de pacotes populares.

NPM e Yarn

O NPM pode usar tanto as variáveis de ambiente HTTP_PROXY/HTTPS_PROXY quanto sua própria configuração. Para configuração explícita em CI/CD:

# No GitHub Actions ou GitLab CI
- name: Configurar proxy do 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: Instalar dependências
  run: npm install

# Para Yarn
- name: Configurar proxy do yarn
  run: |
    yarn config set proxy http://proxy.example.com:8080
    yarn config set https-proxy http://proxy.example.com:8080

Uma alternativa é criar um arquivo .npmrc na raiz do projeto (mas não comite as credenciais!):

# .npmrc (gerado em CI)
proxy=http://proxy.example.com:8080
https-proxy=http://proxy.example.com:8080
noproxy=localhost,127.0.0.1

Python pip e Poetry

O Pip usa variáveis de ambiente, mas também pode ser configurado através de configuração:

# Através de variáveis de ambiente (recomendado para CI)
export HTTP_PROXY=http://proxy.example.com:8080
export HTTPS_PROXY=http://proxy.example.com:8080
pip install -r requirements.txt

# Ou através de parâmetros do pip
pip install --proxy http://proxy.example.com:8080 -r requirements.txt

# Para Poetry
poetry config http-basic.proxy http://proxy.example.com:8080
poetry install

Maven e Gradle

Para projetos Java, a configuração de proxy requer a criação de arquivos de configuração. Para o Maven, crie settings.xml no pipeline de CI:

- name: Configurar proxy do 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: Construir com Maven
  run: mvn clean install

Para o Gradle, adicione as configurações em 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

Armazenamento seguro de credenciais de proxy

O armazenamento de credenciais de proxy é um aspecto crítico da segurança em CI/CD. O vazamento desses dados pode levar ao uso não autorizado do proxy e a perdas financeiras. Vamos considerar as melhores práticas para diferentes plataformas.

GitHub Actions Secrets

O GitHub Actions oferece três níveis de segredos: repositório, ambiente e organização. Para credenciais de proxy, use:

Segredos do repositório — para projetos onde o proxy é necessário apenas em um repositório
Segredos da organização — se um proxy é usado em todos os projetos da organização
Segredos do ambiente — para diferentes proxies em ambientes de staging/produção

Regras importantes de segurança:

Nunca exiba segredos nos logs: o GitHub os mascara automaticamente, mas é melhor evitar o echo
Use credenciais diferentes para diferentes ambientes
Rotacione regularmente as senhas do proxy (pelo menos a cada 90 dias)
Limite o acesso aos segredos através de regras de proteção de branch

GitLab CI/CD Variables

O GitLab oferece opções adicionais de proteção para variáveis:

Protegido — a variável está disponível apenas em branches protegidas (main, production)
Mascarado — o valor é automaticamente ocultado nos logs
Escopo de ambiente — restrição de uso para ambientes específicos

Configuração recomendada para credenciais de proxy:

# Configurações → CI/CD → Variáveis
PROXY_USER: myuser (Protegido: Sim, Mascarado: Sim)
PROXY_PASS: secret123 (Protegido: Sim, Mascarado: Sim)
PROXY_HOST: proxy.example.com (Protegido: Não, Mascarado: Não)
PROXY_PORT: 8080 (Protegido: Não, Mascarado: Não)

Armazenamento de Credenciais do Jenkins

O Armazenamento de Credenciais do Jenkins suporta vários tipos de armazenamento de credenciais. Para proxy, recomenda-se:

Usar "Nome de usuário com senha" para login/senha do proxy
Configurar credenciais de nível de pasta para diferentes equipes/projetos
Ativar o Plugin de Vinculação de Credenciais para uso seguro no Pipeline
Configurar registro de auditoria para monitorar o uso de credenciais

Sistemas externos de gerenciamento de segredos

Para ambientes corporativos, recomenda-se usar sistemas especializados de gerenciamento de segredos: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault ou Google Secret Manager. Exemplo de integração com HashiCorp Vault no GitHub Actions:

- name: Importar Segredos do 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: Configurar Proxy
  run: |
    export HTTP_PROXY="http://${PROXY_USER}:${PROXY_PASS}@${PROXY_HOST}:8080"
    npm install

Solução de problemas comuns

Ao integrar proxies em CI/CD, frequentemente surgem os mesmos problemas. Vamos considerar os mais comuns e suas soluções.

Problema: Timeout de conexão ao baixar dependências

Sintomas: npm install, pip install ou docker pull falham com erro de timeout após 30-60 segundos.

Causas:

O servidor proxy está indisponível ou sobrecarregado
Formato incorreto da URL do proxy (esqueceu http:// no início)
O proxy requer autenticação, mas as credenciais não foram fornecidas
O firewall bloqueia a conexão do runner de CI/CD ao proxy

Solução:

# 1. Verifique a disponibilidade do proxy
- name: Testar conectividade do proxy
  run: |
    curl -v -x http://proxy.example.com:8080 https://www.google.com
    echo "Teste do proxy concluído"

# 2. Aumente o timeout para npm
- name: Instalar com timeout aumentado
  run: |
    npm config set fetch-timeout 300000
    npm install

# 3. Verifique o formato da URL
- name: Depurar configuração do proxy
  run: |
    echo "HTTP_PROXY: $HTTP_PROXY"
    echo "HTTPS_PROXY: $HTTPS_PROXY"
    # Deve ser: http://user:pass@host:port

Problema: Falha na verificação do certificado SSL

Sintomas: Erros como "Problema com o certificado SSL: não foi possível obter o certificado emissor local" ou "CERT_UNTRUSTED".

Causa: Proxies corporativos frequentemente realizam inspeção SSL, substituindo certificados. O runner de CI/CD não confia no CA corporativo.

Solução:

# Opção 1: Adicionar o certificado CA corporativo
- name: Instalar certificado CA corporativo
  run: |
    sudo cp corporate-ca.crt /usr/local/share/ca-certificates/
    sudo update-ca-certificates

# Opção 2: Desativar a verificação SSL (NÃO recomendado para produção!)
- name: Instalar com verificação SSL desativada
  run: |
    npm config set strict-ssl false
    npm install
  env:
    NODE_TLS_REJECT_UNAUTHORIZED: 0

# Opção 3: Usar proxy apenas para HTTP, HTTPS diretamente
- name: Uso seletivo de proxy
  run: npm install
  env:
    HTTP_PROXY: http://proxy.example.com:8080
    # HTTPS_PROXY não é definido

Aviso: Desativar a verificação de certificados SSL cria um sério risco de segurança. Use essa abordagem apenas para redes corporativas internas e adicione o CA corporativo aos confiáveis.

Problema: Proxy funciona para alguns comandos, mas não para outros

Sintomas: npm install funciona através do proxy, mas git clone ou docker pull ignoram as configurações do proxy.

Causa: Diferentes ferramentas usam diferentes mecanismos para configurar proxies. Git e Docker têm seus próprios arquivos de configuração.

Solução:

# Configuração do proxy do Git
- name: Configurar proxy do Git
  run: |
    git config --global http.proxy http://proxy.example.com:8080
    git config --global https.proxy http://proxy.example.com:8080

# Configuração do proxy do Docker (veja a seção Docker acima)
# Para wget/curl
- name: Configurar 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

Problema: Serviços internos indisponíveis com proxy ativado

Sintomas: Após configurar o proxy, as conexões com localhost, contêineres Docker internos ou serviços corporativos pararam de funcionar.

Causa: A variável NO_PROXY está configurada incorretamente, todas as solicitações estão passando pelo proxy, incluindo as locais.

Solução:

# Configuração correta do 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

# Para Docker Compose, adicione também
services:
  app:
    environment:
      - NO_PROXY=localhost,127.0.0.1,db,redis
      # db e redis são nomes de outros serviços no compose

Problema: Credenciais do proxy aparecem nos logs

Sintomas: As senhas do proxy aparecem em texto claro nos logs de CI/CD.

Causa: Exibição de variáveis de ambiente através de echo ou modo verbose dos comandos.

Solução:

# ❌ RUIM - credenciais nos logs
- name: Depurar proxy
  run: |
    echo "Proxy: $HTTP_PROXY"  # Mostrará http://user:pass@host:port
    curl -v ...  # Modo verbose mostra credenciais

# ✅ BOM - saída segura
- name: Depurar proxy (seguro)
  run: |
    echo "Host do proxy configurado: $(echo $HTTP_PROXY | cut -d'@' -f2)"
    # Mostrará apenas host:port
    
# Use secrets para mascarar
- name: Configurar proxy
  env:
    PROXY_URL: ${{ secrets.PROXY_URL }}  # O GitHub mascara automaticamente
  run: |
    export HTTP_PROXY="$PROXY_URL"

Conclusão

A integração de proxies em pipelines de CI/CD é um aspecto importante da automação, que garante segurança, conformidade com políticas corporativas e a capacidade de testar funcionalidades de geolocalização. Neste guia, exploramos maneiras práticas de configurar proxies para GitHub Actions, GitLab CI, Jenkins, Docker e gerenciadores de pacotes populares.

Pontos-chave a serem lembrados ao configurar proxies em CI/CD: sempre use armazenamento seguro de credenciais através dos mecanismos integrados de segredos das plataformas, configure corretamente o NO_PROXY para excluir serviços locais e internos, teste a conexão ao proxy antes das operações principais e monitore os logs para vazamentos de dados sensíveis. Para ambientes de produção críticos, recomenda-se usar sistemas externos de gerenciamento de segredos, como HashiCorp Vault.

A escolha do tipo de proxy depende de suas necessidades: para redes corporativas, geralmente são usados proxies HTTP/HTTPS existentes, para testar funcionalidades de geolocalização, são adequados proxies residenciais com IPs de países necessários, e para downloads de dependências em alta velocidade, podem ser usados proxies de data center. É importante garantir um alto uptime dos servidores proxy, pois sua indisponibilidade levará à falha de todas as compilações e bloqueará o trabalho da equipe de desenvolvimento.

Ao enfrentar problemas, comece verificando a disponibilidade básica do proxy através do curl ou wget, em seguida, verifique a formatação da URL e as credenciais, e só depois passe para configurações específicas de ferramentas. A maioria dos problemas é resolvida com a configuração correta das variáveis de ambiente HTTP_PROXY, HTTPS_PROXY e NO_PROXY.

```

Integração de proxy no pipeline CI/CD: configuração para GitHub Actions, GitLab e Jenkins

Por que usar proxies em processos de CI/CD

Configuração de proxy no GitHub Actions

Configuração básica através de variáveis de ambiente

Armazenamento seguro de credenciais através do GitHub Secrets

Configuração de proxy para etapas específicas

Integração de proxy com GitLab CI/CD

Configuração de proxy no nível do GitLab Runner

Configuração através do .gitlab-ci.yml

Uso de Variáveis do GitLab CI/CD para credenciais

Configuração de proxy no Jenkins

Configuração global de proxy para Jenkins

Configuração de proxy para Jenkins Pipeline

Uso de Credenciais do Jenkins para proxy

Configuração de proxy para agentes do Jenkins

Proxy para Docker em CI/CD

Configuração de proxy para o daemon do Docker

Proxy para contêineres durante a construção

Docker Compose com proxy

Configuração de proxy para gerenciadores de pacotes

NPM e Yarn

Python pip e Poetry

Maven e Gradle

Armazenamento seguro de credenciais de proxy

GitHub Actions Secrets

GitLab CI/CD Variables

Armazenamento de Credenciais do Jenkins

Sistemas externos de gerenciamento de segredos

Solução de problemas comuns

Problema: Timeout de conexão ao baixar dependências

Problema: Falha na verificação do certificado SSL

Problema: Proxy funciona para alguns comandos, mas não para outros

Problema: Serviços internos indisponíveis com proxy ativado

Problema: Credenciais do proxy aparecem nos logs

Conclusão