Intégration des proxies dans CI/CD : configuration pour GitHub Actions et GitLab.

Lors de l'automatisation du déploiement et des tests, il est souvent nécessaire d'utiliser des serveurs proxy dans les processus CI/CD. Cela peut être lié aux politiques de sécurité de l'entreprise, aux tests de fonctionnalités de géolocalisation ou au contournement des limitations de taux lors du téléchargement de dépendances. Dans ce guide, nous examinerons la configuration pratique des proxies pour les plateformes CI/CD populaires avec des exemples de configurations prêtes à l'emploi.

Pourquoi utiliser des proxies dans les processus CI/CD

L'utilisation de serveurs proxy dans les processus de déploiement automatisés résout plusieurs problèmes critiques. Tout d'abord, de nombreux réseaux d'entreprise exigent que tout le trafic sortant passe par des proxies d'entreprise pour le contrôle de la sécurité et la journalisation. Sans une configuration appropriée, le pipeline CI/CD ne pourra tout simplement pas télécharger les dépendances ou se connecter à des services externes.

Deuxièmement, lors des tests d'applications avec une logique de géolocalisation, il est nécessaire de vérifier le fonctionnement depuis différents pays. Par exemple, si vous développez un service avec un contenu ou une tarification régionale, les tests automatisés doivent simuler des utilisateurs provenant de différentes localisations. Les proxies résidentiels avec des adresses IP des régions nécessaires aident ici.

La troisième raison est le contournement des limitations de taux et des blocages. Lors de lancements fréquents de pipeline, en particulier dans de grandes équipes, les serveurs CI/CD peuvent être soumis à des restrictions d'API de services externes. Par exemple, l'API GitHub ou les registres de paquets peuvent temporairement bloquer l'IP en cas de dépassement de la limite de requêtes. La rotation des proxies aide à répartir la charge.

Important : Pour les processus CI/CD, la stabilité de la connexion est critique. Utilisez des proxies avec un temps de disponibilité d'au moins 99,5 % et un temps de réponse rapide (moins de 200 ms). Des proxies instables entraîneront des échecs aléatoires des builds et une perte de temps pour l'équipe à enquêter.

Configuration du proxy dans GitHub Actions

GitHub Actions est l'une des plateformes les plus populaires pour CI/CD. La configuration du proxy ici se fait via des variables d'environnement, qui peuvent être définies au niveau du workflow ou de l'ensemble de l'organisation. Examinons plusieurs méthodes d'intégration.

Configuration de base via des variables d'environnement

La méthode la plus simple consiste à définir les variables d'environnement HTTP_PROXY et HTTPS_PROXY au début de la tâche. La plupart des outils (curl, wget, npm, pip) utilisent automatiquement ces variables :

name: CI avec 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: Configurer Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      
      - name: Installer les dépendances
        run: npm install
      
      - name: Exécuter les tests
        run: npm test

La variable NO_PROXY est critique — elle exclut les adresses locales et les services internes du proxy. Sans elle, des problèmes de connexion à localhost ou aux conteneurs Docker internes peuvent survenir.

Stockage sécurisé des credentials via GitHub Secrets

Si le proxy nécessite une authentification, ne stockez jamais le nom d'utilisateur et le mot de passe en clair dans le fichier de workflow. Utilisez GitHub Secrets :

name: CI avec Proxy Authentifié

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v3
      
      - name: Configurer le 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: Tester la connexion au proxy
        run: curl -I https://api.github.com
      
      - name: Installer les dépendances
        run: npm ci

Créez des secrets dans les paramètres du dépôt : Paramètres → Secrets et variables → Actions → Nouveau secret de dépôt. Ajoutez PROXY_USER, PROXY_PASS, PROXY_HOST et PROXY_PORT. Ces valeurs seront chiffrées et non accessibles dans les journaux.

Configuration du proxy pour des étapes spécifiques

Parfois, il est nécessaire d'utiliser le proxy uniquement pour certaines opérations, par exemple, uniquement pour le téléchargement des dépendances, mais pas pour le déploiement. Définissez les variables au niveau d'une étape spécifique :

steps:
  - name: Télécharger les dépendances via le proxy
    env:
      HTTP_PROXY: http://proxy.example.com:8080
      HTTPS_PROXY: http://proxy.example.com:8080
    run: npm install
  
  - name: Déployer sans proxy
    run: ./deploy.sh

Intégration du proxy avec GitLab CI/CD

GitLab CI/CD propose plusieurs niveaux de configuration du proxy : au niveau du runner, au niveau du projet et au niveau d'une tâche spécifique. Le choix dépend de savoir si le proxy est nécessaire pour tous les projets ou seulement pour certains.

Configuration du proxy au niveau de GitLab Runner

Si vous utilisez un GitLab Runner auto-hébergé et que tous les projets doivent fonctionner via un proxy, configurez-le dans la configuration du runner. Modifiez le fichier /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"

Après avoir modifié la configuration, redémarrez le runner : sudo gitlab-runner restart. Maintenant, toutes les tâches sur ce runner utiliseront automatiquement le proxy.

Configuration via .gitlab-ci.yml

Pour configurer le proxy au niveau d'un projet spécifique, utilisez des variables dans le fichier .gitlab-ci.yml. C'est une approche plus flexible qui permet à différents projets d'utiliser différents 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 configuré : $HTTP_PROXY"
    - npm install
    - npm run build
  artifacts:
    paths:
      - dist/

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

Utilisation des Variables CI/CD de GitLab pour les credentials

Pour stocker des données sensibles, utilisez les Variables CI/CD dans les paramètres du projet : Paramètres → CI/CD → Variables. Créez des variables protégées et masquées :

PROXY_URL — URL complète avec les credentials (masquée)
PROXY_HOST — hôte du serveur proxy
PROXY_PORT — port
PROXY_USER et PROXY_PASS — pour un stockage séparé

Ensuite, utilisez-les dans .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

Configuration du proxy dans Jenkins

Jenkins propose plusieurs façons de configurer le proxy en fonction de l'architecture : paramètres globaux pour Jenkins master, paramètres pour des agents spécifiques ou paramètres au niveau de pipelines individuels.

Configuration globale du proxy pour Jenkins

Pour configurer le proxy qui sera utilisé par Jenkins pour les mises à jour de plugins et d'autres opérations internes, allez dans Gérer Jenkins → Gérer les plugins → Avancé. Dans la section Configuration du proxy HTTP, indiquez :

Serveur : proxy.example.com
Port : 8080
Nom d'utilisateur et mot de passe (si une authentification est requise)
Hôte sans proxy : localhost,127.0.0.1,.internal

Ce paramètre n'affecte que Jenkins lui-même, mais pas les tâches. Pour les tâches, une configuration distincte est nécessaire.

Configuration du proxy pour Jenkins Pipeline

Dans le Jenkinsfile, vous pouvez définir des variables d'environnement pour l'ensemble du pipeline ou pour des étapes spécifiques :

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

Utilisation des Credentials Jenkins pour le proxy

Pour le stockage sécurisé des credentials du proxy, utilisez le Jenkins Credentials Store. Créez des credentials de type "Nom d'utilisateur avec mot de passe" dans Gérer Jenkins → Gérer les credentials, puis utilisez-les dans le pipeline :

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

Configuration du proxy pour les agents Jenkins

Si vous utilisez des agents Jenkins distincts (nodes), configurez le proxy pour chaque agent séparément. Dans la configuration de l'agent (Gérer Jenkins → Gérer les nœuds → Configurer), ajoutez dans les variables d'environnement :

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

Proxy pour Docker dans CI/CD

Docker est une partie intégrante des processus CI/CD modernes. La configuration du proxy pour Docker a ses particularités, car il faut configurer le proxy à la fois pour le démon Docker et pour les conteneurs.

Configuration du proxy pour le démon Docker

Pour que le démon Docker puisse télécharger des images via un proxy, créez un fichier de configuration systemd drop-in. Sur un système Linux, créez un répertoire et un fichier :

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

Ajoutez le contenu suivant :

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

Rechargez la configuration et Docker :

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

Proxy pour les conteneurs lors de la construction

Si les conteneurs ont besoin d'un accès via un proxy lors de la construction (par exemple, pour installer des paquets), passez les variables via les arguments de construction dans le 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 . .

# Supprime les variables de proxy pour l'exécution
ENV HTTP_PROXY=
ENV HTTPS_PROXY=

CMD ["npm", "start"]

Dans le pipeline CI/CD, passez les arguments de construction :

# GitHub Actions
- name: Construire l'image Docker avec le 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 avec proxy

Lors de l'utilisation de Docker Compose dans CI/CD, configurez le proxy via l'environnement dans 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"

Configuration du proxy pour les gestionnaires de paquets

Les gestionnaires de paquets nécessitent souvent une configuration supplémentaire du proxy, surtout s'ils utilisent leurs propres fichiers de configuration. Examinons la configuration pour les gestionnaires de paquets populaires.

NPM et Yarn

NPM peut utiliser à la fois les variables d'environnement HTTP_PROXY/HTTPS_PROXY et sa propre configuration. Pour une configuration explicite dans CI/CD :

# Dans GitHub Actions ou GitLab CI
- name: Configurer le proxy 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: Installer les dépendances
  run: npm install

# Pour Yarn
- name: Configurer le proxy yarn
  run: |
    yarn config set proxy http://proxy.example.com:8080
    yarn config set https-proxy http://proxy.example.com:8080

Une autre méthode consiste à créer un fichier .npmrc à la racine du projet (mais ne commitez pas les credentials !) :

# .npmrc (généré dans CI)
proxy=http://proxy.example.com:8080
https-proxy=http://proxy.example.com:8080
noproxy=localhost,127.0.0.1

Python pip et Poetry

Pip utilise des variables d'environnement, mais peut également être configuré via la configuration :

# Via les variables d'environnement (recommandé pour CI)
export HTTP_PROXY=http://proxy.example.com:8080
export HTTPS_PROXY=http://proxy.example.com:8080
pip install -r requirements.txt

# Ou via les paramètres pip
pip install --proxy http://proxy.example.com:8080 -r requirements.txt

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

Maven et Gradle

Pour les projets Java, la configuration du proxy nécessite la création de fichiers de configuration. Pour Maven, créez settings.xml dans le pipeline CI :

- name: Configurer le proxy 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: Construire avec Maven
  run: mvn clean install

Pour Gradle, ajoutez les paramètres dans 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

Stockage sécurisé des credentials du proxy

Le stockage des credentials du proxy est un aspect critique de la sécurité CI/CD. Une fuite de ces données peut entraîner une utilisation non autorisée du proxy et des pertes financières. Examinons les meilleures pratiques pour différentes plateformes.

Secrets GitHub Actions

GitHub Actions propose trois niveaux de secrets : dépôt, environnement et organisation. Pour les credentials du proxy, utilisez :

Secrets de dépôt — pour des projets où le proxy est nécessaire uniquement dans un dépôt
Secrets d'organisation — si un proxy est utilisé dans tous les projets de l'organisation
Secrets d'environnement — pour différents proxies dans des environnements de staging/production

Règles de sécurité importantes :

Ne jamais afficher les secrets dans les journaux : GitHub les masque automatiquement, mais il est préférable d'éviter echo
Utilisez des credentials différents pour différents environnements
Changez régulièrement les mots de passe du proxy (au moins tous les 90 jours)
Limitez l'accès aux secrets via des règles de protection des branches

Variables GitLab CI/CD

GitLab propose des options de protection supplémentaires pour les variables :

Protégé — la variable est disponible uniquement dans les branches protégées (main, production)
Masqué — la valeur est automatiquement cachée dans les journaux
Portée d'environnement — restriction d'utilisation à des environnements spécifiques

Configuration recommandée pour les credentials du proxy :

# Paramètres → CI/CD → Variables
PROXY_USER: myuser (Protégé : Oui, Masqué : Oui)
PROXY_PASS: secret123 (Protégé : Oui, Masqué : Oui)
PROXY_HOST: proxy.example.com (Protégé : Non, Masqué : Non)
PROXY_PORT: 8080 (Protégé : Non, Masqué : Non)

Jenkins Credentials Store

Le Jenkins Credentials Store prend en charge plusieurs types de stockage des credentials. Pour le proxy, il est recommandé de :

Utiliser "Nom d'utilisateur avec mot de passe" pour le login/mot de passe du proxy
Configurer des credentials au niveau des dossiers pour différentes équipes/projets
Activer le Credentials Binding Plugin pour une utilisation sécurisée dans le Pipeline
Configurer la journalisation des audits pour suivre l'utilisation des credentials

Systèmes externes de gestion des secrets

Pour les environnements d'entreprise, il est recommandé d'utiliser des systèmes spécialisés de gestion des secrets : HashiCorp Vault, AWS Secrets Manager, Azure Key Vault ou Google Secret Manager. Exemple d'intégration avec HashiCorp Vault dans GitHub Actions :

- name: Importer les Secrets depuis 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: Configurer le Proxy
  run: |
    export HTTP_PROXY="http://${PROXY_USER}:${PROXY_PASS}@${PROXY_HOST}:8080"
    npm install

Résolution des problèmes courants

Lors de l'intégration du proxy dans CI/CD, les mêmes problèmes surviennent souvent. Examinons les plus courants et comment les résoudre.

Problème : Délai d'attente de connexion lors du téléchargement des dépendances

Symptômes : npm install, pip install ou docker pull échouent avec une erreur de délai d'attente après 30-60 secondes.

Causes :

Le serveur proxy est inaccessible ou surchargé
Format d'URL du proxy incorrect (oubli de http:// au début)
Le proxy nécessite une authentification, mais les credentials ne sont pas fournis
Le pare-feu bloque la connexion du runner CI/CD au proxy

Solution :

# 1. Vérifiez l'accessibilité du proxy
- name: Tester la connectivité du proxy
  run: |
    curl -v -x http://proxy.example.com:8080 https://www.google.com
    echo "Test du proxy terminé"

# 2. Augmentez le délai d'attente pour npm
- name: Installer avec délai d'attente augmenté
  run: |
    npm config set fetch-timeout 300000
    npm install

# 3. Vérifiez le format de l'URL
- name: Déboguer la configuration du proxy
  run: |
    echo "HTTP_PROXY: $HTTP_PROXY"
    echo "HTTPS_PROXY: $HTTPS_PROXY"
    # Devrait être : http://user:pass@host:port

Problème : Échec de la vérification du certificat SSL

Symptômes : Erreurs du type "problème de certificat SSL : impossible d'obtenir le certificat de l'émetteur local" ou "CERT_UNTRUSTED".

Cause : Les proxies d'entreprise effectuent souvent une inspection SSL, en remplaçant les certificats. Le runner CI/CD ne fait pas confiance au CA d'entreprise.

Solution :

# Option 1 : Ajouter le certificat CA d'entreprise
- name: Installer le certificat CA d'entreprise
  run: |
    sudo cp corporate-ca.crt /usr/local/share/ca-certificates/
    sudo update-ca-certificates

# Option 2 : Désactiver la vérification SSL (NON recommandé pour la production !)
- name: Installer avec vérification SSL désactivée
  run: |
    npm config set strict-ssl false
    npm install
  env:
    NODE_TLS_REJECT_UNAUTHORIZED: 0

# Option 3 : Utiliser le proxy uniquement pour HTTP, HTTPS directement
- name: Utilisation sélective du proxy
  run: npm install
  env:
    HTTP_PROXY: http://proxy.example.com:8080
    # HTTPS_PROXY non défini

Avertissement : Désactiver la vérification des certificats SSL crée un risque de sécurité sérieux. Utilisez cette approche uniquement pour des réseaux d'entreprise internes et assurez-vous d'ajouter le CA d'entreprise aux certificats de confiance.

Problème : Le proxy fonctionne pour certaines commandes, mais pas pour d'autres

Symptômes : npm install fonctionne via le proxy, mais git clone ou docker pull ignorent les paramètres du proxy.

Cause : Différents outils utilisent différents mécanismes de configuration du proxy. Git et Docker ont leurs propres fichiers de configuration.

Solution :

# Configuration du proxy Git
- name: Configurer le proxy Git
  run: |
    git config --global http.proxy http://proxy.example.com:8080
    git config --global https.proxy http://proxy.example.com:8080

# Configuration du proxy Docker (voir section Docker ci-dessus)
# Pour wget/curl
- name: Configurer 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

Problème : Les services internes sont inaccessibles lorsque le proxy est activé

Symptômes : Après la configuration du proxy, les connexions à localhost, aux conteneurs Docker internes ou aux services d'entreprise ne fonctionnent plus.

Cause : La variable NO_PROXY est mal configurée, toutes les requêtes passent par le proxy, y compris les locales.

Solution :

# Configuration correcte 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

# Pour Docker Compose, ajoutez également
services:
  app:
    environment:
      - NO_PROXY=localhost,127.0.0.1,db,redis
      # db et redis — noms d'autres services dans compose

Problème : Les credentials du proxy apparaissent dans les journaux

Symptômes : Les mots de passe du proxy sont visibles en clair dans les journaux CI/CD.

Cause : Affichage des variables d'environnement via echo ou mode verbeux des commandes.

Solution :

# ❌ MAUVAIS - credentials dans les journaux
- name: Déboguer le proxy
  run: |
    echo "Proxy : $HTTP_PROXY"  # Affichera http://user:pass@host:port
    curl -v ...  # Le mode verbeux montre les credentials

# ✅ BON - affichage sécurisé
- name: Déboguer le proxy (sécurisé)
  run: |
    echo "Hôte du proxy configuré : $(echo $HTTP_PROXY | cut -d'@' -f2)"
    # Affichera uniquement host:port
    
# Utilisez des secrets pour masquer
- name: Configurer le proxy
  env:
    PROXY_URL: ${{ secrets.PROXY_URL }}  # GitHub masque automatiquement
  run: |
    export HTTP_PROXY="$PROXY_URL"

Conclusion

L'intégration de proxy dans le pipeline CI/CD est un aspect important de l'automatisation, garantissant la sécurité, la conformité aux politiques d'entreprise et la possibilité de tester des fonctionnalités de géolocalisation. Dans ce guide, nous avons examiné des méthodes pratiques pour configurer des proxies pour GitHub Actions, GitLab CI, Jenkins, Docker et des gestionnaires de paquets populaires.

Points clés à retenir lors de la configuration du proxy dans CI/CD : utilisez toujours un stockage sécurisé des credentials via les mécanismes de secrets intégrés des plateformes, configurez correctement NO_PROXY pour exclure les services locaux et internes, testez la connexion au proxy avant les opérations principales et surveillez les journaux pour détecter d'éventuelles fuites de données sensibles. Pour des environnements de production critiques, il est recommandé d'utiliser des systèmes externes de gestion des secrets tels que HashiCorp Vault.

Le choix du type de proxy dépend de vos besoins : pour les réseaux d'entreprise, on utilise généralement des proxies HTTP/HTTPS existants, pour tester des fonctionnalités de géolocalisation, des proxies résidentiels avec des IP des pays nécessaires sont appropriés, et pour un téléchargement rapide des dépendances, on peut utiliser des proxies de centres de données. Il est important d'assurer un uptime élevé des serveurs proxy, car leur indisponibilité entraînera l'échec de tous les builds et bloquera le travail de l'équipe de développement.

En cas de problème, commencez par vérifier la disponibilité de base du proxy via curl ou wget, puis vérifiez le format de l'URL et les credentials, et seulement ensuite passez aux configurations spécifiques des outils. La plupart des problèmes se résolvent par une configuration correcte des variables d'environnement HTTP_PROXY, HTTPS_PROXY et NO_PROXY.

Intégration de proxy dans le pipeline CI/CD : configuration pour GitHub Actions, GitLab et Jenkins

Pourquoi utiliser des proxies dans les processus CI/CD

Configuration du proxy dans GitHub Actions

Configuration de base via des variables d'environnement

Stockage sécurisé des credentials via GitHub Secrets

Configuration du proxy pour des étapes spécifiques

Intégration du proxy avec GitLab CI/CD

Configuration du proxy au niveau de GitLab Runner

Configuration via .gitlab-ci.yml

Utilisation des Variables CI/CD de GitLab pour les credentials

Configuration du proxy dans Jenkins

Configuration globale du proxy pour Jenkins

Configuration du proxy pour Jenkins Pipeline

Utilisation des Credentials Jenkins pour le proxy

Configuration du proxy pour les agents Jenkins

Proxy pour Docker dans CI/CD

Configuration du proxy pour le démon Docker

Proxy pour les conteneurs lors de la construction

Docker Compose avec proxy

Configuration du proxy pour les gestionnaires de paquets

NPM et Yarn

Python pip et Poetry

Maven et Gradle

Stockage sécurisé des credentials du proxy

Secrets GitHub Actions

Variables GitLab CI/CD

Jenkins Credentials Store

Systèmes externes de gestion des secrets

Résolution des problèmes courants

Problème : Délai d'attente de connexion lors du téléchargement des dépendances

Problème : Échec de la vérification du certificat SSL

Problème : Le proxy fonctionne pour certaines commandes, mais pas pour d'autres

Problème : Les services internes sont inaccessibles lorsque le proxy est activé

Problème : Les credentials du proxy apparaissent dans les journaux

Conclusion