Digdag で CI/CD をした思ひ出
ドキュメントの讀み方 : ドキュメントをgit cloneしてきて grep する
Pros
證左を殘しやすい
基本は YAML で宣言的に
PostgreSQLPostgreSQL.icon が無事なら Digdag 本體は自由に再起動できる タスクの最長實行時閒 (SLA) をタスクごとに決められて、それを超えるとエラーにしてくれる
ループべんり
實行時にループ對象を決めたりできる
條件分岐べんり
YAML に${}で ECMAScriptECMAScript.icon 書けてべんり(JVMJava.icon 組み込みの Nashorn で實行される) タスクを入れ子にできるのよい
他のワークフローを呼び出せるのべんり
パラメータを渡せる
呼び出し先のワークフローにタスクを平坦に書いてるとリトライがめちゃくちゃになるので、大きな一つのタスクの下に置くのがよい
エラー処理用の_error>:多段にできる
手元でもサーバー立てずに、better Makefile として使へる
Cons
スケールはできるけどオートスケールは (作り込めばできるが) 面倒
DockerDocker.icon との連攜は考へられてゐる (sh>:は DockerDocker.icon を呼ぶ事に使へ、とドキュメントに書いてある) が、後始末とかは自分でやらなければならない RubyRuby.iconやPythonPython.iconを使ふ場合、ホストに入れておく必要がある。Digdag には同梱されてゐない YAML に ECMAScript 書いた時}をエスケープできない(という風にデグレってるコミットがあった…) 使ふパラメータが無くても、それを使うタスクにゆくまでエラーにならないし、どんなパラメータが渡されたか log に出ないので、ワークフローの最初にパラメータをecho>:するタスクを置く…
sh>:が DockerDocker.icon を呼ぶ以外の使ひ方を考慮されてゐないので、cwd とか user とか無い…(ので RubyRuby.icon で似たオペレータを書く…) store:でポスグレにちょっとした値を置けるの便利なのだけど、ワークフローの中ではグローバルなのの一つしか無い。他のタスクが何を保存してゐるのか知ってゐなければ競合する
竝列實行
クラスタ全體で竝列度の上限を決めなければならない(めちゃくちゃでかい數にはできる)
ワークフローの同時實行數ではなくてタスクの同時實行數
失敗時の擧動
ワークフローの殘りは實行されない
_error>:に飛ぶ。ここで失敗を通知する
finally 的なものは無い
エラーになったタスクは、強制終了はされない
エラー終了した時は終了しているのでよいのだが、SLA を超えた時はエラー扱いになるだけ
プロセスを探してきて kill する事になる…
Web UI や CLI から digdag kill した時も、そう…
digdag kill した時はerror>:は走らない。エラーではなくて kill だから…
error>:に後始末を書いてあると、過負荷になった時にプロセスを探して kill しなければならなくなる…。なのでerror>:は通知を書く場所で、後始末を書く場所ではないことがわかる
強制終了されないのでどうせプロセスを kill しなければならないが…
後始末は普通のタスクとして書いて、リトライする
ワークフローの實行履歷 (セッション) は全て green にするのが正しい運用
個々のワークフロー實行 (アテンプト) は red になってよいが、ちゃんとリトライして green にする
CI に使ってテストがこけるのを red にしてはいけない。テストは正しく實行できて、結果が「失敗」という値だっただけだから
ビッグデータ扱ってると終了方法が自明ではないのだろうなぁ、と察してゐた
Promise.race 的なのは…在るのかな、使ったことないne-sachirou.icon
何が嬉しいか?
代替手段でも充分、と云ふだけでは代替手段を選ぶ理由には成らない
自分の學習 cost は氣にしない。學習せずに濟む手段は私には常に無いので
選擇肢
Jenkins
どっか行って
Jenkins 2
異形にする爲に眞面目に檢討しなかった
Digdag
TD 製
TreasureData, Fluentd を使ってた
YAML
擴張されてはゐる
include
if, loop, require
_parallel: true
UI から設定させる氣が無い (實は設定出來るが…。出來ないはうが好い)
Airflow
目茶苦茶好ささう
しかし Python は自由に出來過ぎる
workflow 變更に再起動が要る (當時は)
Azkaban
Rundeck
Luigi
作り切れるか?
検証を始める前にわからなければならない
前例。理論的には作れる
検証した結果作れないと成った時に fallback 先は何か? いつまでなら fallback 出來るか?
運用出來るか?
運用してみないと解らない事も有るが、その時にはもう遲い
前例を見る
TD ではめっちゃ使ってる
simulation する
全部 itamae で設定する
人を增やせるか? team を作れるか?
他の product に影響を與へられるか?
既存の、或いは後續の product に好い影響を與へる
R.I.P. Jenkins