エムスリーテックブログ

エムスリー(m3)のエンジニア・開発メンバーによる技術ブログです

Jenkinsをエンジニアでない人も使えるDigdagのWeb UIとして使う

こんにちは、エンジニアリンググループの福林 (@fukubaya) です。

現在、弊社では長年運用され続けているレポート基盤のリニューアルを昨年から続けています。 その一環で、エンジニアでない人も使えるレポート生成UIを実現するため、 DigdagとJenkinsを利用した仕組みを検討しました。 本記事ではその一例をご紹介します。

f:id:fukubaya:20190625222017j:plain
横浜赤レンガ倉庫は横浜港にある歴史的建築物。本文には特に関係ありません。

レポート生成UIとしてのJenkins

弊社では、客観的なデータに基づき意志決定することがエンジニアに限らず基本となっているため、 あらゆるサービスでデータの蓄積、分析、活用が日常的に行われています。

レポート生成処理は基本的にはスクリプト実行なので、実行もコマンド実行になりますが、 エンジニアでない人にコマンド実行でレポートを生成してもらうのは難しいです。

そこで、弊社ではJenkinsをレポート生成UIとして使ってきました。 Jenkinsでパラメータありのビルドジョブを定義するだけで、コマンド実行をWeb UI化できるので、 エンジニアでない人にも使える画面を手軽に作ることができます。

f:id:fukubaya:20190625222835j:plain
レポート生成ジョブが大量にあります。

社内の利用者がこのUIに慣れているのもあり、 今回はこのJenkinsのUIはそのままにバッチはDigdagで実行させることにしました。

Digdag

DigdagはTreasure DataがOSSとして公開しているワークフローエンジンです。

www.digdag.io

定義したワークフローのスケジュール実行だけでなく、依存関係のあるワークフローの実行、失敗時の再実行などを yamlで簡潔に記述して管理できます。 また、ワークフローの実行環境としてDockerを利用できるので、実行環境が変化して実行結果が変わったりする心配がありません。

弊社では、次期レポート基盤としてこのDigdagサーバーをAWS上に構築し、現在オンプレ環境で動いているバッチを移行する検証を進めています。

現在のレポート基盤は、Digdagほど自由にスケジュールの記述ができない、失敗時のリカバリがない、 オンプレの実行環境なのでライブラリなどを自由に更新できない、などの課題があり、 これらを解決するのが目的です*1

Digdagの管理画面

Digdagには最初からWeb UIが用意されており、スケジュール実行でないワークフローであっても、 Web UIからワークフローをオンデマンドで実行させることができます。

ただし、レポートがほしいエンジニアではない人に適宜手動で実行してもらうことを考えた場合、2点課題がありました。

  1. ワークフローの実行にパラメータを指定できない
  2. 認証、ユーザ管理機能などがデフォルトでは用意されていない*2ので、誰でもどのワークフローでも容易に実行できてしまう

このUI部分は使わず、Jenkinsから操作できるようにします。

f:id:fukubaya:20190625222435j:plain
DigdagのWeb UI。パラメータは指定できない。

JenkinsからDigdagのワークフローを実行させる

DigdagはWeb UIだけでなく、REST APIを通して直接ワークフローに対する操作が可能です*3。 DigdagのClient-modeは、このREST APIへのリクエストを投げるCUIコマンドで、 以下のようなコマンドでDigdagサーバに対して指定したワークフローの実行を指示できます。

digdag start project_name workflow_name \
 --endpoint https://digdag-endpoint \
 --session now \
 --param from_date=${from_date} \
 --param to_date=${to_date} \
 --param board_ids=${board_ids}

Jenkinsのジョブにおいてこのコマンドを実行させればDigdagに対してワークフローの実行を指示できます。

validationして使い勝手を高める

Jenkinsのジョブは「ビルドのパラメータ化」で、ジョブ実行時のパラメータを指定させることができますが、 デフォルトのテキストパラメータは自由に入力できてしまいます。 エンジニア以外が使うことを考えると、Digdagに投げる手前でのvalidationが必要です。

なので、テキストパラメータは Validating String Parameter Plugin を使ってvalidationします。

wiki.jenkins.io

入力規則をJavaの正規表現で指定することで、 マッチしない場合にエラーメッセージを表示させられます。

f:id:fukubaya:20190625223015p:plain
日付パラメータの設定例

f:id:fukubaya:20190625223049p:plain
カンマ区切りの入力例

f:id:fukubaya:20190625223115p:plain
パターンにマッチしない場合に指定したメッセージを表示させられます。

実行結果の通知

Jenkinsのジョブ自体は、Digdagへワークフローの実行を登録するだけなので、Digdagサーバに障害がない限り、基本的にジョブとしては成功します。

ワークフローの成否は別途通知が必要です。

とりあえずは成否をslackで通知させる*4 ことにしましたが、メールやその他の通知も必要に応じて追加する予定です。

f:id:fukubaya:20190626105503j:plain
slackの通知例。レポートのダウンロード先を通知します。


以上のような構成により、利用者が実行できるワークフローを制限しつつ、Digdagにパラメータ付きのワークフローを実行させるWeb UIを実現できました。

We are hiring!

冒頭で紹介したように、弊社では長年運用してきたレポート基盤を大きくリニューアルしている最中です。 まだまだリニューアルには課題が山積みで、一緒に進めていける仲間を募集中です。 お気軽にお問い合わせください。

jobs.m3.com

*1:Dockerに関してはECSで実行させることも考えています。

*2:今のところ自前で実装が必要 https://twitter.com/frsyuki/status/878064233589522433

*3:Web UIもこのREST APIを叩いているだけです。

*4:当初Digdagのpluginを使っていましたが、諸事情により、別途slack通知部分は実装しました。