Integration von CI/CD mit Snowflake CLI¶

Snowflake CLI integriert sich in beliebte CI-/CD-Plattformen (Continuous Integration und Continuous Delivery), sodass Sie Snowflake-Bereitstellungen fürDCM -Projekte, Snowpark-Anwendungen,|native-apps| und eigenständige SQL -Skripte automatisieren können. Snowflake veröffentlicht und verwaltet Erstanbieter-Integrationen für die am häufigsten verwendeten CI-/CD-Systeme. Für jede Plattform, die einen Shell-Befehl ausführen kann, können Sie Snowflake CLI auch direkt installieren.

Informationen für breitere DevOps-Konzepte wie deklaratives Objektmanagement und Umgebungsstrategie finden Sie unter:doc:/developer-guide/builders/devops-with-snowflake.

Unterstützte CI-/CD-Integrationen¶

Snowflake verwaltet die folgenden First-Party-CI-/CD-Integrationen. Jede Integration installiert Snowflake CLI für den Runner und konfiguriert die Authentifizierung bei Snowflake.


Integration	Status	Authentifizierung (empfohlen)	Referenz
GitHub-Aktion	Öffentliche Vorschau	Workload Identity Federation (OIDC)	Snowflake-CLI-GitHub-Aktion

Bemerkung

Verwenden Sie Jenkins, Bitbucket Pipelines, CircleCI oder ein anderes CI-System, das nicht in der obigen Tabelle aufgeführt ist, können Sie Snowflake CLI mit einem einzigen Shell-Befehl in Ihrer Pipeline installieren. Siehe Installieren von Snowflake CLI auf anderen CI-Systemen.

Grundlegende Snowflake-seitige Einrichtung¶

Alle First-Party-CI-/CD-Integrationen folgen auf Snowflake-Seite dem gleichen Muster:

Erstellen Sie einen Dienstbenutzer, als den sich die Pipeline authentifiziert.
Konfigurieren Sie die Authentifizierungsmethode des Dienstbenutzers. Snowflake empfiehlt die Workload Identity Federation (WIF) mit OpenID Connect (OIDC), damit keine langlebigen Geheimnisse im CI-System gespeichert werden.
Weisen Sie dem Dienstbenutzer die Rollen zu, die er zum Bereitstellen Ihrer Objekte benötigt.

Authentifizieren mit Workload Identity Federation (OIDC)¶

Durch OIDC erhält der CI-Runner ein kurzlebiges Identitätstoken, das Snowflake direkt validiert. Jede CI-Plattform veröffentlicht Token von einem anderen Aussteller mit einem anderen Anspruchsformat. Auf den Referenzseiten der Integration sind die genauen Werte dokumentiert, die verwendet werden sollen.

Eine minimale Dienstbenutzerdefinition sieht wie folgt aus. Ersetzen Sie Werte von ISSUER und SUBJECT mit den von Ihrer CI-Plattform benötigten Werten (siehe die entsprechende Integrationsreferenzseite).

CREATE USER <username>
  TYPE = SERVICE
  WORKLOAD_IDENTITY = (
    TYPE = OIDC
    ISSUER = '<ci-platform-issuer>'
    SUBJECT = '<ci-platform-subject>'
  );

Hintergrund zu SnowflakeWIF finden Sie hier: Workload Identity Federation.

Authentifizieren mit Schlüsselpaar oder Kennwort¶

Wenn OIDC nicht verfügbar ist (z. B. wenn Sie ältere Snowflake CLI-Versionen oder lokale CI-Runners unterstützen müssen), verwenden Sie die Schlüsselpaar-Authentifizierung. Speichern Sie den privaten Schlüssel als CI-Geheimnis und übergeben Sie es durch die Umgebung mit SNOWFLAKE_PRIVATE_KEY_RAW (für eine temporäre Verbindung) oder SNOWFLAKE_CONNECTIONS_<NAME>_PRIVATE_KEY_RAW (für eine benannte Verbindung).

Die Authentifizierung per Kennwort wird für ältere Workflows unterstützt, wird aber nicht für Produktion-CI/-CD empfohlen. Siehe Verwalten von Snowflake-Verbindungen für eine vollständige Liste der Authentifizierungsparameter.

Konfigurationsdateien und Umgebungsvariablen¶

Die meisten CI-CD-Workflows kombinieren ein bestätigtes config.toml mit Geheimnissen, die über Umgebungsvariablen eingefügt werden. Es gelten die folgenden Vorrangregeln:

Befehlszeilenparameter überschreiben alles.
Umgebungsvariablen, die auf einen bestimmten Verbindungsparameter abzielen (z. B. SNOWFLAKE_CONNECTIONS_MYCONNECTION_PASSWORD) überschreiben config.toml.
Werte, die in config.toml definiert sind, werden verwendet, wenn keine Überschreibung gegeben ist.
Allgemeine Umgebungsvariablen, wie SNOWFLAKE_USER werden zuletzt angewendet.

Weitere Details, einschließlich einer vollständigen Parameterreferenz, finden Sie unter Verwalten von Snowflake-Verbindungen.

Installieren von Snowflake CLI auf anderen CI-Systemen¶

Sie können Snowflake CLI für einen beliebigen CI-Snowflake-Runner ausführen, der einen Shell-Befehl ausführen kann. Die kanonische einzeilige Installation verwendet uv:

uv tool install snowflake-cli
snow --version

Installationsoptionen auf bestimmten Betriebssystemen finden Sie unter Installieren von Snowflake CLI. Weitere Informationen zum Verwalten von Verbindungen (einschließlich der Verwendung von Umgebungsvariablen, um das Speichern von Anmeldeinformationen auf dem Runner zu vermeiden) finden Sie unter Verwalten von Snowflake-Verbindungen.

Typische Pipeline-Jobs¶

Die folgende Tabelle ordnet allgemeine CI-/CD-Pipeline-Jobs den Snowflake CLI-Befehlen zu, mit denen sie implementiert werden. Die gleichen Befehle funktionieren von jedem CI-System.


Pipeline-Job	Befehl Snowflake CLI	Beschreibung
Vorschau von Änderungen bei Pull-Anfrage	`snow dcm plan`	Berechnet einen Plan von Erstellungen, Änderungen und Löschungen für die Zielumgebung. Veröffentlichen Sie die Ausgabe als PR-Kommentar zur Überprüfung.
Bei Zusammenführung bereitstellen	`snow dcm deploy`	Wendet einen zuvor geplanten Satz von Änderungen auf die Zielumgebung an.
Snowpark oder SQL-Skripte ausführen	`snow sql -f <file>`, `snow snowpark deploy`	Führt skriptbasierte Bereitstellungen für Objekte aus, die noch nicht von DCM abgedeckt sind.
Ein Git-Repository-Objekt einrichten	`snow git execute`	Führt SQL-Dateien direkt aus einer Snowflake-Git-Integration aus.

Sicherheitsempfehlungen¶

Nutzen Sie Workload Identity Federation (OIDC) überall dort, wo IhrCI-System dies unterstützt. Vermeiden Sie das Speichern von langlebigen Anmeldeinformationen inCI-Geheimnissen.
Erstellen Sie einen dedizierten Dienstbenutzer für jede Pipeline-Umgebung (z. B. einen Benutzer pro Repository oder pro Umgebung). Weisen Sie nur die für diese Pipeline erforderlichen Rollen zu.
Verwenden Sie möglichst Steuern des Netzwerkdatenverkehrs mit Netzwerkrichtlinien, um einzuschränken, welche Quellen-IPs sich als Dienstbenutzer authentifizieren können.
Nehmen Sie kein Commit von config.toml-Dateien vor, die Anmeldeinformationen enthalten. Übergeben Sie nur den Verbindungs-Skeleton und stellen Sie Geheimnisse über Umgebungsvariablen bereit.
Rotieren Sie private Schlüssel und Kennwörter regelmäßig, wenn Sie OIDC nicht übernehmen können.