Integración de proxy en CI/CD: configuración para GitHub Actions y GitLab

```html

Al automatizar el despliegue y las pruebas, a menudo surge la necesidad de utilizar servidores proxy en los procesos de CI/CD. Esto puede estar relacionado con políticas de seguridad corporativas, pruebas de funciones de geolocalización o eludir limitaciones de tasa al descargar dependencias. En esta guía, analizaremos la configuración práctica de un proxy para plataformas de CI/CD populares con ejemplos de configuraciones listas para usar.

¿Por qué se necesitan proxies en los procesos de CI/CD?

El uso de servidores proxy en procesos de despliegue automatizados resuelve varias tareas críticas. En primer lugar, muchas redes corporativas requieren que todo el tráfico saliente pase a través de proxies corporativos para el control de seguridad y la auditoría. Sin la configuración adecuada, el pipeline de CI/CD simplemente no podrá descargar dependencias o conectarse a servicios externos.

En segundo lugar, al probar aplicaciones con lógica de geolocalización, es necesario verificar el funcionamiento desde diferentes países. Por ejemplo, si está desarrollando un servicio con contenido o precios regionales, las pruebas automáticas deben simular usuarios de diferentes ubicaciones. Aquí es donde ayudan los proxies residenciales con direcciones IP de las regiones necesarias.

La tercera razón es eludir limitaciones de tasa y bloqueos. Con ejecuciones frecuentes del pipeline, especialmente en equipos grandes, los servidores de CI/CD pueden caer bajo las restricciones de API de servicios externos. Por ejemplo, la API de GitHub o los registros de paquetes pueden bloquear temporalmente la IP al superar el límite de solicitudes. La rotación de proxies ayuda a distribuir la carga.

Importante: Para los procesos de CI/CD, la estabilidad de la conexión es crítica. Utilice proxies con un tiempo de actividad de al menos el 99.5% y un tiempo de respuesta rápido (menos de 200ms). Los proxies inestables llevarán a fallos aleatorios en las compilaciones y a la pérdida de tiempo del equipo en la investigación.

Configuración de proxy en GitHub Actions

GitHub Actions es una de las plataformas más populares para CI/CD. La configuración de proxy aquí se realiza a través de variables de entorno, que se pueden establecer a nivel de workflow o de toda la organización. Veamos algunas formas de integración.

Configuración básica a través de variables de entorno

La forma más sencilla es establecer las variables de entorno HTTP_PROXY y HTTPS_PROXY al inicio del job. La mayoría de las herramientas (curl, wget, npm, pip) utilizan automáticamente estas variables:

name: CI con 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 dependencias
        run: npm install
      
      - name: Ejecutar pruebas
        run: npm test

La variable NO_PROXY es crítica: excluye direcciones locales y servicios internos de la proxy. Sin ella, pueden surgir problemas de conexión a localhost o contenedores Docker internos.

Almacenamiento seguro de credenciales a través de GitHub Secrets

Si el proxy requiere autenticación, nunca almacene el nombre de usuario y la contraseña en texto claro en el archivo del workflow. Utilice GitHub Secrets:

name: CI con 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: Probar conexión del proxy
        run: curl -I https://api.github.com
      
      - name: Instalar dependencias
        run: npm ci

Cree secrets en la configuración del repositorio: Configuración → Secrets y variables → Actions → Nuevo secreto de repositorio. Agregue PROXY_USER, PROXY_PASS, PROXY_HOST y PROXY_PORT. Estos valores estarán cifrados y no serán accesibles en los registros.

Configuración de proxy para pasos específicos

A veces es necesario usar el proxy solo para ciertas operaciones, por ejemplo, solo para descargar dependencias, pero no para el despliegue. Establezca las variables a nivel de un step específico:

steps:
  - name: Descargar dependencias a través del proxy
    env:
      HTTP_PROXY: http://proxy.example.com:8080
      HTTPS_PROXY: http://proxy.example.com:8080
    run: npm install
  
  - name: Desplegar sin proxy
    run: ./deploy.sh

Integración de proxy con GitLab CI/CD

GitLab CI/CD proporciona varios niveles de configuración de proxy: a nivel de runner, a nivel de proyecto y a nivel de job específico. La elección depende de si se necesita el proxy para todos los proyectos o solo para algunos específicos.

Configuración de proxy a nivel de GitLab Runner

Si utiliza un GitLab Runner autoalojado y todos los proyectos deben funcionar a través de un proxy, configúrelo en la configuración del runner. Edite el archivo /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"

Después de cambiar la configuración, reinicie el runner: sudo gitlab-runner restart. Ahora todos los jobs en este runner utilizarán automáticamente el proxy.

Configuración a través de .gitlab-ci.yml

Para configurar el proxy a nivel de un proyecto específico, utilice variables en el archivo .gitlab-ci.yml. Este es un enfoque más flexible que permite a diferentes proyectos utilizar diferentes proxies:

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 Variables de GitLab CI/CD para credenciales

Para almacenar datos sensibles, utilice Variables de CI/CD en la configuración del proyecto: Configuración → CI/CD → Variables. Cree variables protegidas y enmascaradas:

PROXY_URL — URL completa con credenciales (enmascarada)
PROXY_HOST — host del servidor proxy
PROXY_PORT — puerto
PROXY_USER y PROXY_PASS — para almacenamiento separado

Luego, utilícelas en .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

Configuración de proxy en Jenkins

Jenkins ofrece varias formas de configurar un proxy dependiendo de la arquitectura: configuraciones globales para Jenkins master, configuraciones para agentes específicos o configuraciones a nivel de pipeline individuales.

Configuración global de proxy para Jenkins

Para configurar un proxy que será utilizado por Jenkins para actualizaciones de plugins y otras operaciones internas, vaya a Administrar Jenkins → Administrar Plugins → Avanzado. En la sección Configuración de Proxy HTTP, indique:

Servidor: proxy.example.com
Puerto: 8080
Nombre de usuario y Contraseña (si se requiere autenticación)
No Proxy Host: localhost,127.0.0.1,.internal

Esta configuración afecta solo a Jenkins en sí, pero no a los jobs. Para los jobs, se necesita una configuración separada.

Configuración de proxy para Jenkins Pipeline

En el Jenkinsfile, puede establecer variables de entorno para todo el pipeline o para etapas específicas:

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 credenciales de Jenkins para proxy

Para almacenar de forma segura las credenciales del proxy, utilice el Almacén de Credenciales de Jenkins. Cree credenciales del tipo "Nombre de usuario con contraseña" en Administrar Jenkins → Administrar Credenciales, luego utilícelas en el pipeline:

pipeline {
    agent any
    
    stages {
        stage('Build con 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
                    '''
                }
            }
        }
    }
}

Configuración de proxy para agentes de Jenkins

Si utiliza agentes de Jenkins separados (nodos), configure el proxy para cada agente por separado. En la configuración del agente (Administrar Jenkins → Administrar Nodos → Configurar) agregue en Variables de entorno:

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

Proxy para Docker en CI/CD

Docker es una parte integral de los modernos procesos de CI/CD. La configuración de proxy para Docker tiene sus propias particularidades, ya que es necesario configurar el proxy tanto para el daemon de Docker como para los contenedores.

Configuración de proxy para el daemon de Docker

Para que el daemon de Docker pueda descargar imágenes a través de un proxy, cree un archivo drop-in de systemd. En un sistema Linux, cree un directorio y un archivo:

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

Agregue el siguiente contenido:

[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 la configuración y Docker:

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

Proxy para contenedores durante la construcción

Si los contenedores necesitan acceso a través de un proxy durante la construcción (por ejemplo, para instalar paquetes), pase las variables a través de build args en el 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 . .

# Eliminamos las variables de proxy para el runtime
ENV HTTP_PROXY=
ENV HTTPS_PROXY=

CMD ["npm", "start"]

En el pipeline de CI/CD, pase los build args:

# GitHub Actions
- name: Construir imagen de Docker con 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 con proxy

Al usar Docker Compose en CI/CD, configure el proxy a través de environment en 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"

Configuración de proxy para gestores de paquetes

Los gestores de paquetes a menudo requieren configuración adicional de proxy, especialmente si utilizan sus propios archivos de configuración. Analicemos la configuración para los gestores de paquetes más populares.

NPM y Yarn

NPM puede utilizar tanto las variables de entorno HTTP_PROXY/HTTPS_PROXY como su propia configuración. Para una configuración explícita en CI/CD:

# En GitHub Actions o GitLab CI
- name: Configurar proxy de 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 dependencias
  run: npm install

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

Una alternativa es crear un archivo .npmrc en la raíz del proyecto (¡pero no comitee las credenciales!):

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

Python pip y Poetry

Pip utiliza variables de entorno, pero también se puede configurar a través de la configuración:

# A través de variables de entorno (recomendado para CI)
export HTTP_PROXY=http://proxy.example.com:8080
export HTTPS_PROXY=http://proxy.example.com:8080
pip install -r requirements.txt

# O a través de parámetros de 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 y Gradle

Para proyectos de Java, la configuración de proxy requiere la creación de archivos de configuración. Para Maven, cree settings.xml en el pipeline de CI:

- name: Configurar proxy de 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 con Maven
  run: mvn clean install

Para Gradle, agregue configuraciones en 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

Almacenamiento seguro de credenciales de proxy

Almacenar credenciales de proxy es un aspecto crítico de la seguridad en CI/CD. La filtración de estos datos puede llevar a un uso no autorizado del proxy y pérdidas financieras. Analicemos las mejores prácticas para diferentes plataformas.

GitHub Actions Secrets

GitHub Actions ofrece tres niveles de secretos: repositorio, entorno y organización. Para las credenciales del proxy, utilice:

Secretos de repositorio — para proyectos donde el proxy solo se necesita en un repositorio
Secretos de organización — si un proxy se utiliza en todos los proyectos de la organización
Secretos de entorno — para diferentes proxies en entornos de staging/producción

Reglas importantes de seguridad:

Nunca imprima secretos en los registros: GitHub los enmascara automáticamente, pero es mejor evitar echo
Utilice diferentes credenciales para diferentes entornos
Rote regularmente las contraseñas del proxy (al menos cada 90 días)
Limite el acceso a los secretos a través de reglas de protección de ramas

GitLab CI/CD Variables

GitLab ofrece opciones adicionales para proteger variables:

Protegido — la variable está disponible solo en ramas protegidas (main, production)
Enmascarado — el valor se oculta automáticamente en los registros
Alcance de entorno — restricción de uso a entornos específicos

Configuración recomendada para las credenciales del proxy:

# Configuración → CI/CD → Variables
PROXY_USER: myuser (Protegido: Sí, Enmascarado: Sí)
PROXY_PASS: secret123 (Protegido: Sí, Enmascarado: Sí)
PROXY_HOST: proxy.example.com (Protegido: No, Enmascarado: No)
PROXY_PORT: 8080 (Protegido: No, Enmascarado: No)

Jenkins Credentials Store

El Almacén de Credenciales de Jenkins admite varios tipos de almacenamiento de credenciales. Para el proxy, se recomienda:

Utilizar "Nombre de usuario con contraseña" para el nombre de usuario/contraseña del proxy
Configurar credenciales a nivel de carpeta para diferentes equipos/proyectos
Habilitar el Plugin de Vinculación de Credenciales para su uso seguro en Pipeline
Configurar el registro de auditoría para rastrear el uso de credenciales

Sistemas externos de gestión de secretos

Para entornos empresariales, se recomienda utilizar sistemas especializados de gestión de secretos: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault o Google Secret Manager. Ejemplo de integración con HashiCorp Vault en GitHub Actions:

- name: Importar secretos desde 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

Solución de problemas comunes

Al integrar un proxy en CI/CD, a menudo surgen los mismos problemas. Analicemos los más comunes y cómo resolverlos.

Problema: Timeout de conexión al descargar dependencias

Síntomas: npm install, pip install o docker pull terminan con un error de timeout después de 30-60 segundos.

Causas:

El servidor proxy no está disponible o está sobrecargado
Formato incorrecto de la URL del proxy (se olvidó de http:// al principio)
El proxy requiere autenticación, pero las credenciales no se han proporcionado
El firewall bloquea la conexión del runner de CI/CD al proxy

Solución:

# 1. Verifique la disponibilidad del proxy
- name: Probar conectividad del proxy
  run: |
    curl -v -x http://proxy.example.com:8080 https://www.google.com
    echo "Prueba de proxy completada"

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

# 3. Verifique el formato de la URL
- name: Depurar configuración del proxy
  run: |
    echo "HTTP_PROXY: $HTTP_PROXY"
    echo "HTTPS_PROXY: $HTTPS_PROXY"
    # Debe ser: http://user:pass@host:port

Problema: Fallo en la verificación del certificado SSL

Síntomas: Errores como "Problema con el certificado SSL: no se puede obtener el certificado del emisor local" o "CERT_UNTRUSTED".

Causa: Los proxies corporativos a menudo realizan inspección SSL, reemplazando los certificados. El runner de CI/CD no confía en la CA corporativa.

Solución:

# Opción 1: Agregar el certificado CA corporativo
- name: Instalar certificado CA corporativo
  run: |
    sudo cp corporate-ca.crt /usr/local/share/ca-certificates/
    sudo update-ca-certificates

# Opción 2: Desactivar la verificación SSL (NO recomendado para producción!)
- name: Instalar con verificación SSL desactivada
  run: |
    npm config set strict-ssl false
    npm install
  env:
    NODE_TLS_REJECT_UNAUTHORIZED: 0

# Opción 3: Usar proxy solo para HTTP, HTTPS directamente
- name: Uso selectivo del proxy
  run: npm install
  env:
    HTTP_PROXY: http://proxy.example.com:8080
    # No establecemos HTTPS_PROXY

Advertencia: Desactivar la verificación de certificados SSL crea un riesgo de seguridad serio. Utilice este enfoque solo para redes corporativas internas y asegúrese de agregar la CA corporativa a las confiables.

Problema: El proxy funciona para algunos comandos, pero no para otros

Síntomas: npm install funciona a través del proxy, pero git clone o docker pull ignoran la configuración del proxy.

Causa: Diferentes herramientas utilizan diferentes mecanismos para configurar el proxy. Git y Docker tienen sus propios archivos de configuración.

Solución:

# Configuración del proxy de Git
- name: Configurar proxy de Git
  run: |
    git config --global http.proxy http://proxy.example.com:8080
    git config --global https.proxy http://proxy.example.com:8080

# Configuración del proxy de Docker (ver sección Docker arriba)
# 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: Servicios internos no disponibles con el proxy habilitado

Síntomas: Después de configurar el proxy, las conexiones a localhost, contenedores Docker internos o servicios corporativos dejaron de funcionar.

Causa: La variable NO_PROXY está configurada incorrectamente, todas las solicitudes pasan a través del proxy, incluidas las locales.

Solución:

# Configuración correcta de 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, también agregue
services:
  app:
    environment:
      - NO_PROXY=localhost,127.0.0.1,db,redis
      # db y redis son nombres de otros servicios en compose

Problema: Credenciales del proxy aparecen en los registros

Síntomas: Las contraseñas del proxy son visibles en texto claro en los registros de CI/CD.

Causa: La salida de variables de entorno a través de echo o el modo verbose de los comandos.

Solución:

# ❌ MALO - credenciales en los registros
- name: Depurar proxy
  run: |
    echo "Proxy: $HTTP_PROXY"  # Mostrará http://user:pass@host:port
    curl -v ...  # El modo verbose muestra credenciales

# ✅ BUENO - salida segura
- name: Depurar proxy (seguro)
  run: |
    echo "Host del proxy configurado: $(echo $HTTP_PROXY | cut -d'@' -f2)"
    # Solo mostrará host:port
    
# Utilice secrets para enmascarar
- name: Configurar proxy
  env:
    PROXY_URL: ${{ secrets.PROXY_URL }}  # GitHub lo enmascara automáticamente
  run: |
    export HTTP_PROXY="$PROXY_URL"

Conclusión

La integración de proxies en el pipeline de CI/CD es un aspecto importante de la automatización que asegura la seguridad, el cumplimiento de políticas corporativas y la posibilidad de probar funciones de geolocalización. En esta guía, hemos revisado formas prácticas de configurar proxies para GitHub Actions, GitLab CI, Jenkins, Docker y gestores de paquetes populares.

Puntos clave a recordar al configurar proxies en CI/CD: siempre utilice almacenamiento seguro de credenciales a través de los mecanismos integrados de secretos de las plataformas, configure correctamente NO_PROXY para excluir servicios locales e internos, pruebe la conexión al proxy antes de las operaciones principales y monitoree los registros en busca de filtraciones de datos sensibles. Para entornos de producción críticos, se recomienda utilizar sistemas externos de gestión de secretos como HashiCorp Vault.

La elección del tipo de proxy depende de sus necesidades: para redes corporativas, generalmente se utilizan proxies HTTP/HTTPS existentes, para probar funciones de geolocalización son adecuados proxies residenciales con IP de los países necesarios, y para descargas de dependencias de alta velocidad se pueden utilizar proxies de centros de datos. Es importante garantizar un alto tiempo de actividad de los servidores proxy, ya que su indisponibilidad llevará a la caída de todas las compilaciones y bloqueará el trabajo del equipo de desarrollo.

Al enfrentar problemas, comience verificando la disponibilidad básica del proxy a través de curl o wget, luego verifique la corrección del formato de la URL y las credenciales, y solo después pase a configuraciones específicas de herramientas. La mayoría de los problemas se resuelven con la configuración adecuada de las variables de entorno HTTP_PROXY, HTTPS_PROXY y NO_PROXY.

```

Integración de proxy en el pipeline CI/CD: configuración para GitHub Actions, GitLab y Jenkins

¿Por qué se necesitan proxies en los procesos de CI/CD?

Configuración de proxy en GitHub Actions

Configuración básica a través de variables de entorno

Almacenamiento seguro de credenciales a través de GitHub Secrets

Configuración de proxy para pasos específicos

Integración de proxy con GitLab CI/CD

Configuración de proxy a nivel de GitLab Runner

Configuración a través de .gitlab-ci.yml

Uso de Variables de GitLab CI/CD para credenciales

Configuración de proxy en Jenkins

Configuración global de proxy para Jenkins

Configuración de proxy para Jenkins Pipeline

Uso de credenciales de Jenkins para proxy

Configuración de proxy para agentes de Jenkins

Proxy para Docker en CI/CD

Configuración de proxy para el daemon de Docker

Proxy para contenedores durante la construcción

Docker Compose con proxy

Configuración de proxy para gestores de paquetes

NPM y Yarn

Python pip y Poetry

Maven y Gradle

Almacenamiento seguro de credenciales de proxy

GitHub Actions Secrets

GitLab CI/CD Variables

Jenkins Credentials Store

Sistemas externos de gestión de secretos

Solución de problemas comunes

Problema: Timeout de conexión al descargar dependencias

Problema: Fallo en la verificación del certificado SSL

Problema: El proxy funciona para algunos comandos, pero no para otros

Problema: Servicios internos no disponibles con el proxy habilitado

Problema: Credenciales del proxy aparecen en los registros

Conclusión