digdagを触ってみる
仕事で一応使っているが、本当にcron daemon以上の使い方を全くしていないので、もうちょいちゃんと見てみる。特にweb uiが気になっている。
とりあえず実行環境を用意する。公式サイトによると
$ curl -o ~/bin/digdag --create-dirs -L "https://dl.digdag.io/digdag-latest"
$ chmod +x ~/bin/digdag
$ echo 'export PATH="$HOME/bin:$PATH"' >> ~/.bashrc
curl、--create-dirs
なんてオプションあったん!?!?と思いながらやってみるも
./digdag: 138: exec: java: not found
(´・ω・`)
dockerhubで探してみるが、怪しげなのしか無い。
仕方ないのでdockerでopenjdkイメージを使って試す。docker run -it openjdk bash
からの上記のやつを実行
bash-4.4# digdag --help
Unrecognized VM option 'AggressiveOpts'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
(´・ω・`)
bash-4.4# java --version
openjdk 18.0.1.1 2022-04-22
OpenJDK Runtime Environment (build 18.0.1.1+2-6)
OpenJDK 64-Bit Server VM (build 18.0.1.1+2-6, mixed mode, sharing)
い、いま18とかなんだ。。。
古い時代の人なので、理解できるjavaバージョンだと11とかになってしまう。ということで
$ docker run -it openjdk:11 bash
# curl -o digdag -L "https://dl.digdag.io/digdag-latest"
# chmod +x digdag
# ./digdag --version
OpenJDK 64-Bit Server VM warning: Option AggressiveOpts was deprecated in version 11.0 and will likely be removed in a future release.
0.10.4
できた。というか、java11の時点でdeprecatedなオプションが使われている。どうやらdigdagは馴染みのある時代のプロダクトのようだ(?)
というか、githubのREADMEを見ると、PrerequirementsにJDK 8とある。
JDK8ってEoLいつなの、と思って調べると、少なくともORACLEのjavaについては2030年とある。まじか。。。普段触ってるweb系の言語やフレームワークとはスケールが違うぜ。。。
とはいえ次の次のLTSである17ですら2029年とあるので、java8はもはや特別ななにかなのだろう。Perl5系的な?
てか、イメージにもユーザにも何の説明も無いし怪しげだなーと思っていたdockerhubのこれ、どうも公式っぽい気配がある。
digdagのgithubリポジトリにdockerってディレクトリがあり、そこで指定されてるイメージ名が一致する。
適当に読みすぎた、このdockerイメージはdigdagをビルドするためのものっぽい。使うためのものではなさそう。
最初に試したjdk11ので進めるとして。
実行ファイルは真面目に置く curl -o /usr/local/bin/digdag -L "https://dl.digdag.io/digdag-latest" && chmod +x /usr/local/bin/digdag
そしてドキュメントによると、 digdag init mydag
みたいな感じでサンプルが生えてくるようだ
digdag run mydag.dig
とするとなんか実行される。とりあえず動作確認はok
今回興味があるのは主にweb ui。そして調べると完全に同じ趣旨の記事があった。参考にしてみる。
こんなところでも登場するクラメソさんさすがやでぇ
digdag server --memory
とするが、ポートはデフォルトだと65432らしい。変えてもいいけどdockerなのでどこでもいい。
docker run -it -p 8080:65432 openjdk:11 bash
として表の8080にbindしつつ、
digdag server --memory -b 0.0.0.0
として、手元からlocalhost:8080にアクセスするとwebuiが見える。ちなみにデフォルトだと127.0.0.1にbindするので、オプションつけないとdockerの外から見えない。
docker execで別shellに入り、cd mydag
でdigdag push mydag
とすると、webui側になんか登録された。
workflowsにmydagがあり、そこからrunとかやるとsessionsが増える。なるほど。
てかそろそろコマンド毎回打つのめんどくさくなってきたのでコード化
FROM openjdk:8
RUN mkdir /workspace
WORKDIR /workspace
RUN curl -L "https://dl.digdag.io/digdag-latest" -o /usr/local/bin/digdag \
&& chmod +x /usr/local/bin/digdag
version: "3"
services:
digdag:
build:
context: .
dockerfile: Dockerfile
volumes:
- .:/workspace
command: bash -c 'digdag server --memory --bind 0.0.0.0'
ports:
- 8080:65432
docker composeのcommandはbash経由じゃないと exec /usr/local/bin/digdag: exec format error
で落ちる。何故なのかはよく調べてない。
webuiをいい感じに起動することはできたので、スケジュールタスクを適当に入れる。
new projectあたりから適当にprojectを作りつつ、workflowをadd fileで足す。雑にこんな感じ
timezone: UTC
schedule:
daily>: 07:00:00
+step1:
sh>: echo 1
適当に変更したものをもう一つほど足す。するとトップのworkflowsに並ぶ。
workflow詳細を見ると、Next run Timeやsessionsが見える。
おぉこれが見たかったんだこれの...一覧...は...
無いですね...digdagはスケジュールタスクの一覧が非常に把握し辛い(digファイルがリポジトリにあったところで、時間とは関係ない分離ファイルが無造作に転がっているだけ)なので、そこをwebuiに期待したのだけど。スケジュール付きのリストは無い
もう解散しそうな勢いであるが、もうちょっと見てみる。
workflow詳細画面にて、chrome devtoolを開きつつリロードすると、/api/projects/1/schedules?workflow=new
みたいなリクエストが見える。そこでクエリパラメータを取っ払ってみると
$ curl -s http://localhost:8080/api/projects/1/schedules | jq
{
"schedules": [
{
"id": "1",
"project": {
"id": "1",
"name": "new-project"
},
"workflow": {
"id": "2",
"name": "new"
},
"nextRunTime": "2022-05-29T07:00:00Z",
"nextScheduleTime": "2022-05-29T00:00:00+00:00",
"disabledAt": null
},
{
"id": "2",
"project": {
"id": "1",
"name": "new-project"
},
"workflow": {
"id": "3",
"name": "new2"
},
"nextRunTime": "2022-05-29T06:00:00Z",
"nextScheduleTime": "2022-05-29T00:00:00+00:00",
"disabledAt": null
}
]
}
はい。欲しい情報はあります。あるっちゃあります。ぐぬぬ...
いっそwebuiのソースをちょっといじって、schedules一覧コンポーネントをトップに置けばいいんじゃないか。挙動を見るに完全にブラウザ側で動いてバックエンドとはAPIでしか通信してないし、独立して動かせそう。