Dans le précédent article, nous avons passé en revue les différentes fonctionnalités DevOps de Snowflake. Elles constituent autant de briques élémentaires pour gérer votre infrastructure Snowflake as code, de manière entièrement automatisée.
Dans cet article, nous verrons comment combiner ces fonctionnalités pour bâtir des pipelines CI/CD qui déploient automatiquement l'infrastructure Snowflake en s'appuyant sur des capacités natives telles que CREATE OR ALTER, l'intégration Git ou EXECUTE IMMEDIATE FROM. GitHub nous sert de service de dépôt et GitHub Actions d'orchestrateur.
Commençons par une brève introduction aux workflows GitHub Actions.
Les workflows GitHub Actions
GitHub Actions est une plateforme CI/CD puissante intégrée directement à GitHub, qui permet aux développeurs d'automatiser leurs workflows logiciels via des pipelines déclenchés par événement. Elle repose sur des workflows définis dans des fichiers YAML, stockés dans le répertoire .github/workflows/ de votre dépôt. Chaque workflow peut comporter un ou plusieurs jobs exécutés sur des machines virtuelles appelées runners. Ces runners peuvent être hébergés par GitHub, ce qui vous évite toute gestion d'infrastructure. Un runner est automatiquement affecté à votre pipeline au déclenchement du workflow, à moins que vous ne préfériez utiliser un runner auto-hébergé.
Pour créer un pipeline, plusieurs éléments clés doivent être définis :
Le déclencheur
Il peut s'agir d'un événement dans le dépôt (par exemple push, pull_request, etc.), d'une tâche cron planifiée ou d'un déclenchement manuel.
L'environnement d'exécution
Il définit l'endroit où votre code s'exécutera, autrement dit le système d'exploitation du runner. On utilise couramment ubuntu-latest ou windows-latest.
La structure d'automatisation
Vous devez ensuite définir l'automatisation à proprement parler, c'est-à-dire la suite d'étapes à exécuter. Gardez à l'esprit qu'à chaque exécution, la machine runner démarre dans un état par défaut, vierge. Vous devez donc préparer l'environnement pour votre job : installer les langages requis (Python par exemple), récupérer le code depuis votre dépôt, lire les variables d'environnement, etc. Chaque étape peut consister en des commandes shell, l'exécution de scripts ou des actions prédéfinies. Les étapes peuvent également tirer parti d'informations contextuelles, comme ${{ github.event_name }} ou ${{ secrets.SF_ACCOUNT_ID }}.
Ces caractéristiques font de GitHub Actions une plateforme particulièrement adaptée à l'exécution de pipelines CI/CD variés, dès lors qu'il faut gérer en toute sécurité des identifiants de base de données, exécuter des scripts SQL, déployer des changements sur plusieurs environnements et tracer les auteurs des modifications, le tout avec une intégration native du contrôle de version.
Pipeline CI/CD Snowflake pour l'infrastructure de compte
Nous allons travailler en local dans VS Code, où nous développerons les scripts SQL ainsi que la définition YAML du workflow GitHub Actions. Une fois tout prêt, nous pousserons les modifications vers le dépôt distant, créerons une pull request et fusionnerons les changements dans notre branche dev. Comme le montre le schéma, nous nous appuierons sur plusieurs fonctionnalités Snowflake pour y parvenir. Nous créerons également deux versions du pipeline CI/CD :
1 Via l'extension Git dans Snowflake Dans cette approche, GitHub Actions n'agit que comme orchestrateur. Grâce à l'extension Git, tout le code peut s'exécuter directement dans Snowflake.
2 Via l'exécution du code sur un runner GitHub avec SnowCLI Si vous préférez ne pas utiliser l'extension Git dans Snowflake, il existe une alternative : exécuter le code directement sur la machine runner à l'aide de la Snowflake Command Line Interface (SnowCLI). Nous aborderons aussi cette option.
Création de l'infrastructure Snowflake
Créons d'abord notre infrastructure et stockons-la dans plusieurs fichiers sql.
Nos warehouses :
USE ROLE sysadmin;
--ELT warehouse definition
CREATE WAREHOUSE IF NOT EXISTS elt WITH
WAREHOUSE_SIZE = XSMALL
AUTO_SUSPEND = 60
AUTO_RESUME = True
INITIALLY_SUSPENDED = True;
--developers warehouse definition
CREATE WAREHOUSE IF NOT EXISTS developers WITH
WAREHOUSE_SIZE = SMALL
AUTO_SUSPEND = 120
AUTO_RESUME = True
INITIALLY_SUSPENDED = True;
Il nous faut également un rôle :
/*
* Role name: LOADER
* Description: Used by ELT pipelines to load data */
*/
USE ROLE securityadmin;
CREATE OR ALTER ROLE loader;
Et enfin notre base de données et notre schéma :
/*
* DB name: DEVOPS
* Description: Used for showcasing Snowflake DevOps capabilities
*/
use role sysadmin;
create or alter database devops;
------------------------SCHEMAS------------------------
/*
* Schema name: ADMIN
* Description: To keep all admin stuff at one place
*/
Expand Code
Pipeline CI/CD reposant sur le stage Git
Les scripts SQL initiaux sont prêts ; passons maintenant au développement du workflow GitHub Actions. Ce workflow s'appuie sur l'extension Git dans Snowflake. Il nécessite une intégration active entre votre compte Snowflake et votre dépôt GitHub. Nous avons détaillé la mise en place de cette intégration dans un article dédié à l'intégration Git de Snowflake.
name: Deploying Snowflake objects with CLI v1
env:
SNOWFLAKE_ACCOUNT: ${{ secrets.SF_ACCOUNT }}
SNOWFLAKE_USER: ${{ secrets.SF_USER }}
SNOWFLAKE_PASSWORD: ${{ secrets.SF_PASSWORD }}
SNOWFLAKE_DATABASE: ${{ secrets.SF_DATABASE }}
SNOWFLAKE_SCHEMA: ${{ secrets.SF_SCHEMA }}
SNOWFLAKE_ROLE: ${{ secrets.SF_ROLE }}
SNOWFLAKE_WAREHOUSE: ${{ secrets.SF_WAREHOUSE }}
on:
workflow_dispatch:
jobs:
deploy-Snowflake-changes:
Expand Code
Parcourons ce code pour en détailler le fonctionnement.
Au début, nous configurons les variables d'environnement nécessaires à la connexion à Snowflake. Ces valeurs sont récupérées depuis GitHub Secrets. Nous définissons ensuite le déclencheur : ici, nous utilisons workflow_dispatch, ce qui signifie que le workflow doit être lancé manuellement depuis le dépôt.
Le reste est relativement simple. Nous devons installer SnowCLI sur la machine runner GitHub afin de pouvoir :
- nous connecter à Snowflake
- déclencher les commandes requises
Snowflake fournit une GitHub Action native qui simplifie la configuration et la gestion de la connexion.
Nous commençons par synchroniser notre stage de dépôt Git Snowflake avec le dépôt distant grâce à la commande ALTER GIT REPOSITORY. Les dernières modifications sont ainsi récupérées directement dans le stage Git de Snowflake.
Nous utilisons ensuite EXECUTE IMMEDIATE pour exécuter le code directement depuis nos fichiers SQL. Nous déploierons les warehouses, les rôles, ainsi que les bases de données et leurs schémas. Et voilà un workflow simple et efficace pour déployer automatiquement les changements de votre infrastructure Snowflake as code.
Pipeline CI/CD exécutant le code sur le runner GitHub
Construisons un pipeline similaire, mais cette fois tout sera exécuté directement sur la machine runner GitHub, sans recourir au stage Git de Snowflake. Bien que le stage Git soit une fonctionnalité puissante, il présente encore quelques limites : il est en lecture seule et inaccessible aux dépôts situés derrière des réseaux privés. Ces contraintes peuvent justifier, dans certains contextes, de se passer de l'intégration Git de Snowflake. Voici notre définition de workflow YAML :
name: Deploying Snowflake objects with cli v2
env:
SNOWFLAKE_ACCOUNT: ${{ secrets.SF_ACCOUNT }}
SNOWFLAKE_USER: ${{ secrets.SF_USER }}
SNOWFLAKE_PASSWORD: ${{ secrets.SF_PASSWORD }}
SNOWFLAKE_DATABASE: ${{ secrets.SF_DATABASE }}
SNOWFLAKE_SCHEMA: ${{ secrets.SF_SCHEMA }}
SNOWFLAKE_ROLE: ${{ secrets.SF_ROLE }}
SNOWFLAKE_WAREHOUSE: ${{ secrets.SF_WAREHOUSE }}
on:
workflow_dispatch:
jobs:
deploy-Snowflake-changes:
name: Snowflake infrastructure deployment
Expand Code
Concentrons-nous sur les différences par rapport à la version précédente. Cette fois, il faut rapatrier notre code depuis le dépôt distant vers la machine runner. Pour cela, nous utilisons une autre action appelée checkout, qui se charge de récupérer le code depuis le dépôt distant.
Nous pouvons ensuite réutiliser SnowCLI, mais cette fois en exécutant le code à partir des fichiers stockés sur la machine runner plutôt que depuis ceux du stage du dépôt.
Pistes d'amélioration
Voici un exemple simple de développement d'un pipeline CI/CD basique pour déployer une infrastructure Snowflake. La marge de progression vers un usage production ready reste importante. Dans un environnement réel, vous auriez :
- des pipelines distincts pour chaque environnement (dev, prod)
- des déclencheurs sur les événements push et pull request limités à des branches spécifiques
- des étapes différentes selon qu'il s'agit d'un push ou d'une pull request
Il serait également judicieux de disposer d'une étape plan, à l'image de Terraform, qui indique quelles ressources seront créées, mises à jour ou supprimées avant d'appliquer les changements. Espérons voir une fonctionnalité similaire arriver dans les capacités natives de Snowflake.
Pour conclure
Cet article a montré comment exploiter les fonctionnalités DevOps natives de Snowflake pour l'intégration et le déploiement continus. Nous avons mis en place un pipeline CI/CD via un workflow GitHub Actions afin de déployer les objets d'infrastructure Snowflake as code directement depuis notre dépôt distant, simplement en poussant les mises à jour depuis nos machines locales.
Il s'agit du dernier volet de notre série consacrée au DevOps dans Snowflake. Nous avons traité ce sujet à travers trois articles :
- Plongée au cœur de l'intégration Git de Snowflake
- CI/CD et DevOps dans Snowflake (Partie 1) : panorama complet des fonctionnalités et des outils
- CI/CD et DevOps dans Snowflake (Partie 2) : guide d'implémentation pas à pas
Tomáš Sobotík·Senior Data Engineer & Snowflake SME chez Norlys
Tomas est un Snowflake Data SuperHero de longue date et un expert reconnu de Snowflake. Son expérience dans le monde de la data couvre plus d'une décennie, durant laquelle il a occupé les rôles de Snowflake data engineer, architecte et administrateur sur des projets variés, dans des secteurs et autour de technologies très diverses. Membre actif de la communauté, Tomas partage son expertise sans relâche et inspire ses pairs. Il est également formateur O'Reilly et anime des sessions de formation en direct en ligne.