Blog Engineering GitLab-Umgebungsvariablen entmystifiziert
Aktualisiert am: January 13, 2025
7 Minuten Lesezeit

GitLab-Umgebungsvariablen entmystifiziert

CI/CD-Variablen sind nützliche (und flexible) Tools zur Steuerung von Jobs und Pipelines. Wir verraten dir alles, was du über GitLab-Umgebungsvariablen wissen musst.

train - visualize - cover

Es gibt viel Flexibilität bei der Definition und Verwendung von Variablen für CI/CD. Variablen sind sehr nützlich für die Steuerung von Jobs und Pipelines und sie helfen dir zu vermeiden, Werte in der Konfigurationsdatei .gitlab-ci.yml festlegen zu müssen. Dieser Blogbeitrag soll ein umfassenderes Bild vermitteln, indem er alle (oder die meisten) Informationen über die Definition und die Handhabung der Variablen zusammenfasst, um das Verständnis des Geltungsbereichs und der Möglichkeiten zu erleichtern. Die relevante Dokumentation in dem Beitrag verlinkt und ist aktuell nur in englischer Sprache verfügbar.

In GitLab CI/CD können mit Variablen Werte definiert und gespeichert werden, um Jobs anzupassen. Bei der Verwendung von Variablen müssen Werte nicht im Klartext gespeichert werden. In GitLab können CI/CD-Variablen unter Einstellungen >> CI/CD >> Variablen oder einfach in der Datei .gitlab-ci.yml definiert werden.

Variablen sind nützlich, um Dienste von Drittanbietern für verschiedene Bereitstellungsumgebungen zu konfigurieren, z. B. testing, staging, production usw. Passe an, welche Dienste mit diesen Umgebungen verknüpft sind, indem du einfach die Variable änderst, die auf den API-Endpunkt zeigt, den die Dienste verwenden sollen. Verwende auch Variablen, um Jobs zu konfigurieren, und stelle sie dann als Umgebungsvariablen innerhalb der Jobs zur Verfügung, wenn diese ausgeführt werde.

GitLab liest die Datei .gitlab-ci.yml, um die referenzierte Variable zu scannen und sendet die Informationen an den GitLab Runner. Die Variablen werden auf dem Runner angezeigt und vom Runner ausgegeben.

Die Beziehung zwischen Variablen und Umgebungen

Der Prozess der Softwareentwicklung umfasst verschiedene Phasen, in denen ein Produkt getestet wird, bevor es an die Benutzer(innen) ausgeliefert wird. Zur Definition dieser Phasen werden Umgebungen verwendet, die von Team zu Team und zwischen Unternehmen unterschiedlich sein können.

Variablen sind dagegen Datenwerte, die sich durch die Interaktion der Benutzer(innen) mit dem Produkt ändern können. Beispielsweise kann ihr Alter, ihre Vorlieben oder eine beliebige andere Eingabe den nächsten Schritt in der Aufgabenfolge des Produkts bestimmen.

Wir hören oft den Begriff Umgebungsvariable. Dabei handelt es sich um Variablen, die in einer bestimmten Umgebung, aber außerhalb der Anwendung definiert sind. CI/CD-Variablen von GitLab bieten Entwickler(inne)n die Möglichkeit, Werte in ihrem Code zu konfigurieren. Variablen sind hilfreich, da sie sicherstellen, dass der Code flexibel ist. Mit CI/CD-Variablen von GitLab können Beutzer(innen) eine in einer bestimmten Umgebung bereitgestellte Anwendung ändern, ohne den Code zu ändern. Es ist einfach, Tests durchzuführen oder sogar Dienste von Drittanbietern zu integrieren, indem eine Umgebungsvariable außerhalb der Anwendung geändert wird.

Geltungsbereich der Variablen für CI/CD

Hierarchie für CI/CD-Variablen: 1) Variablen für die manuelle Ausführung, Auslösung und Planung von Pipelines, 2) Geschützte Variablen auf Projekt-, Gruppen- und Instanzebene, 3) Geerbte CI/CD-Variablen, 4) Job-Ebene, globale yml-definierte Variablen, 5) Bereitstellungsvariablen, 6) Vordefinierte CI/CD-Variablen

.gitlab-ci.yml-definierte Variablen

Variablen, die in der Arbeitsumgebung verfügbar sein müssen, können zu GitLab hinzugefügt werden. Diese CI/CD-Variablen sind dazu gedacht, nicht-sensible Projektkonfigurationen wie z. B. die URL der Datenbank in der Datei .gitlab-ci.yml zu speichern. Verwende diese Variable in mehreren Jobs oder Skripten, wo immer der Wert benötigt wird. Wenn sich der Wert ändert, musst du die Variable nur einmal aktualisieren und die Änderung wird überall dort übernommen, wo die Variable verwendet wird.

Projekt-CI/CD-Variablen

Einen Schritt über die Repository-spezifischen Anforderungen hinaus kannst du CI/CD-Variablen in den Projekt-Einstellungen definieren und für CI/CD-Pipelines verfügbar machen. Diese werden aus dem Repository heraus gespeichert (nicht in der Datei .gitlab-ci.yml), sind aber weiterhin in der CI/CD-Konfiguration und den Skripten verfügbar. Durch das Speichern der Variablen außerhalb der Datei .gitlab-ci.yml werden diese Werte auf einen reinen Projektgeltungsbereich beschränkt und nicht als Klartext im Projekt gespeichert.

CI/CD-Variablen für Gruppen und Instanzen

Einige Variablen sind auf Gruppen- oder sogar Instanzebene relevant und können für alle Projekte in einer Gruppe oder Instanz nützlich sein. Definiere die Variablen in den Gruppen- oder Instanzeinstellungen, sodass alle Projekte innerhalb dieser Bereiche die Variablen verwenden können, ohne den Wert zu kennen oder die Variablen für den untergeordneten Bereich erstellen zu müssen. Zum Beispiel kann ein gemeinsamer Wert, der in mehreren Projekten aktualisiert werden muss, leicht verwaltet werden, wenn er an einer einzigen Stelle aktualisiert wird. Alternativ können mehrere Projekte ein bestimmtes Passwort verwenden, ohne den Wert des Passworts selbst kennen zu müssen.

Jobs und Pipelines als Umgebungen

Die CI/CD-Variablen von GitLab werden nicht nur als Umgebungsvariablen verwendet, sondern auch in der Konfigurationsdatei .gitlab-ci.yml, um das Verhalten der Pipeline unabhängig von der Umgebung zu konfigurieren. Die Variablen können in den Projekt-/Gruppen-/Instanzeinstellungen gespeichert und Jobs in Pipelines zur Verfügung gestellt werden.

Zum Beispiel:

job:  
  rules:  
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH  
  script:  
  - echo "This job ran on the $CI_COMMIT_BRANCH branch."  

Die Variable ($CI_COMMIT_BRANCH) im Skriptabschnitt wird in dem Bereich des Jobs ausgeführt, in dem sie definiert wurde. Dieser Bereich ist die „Job-Umgebung“ – das heißt, wenn der Job gestartet wird, startet der GitLab-Runner einen Docker-Container und führt den Job in dieser Umgebung aus. Der Runner stellt diese Variable (und alle anderen vordefinierten oder benutzerdefinierten Variablen) dem Job zur Verfügung und kann ihren Wert bei Bedarf in der Protokollausgabe anzeigen.

Die Variable wird jedoch auch im Abschnitt if: verwendet, um zu bestimmen, wann der Job ausgeführt werden soll. Dies ist an sich keine Umgebung, weshalb wir diese CI/CD-Variablen aufrufen. Sie können verwendet werden, um CI/CD-Jobs dynamisch zu konfigurieren, sowie als Umgebungsvariablen, wenn der Job ausgeführt wird.

Vordefinierte Variablen

Eine Reihe von Variablen werden vordefiniert, wenn eine GitLab-CI/CD-Pipeline gestartet wird. Benutzer(innen) können sofort auf Werte für Commit-, Projekt- oder Pipeline-Details zugreifen, ohne die Variablen selbst definieren zu müssen.

Benutzerdefinierte CI/CD-Variablen

Runner können zwei Arten von benutzerdefinierten CI/CD-Variablen erstellen: Typ und Datei.

Wenn eine CI/CD-Variable in den Einstellungen erstellt wird, gibt GitLab den Benutzer(innen) mehr Konfigurationsmöglichkeiten für die Variable. Verwende diese zusätzlichen Konfigurationsoptionen für eine strengere Kontrolle sensibler Variablen:

Geltungsbereich: Umgebung: Wenn eine Variable nur in einer bestimmten Umgebung verwendet werden soll, konfiguriere sie so, dass sie nur in dieser Umgebung verfügbar ist. Du kannst beispielsweise festlegen, dass ein Bereitstellungstoken nur in der Umgebung production verfügbar ist.

Geschützte Variablen: Ähnlich wie bei der Option „Geltungsbereich: Umgebung“ kann eine Variable so konfiguriert werden, dass sie nur verfügbar ist, wenn die Pipeline in einem geschützten Branch ausgeführt wird, z. B. in deinem Standard-Branch.

Variablentyp: Für einige Anwendungen musst du die Konfiguration in Form einer Datei übergeben. Wenn du eine Anwendung hast, die diese Konfiguration erfordert, lege den Variablentyp einfach auf „Datei“ fest. Wenn die CI/CD-Variable auf diese Weise konfiguriert wird, schreibt der Runner die Variable in eine temporäre Datei und speichert den Pfad zu dieser Datei als Wert, wenn er sie in der Umgebung verfügbar macht. Als Nächstes können die Benutzer(innen) den Pfad zu der Datei an alle Anwendungen weitergeben, die sie benötigen.

Zusätzlich zu den genannten Methoden zur Definition und Verwendung von Variablen hat GitLab eine Funktion eingeführt, die vorgefertigte Variablen generiert, wenn eine Pipeline manuell ausgeführt werden muss. Vorgefertigte Variablen reduzieren die Fehlerwahrscheinlichkeit und erleichtern die Bedienung der Pipeline.

Maskierte Variablen: Maskierte Variablen sind CI-Variablen, die in Job-Protokollen maskiert wurden, um zu verhindern, dass der Wert der Variablen angezeigt wird.

Maskierte und versteckte Variablen: Die in GitLab 17.4 eingeführten maskierten und versteckten Variablen bieten die gleiche Maskierungsfunktion für Job-Protokolle und verstecken den Wert in der Einstellungsoberfläche. Wir empfehlen, keine dieser Variablen für sensible Daten (z. B. Geheimnisse) zu verwenden, da diese versehentlich offengelegt werden könnten.

Geheimnisse

Geheimnisse sind sensible Zugangsdaten, die vertraulich behandelt werden sollten. Beispiele für Geheimnisse sind

  • Passwörter
  • SSH-Schlüssel
  • Zugriffstoken
  • Alle anderen Arten von Zugangsdaten, deren Offenlegung für ein Unternehmen schädlich wäre.

GitLab ermöglicht es seinen Benutzer(innen) derzeit mit Hilfe von HashiCorp Vault, Google Cloud Secret Manager und Azure Key Vault, externe Geheimnisse für CI zu verwenden, um Schlüssel, Token und andere Geheimnisse auf Projektebene sicher zu verwalten. So können Benutzer(innen) diese Geheimnisse aus Sicherheitsgründen von anderen CI/CD-Variablen trennen.

GitLab Geheimnismanager

Neben der Unterstützung für externe Geheimnisse in CI arbeitet GitLab auch an der Einführung einer nativen Lösung zur Verwaltung von Geheimnissen, um Geheimnisse sicher und bequem in GitLab zu speichern. Diese Lösung wird Kund(inn)en auch dabei helfen, gespeicherte Geheimnisse in GitLab-spezifischen Komponenten und Umgebungen zu verwenden und den Zugriff auf Namensraum-Gruppen und Projektebene einfach zu verwalten.

Mehr lesen

Haftungsausschlussklausel: Dieser Blog enthält Informationen über kommende Produkte, Funktionen oder Funktionalitäten. Bitte beachte, dass die Informationen in diesem Blogbeitrag nur zu Informationszwecken dienen. Bitte verlasse dich nicht auf diese Informationen, wenn du etwas kaufen oder planen möchtest. Wie bei allen Projekten können sich die in diesem Blog und auf den verlinkten Seiten genannten Punkte ändern oder verzögern. Die Entwicklung, Freigabe und der Zeitplan von Produkten, Funktionen oder Funktionalitäten liegen im alleinigen Ermessen von GitLab.

Wir möchten gern von dir hören

Hat dir dieser Blogbeitrag gefallen oder hast du Fragen oder Feedback? Erstelle ein neues Diskussionsthema im GitLab Community-Forum und tausche deine Eindrücke aus. Teile dein Feedback

Bist du bereit?

Sieh dir an, was dein Team mit einer einheitlichen DevSecOps-Plattform erreichen könnte.

Kostenlose Testversion anfordern

Finde heraus, welcher Tarif für dein Team am besten geeignet ist

Erfahre mehr über die Preise

Erfahre mehr darüber, was GitLab für dein Team tun kann

Sprich mit einem Experten/einer Expertin