En el post anterior repasamos varias funcionalidades de DevOps en Snowflake. Son los bloques individuales que te permiten mantener tu infraestructura de Snowflake como código y hacerlo de forma automática.
En este post nos vamos a enfocar en cómo combinar esas funcionalidades para crear pipelines de CI/CD que desplieguen automáticamente la infraestructura de Snowflake, apoyándonos en funcionalidades nativas como CREATE OR ALTER, la integración con Git o EXECUTE IMMEDIATE FROM. Usamos GitHub como servicio de repositorio y GitHub Actions como orquestador.
Empecemos con una breve introducción a los workflows de GitHub Actions.
Workflows de GitHub Actions
GitHub Actions es una potente plataforma de CI/CD integrada directamente en GitHub que permite a los desarrolladores automatizar workflows de software mediante pipelines basados en eventos. Se basa en el concepto de workflows definidos en archivos YAML, almacenados en el directorio .github/workflows/ de tu repositorio. Cada workflow puede contener uno o más jobs que se ejecutan en máquinas virtuales llamadas runners. Estos runners los puede alojar GitHub, así que no tienes que administrar nada. Se asigna un runner automáticamente a tu pipeline cuando se dispara el workflow, o puedes usar un runner autoalojado.
Para crear un pipeline tienes que definir varios elementos clave:
Trigger
Puede ser un evento del repositorio (por ejemplo, push, pull_request, etc.), un cron job programado o un disparador manual.
Entorno del runner
Define dónde se ejecutará tu código, es decir, el sistema operativo del runner. Algunos ejemplos comunes son ubuntu-latest o windows-latest.
Estructura de la automatización
Luego tienes que definir la automatización en sí. Es una serie de pasos que se ejecutan en orden. Ten en cuenta que cada vez que corre tu código, la máquina runner arranca en un estado limpio por defecto. Eso significa que tienes que preparar el entorno para tu job específico: instalar los lenguajes necesarios (por ejemplo, Python), traer el código desde tu repositorio y leer las variables de entorno. Cada paso puede consistir en comandos de shell, ejecución de scripts o acciones predefinidas, y también puede aprovechar información contextual como ${{ github.event_name }} o ${{ secrets.SF_ACCOUNT_ID }}.
Estas características básicas hacen que GitHub Actions sea ideal para correr distintos pipelines de CI/CD en los que necesitas gestionar credenciales de bases de datos de forma segura, ejecutar scripts SQL, desplegar cambios entre entornos y llevar un registro de quién hizo cada cambio, todo con la integración de control de versiones incorporada.
Pipeline de CI/CD en Snowflake para infraestructura de cuenta
Vamos a trabajar en local con VS Code, donde desarrollaremos los scripts SQL y la definición YAML del workflow de GitHub Actions. Cuando todo esté listo, haremos push de los cambios al repositorio remoto, abriremos un pull request y haremos merge a nuestra rama dev. Como se ve en el diagrama, aprovecharemos varias funcionalidades de Snowflake para lograrlo. Además, crearemos dos versiones del pipeline de CI/CD:
1 Usando la extensión Git en Snowflake En este enfoque, GitHub Actions actúa solo como orquestador. Gracias a la extensión Git, podemos ejecutar todo el código directamente dentro de Snowflake.
2 Ejecutando el código en un runner de GitHub con SnowCLI Si prefieres no usar la extensión Git en Snowflake, hay una alternativa: ejecutar el código directamente en la máquina runner usando la Snowflake Command Line Interface (SnowCLI). También vamos a cubrir esa opción.
Creación de la infraestructura en Snowflake
Empecemos por crear nuestra infraestructura y guardémosla en varios archivos sql.
Nuestros 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;
También necesitamos un rol:
/*
* Role name: LOADER
* Description: Used by ELT pipelines to load data */
*/
USE ROLE securityadmin;
CREATE OR ALTER ROLE loader;
Y por último nuestra base de datos y schema:
/*
* 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
*/
Expandir código
Pipeline de CI/CD usando el Git Stage
Ya tenemos listos los scripts SQL iniciales, así que ahora toca desarrollar el workflow de GitHub Actions. Este workflow se apoya en la extensión Git en Snowflake y requiere una integración activa entre tu cuenta de Snowflake y tu repositorio de GitHub. Ya cubrimos cómo configurar esta integración en un post dedicado a la integración de Git en 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:
Expandir código
Repasemos el código para explicar qué hace.
Al inicio se configuran las variables de entorno necesarias para conectarse a Snowflake. Estos valores se obtienen desde GitHub Secrets. Después definimos el trigger; en este caso usamos workflow_dispatch, lo que significa que el workflow debe dispararse manualmente desde el repositorio.
El resto es bastante directo. Tenemos que instalar SnowCLI en la máquina runner de GitHub para poder:
- conectarnos a Snowflake
- disparar los comandos necesarios
Existe una GitHub Action nativa que provee Snowflake y que simplifica la configuración y la gestión de la conexión.
Primero, sincronizamos el stage del repositorio Git de Snowflake con el repositorio remoto usando el comando ALTER GIT REPOSITORY. De este modo se traen los últimos cambios directamente al stage de Git dentro de Snowflake.
Después usamos EXECUTE IMMEDIATE para correr el código directamente desde nuestros archivos SQL. Vamos a desplegar warehouses, roles y bases de datos con sus schemas. Y eso es todo: un workflow simple y efectivo para desplegar automáticamente los cambios a tu infraestructura de Snowflake como código.
Pipeline de CI/CD ejecutando el código en el runner de GitHub
Vamos a armar un pipeline parecido, pero esta vez ejecutamos todo directamente en la máquina runner de GitHub, sin usar el stage Git de Snowflake. Aunque el stage Git es una funcionalidad poderosa, tiene algunas limitaciones: es de solo lectura y no puede acceder a repositorios detrás de redes privadas. Esas restricciones pueden ser motivo suficiente para no usar la integración Git de Snowflake en ciertos escenarios. Esta es nuestra definición de workflow en 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
Expandir código
Veamos las diferencias respecto a la versión anterior. Esta vez tenemos que traer el código desde el repositorio remoto hasta la máquina runner. Para eso usamos otra acción llamada checkout, que básicamente trae el código desde el remoto.
Después podemos volver a usar SnowCLI, pero esta vez ejecutamos el código desde los archivos almacenados en la máquina runner en lugar de los archivos del stage del repositorio.
Mejoras
Este fue un ejemplo simple de cómo armar un pipeline básico de CI/CD para desplegar infraestructura de Snowflake. Hay mucho margen para llevarlo a un nivel más "production ready". En un entorno real tendrías:
- pipelines distintos para cada entorno (dev, prod)
- triggers en eventos push y pull request limitados a ramas específicas
- pasos distintos para los eventos push y los pull request
Sería genial contar con un paso de "plan", como en Terraform, que muestre qué recursos se van a crear, actualizar o eliminar antes de aplicar los cambios. Ojalá veamos algo similar en estas funcionalidades nativas de Snowflake.
Para cerrar
En este post vimos cómo usar las funcionalidades nativas de DevOps de Snowflake para integración y despliegue continuos. Implementamos un pipeline de CI/CD con un workflow de GitHub Actions para desplegar objetos de infraestructura de Snowflake como código directamente desde nuestro repositorio remoto, simplemente haciendo push de las actualizaciones desde nuestras máquinas locales al repo.
Esta es la parte final de nuestra serie dedicada a hacer DevOps en Snowflake. Cubrimos el tema en tres posts:
- Análisis profundo de la integración Git de Snowflake
- CI/CD y DevOps en Snowflake (Parte 1): Resumen completo de funcionalidades y herramientas
- CI/CD y DevOps en Snowflake (Parte 2): Guía de implementación paso a paso
Tomáš Sobotík·Senior Data Engineer & Snowflake SME en Norlys
Tomas es un Snowflake Data SuperHero de larga trayectoria y un referente en temas de Snowflake. Su experiencia en el mundo de los datos abarca más de una década, durante la cual se ha desempeñado como data engineer, arquitecto y admin de Snowflake en proyectos de diversas industrias y tecnologías. Es un miembro activo de la comunidad, que comparte su conocimiento e inspira a otros. También es instructor de O'Reilly, donde dicta sesiones de capacitación en vivo online.