Digdagのserverモードで環境毎に設定値を変える６つの方法

production や development といった環境によってホスト名が違ったりする場合にどう切り替えるか。

## 1. digdag start の --param オプションで指定する

```
$ digdag start —-param environment=development --param endpoint=http://localhost:5432 ...
```

**利点**

* 実行ごとにパラメータを変えられるので柔軟

**欠点**

* 必須なパラメータがあるような場合に Web UI から RUN ボタンを押しても動かなくなる(パラメータ未指定の digdag start と同じ)
* 実行のたびにパラメータを１つずつ渡すのは面倒?

## 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` と

```yaml:environment.yml
defaults: &defaults
  slack_username: digdag
production:
  <<: *defaults
  endpoint: https://production.example.com
development:
  <<: *defaults
  endpoint: http://localhost:5432
```

`tasks/__init__.py` を用意して

```python: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 で環境パラメータを設定するようにする。

```yaml
+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 を楽して環境変数にマップしたい](https://qiita.com/sonots/items/cb71834857235f965225)

**利点**

* 必須なパラメータがあるような場合でも Web UI から RUN ボタンを押して動く
* パラメータを更新するためにサーバを再起動しなくても digdag secrets で登録しなおせば良い

**欠点**

* secret ではない情報を digdag secrets で管理するのは悪用が過ぎる
* 別途管理しないと、どの環境にどの値を登録したのかわからなくなる

## まとめ

個人的には、秘匿情報に関しては6を併用しつつ、5を使うのが良いかな、と思っている。