Dagger Shell - un nouveau shell pour l’ère des conteneurs

 (dagger.io)
2 points par GN⁺ 2025-04-02 | 2 commentaires | Partager sur WhatsApp
  • Le shell Unix est utilisé depuis plus de 50 ans et a constitué un puissant outil informatique capable de combiner des opérations complexes à partir de commandes simples
    • Mais les piles logicielles modernes sont devenues bien plus complexes, et les shells existants ont du mal à couvrir tous ces usages
    • Inspiré par Docker, make, powershell, nix et d’autres, il devient nécessaire de disposer d’un shell moderne prenant en charge nativement les conteneurs, les secrets, les endpoints de service, l’exécution déclarative, le cache et le sandboxing
  • Dagger Shell est un frontend basé sur la syntaxe bash pour Dagger Engine, utilisable pour divers travaux d’automatisation comme le build, les tests, le déploiement ou les environnements temporaires
  • Plutôt qu’un remplacement du shell système, c’est un outil complémentaire qui aide à composer des workflows complexes à partir de combinaisons simples de modules 
    container |  
  from alpine |  
  with-exec apk add git |  
  terminal

  • Le shell et le code suffisent

    • Au lieu d’apprendre un DSL bizarre pour gérer des scripts complexes, il est possible d’écrire dans de vrais langages de programmation
    • Des SDK sont fournis pour Go, Python, Typescript, Java, PHP et d’autres langages
    • Les fonctions écrites dans ces langages peuvent être étendues en nouvelles primitives de Dagger

  • Un shell connecté à l’API

    • Dagger Shell joue le rôle de client de l’API Dagger et permet d’accéder à des objets typés, à la documentation et à un écosystème de modules réutilisables (Daggerverse)
    • Par exemple, il est possible de charger et d’exécuter le module de scan de sécurité Trivy

  • Un environnement sandboxé par défaut

    • Toutes les commandes s’exécutent dans une sandbox par défaut, et l’accès aux fichiers, secrets, services, etc. doit être explicitement défini. C’est un peu plus verbeux, mais cela améliore la reproductibilité et la sécurité 
      container |  
  from alpine |  
  with-secret-variable POSTGRES_PASSWORD op://dev/db-password/credential |  
  with-directory /src ~/src/myapp |  
  with-service-binding db tcp://localhost:5432 |  
  terminal

  • Build simple de conteneur

    • Il est possible d’exécuter en une seule fois la création d’un conteneur basé sur Alpine, l’insertion d’un fichier texte, la configuration d’un message de sortie et le push vers un registre temporaire
    • Cela évite les changements de contexte entre l’écriture du Dockerfile, la commande de build et le push 
      # Build a wolfi linux container with curl, then test connection to stable and dev docs  
github.com/dagger/dagger/modules/wolfi | container --packages=curl |  
  with-service-binding docs-stable $(github.com/dagger/dagger/docs@v0.17.1 | server) |  
  with-service-binding docs-dev $(github.com/dagger/dagger/docs@main | server) |  
  with-exec curl http://docs-stable |  
  with-exec curl http://docs-dev

  • Configuration d’un environnement de test

    • La mise en place de l’environnement de test, un problème fréquent en CI, peut aussi être simplifiée
    • La prise en charge native des bindings de services permet de connecter plusieurs instances actives et d’exécuter des tests 
      repo=$(git https://github.com/dagger/hello-dagger | head | tree)  

env=$(container | from node:23 | with-directory /app $repo | with-workdir /app)  

build=$($env | with-exec npm install | with-exec npm run build | directory ./dist)  

container | from nginx | with-directory /usr/share/nginx/html $build | terminal --cmd=/bin/bash

  • Builds multi-étapes (Multi-Stage Builds)

    • Une syntaxe claire et modulaire permet d’implémenter des pipelines de build complexes
    • Chaque étape peut être explicitement définie dans une variable, ce qui facilite le débogage et la réutilisation 
      container |  
  from golang:latest |  
  with-directory /src $(git https://github.com/dagger/dagger | head | tree) |  
  with-workdir /src |  
  with-exec go build ./cmd/dagger |  
  file ./dagger |  
  export ./dagger

À lire aussi

2 commentaires

 
winterjung 2025-04-02

Pour information, le lien a été modifié pour devenir https://dagger.io/blog/…
 
GN⁺ 2025-04-02
Avis sur Hacker News

  • J’ai de plus en plus de mal à cerner l’utilité réelle de Dagger ces derniers temps

    • Au départ, j’espérais que cela pourrait remplacer Jenkins
    • Cela proposait une alternative permettant d’exécuter et de déboguer localement des pipelines CI
    • C’était écrit en Golang et on pouvait y importer ce dont on avait besoin
    • Maintenant, la direction paraît dispersée : le projet essaie de remplacer Docker, de devenir un nouveau shell, et on dirait même qu’il essaie étrangement de devenir Langchain
    • Les nouveaux arguments CLI n’ont rien de mieux que les scripts shell existants ou qu’un Jenkinsfile
    • C’est dommage, on a l’impression que le projet s’est éloigné de son objectif initial

  • J’assemble souvent des Dockerfiles et des scripts shell pour construire différentes images

    • Il faut les exécuter différemment selon l’environnement : machine de développeur, robot, CI, etc.
    • Cet outil semble pouvoir résoudre cette complexité
    • J’aime le fait qu’on puisse référencer la sortie du build sans avoir à manipuler des tags

  • J’avais raté le fait que Dagger essaie de remplacer Docker

    • C’est une vision d’envergure
    • C’est ambitieux, mais difficile d’en déduire qu’il pourrait remplacer les outils existants dès maintenant
    • Je trouve dommage qu’ils aient choisi la compatibilité Bash
    • Je pense qu’il est temps de s’éloigner de la syntaxe et des problèmes de Bash

  • Une interface web permettant d’écrire des scripts Dagger Shell au format notebook existe déjà

    • C’est très intéressant, je recommande d’y jeter un œil

  • La description sur la page d’accueil de Dagger m’a laissé perplexe

    • "Moteur de composition cross-platform"
    • Construisez de puissants environnements logiciels avec des composants modulaires et des fonctions simples
    • Adapté aux builds complexes et aux workflows d’IA
    • C’est tellement générique que ça ne sert à rien
    • Tout est un moteur de composition. Javascript aussi, macOS aussi

  • Auto-promotion liée au sujet

  • Le but est-il de faire du développement à l’intérieur de conteneurs ?

    • Cela me fait penser à Devbox de Jetify et à Flox.dev

  • Concrètement, que peut-on faire avec cet outil ?

    • Pour quelles activités est-il utile ?
    • Quels programmes peut-il remplacer ?
    • Que fait un "système d’exploitation DevOps" ?

  • Ma première impression est que c’est une étape intermédiaire entre un Dockerfile et le fait de définir et configurer un logiciel avec du vrai code

    • En tant que gros utilisateur de Nix, cela ne m’attire pas

  • Dagger a-t-il changé d’orientation produit ?

    • Si je me souviens bien, son principal argument de vente était d’être un service indépendant de pipeline-as-code
    • Maintenant, on dirait qu’il essaie de reconfigurer Docker