UXからアップデートを行うと、最終的にはコマンドラインアップデートを実行する必要があるというメッセージが表示されます。これはDebianではなく、ベースとなるDiscourseイメージに依存します。
「いいね！」 2
そして、2コンテナ方式ではGUIの更新ボタンは全くなくなるということでよろしいでしょうか？
GUIのアップデートは discourse_docker プラグインから提供されます。そのプラグインをお持ちであれば、GUIのアップデートが適用されます。
画像操作ツールで脆弱性が発見された場合、過去にリモートコード実行例外が発生したことは間違いありません。つまり、システムが侵害されるのは画像アップロード1回分ということです。
Clear Linuxは、Linuxでの起動速度の基準を設定しました。素晴らしい仕事であり、心から推奨します。
「いいね！」 1
ああ、それは少し状況を変えますね。なぜか、GUIアップデーターが標準的でない2コンテナのインストールでは機能しないと思っていました。その場合、管理者が技術的に有能である限り、2コンテナのインストールにはあまりデメリットがないように思えます。例えば、携帯電話だけで旅行中に、主要なDiscourseのセキュリティアップデートが出た場合でも、SSHアクセスなしで少なくともそれを適用できるので、GUIアップデートは絶対に欲しいです。
「いいね！」 1
それが私の考えです。PostgresまたはRedisのアップグレードでデータコンテナを再構築する必要があるときを知るために注意を払うだけで十分です。また、./launcher bootstrap web_only && ./launcher destry web_only; ./launcher start web_onlyを実行する必要があることも知っておく必要がありますが、それはそれほど難しくありません。単に./launcher rebuild web_onlyを実行することもできますが、再構築中はサイトがダウンします。
「いいね！」 2
念のため補足しておきます。Web UI のビルドには通常、ダウンタイムは全くありません。ブートストラップ/破棄/開始には最小限のダウンタイムがあり、ドキュメントに記載されているように、外部の Nginx を使用してメンテナンス ページを提供する場合にのみ、通常どおり実行します。しかし、これはコンテナに IPv6 アドレスを割り当てるためだけでも、常に良い習慣です。
はい、ありがとうございます。2コンテナのインストールでも、コンテナの再構築が必要な場合にDiscourseダッシュボードの通知は引き続き表示されますか？その場合、アプリコンテナのみを再構築するか、データコンテナも再構築するかを判断できますか？
「いいね！」 1
はい。まだ「バージョンのみ変更」の3.1.0.beta1アップデートを適用していないため、今すぐ確認できます。
「いいね！」 1
これは「問題ないうちは問題ない」というケースです。UIでのアップデートが失敗したときにユーザーはパニックになりますが、問題を回避するために git pull; ./launcher rebuild app を実行する必要があることを知りません。これは、GUIのアップデートが無効になる変更があるたびに発生していると思います。今回もまた発生しました。
このパニックは、この経験を避けるための、一貫性のある通常のアップデートメカニズムを持つことの重要性を浮き彫りにしていると感じます。
同時に、ブートストラップが実行中のシステムを破損させる、これもまた稀なケースに遭遇しました。ゼロダウンタイムアップデートは、年に1、2回程度、このように壊れることがありますか？そのため、ブートストラップと破棄/開始の間に遅延を設けないでください。
それを明確にするためにテキストを更新する必要があります。次にそうします。
LibreTranslate をまだデプロイしていませんが、サイトの国際的な利用可能性を高めるためにデプロイすることを検討しています。
もし成功したら、それを最初の投稿に編集するつもりです。
「いいね！」 2