再読み込みと起動
再起動なしでのファイルの変更と、起動時に起きること
再起動せずにファイルを変更する
シードは CONFIG_SEED_RELOAD_SECONDS ごと（既定は 60、 0 でオフ）に読み直され、 内容が変わっていれば再適用されます。そのため、git にコミットした変更は実行中のインスタンスに 自動的に届きます。Kubernetes では、 ConfigMap は約 1 分以内に Pod の下に再マウントされ、 次の確認でそれが取り込まれます。ロールアウトも再起動も不要で、何かを呼び出すフックも 必要ありません。
変更されていないファイルの場合、ポーリングはハッシュを一つ計算して止まるので、すでに適用した行を 書き直すことはありません。
次の確認を待たずにすぐファイルを適用するには、次のどちらかを使います。
POST /api/v2/config-seed/apply # settings admin ; answers with what it did
kill -HUP 1 # inside the container, no credentials needed
どちらも、ファイルが変わっていなくても適用を 強制 します。強制した適用では、データベースで直接編集された 管理対象のレコードが再び適用され、作業ツリーがない宣言済みのリポジトリが再びクローンされます。
起動時の適用と違い、再読み込みが 致命的になることはありません 。すでにサービスを提供しているインスタンスは 現在の設定を保ち、理由がログに記録され、ステータスページの Config seed の行が赤くなってその理由を 示します。git にプッシュした誤字のせいで、運用者が何もしないうちに実行中のインスタンスが停止することがあってはなりません。
同じ壊れた内容が確認のたびに再試行されることもありません。そうでなければ、一つの誤った編集で同じエラーが 際限なくログに書き込まれてしまいます。ファイルを修正するか、エンドポイントを呼び出してすぐに再試行してください。
壊れたシードは起動を拒否する
読み取れないファイル、無効な YAML、不明なフィールド、重複した名前、解決できない ${VARIABLE} があると、サーバーは起動せずに 終了 します。これは 起動時 の経路だけです。 すでに稼働しているインスタンスに同じファイルが与える影響については、上の注記を参照してください。
これは意図的です。以前の設定のまま続行すると、そのインスタンスの動作は、それを記述するはずのマニフェストと 一致しなくなり、しかもその不一致を報告するものが何もありません。理由はログファイルだけでなく標準エラーにも書き込まれるので、 kubectl logs と docker logs で確認できます。
検証は厳格です。不明なフィールドは無視されずに拒否され、エラーには 問題のキーが示されます。
Config seed failed, refusing to start: Seed file validation failed: /awx/items/0 must NOT have additional properties 'tokenn'
空のデータベースは自分で構築される
ALLOW_SCHEMA_CREATION がオン（既定）の場合、 AnsibleForms のテーブルがまったくない データベースでは、 起動時にスキーマが作成されます。そのため、新しいデプロイメントは、誰かが手動で /schema エンドポイントを 呼び出さなくても起動します。
この前提条件は意図的に厳格です。スキーマの作成では 最初にすべてのテーブルが削除される ので、 完全に空のデータベースに対してしか実行されません。列が一つ欠けているデータベースや、テーブルはあってもユーザーアカウントがない データベースは、空では なく 、そのまま残されます。そうしたケースはスキーマのパッチが処理します。