Docker創始者らが開発、ビルド／テスト／デプロイの自動化をポータブルにするツール「Dagger」登場 何がすごいかケンモはわかるんか？ [158478931]
■ このスレッドは過去ログ倉庫に格納されています
Docker創始者らが開発、ビルド／テスト／デプロイの自動化をポータブルにするツール「Dagger」登場。そのままローカルでもGitHubでもCircleCIでも実行可能に
2022年4月19日
Dockerの創始者であるSolomon Hykes氏らが中心となって開発しているオープンソースのCI/CD環境構築ツール「Dagger」が公開されました。
Windows、Mac、Linuxで試すことができます。
Daggerが定義したCI/CDパイプラインはポータブルになる
Daggerとは「A Portable Devkit for CI/CD Pipelines」だと説明されています。すなわち、ソフトウェアのビルド、テスト、デプロイを行う一連のCI/CDパイプラインをポータブルにするための開発キットだ、ということです。
具体的には、DaggerでいちどCI/CDパイプラインを定義すれば、そのまま定義を書き換えることなくローカルのPCやサーバで実行可能なだけではなく、GitHubやCircleCIなどの主要なCI/CDサービスの上でも実行可能になります。
一般に、例えばGitHubを利用して構築したCI/CDパイプラインがあったとして、それをローカルで再現しようとする場合、もしくはJenkinsやCircleCIやGitLabなどの別のツールやサービスを用いて再構築しようとする場合、設定ファイルなどの大幅な書き換えや作り直しをせざるを得ません。
そのため、ほとんどのCI/CDパイプラインはそれを構成する環境やツール、サービスにロックインされている状態と言えます。
ところがDaggerでCI/CDパイプラインの定義をすると、その定義を書き換えることなくローカルのPC環境でも、サーバでも、GitHubでもJenkinsでもCircleCIでも、同じように機能を持つCI/CDパイプラインを構築できるようになります。
これにより、CI/CDパイプラインが特定のツールやサービスにロックインされることがなくなります。また、開発者は開発チームのCI/CDパイプラインと同じものを簡単に手元のローカルPCで再現することや、逆にローカルのCI/CDパイプラインをサービス上に大規模に展開することなどができるようになります。
DaggerのGitHubのページにも、以下の2つの利点が強調されています。
1つ目は、開発環境とCI環境の統合。一度CI/CDパイプラインを記述すれば、Daggerはそれをどこでも同じように実行する、ということ。2つ目は、CI環境へのロックインの削減。（環境の変更により）6カ月ごとにすべてを最初から書き直すことは、もうしなくてよい、ということです。
Dockerコンテナが登場したことにより、ローカルのPC、サーバ上のビルド環境、ステージング環境、本番環境などに対する高いポータビリティが実現され、それらの間でソフトウェアを自由に移動、展開させることが容易になりました。
Daggerはこれをさらに推し進め、ビルド、テスト、デプロイを含む一連のCI/CDパイプラインをまるごとポータブルにし、ローカルのPC上の開発環境でも、開発チームが管理するステージング環境でも、どんな環境に対してもCI/CDパイプラインの移動、展開を容易にするものと言えます。
https://www.publickey1.jp/blog/22/dockerdaggergithubcircleci.html Docker開発者の人グーグルやMS渡り歩いてんだよな
年収どのくらいあるんだろう 流行んなそう
既存の仕組みからわざわざコスト払って乗り換えるほどのメリットis >>2
ジェンキンスとか色んなCIプラットフォームで共通して使えるテストツールみたいな感じじゃないの >>4
そもそもCI環境を複数使ってるプロジェクトじゃないとあまり意味なさそうだし 便利そうだけどなかなか適用しどころが難しい、っていうパターンだなこりゃ ジャップの開発ってマジで頭の固いジジイばっかだから
この手の新しい仕組み導入しても理解しようとせずに適当に使ったあげく、変なミスしてかえって工数上がるんよな
subversionの世代管理すら理解できないガイジみたいなのが普通に中堅どころとして君臨してたりするからな うちみたいな糞古いウォーターフォール開発してgitなにそれみたいな連中をわからせるために試しに導入するにはいいかも知れない CI乗り換えることそんな無いしなあ
そもそもスクリプト類はプロジェクトのフォルダにシェルスクリプトとして抽出するし
Dockerは最初から使うし 新規プロジェクトならいいかもしれんけど、既存プロジェクトは乗り換えのメリットがうすそうだよね
うちはAzureとAWS両方でPaas提供してユーザに選択させてるから、これは少し便利かも 一昔前はOSSだとTravis CIでLinuxのテストしてAppveyorでWindowsのテストとかやってた CIスレは嫌儲で伸びない
何故ならパソコンの大先生はほとんどDockerやCIを使う機会なんて無いから 今じゃコンテナ無しの環境や開発なんて考えられないわな >>11,12
そういう用途なら使いたい感はあるね
それか今後これにネイティブで対応するようになるとか
個人的にはDockerレジストリも含めてアーティファクトリポジトリの仕様統一してくれんかなという感じはある
maven, npm, pypi, conanとか色々ありすぎ だいたいギフハブベースで開発するからギフハブactionsから逃れられない >>13
趣味でフリーソフト作ってる程度の人間だけどGitHub Actionsくらいは使うよ >>22
嫌儲ででかい顔してる大先生はGitHubすら使うことなんて無いぞ >>24
一応カッコつけてギフハブにレポジトリ上げてるけどかっこだけだな
俺以外触らないから意味ないし すまんnoepadでホムペ
パールでCGI掲示板設置しとったレベルにもわかるように誰か説明してくれや >>13
ほんと伸びなくて草はえる
SESとかのスレは伸びるのにね >>26
cgiの一行目でサーバーサイドのPerlのbin位置指定してただろ？そのPerlもバージョンが違うとcgiの一部機能が使えなかったりする
環境要因の不具合を出さないために全部クライアント側で仮想構築したものがコンテナ
それを丸ごと仮想サーバーにDockerでデプロイするのが今の主流
それもファイルの上書きではなく差分だけを当ててる仕組み >>28
簡単に仮想環境立てられるのはいいが複雑怪奇なdockerfileをいじるぐらいなら本物のサーバーイジったほうがええやんって思っちゃうんだよな >>29
どこが複雑なんだ？
手でいじられたスノーフレークサーバのほうが1万倍複雑だが これ良さそうだな。
とにかく、使い方覚えなきゃいけないものを減らしたいよ。
terraform とこれがあれば、サービスロックインはほぼ無くなるのかな。 テストってどうせC2の単体とかだろ？
そんなのにかかるコード書くやつなんか今どきおらん >>28
ありがとう
サイズはでかくなるけどwindowsアプリのランタイム同梱みたいなものかな
そこを差分で済ましてるのがうまいところなんだろうか >>34
まあそういう感じの超でっかいランタイム付きという捉え方で良いかな
差分管理はおまけであってあんまり本質じゃない
親OSが仮想サーバーである必要もない
カーネル部分、つまりシステムコールは親OSそのまま使う
仮想化に比べるとリソースコストが低いし立ち上がりも速い
ほとんど生のプロセス並み >>35
わざわざサンクス
結構なんとなくだけど理解できたわ ■ このスレッドは過去ログ倉庫に格納されています
