Docker創始者らが開発、ビルド/テスト/デプロイの自動化をポータブルにするツール「Dagger」登場 何がすごいかケンモはわかるんか?

1 : 2022/04/19(火) 10:56:53.61 ID:ZSZf94Iw0

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

2 : 2022/04/19(火) 10:58:16.05 ID:+2TrgoG00
Jenkinsをローカルで使えるってこと?
5 : 2022/04/19(火) 11:00:16.37 ID:ebVH+1iea
>>2
ジェンキンスとか色んなCIプラットフォームで共通して使えるテストツールみたいな感じじゃないの
3 : 2022/04/19(火) 10:58:22.84 ID:BITSYbqI0
Docker開発者の人グーグルやMS渡り歩いてんだよな
年収どのくらいあるんだろう
4 : 2022/04/19(火) 11:00:15.27 ID:IjPfKngZ0
流行んなそう
既存の仕組みからわざわざコスト払って乗り換えるほどのメリットis
6 : 2022/04/19(火) 11:01:56.22 ID:ebVH+1iea
>>4
そもそもCI環境を複数使ってるプロジェクトじゃないとあまり意味なさそうだし
7 : 2022/04/19(火) 11:05:24.21 ID:SmUKhnOb0
便利そうだけどなかなか適用しどころが難しい、っていうパターンだなこりゃ
8 : 2022/04/19(火) 11:07:14.31 ID:wJDcNReEd
ジャップの開発ってマジで頭の固いジジイばっかだから
この手の新しい仕組み導入しても理解しようとせずに適当に使ったあげく、変なミスしてかえって工数上がるんよな
subversionの世代管理すら理解できないガ●ジみたいなのが普通に中堅どころとして君臨してたりするからな
9 : 2022/04/19(火) 11:09:51.24 ID:ba6ayXUq0
うちみたいな糞古いウォーターフォール開発してgitなにそれみたいな連中をわからせるために試しに導入するにはいいかも知れない
10 : 2022/04/19(火) 11:10:16.80 ID:UH9oMxxd0
CI乗り換えることそんな無いしなあ
そもそもスクリプト類はプロジェクトのフォルダにシェルスクリプトとして抽出するし
Dockerは最初から使うし
11 : 2022/04/19(火) 11:13:47.28 ID:rw5zhADD0
新規プロジェクトならいいかもしれんけど、既存プロジェクトは乗り換えのメリットがうすそうだよね

うちはAzureとAWS両方でPaas提供してユーザに選択させてるから、これは少し便利かも

16 : 2022/04/19(火) 11:33:10.39 ID:UH9oMxxd0
>>11,12
そういう用途なら使いたい感はあるね
それか今後これにネイティブで対応するようになるとか

個人的にはDockerレジストリも含めてアーティファクトリポジトリの仕様統一してくれんかなという感じはある
maven, npm, pypi, conanとか色々ありすぎ

12 : 2022/04/19(火) 11:15:11.72 ID:S3BxX15wa
一昔前はOSSだとTravis CIでLinuxのテストしてAppveyorでWindowsのテストとかやってた
13 : 2022/04/19(火) 11:25:24.02 ID:qzqM0Ve00
CIスレは嫌儲で伸びない
何故ならパソコンの大先生はほとんどDockerやCIを使う機会なんて無いから
22 : 2022/04/19(火) 12:15:59.97 ID:nqSnySun0
>>13
趣味でフリーソフト作ってる程度の人間だけどGitHub Actionsくらいは使うよ
24 : 2022/04/19(火) 13:08:19.58 ID:qzqM0Ve00
>>22
嫌儲ででかい顔してる大先生はGitHubすら使うことなんて無いぞ
25 : 2022/04/19(火) 13:28:17.03 ID:ZSZf94Iw0
>>24
一応カッコつけてギフハブにレポジトリ上げてるけどかっこだけだな
俺以外触らないから意味ないし
27 : 2022/04/19(火) 15:54:28.63 ID:rw5zhADD0
>>13
ほんと伸びなくて草はえる
SESとかのスレは伸びるのにね
30 : 2022/04/19(火) 18:59:01.20 ID:EA65zcyt0
>>13
はい
14 : 2022/04/19(火) 11:31:14.60 ID:ZDezfmKm0
今じゃコンテナ無しの環境や開発なんて考えられないわな
15 : 2022/04/19(火) 11:31:57.88 ID:TA92VEjX0
コンテナなんて必要ねえだろ
17 : 2022/04/19(火) 11:34:12.68 ID:FMcgjIuIM
だいたいギフハブベースで開発するからギフハブactionsから逃れられない
18 : 2022/04/19(火) 11:37:37.59 ID:UH9oMxxd0
ギトラブええで
21 : 2022/04/19(火) 12:12:09.97 ID:UbVbgg4k0
sockerの親戚?
23 : 2022/04/19(火) 12:45:32.00 ID:DGYKszFq0
テスト自動化のための設定も自動化してほしい
26 : 2022/04/19(火) 15:44:12.94 ID:f2LrIrVYd
すまんnoepadでホムペ
パールでCGI掲示板設置しとったレベルにもわかるように誰か説明してくれや
28 : 2022/04/19(火) 17:48:52.12 ID:r1fyFtQZa
>>26
cgiの一行目でサーバーサイドのPerlのbin位置指定してただろ?そのPerlもバージョンが違うとcgiの一部機能が使えなかったりする
環境要因の不具合を出さないために全部クライアント側で仮想構築したものがコンテナ
それを丸ごと仮想サーバーにDockerでデプロイするのが今の主流
それもファイルの上書きではなく差分だけを当ててる仕組み
29 : 2022/04/19(火) 18:55:51.65 ID:e1N8vACbM
>>28
簡単に仮想環境立てられるのはいいが複雑怪奇なdockerfileをいじるぐらいなら本物のサーバーイジったほうがええやんって思っちゃうんだよな
31 : 2022/04/19(火) 19:08:58.69 ID:UH9oMxxd0
>>29
どこが複雑なんだ?
手でいじられたスノーフレークサーバのほうが1万倍複雑だが
34 : 2022/04/19(火) 20:37:10.55 ID:f2LrIrVYd
>>28
ありがとう
サイズはでかくなるけどwindowsアプリのランタイム同梱みたいなものかな
そこを差分で済ましてるのがうまいところなんだろうか
32 : 2022/04/19(火) 19:11:21.12 ID:oqaXSeBa0
これ良さそうだな。
とにかく、使い方覚えなきゃいけないものを減らしたいよ。

terraform とこれがあれば、サービスロックインはほぼ無くなるのかな。

33 : 2022/04/19(火) 19:11:50.32 ID:x69ZxAA10
テストってどうせC2の単体とかだろ?
そんなのにかかるコード書くやつなんか今どきおらん

コメント

タイトルとURLをコピーしました