- Diddag = ワークフローオートメーションシステム
- 複数のタスクを管理するためのシステム
- あらゆる手作業の自動化
- バッチデータ解析の自動化
- ジョインジョイン→メール送信などを手作業ではなく自動化
- メールアドレス一覧の取得、対象の絞り込み→テンプレートから本文を生成
- CircleCIと似たようなシステム？
似たようなプロダクト
- Makefile
- Jenkins
- Rundeck
- Airflow
などなど
ワークフローの定義方法による分類
プログラミング言語型
- Luigi
- Airflow
Pythonのワークフロー管理 タスクとタスクの依存関係
メリット 何でもかける
- デメリット 書くのも管理するのもめんどくさい
GUI型
Rundeck
メリット シンプルで誰でも作れる
- デメリット バージョン管理がしんどい
定義ファイル + スクリプト型
- Azkaban
GUI + スクリプト
- メリット バージョン管理が簡単
- メリット 定型的な処理は簡単
- デメリット 複雑な処理を書こうと思うと半ザツに生る
Digdugは？？
定義ファイル + スクリプト型 + 俺達のYAML
- バージョン管理が簡単
- 開発しやすい
- それと、独自のYAML
普通のYAML
利点
- 読みやすい
- 書きやすい
- プログラムでパースしやすい
- エディタの公文
欠点
- includeできない
- 変数の埋め込みできない
- DSLかけない
Digdagは上記の欠点を すべて克服した
includeできる、変数の埋め込みができる、DSLかける
requireが使えて、外部スクリプトと変数のやりとりができる
DigdagのYAML
- includeできること
- 変数を埋め込めること
- dockerを呼び出せる
YAMLパーサの実装
DocumentStart DocumentEndなど
+ step1: array: [a,b,c] !include : abc.yml
- Scalar値に注目すること
- 一個一個のScalar値にTagをつけて解決すること
- 正規表現によるマッチでTagを決定する
- Tag + Scalar = Node
- includeと:の間にスペースがないと、エラーになる
- YAMLをパースして、オブジェクトを構築する
- 対応する値が指すパスを読み込んでマージすること
- DigdagはJavaで動いている
- と、JavaScriptで評価
なぜYAMLか
- それなりに読みやすい/書きやすい
- 別候補 SimpleJSON プログラミングでパースしやすくするために、独自フォーマットは避けたい
なぜYAMLか
- Digdagはグラフ構造の実行エンジンではない
- Dagの木構造
- テキストでグラフ構造を記述するのは結構無理がある
- グラフ構造は人間が理解するのは難しい
- ので、木構造としてまとめたほうが読みやすい。わかりやすい
GUI
- 実装中
YAMLのなかでソースコードを呼び出せるならそれは脆弱性になりうるのでは
- ちゃんと防御してる
- 副作用のない処理しか実装できない
!includeについて
- !include: だとエラーになるのはつらいかも
