Dagger : comprendre le mental model local-first

Dagger est une plateforme qui vous permet d’exécuter vos pipelines CI/CD localement sur votre machine, exactement comme ils s’exécuteront en CI. Contrairement aux CI traditionnelles où vous devez pousser votre code et attendre les logs, Dagger vous donne un feedback immédiat. C’est ce qu’on appelle l’approche “local-first”.

Vous venez de GitLab CI ?

Ce guide fait régulièrement le parallèle avec GitLab CI pour vous aider à transposer vos connaissances. Les encadrés “Parallèle GitLab CI” comparent les concepts équivalents entre les deux outils.

Prérequis : Notions de base en programmation Python et compréhension de ce qu’est un conteneur Docker. Si besoin, consultez :

• Les fonctions en Python — Arguments, retours, lambdas
• Les décorateurs — Comprendre @function
• La POO en Python — Classes et objets
• Docker pour les conteneurs — Comprendre les images et conteneurs

Ce que Dagger n’est PAS

Avant de comprendre ce qu’est Dagger, clarifions une confusion courante.

Attention à la confusion !

Dagger (plateforme CI/CD) n’a rien à voir avec Dagger (Hilt/Dagger), le framework d’injection de dépendances pour Java/Android créé par Google.

Ce sont deux projets complètement différents !

Dagger (CI/CD)	Dagger (Android)
Créé par Solomon Hykes (fondateur de Docker)	Créé par Google
Plateforme de pipelines programmables	Framework d’injection de dépendances
Python, Go, TypeScript	Java, Kotlin
Exécute des conteneurs	Compile du code Android

Glissez pour voir

Dans cette formation, on parle uniquement de Dagger la plateforme CI/CD.

Qu’est-ce que Dagger ?

Dagger est une plateforme pour automatiser la livraison logicielle. Elle permet de construire, tester et déployer n’importe quelle application, de manière fiable et à grande échelle.

Mais “plateforme de livraison logicielle”, ça reste abstrait. Concrètement, Dagger vous permet de :

1. Écrire vos pipelines en code (Python, pas YAML)
2. Les exécuter localement (sans pousser vers une CI)
3. Les partager et réutiliser (comme des librairies)
4. Bénéficier du cache automatique (exécutions ultra-rapides)

Une analogie pour comprendre

Imaginez que vous construisez une maison :

• CI traditionnelle (Jenkins, GitLab CI) : Vous envoyez vos plans par courrier à une entreprise de construction. Vous attendez qu’ils construisent. S’il y a un problème, vous recevez un compte-rendu par courrier. Vous corrigez et renvoyez. Ça prend des jours.

• Dagger : Vous avez une maquette 3D sur votre bureau. Vous pouvez tester chaque modification instantanément, voir les problèmes en temps réel, et quand tout est parfait, vous envoyez les plans finaux.

Dagger vous donne cette “maquette 3D” pour vos pipelines.

L’approche “Local-first” : pourquoi c’est révolutionnaire

Le terme “local-first” signifie que votre pipeline s’exécute d’abord sur votre machine locale, pas sur un serveur distant.

Le problème avec les CI traditionnelles

Quand vous utilisez GitLab CI, GitHub Actions ou Jenkins, voici le workflow typique :

1. Modifier le code
2. git commit && git push
3. Attendre 2-10 minutes
4. Lire les logs (souvent incompréhensibles)
5. Si erreur : deviner le problème
6. Retour à l'étape 1

Ce cycle peut prendre des heures pour un simple bug de configuration.

Avec Dagger : feedback immédiat

1. Modifier le code
2. dagger call ma-fonction
3. Voir le résultat en quelques secondes
4. Si erreur : debugger localement
5. Une fois que ça marche : pousser

Le même pipeline qui tourne sur votre laptop tournera à l’identique en CI.

Parallèle GitLab CI

Workflow	GitLab CI	Dagger
Modifier	.gitlab-ci.yml	main.py
Tester	git push → attendre	dagger call → instantané
Debug	Lire les logs dans l’UI	IDE + terminal interactif
Feedback	2-10 min au mieux	5-30 sec

Glissez pour voir

Résultat : le cycle “modifier → tester” passe de 15 min à 30 sec.

Pourquoi c’est possible ?

Dagger repose sur les conteneurs. Chaque opération s’exécute dans un conteneur isolé, ce qui garantit :

• Reproductibilité : même comportement partout
• Isolation : pas de dépendances système cachées
• Portabilité : fonctionne sur Linux, macOS, Windows (via Docker Desktop)

Lien avec Docker

Si vous connaissez déjà Docker, vous êtes bien préparé pour Dagger. Dagger utilise Docker (ou Podman) pour exécuter ses conteneurs. Voir notre guide Docker si besoin.

Architecture de Dagger

Dagger est composé de plusieurs éléments qui travaillent ensemble. Comprendre cette architecture vous aidera à diagnostiquer les problèmes.

Vue d’ensemble

Les composants clés

1. Le Dagger Engine

Le Dagger Engine est le cœur du système. C’est un daemon (programme qui tourne en arrière-plan) qui :

• Orchestre l’exécution des conteneurs
• Gère le cache intelligent
• Fournit l’API que vous appelez

Analogie : Le Dagger Engine, c’est comme le chef cuisinier dans un restaurant. Il reçoit les commandes (vos fonctions), coordonne les cuisiniers (les conteneurs), et s’assure que tout est prêt dans le bon ordre.

Le Dagger Engine est lui-même un conteneur Docker. C’est pour ça que Docker doit être installé.

2. Le Dagger CLI

Le Dagger CLI (dagger) est l’outil en ligne de commande que vous utilisez pour interagir avec Dagger. C’est votre point d’entrée principal.

Commandes principales :

Commande	Description
dagger version	Affiche la version installée
dagger init	Initialise un module Dagger
dagger call	Appelle une fonction de votre module
dagger check	Exécute les validations automatiques

Glissez pour voir

Le CLI communique avec l’Engine et affiche les résultats dans un terminal interactif (TUI) qui montre en temps réel ce qui se passe.

Parallèle GitLab CI

Dagger CLI	GitLab CI équivalent
dagger call build	Le job build: s’exécute
dagger call test --source=.	Le job test: avec artifacts
dagger call --interactive	SSH dans le runner (si configuré)
dagger init	Créer .gitlab-ci.yml

Glissez pour voir

La différence majeure : avec Dagger, vous lancez le “job” depuis votre terminal, sans pousser de code.

3. Les SDKs

Les SDKs vous permettent d’écrire vos pipelines dans un langage de programmation au lieu de YAML. Dagger propose des SDKs pour :

• Python (c’est notre focus dans cette formation)
• Go
• TypeScript
• PHP, Java, Rust, Elixir, .NET

Chaque SDK fournit :

• Un client pour appeler l’API Dagger
• Un générateur pour exposer vos fonctions

Lien avec Python

Le SDK Python utilise des concepts que vous connaissez peut-être déjà : les décorateurs (@function), les classes (@object_type), et l’asynchrone (async/await).

4. Les Modules

Un module Dagger est un ensemble de fonctions packagées ensemble. Quand vous exécutez dagger init, vous créez un module.

Les modules peuvent :

• Être appelés depuis le CLI
• Être importés par d’autres modules
• Être partagés via le DaggerVerse (comme PyPI pour Python)

Concepts clés de Dagger

Pour maîtriser Dagger, vous devez comprendre ces 5 concepts fondamentaux.

1. Les Fonctions

Les fonctions Dagger sont l’unité de base de calcul. Une fonction :

• Accepte des entrées (arguments)
• Exécute des opérations (souvent dans des conteneurs)
• Retourne des sorties (fichiers, conteneurs, texte…)

En Python, une fonction Dagger ressemble à ceci :

from dagger import dag, function, object_type

@object_type
class MonPipeline:
    @function
    def saluer(self, nom: str) -> str:
        """Retourne un message de salutation."""
        return f"Bonjour, {nom} !"

Analogie : Une fonction Dagger, c’est comme une recette de cuisine. Elle décrit les ingrédients (entrées), les étapes (opérations), et le plat final (sortie).

Parallèle GitLab CI

Dagger	GitLab CI
@function def build()	Un job build:
@function def test()	Un job test:
Paramètres Python (source: dagger.Directory)	artifacts: paths:
Retour (-> dagger.Container)	Output du job

Glissez pour voir

Avantage Dagger : les fonctions sont des vrais fonctions Python — vous pouvez les tester, les debugger dans un IDE, réutiliser du code.

2. Les Types

Dagger fournit des types pour manipuler les artefacts de vos workflows :

Type	Description	Exemple d’utilisation
Container	Une image de conteneur	Builder une application
Directory	Un répertoire de fichiers	Monter du code source
File	Un fichier unique	Récupérer un binaire compilé
Secret	Une valeur sensible	Injecter un token API
Service	Un service réseau	Tester avec une base de données

Glissez pour voir

Ces types ont des méthodes que vous enchaînez pour construire votre workflow.

3. Le Chaînage (Chaining)

Le chaînage est la technique qui permet d’enchaîner les opérations sur les types. C’est le cœur de la construction des workflows Dagger.

container = (
    dag.container()              # Crée un conteneur vide
    .from_("python:3.12")        # Utilise l'image Python
    .with_exec(["pip", "install", "flask"])  # Installe Flask
    .with_exec(["python", "--version"])      # Affiche la version
)

Chaque méthode retourne un nouveau type, sur lequel vous appelez la méthode suivante. C’est similaire au pipeline Unix (|).

Analogie : C’est comme une chaîne de montage. Chaque station (méthode) transforme le produit (conteneur) avant de le passer à la suivante.

Parallèle GitLab CI

Le chaînage Dagger correspond à la section script: d’un job GitLab :

# GitLab CI
build:
  image: python:3.12
  script:
    - pip install flask
    - python --version

# Dagger (même chose)
container = (
    dag.container()
    .from_("python:3.12")
    .with_exec(["pip", "install", "flask"])
    .with_exec(["python", "--version"])
)

Avantage Dagger : le chaînage est du vrai code — vous pouvez utiliser des boucles, conditions, fonctions pour construire dynamiquement votre pipeline.

4. Le Cache

Dagger cache automatiquement les résultats pour accélérer les exécutions. Il existe 3 niveaux de cache :

1. Layer cache : comme Docker, chaque étape est cachée
2. Volume cache : pour pip, npm, etc. (cache des dépendances)
3. Function cache : les appels de fonctions identiques sont réutilisés

Le cache est basé sur le contenu : si les entrées n’ont pas changé, le résultat est réutilisé.

Chiffres réels : Un pipeline qui prend 5 minutes la première fois peut s’exécuter en 10 secondes les fois suivantes grâce au cache.

Parallèle GitLab CI

Cache	GitLab CI	Dagger
Dépendances	cache: paths: [.cache/pip]	Automatique (with_mounted_cache)
Layers Docker	--cache-from (manuel)	Automatique (intégré)
Configuration	Plusieurs lignes YAML	Zéro config par défaut

Glissez pour voir

En GitLab, vous devez configurer le cache explicitement. En Dagger, il fonctionne par défaut — vous l’optimisez seulement si nécessaire.

5. Les Modules et le DaggerVerse

Les modules permettent de packager et partager des fonctions. Le DaggerVerse (daggerverse.dev) est le registre public où la communauté partage ses modules.

Exemples de modules disponibles :

Module	Description
github.com/dagger/dagger/modules/go	Build de projets Go
github.com/dagger/dagger/modules/python	Build de projets Python
trivy	Scan de vulnérabilités

Glissez pour voir

Vous pouvez utiliser ces modules directement ou vous en inspirer.

Parallèle GitLab CI

Les modules Dagger sont l’équivalent des CI/CD Templates GitLab ou des Reusable Workflows GitHub :

Dagger	GitLab CI
dagger call python/test	include: 'Python.gitlab-ci.yml'
Modules Python natifs	Templates YAML à copier
Import avec typage	Merge de YAML sans validation

Glissez pour voir

Avantage Dagger : les modules sont des vrais packages avec versioning sémantique, tests, et documentation intégrée.

Comparaison avec les CI traditionnelles

Voici un tableau récapitulatif des différences :

Aspect	CI traditionnelle	Dagger
Configuration	YAML	Code (Python, Go, TS)
Exécution locale	Difficile ou impossible	Native (“local-first”)
Debugging	Ajouter des echo	IDE, breakpoints, logs
Reproductibilité	”Works on CI”	Identique partout
Portabilité	Vendor-locked	Agnostique (GitLab, GitHub…)
Cache	Configuration manuelle	Automatique
Réutilisation	Copier-coller	Importer des modules
Tests du pipeline	Pousser pour tester	Tester localement

Glissez pour voir

Quand utiliser Dagger ?

Dagger est idéal pour

• Pipelines complexes avec beaucoup de logique conditionnelle
• Équipes polyvalentes qui maîtrisent Python/Go/TS
• Portabilité : même pipeline local et CI
• Debug rapide : feedback en secondes

Dagger peut être excessif pour

• Pipelines très simples (un script de 3 lignes)
• Équipes 100% ops qui préfèrent le YAML
• Environnements sans Docker (très rares)

Comment Dagger s’intègre aux CI existantes

Dagger ne remplace pas GitLab CI ou GitHub Actions. Il complète ces outils.

Votre CI traditionnelle :

1. Déclenche le pipeline (sur push/merge)
2. Appelle dagger call avec vos fonctions
3. Dagger exécute le vrai travail dans des conteneurs

Résultat : un fichier .gitlab-ci.yml ou .github/workflows/ci.yml de 10 lignes qui appelle Dagger, au lieu de centaines de lignes YAML.

# .gitlab-ci.yml (exemple minimal)
build:
  image: docker:dind
  services:
    - docker:dind
  variables:
    DOCKER_HOST: tcp://docker:2376
    DOCKER_TLS_CERTDIR: "/certs"
  script:
    - apk add curl
    - curl -fsSL https://dl.dagger.io/dagger/install.sh | sh
    - ./bin/dagger call build --source=.

Parallèle GitLab CI

Avant Dagger : votre .gitlab-ci.yml contenait toute la logique — 100+ lignes de script:, before_script:, artifacts:, cache:, etc.

Avec Dagger : votre .gitlab-ci.yml ne fait que déclencher le pipeline. La logique est dans votre code Python, testable localement.

Aspect	Sans Dagger	Avec Dagger
.gitlab-ci.yml	200 lignes	15 lignes
Debug	Push → attendre	dagger call local
Réutilisation	Copier-coller	Import de modules
Tests du pipeline	Pousser pour voir	pytest sur vos fonctions

Glissez pour voir

À retenir

• Local-first : exécutez vos pipelines localement avec le même résultat qu’en CI — plus de “push → attendre → lire les logs”
• Pipelines en code : Python au lieu de YAML, avec boucles, conditions, tests et IDE complet
• Architecture 3 couches : CLI → Engine → Docker — le CLI parle à l’Engine qui orchestre les conteneurs
• Cache automatique : 3 niveaux (layers, volumes, fonctions) — premier run = 5 min, runs suivants = 10 sec
• Fonctions : unité de base, décorées avec @function
• Types : Container, Directory, File, Secret, Service
• Chaînage : enchaîner les méthodes pour construire un workflow
• Modules : packager et partager via le DaggerVerse

Prochaines étapes

Maintenant que vous comprenez le mental model de Dagger, vous êtes prêt à passer à la pratique :

• Installation et premier pipeline — Installer Dagger CLI et créer votre premier module Python
• Connexion, async et erreurs — Comprendre le cycle de vie async et gérer les erreurs

Ressources complémentaires

• Documentation officielle : docs.dagger.io
• Core Concepts : docs.dagger.io/core-concepts
• DaggerVerse : daggerverse.dev

×

📖 Voir la documentation →