Dagger、「Dagger Shell」をOSSとして公開 CI/CDパイプライン構築をどう効率化するのか？：シェルとコードだけでビルドやテスト、デプロイがシンプルに

Daggerは、「コンテナ時代のシェル」をうたうオープンソースソフトウェア（OSS）の「Dagger Shell」を公開した。

[＠IT]

　クロスプラットフォーム構成エンジンの「Dagger Engine」を提供するDagger社は2025年3月26日（米国時間）、「コンテナ時代のシェル」をうたうオープンソースソフトウェア（OSS）の「Dagger Shell」を公開した。同社は以下のように紹介している。

---

　Dagger Shellは、最新の実行、構成システムであるDagger Engineと連携する、bash構文ベースのフロントエンドだ。ビルドやテスト、一時的な開発環境の構築、デプロイメント、さらにはターミナルから自動化したいあらゆる処理に対応する。AI（人工知能）エージェントの構成にも適している。

システムシェルの補完

　Dagger Shellは、既存のシステムシェルを置き換えるものではなく、補完することを目的としている。従来のシェルスクリプトでは複雑過ぎて扱えないワークフローを実現しようとすると、しばしば不完全で脆弱（ぜいじゃく）なモノリスに頼ることになる。シェルスクリプトほど手軽ではなく、ソフトウェアほど堅牢（けんろう）でもないためだ。Dagger Shellは、そうしたモノリスを標準化されたインタフェースの小さなモジュール群に置き換えることで、再利用性と保守性を高めることを目指している。

container |
  from alpine |
  with-exec apk add git |
  terminal

Alpineコンテナ内でのDagger Shell操作例（提供：Dagger）

必要なのはシェルとコードのみ

　スクリプトが肥大化し、シェル構文だけでは対応できなくなったとき、DSL（Domain Specific Language：ドメイン固有の言語）を学ぶよりも、プログラミング言語で直接コードを書く方が現実的だ。

　UNIXは、シェルと「C」という2本柱の上に構築された。Daggerも同様のモデルに従っており、「Go」「Python」「TypeScript」「Java」「PHP」向けのSDKが用意されている。言語を選び、関数を書くだけで、Daggerの基本機能を自分仕様にカスタマイズできる。どんなに複雑なシステムでも、必要なのはこの2つだけだ。

（提供：Dagger）

APIと統合されたシェル

　Dagger Shellは、Dagger APIのクライアントの一つとして機能する。型付きオブジェクト、組み込みドキュメント、再利用可能なモジュールを読み込み、関数を実行し、APIを探ることもできる。

　Dagger Shellは「Daggerverse」（Dagger用の公開モジュールレジストリ）に存在する数千のモジュールを読み込み、APIを調査し、関数を実行できる。ここでは、Trivyモジュールを例に挙げる。

Trivyモジュールを用いたコンテナイメージ（alpine:latest）のセキュリティスキャン結果（提供：Dagger）

デフォルトでサンドボックス実行

　Dagger Shellのコマンドは、サンドボックス化された関数として実行され、引数として明示的に指定された場合にのみホストのリソース（ファイル、シークレット、サービスなど）にアクセスする。

　この設計により、コマンドはやや冗長になることもあるが、再現性が高く、素早く試行を繰り返せる。

　シークレット、ローカルディレクトリ、データベースアクセスを使用する開発環境の例は下記の通り。

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

シンプルなコンテナビルド

　Dagger Shellでは、Alpineコンテナの作成からファイルの挿入、実行時に表示するメッセージの設定、一時レジストリへの公開までを1つのパイプラインで完結できる。Dockerfile作成、ビルドコマンド、レジストリへのプッシュといった作業を行き来する必要はなく、一連の処理をシームレスに実行できる。

テスト環境

　CI（継続的インテグレーション）における一般的な課題の一つとして、一時的なテスト環境の構築がある。テスト対象のソフトウェアをコンテナ化し、それを依存サービスに接続する必要がある。Daggerは、サービスバインディングをネイティブにサポートしているため、この課題を容易に解決できる。

　以下は、Daggerのドキュメントを複数のライブインスタンスとして立ち上げ、それらに「curl」で接続してテストする環境の例だ。サードパーティー製のモジュールもスムーズに組み込める。

# 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

マルチステージビルド

　複雑なビルドワークフローを、明確かつモジュール化された構文で実装できる。パイプラインの各ステージにおける可視性と制御性を保ちつつ、パイプラインの一部を保存し、再利用できる。Dockerfileの編集、ビルドコマンドとプッシュコマンドの実行を何度も切り替える必要はない。全てを一度に実行できる。

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

　例えば、Node.jsのビルド環境でソースコードをビルドし、成果物のみをnginxベースの軽量コンテナにパッケージ化する、といった処理が一貫した構文で実装できる。状態は明示的に管理され、Dockerfileのレイヤーに隠れることはない。

　以下は、Daggerの開発ビルドを最新のリポジトリから取得する例だ。

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