DevOps avec Snowflake¶

Projets DCM (recommandé)¶

Les projets DCM (Database Change Management Projets) fournissent une approche déclarative, basée sur l’infrastructure, pour gérer votre environnement Snowflake. Au lieu d’écrire des scripts impératifs qui spécifient chaque étape, vous définissez l’état cible souhaité de vos objets. Snowflake compare ces définitions à l’état actuel et détermine les changements nécessaires.

Un projet DCM se compose de :

• Un fichier manifeste (manifest.yml ) qui spécifie les cibles de déploiement, les rôles du propriétaire et les configurations de modélisation pour chaque environnement.

• Fichiers de définition (fichiers SQL sous``sources/definitions/``) fichiers qui contiennent les instructions DEFINE pour vos objets Snowflake, les instructions GRANT pour le contrôle d’accès, et les instructions ATTACH pour les attentes en matière de qualité des données.

L’exemple suivant montre un fichier de définition qui crée une infrastructure pour plusieurs équipes utilisant la modélisation Jinja2 :

{% for team in teams %}

  DEFINE DATABASE {{team.name}}_DB;

  DEFINE WAREHOUSE {{team.name}}_WH
    WITH
      warehouse_size = '{{team.wh_size}}'
      auto_suspend = 300;

  DEFINE ROLE {{team.name}}_ADMIN;

  GRANT OWNERSHIP ON DATABASE {{team.name}}_DB TO ROLE {{team.name}}_ADMIN;
  GRANT OWNERSHIP ON WAREHOUSE {{team.name}}_WH TO ROLE {{team.name}}_ADMIN;

{% endfor %}

Pour une documentation complète sur les projets DCM, y compris comment configurer vos fichiers de projet, gérer plusieurs environnements et automatiser des déploiements, voir:doc:/user-guide/dcm-projects/dcm-projects-overview.

Projets dbt sur Snowflake¶

Les projets dbt sur Snowflake vous permettent de déployer et d’exécuter les projets ` dbt Core<https://www.getdbt.com/>`__ en tant qu’objets Snowflake natifs. Vous définissez des transformations SQL dans les modèles dbt, vous les déployez en tant qu’objet DBTPROJECT versionné et les exécutez avec Snowflake SQL ou la CLI de Snowflake. Vous pouvez planifier des exécutions avec des tâches Snowflake et intégrer le déploiement dans des pipelines CI/CD.

Pour plus d’informations, voir Projets dbt sur Snowflake.

Alternative : CREATEORALTER avec scripts versionnés¶

Pour les modifications d’objet individuels en dehors d’un projet DCM, vous pouvez utiliser la commande CREATE OR ALTER <objet> qui crée l’objet ou le modifie pour qu’il corresponde à la définition spécifiée par la commande. En utilisant cette commande à partir d’un fichier versionné dans un référentiel distant, vous pouvez revenir à une version antérieure en exécutant une version précédente du fichier.

CREATE OR ALTER TABLE vacation_spots (
  city VARCHAR,
  airport VARCHAR,
  avg_temperature_air_f FLOAT,
  avg_relative_humidity_pct FLOAT,
  avg_cloud_cover_pct FLOAT,
  precipitation_probability_pct FLOAT
) data_retention_time_in_days = 1;

from snowflake.core import Root
from snowflake.core.table import PrimaryKey, Table, TableColumn

my_table = root.databases["my_db"].schemas["my_schema"].tables["vacation_spots"].fetch()
my_table.columns.append(TableColumn(name="city", datatype="varchar", nullable=False))
my_table.columns.append(TableColumn(name="airport", datatype="varchar", nullable=False))
my_table.columns.append(TableColumn(name="avg_temperature_air_f", datatype="float", nullable=False))
my_table.columns.append(TableColumn(name="avg_relative_humidity_pct", datatype="float", nullable=False))
my_table.columns.append(TableColumn(name="avg_cloud_cover_pct", datatype="float", nullable=False))
my_table.columns.append(TableColumn(name="precipitation_probability_pct", datatype="float", nullable=False))

my_table_res = root.databases["my_db"].schemas["my_schema"].tables["vacation_spots"]
my_table_res.create_or_alter(my_table)

Planifier avec des projets DCM¶

Les projets DCM utilisent un modèle de planification, puis de déploiement. La commande PLAN compare vos fichiers de définition à l’état actuel de votre compte et produit une liste des changements proposés sans modifier quoi que ce soit.

Vous pouvez exécuter un plan à l’aide de la CLI Snowflake :

snow dcm plan --target PROD

Ou à l’aide de SQL :

EXECUTE DCM PROJECT my_db.my_schema.my_project
  PLAN
  USING CONFIGURATION PROD
FROM
  '@my_stage/my_project/';

Examinez la sortie pour confirmer les créations, les modifications et les suppressions attendues avant de poursuivre le déploiement.

Actions GitHub¶

Vous pouvez utiliser GitHub Actions pour automatiser les tâches qui constituent un pipeline CI/CD.

Pour une authentification sécurisée, Snowflake recommande d’utiliser la fédération d’identité de charge de travail (WIF) avecOpenID Connect (OIDC) au lieu d’identifiants statiques comme des mots de passe ou des clés privées. Avec WIFOIDC, GitHub Actions demande un jeton de courte durée de vie auprès du fournisseur OIDC de GitHub, et Snowflake vérifie le jeton directement. Aucun secret à longue durée de vie n’est stocké dans votre référentiel.

Pour configurer WIFOIDC, créez un utilisateur de service Snowflake qui fait confiance au fournisseur OIDC de GitHub :

CREATE USER github_deployer
  TYPE = SERVICE
  DEFAULT_ROLE = deployer_role
  WORKLOAD_IDENTITY = (
    TYPE = OIDC
    ISSUER = 'https://token.actions.githubusercontent.com'
    SUBJECT = 'repo:<owner>/<repo>:environment:<environment_name>'
  );

Pour plus d’informations sur la configuration de la revendication de sujet et la WIF en général, voir:doc:/user-guide/workload-identity-federation.

L’exemple suivant montre un workflow qui utilise WIFOIDC et les projets DCM pour planifier et déployer les changements sur push à la branche main :

name: Deploy DCM project to production

on:
  push:
    branches:
      - main

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          persist-credentials: false

      - name: Set up Snowflake CLI
        uses: snowflakedb/snowflake-cli-action@v2
        with:
          use-oidc: true
          cli-version: "3.11"

      - name: Plan DCM project
        env:
          SNOWFLAKE_ACCOUNT: ${{ secrets.SNOWFLAKE_ACCOUNT }}
        run: snow dcm plan --target PROD --save-output -x

      - name: Deploy DCM project
        env:
          SNOWFLAKE_ACCOUNT: ${{ secrets.SNOWFLAKE_ACCOUNT }}
        run: snow dcm deploy --target PROD -x

Pour plus d’informations sur la configuration de CI/CD avec la CLI Snowflake, y compris les méthodes d’authentification alternatives, voir:doc:/developer-guide/snowflake-cli/cicd/integrate-ci-cd.

Profils de connexion pour le ciblage d’environnement¶

Avec les projets DCM, vous pouvez définir plusieurs cibles de déploiement dans votre fichier manifest.yml. Chaque cible correspond à un compte Snowflake (ou base de données), à un objet de projet, à un rôle de propriétaire et à une configuration de modèle spécifiques. Les mêmes fichiers de définition peuvent être déployés dans tous les environnements dont les paramètres spécifiques à l’environnement sont appliqués par le biais de profils de configuration.

targets:
  DEV:
    account_identifier: MYORG-MYACCOUNT_DEV
    project_name: MY_DB.MY_SCHEMA.MY_PROJECT_DEV
    project_owner: DEV_DEPLOYER
    templating_config: DEV

  PROD:
    account_identifier: MYORG-MYACCOUNT_PROD
    project_name: MY_DB.MY_SCHEMA.MY_PROJECT_PROD
    project_owner: PROD_DEPLOYER
    templating_config: PROD

templating:
  configurations:
    DEV:
      wh_size: "X-SMALL"
    PROD:
      wh_size: "LARGE"

Pour les modèles d’entreprise tels que les configurations de multi-projets et la collaboration en équipe, voir:doc:/user-guide/dcm-projects/dcm-projects-enterprise.

Avancé : Paramétrage Jinja pour les scripts personnalisés¶

Les projets DCM prennent en charge nativement la création de modèles Jinja2 dans les fichiers de définition. Vous pouvez utiliser des variables de modèle, des boucles, des conditions, des macros et des dictionnaires pour rendre vos définitions réutilisables dans tous les environnements. Les valeurs des variables proviennent de profils de configuration dans le fichier manifest.yml ou de remplacements de l’environnement d’exécution.

Pour plus de détails sur les modèles DCM, voir:doc:/user-guide/dcm-projects/dcm-projects-files .

Vous pouvez également paramétrer des scripts SQL autonomes (en dehors de projets DCM) utilisant Jinja2 avec EXECUTE IMMEDIATE FROM. La CLI Snowflake vous permet également de transmettre des variables d’environnement aux scripts Python.

Pour modifier une cible de déploiement, par exemple, vous remplacez le nom de la base de données cible par une variable Jinja telle que {{ environment }} dans les scripts SQL, ou une variable d’environnement dans les scripts Python. Cette technique est illustrée dans les exemples de code Python et SQL suivants :

CREATE OR ALTER TASK {{ environment }}.my_schema.my_task
  WAREHOUSE = my_warehouse
  SCHEDULE = '60 minute'
  AS select pi();

import os
from snowflake.core import Root, CreateMode
from datetime import timedelta
from snowflake.core.task import Task

my_task = Task(
    name="my_task",
    warehouse="my_warehouse",
    definition="select pi()",
    schedule=timedelta(minutes=60)
)
root = Root(Session.builder.getOrCreate())
tasks = root.databases[os.environ["environment"]].schemas["my_schema"].tasks
tasks.create(my_task, mode=CreateMode.or_replace)