Integration von Proxys in CI/CD: Einrichtung für GitHub Actions und GitLab

```html

Bei der Automatisierung von Bereitstellungen und Tests besteht häufig die Notwendigkeit, Proxys in CI/CD-Prozessen zu verwenden. Dies kann mit Unternehmenssicherheitsrichtlinien, dem Testen von Geolokalisierungsfunktionen oder dem Umgehen von Rate-Limiting beim Herunterladen von Abhängigkeiten zusammenhängen. In diesem Leitfaden werden wir die praktische Konfiguration von Proxys für beliebte CI/CD-Plattformen mit fertigen Konfigurationsbeispielen behandeln.

Warum Proxys in CI/CD-Prozessen benötigt werden

Der Einsatz von Proxys in automatisierten Bereitstellungsprozessen löst mehrere kritische Aufgaben. Erstens verlangen viele Unternehmensnetzwerke, dass der gesamte ausgehende Datenverkehr über Unternehmensproxys geleitet wird, um die Sicherheit zu kontrollieren und Protokolle zu führen. Ohne die richtige Konfiguration kann die CI/CD-Pipeline einfach keine Abhängigkeiten herunterladen oder sich mit externen Diensten verbinden.

Zweitens muss beim Testen von Anwendungen mit Geolokalisierungslogik die Funktionalität aus verschiedenen Ländern überprüft werden. Wenn Sie beispielsweise einen Dienst mit regionalem Inhalt oder Preisgestaltung entwickeln, müssen automatisierte Tests Benutzer aus verschiedenen Standorten simulieren. Hier helfen residential Proxys mit IP-Adressen aus den benötigten Regionen.

Der dritte Grund ist das Umgehen von Rate-Limiting und Blockierungen. Bei häufigen Pipeline-Ausführungen, insbesondere in großen Teams, können CI/CD-Server unter die API-Beschränkungen externer Dienste fallen. Beispielsweise können GitHub API oder Paketregister IPs vorübergehend blockieren, wenn das Anfrage-Limit überschritten wird. Die Rotation von Proxys hilft, die Last zu verteilen.

Wichtig: Für CI/CD-Prozesse ist die Stabilität der Verbindung entscheidend. Verwenden Sie Proxys mit einer Verfügbarkeit von mindestens 99,5 % und einer schnellen Reaktionszeit (unter 200 ms). Instabile Proxys führen zu zufälligen Build-Abbrüchen und zu einem Zeitverlust für das Team bei der Fehlersuche.

Proxy in GitHub Actions konfigurieren

GitHub Actions ist eine der beliebtesten Plattformen für CI/CD. Die Konfiguration von Proxys erfolgt hier über Umgebungsvariablen, die auf Workflow- oder Organisationsebene festgelegt werden können. Lassen Sie uns einige Integrationsmethoden betrachten.

Grundkonfiguration über Umgebungsvariablen

Der einfachste Weg ist, die Umgebungsvariablen HTTP_PROXY und HTTPS_PROXY zu Beginn des Jobs festzulegen. Die meisten Tools (curl, wget, npm, pip) verwenden diese Variablen automatisch:

name: CI mit 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: Node.js einrichten
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      
      - name: Abhängigkeiten installieren
        run: npm install
      
      - name: Tests ausführen
        run: npm test

Die Variable NO_PROXY ist entscheidend — sie schließt lokale Adressen und interne Dienste vom Proxieren aus. Ohne sie können Probleme beim Verbinden mit localhost oder internen Docker-Containern auftreten.

Sichere Speicherung von Anmeldeinformationen über GitHub Secrets

Wenn der Proxy eine Authentifizierung erfordert, speichern Sie niemals Benutzernamen und Passwort im Klartext in der Workflow-Datei. Verwenden Sie GitHub Secrets:

name: CI mit authentifiziertem Proxy

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v3
      
      - name: Proxy konfigurieren
        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: Proxy-Verbindung testen
        run: curl -I https://api.github.com
      
      - name: Abhängigkeiten installieren
        run: npm ci

Erstellen Sie Secrets in den Repository-Einstellungen: Einstellungen → Secrets und Variablen → Aktionen → Neues Repository-Secret. Fügen Sie PROXY_USER, PROXY_PASS, PROXY_HOST und PROXY_PORT hinzu. Diese Werte werden verschlüsselt und sind in den Protokollen nicht sichtbar.

Proxy für bestimmte Schritte konfigurieren

Manchmal müssen Proxys nur für bestimmte Operationen verwendet werden, z. B. nur für das Herunterladen von Abhängigkeiten, jedoch nicht für das Deployment. Setzen Sie die Variablen auf der Ebene des spezifischen Schrittes:

steps:
  - name: Abhängigkeiten über Proxy herunterladen
    env:
      HTTP_PROXY: http://proxy.example.com:8080
      HTTPS_PROXY: http://proxy.example.com:8080
    run: npm install
  
  - name: Ohne Proxy deployen
    run: ./deploy.sh

Integration von Proxys mit GitLab CI/CD

GitLab CI/CD bietet mehrere Ebenen zur Konfiguration von Proxys: auf Runner-Ebene, auf Projektebene und auf Ebene des spezifischen Jobs. Die Wahl hängt davon ab, ob der Proxy für alle Projekte oder nur für bestimmte benötigt wird.

Proxy auf GitLab Runner-Ebene konfigurieren

Wenn Sie einen selbst gehosteten GitLab Runner verwenden und alle Projekte über einen Proxy arbeiten sollen, konfigurieren Sie ihn in der Runner-Konfiguration. Bearbeiten Sie die Datei /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"

Nach der Änderung der Konfiguration starten Sie den Runner neu: sudo gitlab-runner restart. Jetzt verwenden alle Jobs auf diesem Runner automatisch den Proxy.

Konfiguration über .gitlab-ci.yml

Um den Proxy auf Projektebene zu konfigurieren, verwenden Sie Variablen in der Datei .gitlab-ci.yml. Dies ist ein flexiblerer Ansatz, der es verschiedenen Projekten ermöglicht, unterschiedliche Proxys zu verwenden:

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

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

Verwendung von GitLab CI/CD-Variablen für Anmeldeinformationen

Zur Speicherung sensibler Daten verwenden Sie CI/CD-Variablen in den Projekteinstellungen: Einstellungen → CI/CD → Variablen. Erstellen Sie geschützte und maskierte Variablen:

PROXY_URL — vollständige URL mit Anmeldeinformationen (maskiert)
PROXY_HOST — Host des Proxy-Servers
PROXY_PORT — Port
PROXY_USER und PROXY_PASS — zur getrennten Speicherung

Verwenden Sie diese dann in .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

Proxy-Konfiguration in Jenkins

Jenkins bietet mehrere Möglichkeiten zur Konfiguration von Proxys, abhängig von der Architektur: globale Einstellungen für Jenkins Master, Einstellungen für bestimmte Agenten oder Einstellungen auf der Ebene einzelner Pipelines.

Globale Proxy-Einstellung für Jenkins

Um einen Proxy zu konfigurieren, der von Jenkins für Plugin-Updates und andere interne Vorgänge verwendet wird, gehen Sie zu Verwalten von Jenkins → Verwalten von Plugins → Erweitert. Geben Sie im Abschnitt HTTP-Proxy-Konfiguration Folgendes an:

Server: proxy.example.com
Port: 8080
Benutzername und Passwort (falls Authentifizierung erforderlich)
Kein Proxy-Host: localhost,127.0.0.1,.internal

Diese Einstellung betrifft nur Jenkins selbst, nicht die Jobs. Für Jobs ist eine separate Konfiguration erforderlich.

Proxy für Jenkins-Pipeline konfigurieren

In der Jenkinsfile können Umgebungsvariablen für die gesamte Pipeline oder für bestimmte Stufen festgelegt werden:

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

Verwendung von Jenkins-Anmeldeinformationen für Proxys

Zur sicheren Speicherung von Proxy-Anmeldeinformationen verwenden Sie den Jenkins Credentials Store. Erstellen Sie Anmeldeinformationen vom Typ "Benutzername mit Passwort" in Verwalten von Jenkins → Verwalten von Anmeldeinformationen und verwenden Sie diese dann in der Pipeline:

pipeline {
    agent any
    
    stages {
        stage('Build mit authentifiziertem Proxy') {
            steps {
                withCredentials([usernamePassword(
                    credentialsId: 'proxy-credentials',
                    usernameVariable: 'PROXY_USER',
                    passwordVariable: 'PROXY_PASS'
                )]) {
                    sh '''
                        export HTTP_PROXY="http://${PROXY_USER}:${PROXY_PASS}@proxy.example.com:8080"
                        export HTTPS_PROXY="http://${PROXY_USER}:${PROXY_PASS}@proxy.example.com:8080"
                        npm install
                    '''
                }
            }
        }
    }
}

Proxy für Jenkins-Agenten konfigurieren

Wenn Sie separate Jenkins-Agenten (Nodes) verwenden, konfigurieren Sie den Proxy für jeden Agenten separat. Fügen Sie in der Agenten-Konfiguration (Verwalten von Jenkins → Verwalten von Nodes → Konfigurieren) Folgendes zu den Umgebungsvariablen hinzu:

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

Proxys für Docker in CI/CD

Docker ist ein wesentlicher Bestandteil moderner CI/CD-Prozesse. Die Konfiguration von Proxys für Docker hat ihre eigenen Besonderheiten, da sowohl der Docker-Daemon als auch die Container konfiguriert werden müssen.

Proxy für Docker-Daemon konfigurieren

Damit der Docker-Daemon Images über einen Proxy herunterladen kann, erstellen Sie eine systemd-Drop-in-Datei. Erstellen Sie auf einem Linux-System ein Verzeichnis und eine Datei:

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

Fügen Sie den folgenden Inhalt hinzu:

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

Laden Sie die Konfiguration und Docker neu:

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

Proxy für Container während des Builds

Wenn Container während des Builds über einen Proxy zugreifen müssen (z. B. zum Installieren von Paketen), übergeben Sie die Variablen über Build-Argumente im 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 . .

# Entfernen Sie die Proxy-Variablen für die Laufzeit
ENV HTTP_PROXY=
ENV HTTPS_PROXY=

CMD ["npm", "start"]

Übergeben Sie in der CI/CD-Pipeline die Build-Argumente:

# GitHub Actions
- name: Docker-Image mit Proxy bauen
  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 mit Proxy

Bei der Verwendung von Docker Compose in CI/CD konfigurieren Sie den Proxy über die Umgebungsvariablen in 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"

Proxy für Paketmanager konfigurieren

Paketmanager erfordern häufig eine zusätzliche Proxy-Konfiguration, insbesondere wenn sie eigene Konfigurationsdateien verwenden. Lassen Sie uns die Konfiguration für beliebte Paketmanager betrachten.

NPM und Yarn

NPM kann sowohl Umgebungsvariablen HTTP_PROXY/HTTPS_PROXY als auch seine eigene Konfiguration verwenden. Für eine explizite Konfiguration in CI/CD:

# In GitHub Actions oder GitLab CI
- name: NPM-Proxy konfigurieren
  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: Abhängigkeiten installieren
  run: npm install

# Für Yarn
- name: Yarn-Proxy konfigurieren
  run: |
    yarn config set proxy http://proxy.example.com:8080
    yarn config set https-proxy http://proxy.example.com:8080

Eine alternative Methode besteht darin, eine .npmrc-Datei im Stammverzeichnis des Projekts zu erstellen (aber keine Anmeldeinformationen einpflegen!):

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

Python pip und Poetry

Pip verwendet Umgebungsvariablen, kann aber auch über die Konfiguration eingerichtet werden:

# Über Umgebungsvariablen (empfohlen für CI)
export HTTP_PROXY=http://proxy.example.com:8080
export HTTPS_PROXY=http://proxy.example.com:8080
pip install -r requirements.txt

# Oder über pip-Parameter
pip install --proxy http://proxy.example.com:8080 -r requirements.txt

# Für Poetry
poetry config http-basic.proxy http://proxy.example.com:8080
poetry install

Maven und Gradle

Für Java-Projekte erfordert die Proxy-Konfiguration die Erstellung von Konfigurationsdateien. Für Maven erstellen Sie settings.xml in der CI-Pipeline:

- name: Maven-Proxy konfigurieren
  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: Mit Maven bauen
  run: mvn clean install

Für Gradle fügen Sie die Einstellungen in gradle.properties hinzu:

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

Sichere Speicherung von Proxy-Anmeldeinformationen

Die Speicherung von Proxy-Anmeldeinformationen ist ein kritischer Aspekt der Sicherheit in CI/CD. Ein Leck dieser Daten kann zu unbefugter Nutzung des Proxys und finanziellen Verlusten führen. Lassen Sie uns bewährte Praktiken für verschiedene Plattformen betrachten.

GitHub Actions Secrets

GitHub Actions bietet drei Ebenen von Secrets: Repository, Umgebung und Organisation. Verwenden Sie für Proxy-Anmeldeinformationen:

Repository-Secrets — für Projekte, bei denen der Proxy nur in einem Repository benötigt wird
Organisations-Secrets — wenn ein Proxy in allen Projekten der Organisation verwendet wird
Umgebungs-Secrets — für verschiedene Proxys in Staging-/Produktionsumgebungen

Wichtige Sicherheitsregeln:

Geben Sie Secrets niemals in Protokollen aus: GitHub maskiert sie automatisch, aber es ist besser, echo zu vermeiden
Verwenden Sie unterschiedliche Anmeldeinformationen für verschiedene Umgebungen
Rotieren Sie regelmäßig die Proxy-Passwörter (mindestens alle 90 Tage)
Beschränken Sie den Zugriff auf Secrets durch Branch-Schutzregeln

GitLab CI/CD-Variablen

GitLab bietet zusätzliche Schutzoptionen für Variablen:

Protected — die Variable ist nur in geschützten Branches (main, production) verfügbar
Masked — der Wert wird automatisch in Protokollen ausgeblendet
Umfang der Umgebung — Einschränkung der Verwendung auf bestimmte Umgebungen

Empfohlene Konfiguration für Proxy-Anmeldeinformationen:

# Einstellungen → CI/CD → Variablen
PROXY_USER: myuser (Protected: Ja, Masked: Ja)
PROXY_PASS: secret123 (Protected: Ja, Masked: Ja)
PROXY_HOST: proxy.example.com (Protected: Nein, Masked: Nein)
PROXY_PORT: 8080 (Protected: Nein, Masked: Nein)

Jenkins Credentials Store

Der Jenkins Credentials Store unterstützt mehrere Arten der Speicherung von Anmeldeinformationen. Für Proxys wird empfohlen:

"Benutzername mit Passwort" für die Proxy-Anmeldung/Passwort zu verwenden
Folder-Level-Credentials für verschiedene Teams/Projekte einzurichten
Credentials Binding Plugin aktivieren, um sie sicher in der Pipeline zu verwenden
Audit-Logging einrichten, um die Verwendung von Anmeldeinformationen zu verfolgen

Externe Systeme zur Verwaltung von Secrets

Für Unternehmensumgebungen wird empfohlen, spezialisierte Systeme zur Verwaltung von Secrets zu verwenden: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault oder Google Secret Manager. Beispiel für die Integration mit HashiCorp Vault in GitHub Actions:

- name: Secrets aus Vault importieren
  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: Proxy konfigurieren
  run: |
    export HTTP_PROXY="http://${PROXY_USER}:${PROXY_PASS}@${PROXY_HOST}:8080"
    npm install

Lösung typischer Probleme

Bei der Integration von Proxys in CI/CD treten häufig die gleichen Probleme auf. Lassen Sie uns die häufigsten Probleme und deren Lösungen betrachten.

Problem: Verbindungstimeout beim Herunterladen von Abhängigkeiten

Symptome: npm install, pip install oder docker pull enden mit einem Timeout-Fehler nach 30-60 Sekunden.

Ursachen:

Der Proxy-Server ist nicht verfügbar oder überlastet
Falsches Format der Proxy-URL (http:// am Anfang vergessen)
Der Proxy erfordert eine Authentifizierung, aber die Anmeldeinformationen wurden nicht übergeben
Firewall blockiert die Verbindung vom CI/CD-Runner zum Proxy

Lösung:

# 1. Überprüfen Sie die Erreichbarkeit des Proxys
- name: Proxy-Konnektivität testen
  run: |
    curl -v -x http://proxy.example.com:8080 https://www.google.com
    echo "Proxy-Test abgeschlossen"

# 2. Erhöhen Sie das Timeout für npm
- name: Installation mit erhöhtem Timeout
  run: |
    npm config set fetch-timeout 300000
    npm install

# 3. Überprüfen Sie das URL-Format
- name: Debugging der Proxy-Konfiguration
  run: |
    echo "HTTP_PROXY: $HTTP_PROXY"
    echo "HTTPS_PROXY: $HTTPS_PROXY"
    # Sollte sein: http://user:pass@host:port

Problem: SSL-Zertifikatsüberprüfung fehlgeschlagen

Symptome: Fehler wie "SSL-Zertifikatproblem: Lokalen Ausstellerzertifikat nicht erhalten" oder "CERT_UNTRUSTED".

Ursache: Unternehmensproxys führen häufig eine SSL-Inspektion durch und ersetzen Zertifikate. Der CI/CD-Runner vertraut dem Unternehmens-CA nicht.

Lösung:

# Option 1: Fügen Sie das Unternehmens-CA-Zertifikat hinzu
- name: Unternehmens-CA-Zertifikat installieren
  run: |
    sudo cp corporate-ca.crt /usr/local/share/ca-certificates/
    sudo update-ca-certificates

# Option 2: Deaktivieren Sie die SSL-Überprüfung (NICHT für Produktion empfohlen!)
- name: Installation mit deaktivierter SSL-Überprüfung
  run: |
    npm config set strict-ssl false
    npm install
  env:
    NODE_TLS_REJECT_UNAUTHORIZED: 0

# Option 3: Verwenden Sie den Proxy nur für HTTP, HTTPS direkt
- name: Selektive Proxy-Nutzung
  run: npm install
  env:
    HTTP_PROXY: http://proxy.example.com:8080
    # HTTPS_PROXY nicht setzen

Warnung: Das Deaktivieren der Überprüfung von SSL-Zertifikaten birgt erhebliche Sicherheitsrisiken. Verwenden Sie diesen Ansatz nur für interne Unternehmensnetzwerke und fügen Sie unbedingt das Unternehmens-CA zu den vertrauenswürdigen hinzu.

Problem: Proxy funktioniert für einige Befehle, aber nicht für andere

Symptome: npm install funktioniert über den Proxy, aber git clone oder docker pull ignorieren die Proxy-Einstellungen.

Ursache: Verschiedene Tools verwenden unterschiedliche Mechanismen zur Proxy-Konfiguration. Git und Docker haben eigene Konfigurationsdateien.

Lösung:

# Git-Proxy konfigurieren
- name: Git-Proxy konfigurieren
  run: |
    git config --global http.proxy http://proxy.example.com:8080
    git config --global https.proxy http://proxy.example.com:8080

# Docker-Proxy konfigurieren (siehe Abschnitt Docker oben)
# Für wget/curl
- name: wget/curl konfigurieren
  run: |
    echo "use_proxy = on" >> ~/.wgetrc
    echo "http_proxy = http://proxy.example.com:8080" >> ~/.wgetrc
    echo "https_proxy = http://proxy.example.com:8080" >> ~/.wgetrc

Problem: Interne Dienste sind bei aktiviertem Proxy nicht erreichbar

Symptome: Nach der Proxy-Konfiguration funktionieren Verbindungen zu localhost, internen Docker-Containern oder Unternehmensdiensten nicht mehr.

Ursache: Die NO_PROXY-Variable ist falsch konfiguriert, alle Anfragen gehen über den Proxy, einschließlich lokaler.

Lösung:

# Richtige Konfiguration von 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

# Für Docker Compose fügen Sie auch hinzu
services:
  app:
    environment:
      - NO_PROXY=localhost,127.0.0.1,db,redis
      # db und redis sind die Namen anderer Dienste im Compose

Problem: Proxy-Anmeldeinformationen erscheinen in Protokollen

Symptome: In den CI/CD-Protokollen sind die Proxy-Passwörter im Klartext sichtbar.

Ursache: Ausgabe von Umgebungsvariablen über echo oder den ausführlichen Modus von Befehlen.

Lösung:

# ❌ SCHLECHT - Anmeldeinformationen in Protokollen
- name: Proxy debuggen
  run: |
    echo "Proxy: $HTTP_PROXY"  # Zeigt http://user:pass@host:port
    curl -v ...  # Ausführlicher Modus zeigt Anmeldeinformationen

# ✅ GUT - sichere Ausgabe
- name: Proxy debuggen (sicher)
  run: |
    echo "Proxy-Host konfiguriert: $(echo $HTTP_PROXY | cut -d'@' -f2)"
    # Zeigt nur host:port
    
# Verwenden Sie Secrets zur Maskierung
- name: Proxy konfigurieren
  env:
    PROXY_URL: ${{ secrets.PROXY_URL }}  # GitHub maskiert automatisch
  run: |
    export HTTP_PROXY="$PROXY_URL"

Fazit

Die Integration von Proxys in CI/CD-Pipelines ist ein wichtiger Aspekt der Automatisierung, der Sicherheit, die Einhaltung von Unternehmensrichtlinien und die Möglichkeit zur Prüfung von Geolokalisierungsfunktionen gewährleistet. In diesem Leitfaden haben wir praktische Möglichkeiten zur Konfiguration von Proxys für GitHub Actions, GitLab CI, Jenkins, Docker und beliebte Paketmanager behandelt.

Wichtige Punkte, die Sie bei der Konfiguration von Proxys in CI/CD beachten sollten: Verwenden Sie immer eine sichere Speicherung von Anmeldeinformationen über die integrierten Secrets-Mechanismen der Plattform, konfigurieren Sie NO_PROXY korrekt, um lokale und interne Dienste auszuschließen, testen Sie die Verbindung zum Proxy vor den Hauptoperationen und überwachen Sie die Protokolle auf mögliche Lecks sensibler Daten. Für kritische Produktionsumgebungen wird empfohlen, externe Systeme zur Verwaltung von Secrets wie HashiCorp Vault zu verwenden.

Die Wahl des Proxy-Typs hängt von Ihren Anforderungen ab: Für Unternehmensnetzwerke werden in der Regel bestehende HTTP/HTTPS-Proxys verwendet, für das Testen von Geolokalisierungsfunktionen sind residential Proxys mit IPs aus den gewünschten Ländern geeignet, und für den schnellen Download von Abhängigkeiten können Datacenter-Proxys verwendet werden. Es ist wichtig, eine hohe Verfügbarkeit der Proxy-Server sicherzustellen, da deren Nichterreichbarkeit zu Ausfällen aller Builds und zur Blockierung der Arbeit des Entwicklungsteams führen kann.

Bei Problemen beginnen Sie mit der Überprüfung der grundlegenden Erreichbarkeit des Proxys über curl oder wget, überprüfen Sie dann das richtige Format der URL und der Anmeldeinformationen und gehen Sie erst danach zu spezifischen Einstellungen der einzelnen Tools über. Die meisten Probleme lassen sich durch die richtige Konfiguration der Umgebungsvariablen HTTP_PROXY, HTTPS_PROXY und NO_PROXY lösen.

```

Integration von Proxys in CI/CD-Pipelines: Konfiguration für GitHub Actions, GitLab und Jenkins

Warum Proxys in CI/CD-Prozessen benötigt werden

Proxy in GitHub Actions konfigurieren

Grundkonfiguration über Umgebungsvariablen

Sichere Speicherung von Anmeldeinformationen über GitHub Secrets

Proxy für bestimmte Schritte konfigurieren

Integration von Proxys mit GitLab CI/CD

Proxy auf GitLab Runner-Ebene konfigurieren

Konfiguration über .gitlab-ci.yml

Verwendung von GitLab CI/CD-Variablen für Anmeldeinformationen

Proxy-Konfiguration in Jenkins

Globale Proxy-Einstellung für Jenkins

Proxy für Jenkins-Pipeline konfigurieren

Verwendung von Jenkins-Anmeldeinformationen für Proxys

Proxy für Jenkins-Agenten konfigurieren

Proxys für Docker in CI/CD

Proxy für Docker-Daemon konfigurieren

Proxy für Container während des Builds

Docker Compose mit Proxy

Proxy für Paketmanager konfigurieren

NPM und Yarn

Python pip und Poetry

Maven und Gradle

Sichere Speicherung von Proxy-Anmeldeinformationen

GitHub Actions Secrets

GitLab CI/CD-Variablen

Jenkins Credentials Store

Externe Systeme zur Verwaltung von Secrets

Lösung typischer Probleme

Problem: Verbindungstimeout beim Herunterladen von Abhängigkeiten

Problem: SSL-Zertifikatsüberprüfung fehlgeschlagen

Problem: Proxy funktioniert für einige Befehle, aber nicht für andere

Problem: Interne Dienste sind bei aktiviertem Proxy nicht erreichbar

Problem: Proxy-Anmeldeinformationen erscheinen in Protokollen

Fazit