なんちゃってエンジニアぶろぐ

プログラムがガリガリ書けるわけじゃない。でもなんか新しいことに手を出したいそんな人のブログ。

最近暇だからWordPressを立てて遊んでみよう-その1-

凄い時間空いていることに驚きつつ。 最近あんまり何もしてなかったから、 この間小耳に挟んだシステム構成でWordPress立てて遊ぼうかなと思いました。 まだ、考えてる段階なので、最後までやるか不明ですが・・・。

AWS EC2 × LiteSpeed × WordPress で個人ブログっぽいの作ってみようかなと。

最近自分のスキルとか経歴とかまとめたいなと思ってたので、やってみようかなと思います。 ※なので、完成したらお引越し。

とりあえず、今日はその宣言で。

ちなみに「LiteSpeed 」にした理由。

なんか一緒に働いている人に、「知ってますか?」って聞かれて全然知らなかったからです。

見せてもらった記事的には有名らしいんですが・・・? そもそもApacheとか以外の選択したことなかったので、たまには気分転換的に。 Apache互換とかあったし。

そんな適当な理由で始めていきます。

新しいことしてみよう。 AWS Sagemaker その1

前回までは連携基盤の構築をやってきましたが、今回から新しいテーマで書きます。

いちおう前職でAWS関連の作業してたので、ちょこちょこアップデート気にしてたんですが、先日RebuildでAWSのsagemakerを取り上げてたこともあり、なんとなくやってみたいと思います。

aws.amazon.com

まずはJupyterNotebookのEC2インスタンスを作るっぽい。 そもそも前にJupyterNotebookのインスタンス作ったことあったんですが、途中で飽きてやめてしまったので、どんなものなのかさっぱりわかりません。

とりあえず一番安そうなのをインスタンスタイプを選択。 それでも ml.t2.medium かぁ。

で、JupyterNotebookが立ち上がってきた画面がこれ。 ちなみに、インスタンス構築時の情報は超適当にやりました。 ロールも新しく作りましたし。

f:id:inui_beta:20171210011719p:plain

Pendingを待つこと数分。

f:id:inui_beta:20171210012033p:plain

上がってきました。 こっからが、まぁわからない。

雰囲気はわかるけど、何ができるのかも不明。

f:id:inui_beta:20171210012831p:plain あ、これもうファイル作ったあとです。

とりあえず中に入って、NEWしてみました。 ソースを書いて動かせるはずなので、こんな感じで動かしてみました。

f:id:inui_beta:20171210012956p:plain

ふんふん。 動いた。 で、、、こっから機械学習をしていくわけですが、今日のところはここまで。 長い道のりになりそうだ。

あまり、エンジニア関係ない話ですけど、 今日ビックカメラGoogle Home Mini買いました。 なぞに安かったので。 というか、半額って・・・

全然Googleアカウント活用していないんですが、 せっかくだし、ちょっと使ってみようかなと。 面白いことできたらネタにしようと思います。

embulk × digdag 動かしてみた2

続き。embulkをdigdagで動かしてみます。 なんか書いてる間にエラー多発して、更新遅れちゃいました・・・。

inui-beta.hatenablog.com

お題目はこんな感じ。

1. プラグインの導入

2. embulkのymlを作成

3. S3アップロード

4.digdagを利用してのファイルアップロード

5.ちょっとした応用

というわけで、前回実行したembulkをdigdagから起動してみます。

まずdigdagについて触れておきます。 ざっくりだし、別に深く考察しているわけでもないので、マジなエンジニアの方は流してください。←

簡単に言うとジョブを管理するフレームワーク的なもので、YAML形式のdigという設定ファイルに基づいて"ワークフロー"(="ジョブ")を管理します。 今回の設定ではジョブの情報をメモリ上で管理する設定にしていますが、本来はPostgreSQLとか入れて管理したり、実行状況をウォッチしたりすべきだと思います。

というわけで、本家へのリンク。 www.digdag.io

で、digファイルの構成要素は、本家のドキュメント見るのが良いかと。 僕みたいなのが使うのは、"sh>"オペレータくらいなものですが、きっともっといろいろできます。

ドキュメントリンク Workflow definition — Digdag 0.9.5 documentation

embulkのオペレータとかもあるのですが、今回最後に書く応用のところで"sh>"縛りが発生しているので、"sh>"だけ使っていきます。

まず、digdagのワークフローのテンプレートを作成します。

$ digdag init sample
$ cd ./sample
$ ls -a
  .digdag  .gitignore  sample.dig

カレントディレクトリに、sampleディレクトリが作成されて中にこのワークフローのdigファイルが作成されます。 このsample.digファイルを以下のように編集しました。

$ cat ./sample.dig
timezone: Asia/Tokyo

schedule:
  minutes_interval>: 5

+setup:
  echo>: start ${session_time}

+disp_current_date:
  echo>: ${moment(session_time).format('YYYY-MM-DD HH:mm:ss Z')}

+step1:
  sh>: /home/centos/.embulk/bin/embulk run /home/centos/bin/s3.yml > /home/cento                                                                                                                                                                s/logs/embulk_s3.log

_check:
  echo>: success.

_error:
  echo>: error!!

+teardown:
  echo>: finish ${session_time}

では、これを登録します。 コマンドは、作成されたsampleディレクトリ内で実行しております。

 $ digdag push sample
 2017-11-26 15:06:57 +0000: Digdag v0.9.20
Creating .digdag/tmp/archive-3700971538591255345.tar.gz...
  Archiving sample.dig
Workflows:
  sample.dig
Uploaded:
  id: 1
  name: sample
  revision: 04a783ad-332d-4c21-b923-eef391add5a1
  archive type: db
  project created at: 2017-11-26T15:07:00Z
  revision updated at: 2017-11-26T15:07:00Z

Use `digdag workflows` to show all workflows.

この辺は、もっとベターな方法があるかもしれませんが、いったん公式のサンプル通りに進めます。

これで準備完了です。 今回の設定ファイルは5分おき(schedule:の部分)に前回作成したs3アップロードのembulkを実行する(+step1:の部分)ようにしています。 また、成功の場合(check:の部分)は標準出力に"success."、エラーの場合(error:の部分)は"error!!"と出力するように指定しておりますので、以下に2パターンの結果を貼り付けます。

まず、errorの場合(logディレクトリ作り忘れてた・・・。)

2017-11-26 15:20:00 +0000 [INFO] (scheduler-0) io.digdag.core.workflow.WorkflowExecutor: Starting a new session project id=1 workflow name=sample session_time=2017-11-27T00:20:00+09:00
2017-11-26 15:20:00 +0000 [INFO] (0037@[0:sample]+sample+setup) io.digdag.core.agent.OperatorManager: echo>: start 2017-11-27T00:20:00+09:00
start 2017-11-27T00:20:00+09:00
2017-11-26 15:20:01 +0000 [INFO] (0037@[0:sample]+sample+disp_current_date) io.digdag.core.agent.OperatorManager: echo>: 2017-11-27 00:20:00 +09:00
2017-11-27 00:20:00 +09:00
2017-11-26 15:20:01 +0000 [INFO] (0039@[0:sample]+sample+step1) io.digdag.core.agent.OperatorManager: sh>: /home/centos/.embulk/bin/embulk run /home/centos/bin/s3.yml > /home/centos/logs/embulk_s3.log
/bin/sh: line 1: /home/centos/logs/embulk_s3.log: No such file or directory
2017-11-26 15:20:01 +0000 [ERROR] (0039@[0:sample]+sample+step1) io.digdag.core.agent.OperatorManager: Task failed with unexpected error: Command failed with code 1
java.lang.RuntimeException: Command failed with code 1
        at io.digdag.standards.operator.ShOperatorFactory$ShOperator.runTask(ShOperatorFactory.java:143)
        at io.digdag.util.BaseOperator.run(BaseOperator.java:35)
        at io.digdag.core.agent.OperatorManager.callExecutor(OperatorManager.java:312)
        at io.digdag.core.agent.OperatorManager.runWithWorkspace(OperatorManager.java:254)
        at io.digdag.core.agent.OperatorManager.lambda$runWithHeartbeat$2(OperatorManager.java:137)
        at io.digdag.core.agent.ExtractArchiveWorkspaceManager.withExtractedArchive(ExtractArchiveWorkspaceManager.java:36)
        at io.digdag.core.agent.OperatorManager.runWithHeartbeat(OperatorManager.java:135)
        at io.digdag.core.agent.OperatorManager.run(OperatorManager.java:119)
        at io.digdag.core.agent.MultiThreadAgent.lambda$null$0(MultiThreadAgent.java:127)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
2017-11-26 15:20:02 +0000 [INFO] (0037@[0:sample]+sample^error) io.digdag.core.agent.OperatorManager: echo>: error!!
error!!
2017-11-26 15:20:02 +0000 [INFO] (0039@[0:sample]+sample^failure-alert) io.digdag.core.agent.OperatorManager: type: notify

で、うまくいった場合。

2017-12-02 13:05:00 +0000 [INFO] (scheduler-0) io.digdag.core.workflow.WorkflowExecutor: Starting a new session project id=1 workflow name=sample session_time=2017-12-02T22:05:00+09:00
2017-12-02 13:05:00 +0000 [INFO] (0030@[0:sample]+sample+setup) io.digdag.core.agent.OperatorManager: echo>: start 2017-12-02T22:05:00+09:00
start 2017-12-02T22:05:00+09:00
2017-12-02 13:05:01 +0000 [INFO] (0030@[0:sample]+sample+disp_current_date) io.digdag.core.agent.OperatorManager: echo>: 2017-12-02 22:05:00 +09:00
2017-12-02 22:05:00 +09:00
2017-12-02 13:05:01 +0000 [INFO] (0030@[0:sample]+sample+step1) io.digdag.core.agent.OperatorManager: sh>: /home/centos/.embulk/bin/embulk run /home/centos/bin/s3.yml > /home/centos/logs/embulk_s3.log
OpenJDK 64-Bit Server VM warning: If the number of processors is expected to increase from one, then you should configure the number of parallel GC threads appropriately using -XX:ParallelGCThreads=N
2017-12-02 13:05:14 +0000 [INFO] (0030@[0:sample]+sample+teardown) io.digdag.core.agent.OperatorManager: echo>: finish 2017-12-02T22:05:00+09:00
finish 2017-12-02T22:05:00+09:00

JDKの警告はいったん無視。

S3へのアップロード結果がこんな感じ。

f:id:inui_beta:20171202223340p:plain

時刻が更新されているので、うまくいってる感じですね。 今回のは5分おきにスケジュールしているので、 しばらくしてから見るとこんな感じ。

f:id:inui_beta:20171202223754p:plain

更新日時が+5分。 うん。動いてる動いてる。

止めるときは以下のコマンド。 一時停止的なのもできるっぽいけど。

$ digdag delete sample
2017-12-02 14:16:14 +0000: Digdag v0.9.20
Project:
  id: 1
  name: sample
  latest revision: 08753ed6-36b2-46d6-a976-5b837810e6fd
  created at: 2017-12-02 12:58:05 +0000
  last updated at: 2017-12-02 12:58:05 +0000
Are you sure you want to delete this project? [y/N]: y
Project 'sample' is deleted.

以上、基本的な使い方。 ついでに、こんなコマンドでジョブのステータス確認もできるからいい感じ。

$ digdag schedules
2017-12-02 14:00:35 +0000: Digdag v0.9.20
Schedules:
  id: 1
  project: sample
  workflow: sample
  disabled at:
  next session time: 2017-12-02 23:05:00 +0900
  next scheduled to run at: 2017-12-02 14:05:00 +0000 (in 4m 23s)

1 entries.
Use `digdag workflows [project-name] [workflow-name]` to show workflow details.

次回実行時刻とかが見えてるのが安心感ありますね。 で、ここまでがdigdagの使い方です。

ここからはちょっとした応用。

digdagのdigファイルで設定した変数をymlに引き渡してみます。 何が便利かというと、・・・なんも考えなくても、変数をパラメータちっくに渡せるのが素晴らしい。 例えば、以下の例ではs3に日時ごとのパスを作ってアップロードしていますが、ファイル名に日時を入れたり、input定義側のqueryに日時入れたりもできるので、ジョブ管理が非常に楽ちん。 sysdateみたいなのを使うのもいいけど、再実行に困ったりしますからね。

ポイントは3つ。 digファイルで変数をセット。 ymlをyml.liquidにする。 yml.liquidからdigで定義した変数を参照する。

というわけで、以下その設定。

まずdigへ以下を追加。

_export:
  today: ${moment(session_time).format('YYYYMMDDHHmmss')}

で、ついでにymlファイルからyml.liquidへ実行ファイルを変更しておきます。

+step1:
  sh>: /home/centos/.embulk/bin/embulk run /home/centos/bin/s3.yml.liquid > /home/centos/logs/embulk_s3.log

最終的なファイルはこんな感じ。 変数"today"に日時を入れています。

timezone: Asia/Tokyo

schedule:
  minutes_interval>: 5

+setup:
  echo>: start ${session_time}

+disp_current_date:
  echo>: ${moment(session_time).format('YYYY-MM-DD HH:mm:ss Z')}

_export:
  today: ${moment(session_time).format('YYYYMMDDHHmmss')}

+step1:
  sh>: /home/centos/.embulk/bin/embulk run /home/centos/bin/s3.yml.liquid > /home/centos/logs/embulk_s3.log

_check:
  echo>: success.

_error:
  echo>: error!!

+teardown:
  echo>: finish ${session_time}

で、次にymlをyml.liquidにして、中身を編集します。

$  mv ../bin/s3.yml ../bin/s3.yml.liquid
$  vi ../bin/s3.yml.liquid

path_prefix: data/{{env.today}}/output
                       ↑ここを追加

で、これをdigdagで登録して動かすと・・・

f:id:inui_beta:20171203000835p:plain

この通り、勝手に日時のパスが作成されました。 こんな感じで環境変数で色んなものをやり取りできるのが便利ですね。 まだまだ活用のし甲斐がありそうです。

じゃあ、次回は、連携部分終わったので、BI部分に少し触れて、別のお題を検討していきます。

embulk × digdag 動かしてみた1

前回、即席ではありますが、digdagがバックグラウンド動くように設定を行いました。

inui-beta.hatenablog.com

なので、今回はdigdagでジョブ定義して、embulkによるデータ連携を動かしたいと思います。

事前準備が長かったですね。 とりあえず、手元に何もデータが無いので適当にローカルからS3とかやってみましょうかね。

今回の手順は以下のような感じ。

  1. プラグインの導入

  2. embulkのymlを作成

  3. S3アップロード

  4. digdagを利用してのファイルアップロード

  5. ちょっとした応用 そんな感じで、はじめていきます。

とりあえずテストデータは手元にあったのを利用。 AWSのコンソールからs3にアップロードして、 embulkでダウンロードしたのを別バケットにアップロードしてみます。

ダウンロードするファイルとアップロード先は、こんな感じです。

f:id:inui_beta:20171119235611p:plainf:id:inui_beta:20171119235619p:plain
実行前

上記を行うためには、s3からダウンロードしてアップロードするプラグインが必要になります。 以下のコマンドで導入できます。

$ embulk gem install embulk-input-s3
2017-11-19 13:27:29.101 +0000: Embulk v0.8.36

********************************** INFORMATION **********************************
  Join us! Embulk-announce mailing list is up for IMPORTANT annoucement such as
    compatibility-breaking changes and key feature updates.
  https://groups.google.com/forum/#!forum/embulk-announce
*********************************************************************************


Gem plugin path is: /home/centos/.embulk/jruby/2.3.0

Fetching: embulk-input-s3-0.2.11.gem (100%)
Successfully installed embulk-input-s3-0.2.11
1 gem installed

$ embulk gem install embulk-output-s3
2017-11-19 13:28:03.321 +0000: Embulk v0.8.36

********************************** INFORMATION **********************************
  Join us! Embulk-announce mailing list is up for IMPORTANT annoucement such as
    compatibility-breaking changes and key feature updates.
  https://groups.google.com/forum/#!forum/embulk-announce
*********************************************************************************


Gem plugin path is: /home/centos/.embulk/jruby/2.3.0

Fetching: embulk-output-s3-1.4.0.gem (100%)
Successfully installed embulk-output-s3-1.4.0
1 gem installed


$ embulk gem list --local
2017-11-19 13:49:59.794 +0000: Embulk v0.8.36

********************************** INFORMATION **********************************
  Join us! Embulk-announce mailing list is up for IMPORTANT annoucement such as
    compatibility-breaking changes and key feature updates.
  https://groups.google.com/forum/#!forum/embulk-announce
*********************************************************************************


Gem plugin path is: /home/centos/.embulk/jruby/2.3.0


*** LOCAL GEMS ***

did_you_mean (default: 1.0.1)
embulk-input-s3 (0.2.11)
embulk-output-s3 (1.4.0)
jar-dependencies (default: 0.3.10)
jruby-openssl (default: 0.9.21 java)
jruby-readline (default: 1.1.1 java)
json (default: 1.8.3 java)
minitest (default: 5.4.1)
net-telnet (default: 0.1.1)
power_assert (default: 0.2.3)
psych (default: 2.2.4 java)
rake (default: 10.4.2)
rdoc (default: 4.2.0)
test-unit (default: 3.1.1)

うん入ってる入ってる。 次にymlを作成。 こんな感じでいいんじゃないですかね。 s3のパスやアクセス情報は適宜変更してください。

in:
  type: s3
  bucket: inui-input
  path_prefix: data/input
  endpoint: s3-ap-northeast-1.amazonaws.com ←環境に合わせて
  access_key_id: ひみつ ←環境に合わせて
  secret_access_key: ひみつ ←環境に合わせて
  parser:
    charset: UTF-8
    newline: CRLF
    type: csv
    delimiter: ','
    skip_header_lines: 1
    columns:
    - {name: year, type: string}
    - {name: day, type: string}
    - {name: hh, type: string}
    - {name: num, type: long}
out:
  type: s3
  path_prefix: data/output
  file_ext: .csv
  bucket: inui-output ←環境に合わせて
  endpoint: s3-ap-northeast-1.amazonaws.com ←環境に合わせて
  access_key_id: ひみつ ←環境に合わせて
  secret_access_key: ひみつ ←環境に合わせて
  formatter:
    type: csv
  parser:
    charset: UTF-8
    newline: CRLF
    type: csv
    delimiter: ','
    skip_header_lines: 1
    columns:
    - {name: year, type: string}
    - {name: day, type: string}
    - {name: hh, type: string}
    - {name: num, type: long}

それじゃあembulkを実行してみましょう! 以下のコマンドで実行。

※ここで、はじめてembulkがなんか言ってる(INFORMATION)のに気づきました。←

$ embulk run s3.yml
2017-11-19 14:40:22.740 +0000: Embulk v0.8.36

********************************** INFORMATION **********************************
  Join us! Embulk-announce mailing list is up for IMPORTANT annoucement such as
    compatibility-breaking changes and key feature updates.
  https://groups.google.com/forum/#!forum/embulk-announce
*********************************************************************************

2017-11-19 14:40:31.055 +0000 [INFO] (0001:transaction): Loaded plugin embulk-input-s3 (0.2.11)
2017-11-19 14:40:31.153 +0000 [INFO] (0001:transaction): Loaded plugin embulk-output-s3 (1.4.0)
2017-11-19 14:40:32.781 +0000 [INFO] (0001:transaction): Using local thread executor with max_threads=2 / tasks=1
2017-11-19 14:40:32.854 +0000 [INFO] (0001:transaction): {done:  0 / 1, running: 0}
2017-11-19 14:40:33.250 +0000 [INFO] (0015:task-0000): Writing S3 file 'data/output.000.00.csv'
2017-11-19 14:40:34.015 +0000 [INFO] (0001:transaction): {done:  1 / 1, running: 0}
2017-11-19 14:40:34.020 +0000 [INFO] (main): Committed.
2017-11-19 14:40:34.020 +0000 [INFO] (main): Next config diff: {"in":{"last_path":"data/input.csv"},"out":{}}

はい上手くいきました。 では確認。

f:id:inui_beta:20171119235621p:plain
実行後

アップロードされてますね。 diffとった結果も問題なし。

※厳密にはヘッダの大文字・小文字が統一されてませんでしたが・・・

あ、結構書いちゃった。digdagは来週で。←

なんか、そろそろこれ書き終わるので、なんかこういうの書いてほしいとかあったらテーマください。笑

embulk × digdag の即席環境

というわけで前回の続き。

inui-beta.hatenablog.com

embulkをジョブ管理するためのフレームワークとして、digdagを入れてみたのですが、コンソール上で起動できたけど、バックグラウンドじゃなきゃ使えないw

というわけで、バックグラウンドプロセスとして起動させる方法を探してみました。

今回のオチを先に書くと、ぶっちゃけCentOSのsystemdでも、やりたいことできたと思うんですよね。 supervisorってのを入れてデーモン化したんですが、いらないひと手間だった気がします。 とりあえず、やった手順で書きますがsystemdのバージョンのほうが絶対いいいような気がするけど・・・。

まず下準備。

今回Web調べてて見つけたのが"supervisor"で"digdag"を管理するというもの。 安易に飛びついたのがいけなかったですね。 でも、まぁ仕方ないので書いていきます。

supervisorとは!

  • プロセスのデーモン化ツール

はい、それだけ。 細かいことは気にしないのがなんちゃって流。←

まず、導入。参考にした手順のOSが違ったので適当にWeb散策して以下の手順で導入。

  1. EPELリポジトリを使えるようにする。

  2. supervisor入れる。

  3. digdagをデーモン化する。

そんな感じ。 あ、wget入ってないから入れておこう。 的なコマンドを交えて、えいや。

$ sudo yum install wget
$ wget http://ftp-srv2.kddilabs.jp/Linux/distributions/fedora/epel/epel-release-latest-7.noarch.rpm
$ sudo rpm -ivh epel-release-latest-7.noarch.rpm
$ sudo yum install supervisor --enablerepo=epel

問題なく成功。 で、確認。

$ ll /etc/supervisord.conf
-rw-r--r--. 1 root root 7953 Jul 28 23:32 /etc/supervisord.conf

できてるできてる。 で、こやつをサービス化。 この時に気づけばよかったのでは・・・

$ sudo vi supervisord.service
[Unit]
Description=Supervisor process control system for UNIX
Documentation=http://supervisord.org
After=network.target

[Service]
ExecStart=/usr/bin/supervisord -n -c /etc/supervisord.conf
ExecStop=/usr/bin/supervisorctl $OPTIONS shutdown
ExecReload=/usr/bin/supervisorctl $OPTIONS reload
KillMode=process
Restart=on-failure
RestartSec=50s

[Install]
WantedBy=multi-user.target

で、起動。

$ sudo systemctl start supervisord
$ sudo systemctl status supervisord
Nov 11 18:03:29 ip-XXX-XXX-XXX-XXX.ap-northeast-1.compute.internal systemd[1]: Started Supervisor process control system for UNIX.
Nov 11 18:03:29 ip-XXX-XXX-XXX-XXX.ap-northeast-1.compute.internal systemd[1]: Starting Supervisor process control system for UNIX...
Nov 11 18:03:29 ip-XXX-XXX-XXX-XXX.ap-northeast-1.compute.internal supervisord[1268]: 2017-11-11 18:03:29,213 CRIT Supervisor running as root (no user in config file)
Nov 11 18:03:29 ip-XXX-XXX-XXX-XXX.ap-northeast-1.compute.internal supervisord[1268]: 2017-11-11 18:03:29,213 WARN No file matches via include "/etc/supervisord.d/*.ini"
Nov 11 18:03:29 ip-XXX-XXX-XXX-XXX.ap-northeast-1.compute.internal supervisord[1268]: 2017-11-11 18:03:29,233 INFO RPC interface 'supervisor' initialized
Nov 11 18:03:29 ip-XXX-XXX-XXX-XXX.ap-northeast-1.compute.internal supervisord[1268]: 2017-11-11 18:03:29,233 CRIT Server 'inet_http_server' running without any HTTP authentication checking
Nov 11 18:03:29 ip-XXX-XXX-XXX-XXX.ap-northeast-1.compute.internal supervisord[1268]: 2017-11-11 18:03:29,234 INFO RPC interface 'supervisor' initialized
Nov 11 18:03:29 ip-XXX-XXX-XXX-XXX.ap-northeast-1.compute.internal supervisord[1268]: 2017-11-11 18:03:29,234 CRIT Server 'unix_http_server' running without any HTTP authentication checking
Nov 11 18:03:29 ip-XXX-XXX-XXX-XXX.ap-northeast-1.compute.internal supervisord[1268]: 2017-11-11 18:03:29,234 INFO supervisord started with pid 1268

なんかいくつか文句言われてるけど、とりあえず起動したっぽい。 続けて、supervisorからdigdagを起動するためのファイルを準備。

$ cat /etc/supervisord.d/digdag.ini
[program:digdag]
command=/usr/local/bin/exec-digdag.sh
stdout_logfile=/var/log/supervisor/digdag-stdout.log
stderr_logfile=/var/log/supervisor/digdag-stderr.log

定義したshの中身は、こんな感じ。 この辺はwebで拾ったものを使わせていただいています。

$ cat /usr/local/bin/exec-digdag.sh
#!/bin/sh
export PATH=$PATH:/opt/jre/bin
exec /home/centos/bin/digdag server --memory

というわけで。 これでsupervisorを再起動すると・・・

Nov 11 18:14:31 ip-XXX-XXX-XXX-XXX.ap-northeast-1.compute.internal systemd[1]: Starting Supervisor process control system for UNIX...
Nov 11 18:14:31 ip-XXX-XXX-XXX-XXX.ap-northeast-1.compute.internal supervisord[8656]: 2017-11-11 18:14:31,326 CRIT Supervisor running as root (no user in config file)
Nov 11 18:14:31 ip-XXX-XXX-XXX-XXX.ap-northeast-1.compute.internal supervisord[8656]: 2017-11-11 18:14:31,326 WARN Included extra file "/etc/supervisord.d/digdag.ini" during parsing
Nov 11 18:14:31 ip-XXX-XXX-XXX-XXX.ap-northeast-1.compute.internal supervisord[8656]: 2017-11-11 18:14:31,346 INFO RPC interface 'supervisor' initialized
Nov 11 18:14:31 ip-XXX-XXX-XXX-XXX.ap-northeast-1.compute.internal supervisord[8656]: 2017-11-11 18:14:31,346 CRIT Server 'inet_http_server' running without any HTTP authentication checking
Nov 11 18:14:31 ip-XXX-XXX-XXX-XXX.ap-northeast-1.compute.internal supervisord[8656]: 2017-11-11 18:14:31,346 INFO RPC interface 'supervisor' initialized
Nov 11 18:14:31 ip-XXX-XXX-XXX-XXX.ap-northeast-1.compute.internal supervisord[8656]: 2017-11-11 18:14:31,346 CRIT Server 'unix_http_server' running without any HTTP authentication checking
Nov 11 18:14:31 ip-XXX-XXX-XXX-XXX.ap-northeast-1.compute.internal supervisord[8656]: 2017-11-11 18:14:31,346 INFO supervisord started with pid 8656
Nov 11 18:14:32 ip-XXX-XXX-XXX-XXX.ap-northeast-1.compute.internal supervisord[8656]: 2017-11-11 18:14:32,349 INFO spawned: 'digdag' with pid 8659
Nov 11 18:14:33 ip-XXX-XXX-XXX-XXX.ap-northeast-1.compute.internal supervisord[8656]: 2017-11-11 18:14:33,700 INFO success: digdag entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

どうも動いているようだ。

$ digdag schedules
2017-11-11 18:26:53 +0000: Digdag v0.9.20
Schedules:
0 entries.
Use `digdag workflows [project-name] [workflow-name]` to show workflow details.

うんうん。起動している。 これで、とりあえず、環境が整いましたね。

ん?せきゅりてぃ?けいこく?えらー?細かい設定は各自でお願いします。←

ってわけで、ジョブを定義してembulk使ってみますかね。

embulk 動か・・・す前に動かし方を考えた

前回導入までの話を書いたので、今日は動かすところと、見せかけて(?)動かし方を考えた話を書いてみました。

inui-beta.hatenablog.com

元々某関連会社でJP1AJSというジョブ管理ツールの設定やらジョブ管理をやってたのでそういうフレームワークが欲しくなり、検討してみました。

そもそもETLとかのツールって便利なんですけど、ジョブスケジューリングはできず、結局OS標準のスケジューラ使ってみるけど、できることは限られててみたいなパターン多くないですかね?

なので、今回はやったことがないdigdagの環境を作ってみることにしました。

github.com

理由は、言わずもがな。

やっぱり、親和性って大事だと思うんだ。

で、今回の導入もいつも通り公式ページの手順で導入。

$ curl -o ~/bin/digdag --create-dirs -L "https://dl.digdag.io/digdag-latest"
$ chmod +x ~/bin/digdag
$ echo 'export PATH="$HOME/bin:$PATH"' >> ~/.bashrc
$ digdag
2017-11-05 15:38:43 +0000: Digdag v0.9.20
Usage: digdag <command> [options...]
  Local-mode commands:
    init <dir>                         create a new workflow project
    r[un] <workflow.dig>               run a workflow
    c[heck]                            show workflow definitions
    sched[uler]                        run a scheduler server
    selfupdate                         update cli to the latest version

  Server-mode commands:
    server                             start server

  Client-mode commands:
    push <project-name>                create and upload a new revision
    download <project-name>            pull an uploaded revision
    start <project-name> <name>        start a new session attempt of a workflow
    retry <attempt-id>                 retry a session
    kill <attempt-id>                  kill a running session attempt
    backfill <project-name> <name>     start sessions of a schedule for past tim                                                                                                                                                                es
    reschedule                         skip sessions of a schedule to a future t                                                                                                                                                                ime
    log <attempt-id>                   show logs of a session attempt
    workflows [project-name] [name]    show registered workflow definitions
    schedules                          show registered schedules
    disable <schedule-id>              disable a workflow schedule
    disable <project-name>             disable all workflow schedules in a proje                                                                                                                                                                ct
    disable <project-name> <name>      disable a workflow schedule
    enable <schedule-id>               enable a workflow schedule
    enable <project-name>              enable all workflow schedules in a projec                                                                                                                                                                t
    enable <project-name> <name>       enable a workflow schedule
    sessions                           show sessions for all workflows
    sessions <project-name>            show sessions for all workflows in a proj                                                                                                                                                                ect
    sessions <project-name> <name>     show sessions for a workflow
    session  <session-id>              show a single session
    attempts                           show attempts for all sessions
    attempts <session-id>              show attempts for a session
    attempt  <attempt-id>              show a single attempt
    tasks <attempt-id>                 show tasks of a session attempt
    delete <project-name>              delete a project
    secrets --project <project-name>   manage secrets
    version                            show client and server version

  Options:
    -L, --log PATH                   output log messages to a file (default: -)
    -l, --log-level LEVEL            log level (error, warn, info, debug or trac                                                                                                                                                                e)
    -X KEY=VALUE                     add a performance system config
    -c, --config PATH.properties     Configuration file (default: /home/centos/.                                                                                                                                                                config/digdag/config)

Use `<command> --help` to see detailed usage of a command.
$ digdag server -m
2017-11-05 15:50:58 +0000: Digdag v0.9.20
2017-11-05 15:51:00 +0000 [INFO] (main): secret encryption engine: disabled
2017-11-05 15:51:00 +0000 [INFO] (main): XNIO version 3.3.6.Final
2017-11-05 15:51:00 +0000 [INFO] (main): XNIO NIO Implementation Version 3.3.6.Final
2017-11-05 15:51:00 +0000 [INFO] (main): Starting server on 127.0.0.1:65432
2017-11-05 15:51:00 +0000 [INFO] (main): Bound on 127.0.0.1:65432 (api)

おお、動いた。 ・・・動いたけども? サーバモードで動かすと、このコンソールセッション開きっぱなしじゃないとだめっぽい?

なるほど。もう一台サーバ建てるかバックグラウンド起動とかにしないとだめかも。

というわけで、次回はバックグラウンドでdigdagを動作させるをやってみます。 すさまじく話が進まなくて自分でも衝撃的w

embulk 導入してみた

前回導入の経緯を書きましたが、今日は導入までのお話を書きます。

inui-beta.hatenablog.com

さて、ツールは決まりましたが、どこから手を付けてよいものか。 まずサーバですね。 これは諸事情で仮想環境のCentOSになりました。 正直、AWS上に構築したかったんですけど、ランニングコスト的な事情で。

構築の手順確認をAWSのEC2でやって、 本番の仮想環境に構築するみたいな感じでやってみました。 こういうのやるときAWS楽でいいですよね。

大まかな導入手順は以下のとおり。

  • 公式ドキュメント通りにやる

github.com

・・・。 まぁなんですかね。 だいたいマニュアル読めばなんとかなるってのが、僕の信条です。 ただ、あくまでクイックスタートなんで、結果入れなおしたりしましたけどね。

で、これだけだとリンク貼って終わりになっちゃうので、苦労話。

まず、EC2に入れないっていうねw それだけで30分くらい使ったと思う。

EC2ってデフォルトec2-userだと思ってたんですけど、違うんですね。 AmazonLinuxしか使ってなかったから知らなかった。

よくよく考えたら、Windowsは構築して運用したことあるから、ec2-userじゃないOSあるの知ってたんだけどね。

そのあと、yumで最新化して、手順通りにやったら、デフォルトユーザのホーム配下にできるという。 コマンドみりゃわかるんだからやめときゃいいのにそのまま打つのが浅はかですよね。 こういうところが"なんちゃって"w

あと、ドキュメントにJava入れてねって書いてあるのに一回Java入れずにembulkコマンド打ったしね。 確認を怠るなといういい教訓になりましたよ。

> sudo yum update
> sudo yum install java
> curl --create-dirs -o ~/.embulk/bin/embulk -L "https://dl.embulk.org/embulk-latest.jar"
> chmod +x ~/.embulk/bin/embulk
> echo 'export PATH="$HOME/.embulk/bin:$PATH"' >> ~/.bashrc
> source ~/.bashrc
> embulk 
Embulk v0.8.36
Usage: embulk [-vm-options] <command> [--options]
Commands:
   mkbundle   <directory>                             # create a new plugin bundle environment.
   bundle     [directory]                             # update a plugin bundle environment.
   run        <config.yml>                            # run a bulk load transaction.
   cleanup    <config.yml>                            # cleanup resume state.
   preview    <config.yml>                            # dry-run the bulk load without output and show preview.
   guess      <partial-config.yml> -o <output.yml>    # guess missing parameters to create a complete configuration file.
   gem        <install | list | help>                 # install a plugin or show installed plugins.
   new        <category> <name>                       # generates new plugin template
   migrate    <path>                                  # modify plugin code to use the latest Embulk plugin API
   example    [path]                                  # creates an example config file and csv file to try embulk.
   selfupdate [version]                               # upgrades embulk to the latest released version or to the specified version.

VM options:
   -E...                            Run an external script to configure environment variables in JVM
                                    (Operations not just setting envs are not recommended nor guaranteed.
                                     Expect side effects by running your external script at your own risk.)
   -J-O                             Disable JVM optimizations to speed up startup time (enabled by default if command is 'run')
   -J+O                             Enable JVM optimizations to speed up throughput
   -J...                            Set JVM options (use -J-help to see available options)
   -R...                            Set JRuby options (use -R--help to see available options)

Use `<command> --help` to see description of the commands.

はい、ここまでで導入完了。 では、次は連携を開始。。。する前に気になったこと。 これって、クーロンで実行するの?エラーってどうやってハンドリングすりゃええの?

そこで、ジョブ管理入れました。

digdagさん。

というわけで、次回は実行環境整備でございます。