最近の検索
検索オプション
うーん、何かつかめた気がする
たぶん私が欲しかったアプリインフラ管理は、宣言的であるとかステートレスであるとかが重要なのではなく、「どうしても発生してしまう保持すべきステートは簡単に移動でき、保持する必要のない部分は宣言から再構築できる」という部分が本質なのか
で、 docker-compose.yml (not compose.yml) 含めあれこれ ansible でデプロイするのは、「保持する必要のない部分は宣言から再構築できる」を実現しているとはいえるが、「ステートを簡単に移動できる」の部分が微妙。特に、ホストの IPv6 アドレスや /64 prefix に依存している (せざるを得なかった) 設定ファイルなんかがあったとき、
ステートを移動する→ステートの一部を宣言から生成したデータで上書きする
という手順が必要になって、ここで作業の順序 (依存関係) が発生してしまうのがあまりにダルいし間違いの元になる。私が今の方式で一番気に入っていないのが、たぶんこれだ
k8s が魅力的に見えた (結局ちゃんと使ってないけど) のは、「ステートの移動」の部分を含めてうまくやってくれそうに見えたからなんだよな。実際どうなのかは別として。
現状の手元でのモデル化の試みも、うまくいっていないことはないけど微妙ではあるんだよな。 XDG base directory のアレを参考に conf, data, cache と分けてみたけど、たとえば「事あるごとにスクリプトから再生成されるが、勝手に消されては困るような設定ファイル」みたいなのは conf に置くべきなのか data なのか、それとも cache なのか……みたいなところがいまひとつしっくりこない
役割や生存期間ではなくて、生成者で分けないといけなかったのかな。orchestrator と、user-defined startup script と、 app-provided startup と、 app state の4つ？