管理対象オブジェクト
シードが一覧にしたオブジェクトをどのように所有し、シークレットをどのように外に置くか
単一行のセクションはすべてか無しか
ldap 、 settings 、 chat はそれぞれ 単一行 なので、シードはそのすべてのフィールドを宣言する必要があります。ほかのセクションはリストです。
フィールドを省いたシードは起動を拒否し、そのフィールドの名前を示します。
Config seed failed, refusing to start: Seed file validation failed: /settings must have required property 'mail_server'
空の値は "" または false で明示的に宣言します。いくつかのフィールドは任意で、省いた場合は変更されません。
| セクション | 任意のフィールド |
|---|---|
ldap | description 、 credential （バインドに使う認証情報）、 groupfilter |
chat | auth_type 、 api_version 、 request_user 、 ignore_certs 、 extra_headers |
settings | なし |
settings が対象とするのはメールのフィールドと URL だけです。ほかの設定はすべて編集可能なままです。
ファイルはシークレットを持たない
各 ${VARIABLE} はその環境変数（Kubernetes では Secret から）で置き換えられるので、ファイルは Git に置けます。
設定されていない変数は 致命的なエラー になるので、プレースホルダーがパスワードとして保存されてしまうことは決してありません。
認証情報は シークレットストア （ secret_store 、 secret_ref ）も使えます。 vault_path は 8 で削除されます。
管理対象オブジェクト
シードから来たオブジェクトには 管理対象 のフラグが付きます。
- 起動のたびに 適用されるので、ファイルが正であり続けます。
- 読み取り専用です。API は 403 を返し、インターフェースでは編集と削除が無効になり、そのページには構成 シードファイルから来ていて読み取り専用であることが表示されます。
- フラグを設定または解除できるのはシードだけです。
手動で作成したオブジェクトは、シードが同じ名前を宣言しない限り 決して変更されません 。宣言した場合、そのレコードは 引き継がれ 、 宣言したフィールドが適用されて読み取り専用になります。引き継ぎは警告としてログに記録され、監査証跡にも残ります。
シードの適用はべき等です。すでに一致しているレコードはそのまま残るので、再起動では通常 0 updated と報告されます。
作業ツリーがない宣言済みのリポジトリは、起動のたびに 再びクローンされる ので、最初のクローンが失敗しても 再試行されます。ステータスページの リポジトリ の行には、作業ツリーのないリポジトリが表示されます。
オブジェクトの削除
ファイルからオブジェクトを削除すると、それは 解放 されます。レコードは残り、再び編集可能になります。セクション全体を削除しても 同じです。
ファイルがもう宣言していない管理対象のレコードを 削除 するには、リストのセクションに prune: true を追加します。
credentials:
prune: true
items:
- name: production-db
# anything else the seed used to manage is deleted
prune が手動で作成したレコードを削除することはありません。
シードをオフにする
CONFIG_SEED_PATH の設定を外しても、何も 解放されません 。シードが適用されなくなるだけで、シードが管理していたレコードは管理対象のまま 読み取り専用で残ります。再び編集するには、先にそれらを解放してください。 CONFIG_SEED_PATH をそれらを含まないファイルに向け（空のファイルは何も宣言せず、 すべてのレコードを解放します）、起動時または再読み込みで適用させてから、変数の設定を外します。解放されたレコードはそのまま 残り、編集可能になります。