Technical Tutorials

Dans le paysage en rapide évolution de l'ingénierie des données et du DevOps, l'orchestration de workflows est devenue un composant critique de toute pile technique robuste. Alors que des géants comme Apache Airflow et Prefect dominent les discussions, un nouveau joueur fait sensation grâce à sa conception centrée sur le développeur et sa simplicité : Kestra. Kestra est une plateforme universelle d'orchestration et de planification qui permet aux développeurs de définir les workflows comme du code. Contrairement aux outils traditionnels qui reposent lourdement sur des représentations complexes de DAG (Directed Acyclic Graph) en Python ou en Java, Kestra utilise le YAML pour les définitions de workflow. Cette approche offre un mélange unique d'accessibilité pour les analystes de données et de puissance pour les ingénieurs logiciels.

Pourquoi choisir Kestra ?

Le principal différenciateur de Kestra est sa philosophie de « l'infrastructure en tant que code » appliquée aux workflows de données. En définissant l'intégralité de votre pipeline dans un seul fichier YAML, vous obtenez plusieurs avantages clés : 1. **Simplicité et lisibilité** : Le YAML est lisible par les humains. Un job ETL complexe peut être compris en un coup d'œil, réduisant la charge cognitive lors de l'intégration ou du débogage. 2. **Intégration native** : Kestra se connecte nativement à des centaines d'outils, notamment PostgreSQL, Kafka, Slack, S3 et AWS, réduisant ainsi le besoin de code boilerplate personnalisé. 3. **Reproductibilité** : Puisque le workflow est du code, il peut être versionné, testé et déployé via des pipelines CI/CD comme n'importe quelle autre application. 4. **Pas de verrouillage fournisseur** : Kestra est open-source, vous permettant de l'héberger vous-même sur n'importe quelle infrastructure, des environnements Docker locaux aux clusters Kubernetes.

Concepts clés : Tâches et Flux

Dans Kestra, tout tourne autour du concept de Flux (Flow). Un flux est un ensemble de tâches exécutées dans un ordre spécifique. Les tâches sont les unités atomiques de travail, telles que l'exécution d'une requête SQL, la copie d'un fichier ou le déclenchement d'une API. Contrairement à Airflow, où vous définissez les tâches en Python et les liez avec des opérateurs logiques, Kestra vous permet de définir l'ordre d'exécution directement dans la structure YAML. Cette approche déclarative minimise les erreurs et rend le chemin d'exécution explicite.

Pour commencer : Un exemple pratique

Regardons un exemple pratique. Imaginez un job ETL simple qui extrait des données d'un fichier CSV, les transforme à l'aide d'une requête SQL et charge le résultat dans une base de données PostgreSQL. Voici comment vous définiriez cela dans Kestra :

id: simple_etl
namespace: com.example

tasks:
  - id: extract
    type: io.kestra.plugin.csv.Extract
    resource: "s3://my-bucket/data/input.csv"

  - id: transform
    type: io.kestra.plugin.jdbc.postgresql.Query
    sql: |
      SELECT 
        customer_id, 
        SUM(order_amount) as total_spent
      FROM raw_data
      GROUP BY customer_id
    
  - id: load
    type: io.kestra.plugin.jdbc.postgresql.Insert
    table: monthly_sales_summary
    from: "{{ outputs.transform.outputs }}"

  - id: notify
    type: io.kestra.plugin.slack.SlackWebhook
    title: "ETL Job Completed"
    channel: "#data-alerts"
    text: "Successfully loaded data into {{ flow.namespace }}.{{ flow.id }}"

Dans cet extrait : - La tâche extract récupère les données depuis un bucket S3. - La tâche transform exécute une requête d'agrégation SQL contre votre instance PostgreSQL. - La tâche load prend la sortie de la tâche de transformation et l'insère dans une table de résumé. Notez l'utilisation d'expressions de modèle ({{ outputs.transform.outputs }}) pour transmettre les données entre les tâches de manière transparente. - Enfin, la tâche notify envoie une notification Slack une fois l'exécution terminée.

Intégration avec CI/CD

L'une des fonctionnalités les plus puissantes de Kestra est sa capacité à s'intégrer à vos pipelines CI/CD existants. Puisque vos workflows sont stockés sous forme de fichiers YAML dans votre dépôt Git, vous pouvez déclencher des déploiements automatiquement lorsque des modifications sont poussées. Par exemple, vous pouvez utiliser une GitHub Action pour valider la syntaxe de votre YAML et déployer le flux vers votre instance Kestra :

name: Deploy Kestra Flows
on:
  push:
    paths:
      - 'kestra/**'

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Deploy to Kestra
        run: |
          curl -X POST https://kestra.example.com/api/v1/executions/run \
            -H "Authorization: Bearer ${{ secrets.KESTRA_TOKEN }}" \
            -F "flowId=simple_etl" \
            -F "namespace=com.example"

Conclusion

Kestra représente un changement vers une orchestration de workflows plus simple et plus transparente. Pour les équipes fatiguées de la complexité associée aux outils traditionnels basés sur les DAG, Kestra offre une alternative rafraîchissante. Son approche code-first, combinée à un riche écosystème de plugins, en fait un excellent choix pour les pratiques modernes d'ingénierie des données et du DevOps. Que vous orchestreriez un job ETL simple ou un pipeline de données multi-cloud complexe, Kestra offre la flexibilité et la puissance nécessaires pour le gérer efficacement. Essayez-le en lançant une instance locale avec Docker et voyez comment il transforme votre stratégie de gestion des workflows.