再構築前のYMLバリデーション?

これは、典型的なDockerインストールを備えたプライベートVPSのセルフホスト型Discourseインストールに関するものです。

もう一度やりました。
「完璧な」アップデートの再構築を2時間かけて v3.4.0.beta2-dev に行いました。
次に、app.ymlに数行追加し、さらに2時間かけて別の再構築を行いました。
(なぜ操作を分けたのか? エラーの可能性がある場合、二重のパンチは決して良くないからです。)
その後、app.ymlにスペースを入れ忘れた(MaxMindアカウントとキーのため)ために、ログに実行時エラーが見つかりました。
そのため、今夜はさらに別の再構築が必要です。

これは、WordPressやその他のCMSサイトが同じシナリオで数分しかかからないのと比較して、6時間以上の仮想ダウンタイムに相当します。これは「悪いUX」であり、したがって「アンチマーケティング」を叫んでいます。プラットフォームにとって良くありません。

2回目の再構築が必要だった唯一の理由は、これらの忌々しい2行を追加したためです。この設定ファイルでの小さな変更だけで、完全な再構築が必要になるなんて、本当に残念です。

  1. 再構築の前にymlファイルの検証を行うことについて、何か話し合いはありましたか? その単純な機能があれば、時間のかかる操作とそれに続く問題を排除できたでしょう。

  2. 特定の変更後に完全な再構築が必要かどうかを判断するプリプロセッサについて、何か話し合いはありましたか?

  3. YAMLエラーがログに報告されなかったことに驚いています。実行時のメイン.ymlフォルダやその他のフォルダが構文エラーに対してチェックされない理由は何ですか? …それとも、より経験豊富な管理者は、再構築に独自のリンティングを行いますか? :thinking:

Dockerをホストしているのは、このシステムをメンテナンスのために他の人に引き継ぐ場合に「最も簡単」だと信じているからです。それが正しくなく、私が「最も簡単ではない」だけでなく「最も遅い」を選択した場合、別のインストールオプションを検討すべきかもしれません。

ありがとうございます!

古いコンテナが稼働し続ける一方で、新しいコンテナを構築できる2コンテナ構成では、新しいコンテナが起動するまでのダウンタイムは1分程度です。

それは非常に親切な再構築時間ですね。Piか、それに類する非常に遅いものを使っているのですか?

通常、YAML設定に問題がある場合はすぐに通知されます。

ファイルサイズを確認するには、このコードを使用してください。これにより、スペースの問題かどうかを分析できます。

/var/discourse# du -sh /* | sort -h

MaxMind の 2 つのスペースを除いて、それは機能しますが、ジオロケーションは機能しません。したがって、それは YAML の構文エラーというわけではありませんが、それでもエラーです :man_shrugging:

「いいね!」 1