production や development といった環境によってホスト名が違ったりする場合にどう切り替えるか。
1. digdag start の --param オプションで指定する
$ digdag start —-param environment=development --param endpoint=http://localhost:5432 ...
利点
- 実行ごとにパラメータを変えられるので柔軟
欠点
- 必須なパラメータがあるような場合に Web UI から RUN ボタンを押しても動かなくなる(パラメータ未指定の digdag start と同じ)
- 実行のたびにパラメータを1つずつ渡すのは面倒?
2. digdag start の --param-file オプションで指定する
development.yml
environment: development
endpoint: http://localhost:5432
$ digdag start --param-file=development.yml ....
利点
- (--param と比較して)パラメータをまとめて渡せるので楽
欠点
- 必須なパラメータがあるような場合に Web UI から RUN ボタンを押しても動かなくなる(パラメータ未指定の digdag start と同じ)
- development.yml と production.yml に共通パラメータがある場合に、ファイルが別れているので YAML のアンカー機能が使えなくてちょっと不便。
3. digdag server の --param オプションで指定する
$ digdag server —-param environment=development --param endpoint=http://localhost:65432
利点
- 必須なパラメータがあるような場合でも Web UI から RUN ボタンを押して動く
欠点
- パラメータを更新するためにはサーバを再起動しなければならない
4. digdag server の --param-file オプションで指定する
development.yml
environment: development
endpoint: http://localhost:5432
$ digdag server —-param-file development.yml
利点
- 必須なパラメータがあるような場合でも Web UI から RUN ボタンを押して動く
欠点
- パラメータを更新するためにはサーバを再起動しなければならない
- development.yml と production.yml に共通パラメータがある場合に、ファイルが別れているので YAML のアンカー機能が使えなくてちょっと不便。
5. Python (Ruby) API で環境設定ファイルを読み込む
digdag server 起動時には environment=環境
パラメータだけ渡して起動する
$ digdag server —-param environment=development ...
environment.yml
と
environment.yml
defaults: &defaults
slack_username: digdag
production:
<<: *defaults
endpoint: https://production.example.com
development:
<<: *defaults
endpoint: http://localhost:5432
tasks/__init__.py
を用意して
tasks/__init__.py
import digdag
import yaml
class Environment(object):
def load(self):
environment = digdag.env.params.get("environment", "development")
params = {}
with open("environment.yml", "r") as f:
data = yaml.load(f)
params = data[environment]
digdag.env.store(params)
.dig ファイルの先頭で実行して environment.yml を読み込んで、digdag.env.store で環境パラメータを設定するようにする。
+prepare_environment:
py>: tasks.Environment.load
パラメータを更新したい場合は environment.yml を digdag push し直す
利点
- 必須なパラメータがあるような場合でも Web UI から RUN ボタンを押して動く
- パラメータを更新するためにサーバを再起動しなくても digdag push すれば良い
- digdag project をコードで管理していれば、コードで見える化される。Infrastructure as Codes
- development と production に共通パラメータがある場合に、アンカー機能を使って共通化できる
欠点
- .dig ファイルの先頭で呼び出すように修正する必要があり、ちょっと準備が面倒?
ref. https://qiita.com/katsuyan/items/0fd58af5763a655b9b03
6. 環境ごとに digdag secrets で違う値を登録する
digdag secrets —-param environment=development --param endpoint=http://localhost:65432 ...
.dig ファイルでは
${secret:environment}
なり
_env:
environment: ${secret:environment}
endpoint: ${secret:endpoint}
のようにパラメータにマップして使う。FYI: digdag secrets を楽して環境変数にマップしたい
利点
- 必須なパラメータがあるような場合でも Web UI から RUN ボタンを押して動く
- パラメータを更新するためにサーバを再起動しなくても digdag secrets で登録しなおせば良い
欠点
- secret ではない情報を digdag secrets で管理するのは悪用が過ぎる
- 別途管理しないと、どの環境にどの値を登録したのかわからなくなる
まとめ
個人的には、秘匿情報に関しては6を併用しつつ、5を使うのが良いかな、と思っている。