Digdag公式ドキュメントからDigdagを学ぶ-アーキテクチャ

## 目標
Digdagの公式サイトのドキュメントのアーキテクチャを翻訳＋α
DigdagのRubyを使ってRailsにバッチを作るまでが最後の目標
http://docs.digdag.io/architecture.html

#＃目次
[Getting started](https://qiita.com/amagasu/items/92ad70c33f73ab613d08)
[Architecture](https://qiita.com/amagasu/items/572075dcc8b3c8640072)
[Concepts](https://qiita.com/amagasu/items/c850db3b564a7d6dc99c)
[Workflow definition](https://qiita.com/amagasu/items/2a8b84ac8fb4da2d9968)
[Scheduling workflow](https://qiita.com/amagasu/items/9f47a34884ba06d93264)
[Operators](https://qiita.com/amagasu/items/1f9b26a71c86fc9d4607)
Command reference
[Language API -Ruby](https://qiita.com/amagasu/items/b11527d92d259bd3ab48)
[Digdagで環境毎に設定値を変える（RubyOnRails）](https://qiita.com/HavenSpring/items/bb1c7fbae9175c1f9479)
[Digdagを用いてRubyOnRails環境でバッチ実装](https://qiita.com/HavenSpring/items/b3c3e26ef868f8d5eaf4)v

## Digdag Architecture
### Automating workflow with Digdag
ワークフローは手動の動作を自動化します。
一連のタスクをワークフローとして定義します。
Digdagは実行し続けます。タスクはオペレータープラグインを使用して定義されるため、中央のワークフローエンジンから多数の種類のシステムをコントロールできます。

プラグインのランタイムフレームワークとして、Digdagはワークロードの自動化に関する残りの問題を処理し、自動化に集中できるようにします。
タスクが失敗した場合、Digdagはアラートを送信します。ワークフローが想定時間内に完了しない場合、Digdagは通知を送信します。 
タスクは、ローカルマシン、分散サーバー、またはDockerコンテナーで実行できます。

### グループによるタスクの組織化
複雑なワークフローを自動化すると定義はすぐに複雑になります。 Digdagを使用するとタスクをグループに整理できます。
定義を確認する時に概要から見て詳細に移ると思います。
図の上の部分が概要部分でやろうとするのがデータ準備・分析・評価の流れだとすぐわかります。その後各グループの詳細を見ることで開発中デバッグとレビューが簡単になります。管理者は本番環境で何が起こっているのか問題を修正する方法は何かすぐわかります。

データ準備グループ、分析グループ、評価クループ
![Untitled Diagram.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/108475/0be75c34-6aa4-c459-8167-23ce11fbfd28.png)


依存する兄弟タスクがない場合、またはすべての兄弟タスクが正常に完了した場合にタスクが開始されます。
グループの親タスクが実行されるとその子タスクが実行されます。それらのすべてが正常に完了すると親タスクも正常に完了します。子タスクが失敗すると失敗した子タスクとその親タスクも失敗します。
ルートタスクが完了するかもしくは失敗すると実行全体が終了します。

### Parameters
タスクのグループ化はタスク間でパラメーターを渡すためにも使用されます。
親タスクは子タスクのため変数をエクスポートできます。（例：UNIXシェルのエクスポートコマンドが環境変数を設定するように）。親タスクは実行時に子タスクを生成できるため前のタスクの結果に応じてさまざまなタスクを実行できます。

### Workflow as code
Digdagワークフローはコードで定義されます。これによりソフトウェア開発のベストプラクティス（バージョン管理、コードレビュー、テスト、プルリクエストを使用したコラボレーション）がもたらされます。ワークフローをgitリポジトリにプッシュすると誰でもそれをプルして同じ結果を再現できます。

### Running with local mode
Digdagは、単一ファイルの実行可能コマンドです。
新しいワークフローの作成と実行はMakefileと同じくらい簡単です。

```*.dig``` 拡張子ファイルはワークフロー定義に使用されます。 
```digdag run my_workflow.dig```コマンドはワークフローを実行します。

ローカルマシンでワークフローを開発してテストが終わったらワークフローを定期的に実行するためにサーバーにプッシュする必要があります。

### Running on a server
同じディレクトリに存在する```* .dig```ファイルとその他のファイルはプロジェクトと呼ばれます。
全てのプロジェクトをDigdagサーバーにプッシュしてその結果サーバー上でワークフローを実行できるようになります。
少し早いですが、前回作ったWorkflowをサーバーにPushしたら以下のようになります。

```:Digdagサーバー起動
$ digdag init mydag
$ cd mydag
$ digdag run mydag.dig
$ digdag server --memory
```

```:WorflowにProject追加
$digdag push mydag

2020-07-09 20:39:20 +0900: Digdag v0.9.41
Creating .digdag/tmp/archive-3560803829245476890.tar.gz...
  Archiving mydag.dig
Workflows:
  mydag.dig
Uploaded:
  id: 1
  name: mydag
  revision: b8b9abb8-b156-4089-a009-a01aa0337d9f
  archive type: db
  project created at: 2020-07-09T11:39:21Z
  revision updated at: 2020-07-09T11:39:21Z

Use `digdag workflows` to show all workflows.

```
![スクリーンショット 2020-07-09 20.39.46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/108475/d0bcf143-87a3-0d03-7265-4d8ce8a65d9b.png)

### Running tasks on Docker
Dockerを利用してコンテイナー中のタスクを実行できます。
dockerオプションが設定されていたらタスクはDockerコンテイナーで実行されます。

まだ詳細タスクについて学んでないので以下のコードの説明はWorkflow definition部分で説明する予定

```
_export:
  docker:
    image: ubuntu:14.04

+step1:
  py>: tasks.MyWorkflow.step1
```

Digdagは、プルされたイメージをキャッシュして再利用します。デフォルトでDigdagは更新があった場合でもキャッシュされたイメージを一貫して使用します。 pull_always：trueオプションを設定してDigdagが更新をチェックしタスクが開始されるたびにタグの最新のイメージをプルすることができます。

```
_export:
  docker:
    image: ubuntu:latest
    pull_always: true

+step1:
  py>: tasks.MyWorkflow.step1
```