こんにちは。
Discourse を 2 つの別々の Azure VM (ステージングと本番) にインストールしています。ステージング Discourse から本番 Discourse への変更を自動的にデプロイする方法はありますか?
UI の変更 (テーマ) は Git リポジトリで管理されるため、本番環境への出荷は問題ありません。主な懸念は、Discourse の設定と構成のデプロイを本番環境に自動化することです。これをどのように達成できますか?
こんにちは。
Discourse を 2 つの別々の Azure VM (ステージングと本番) にインストールしています。ステージング Discourse から本番 Discourse への変更を自動的にデプロイする方法はありますか?
UI の変更 (テーマ) は Git リポジトリで管理されるため、本番環境への出荷は問題ありません。主な懸念は、Discourse の設定と構成のデプロイを本番環境に自動化することです。これをどのように達成できますか?
ステージングコンテナをリポジトリにプッシュしてから、本番環境で起動できます。./launcher start-cmd app を実行すると、Dockerでコンテナを起動するために必要なものが得られます。
また、データベースの移行(ゼロダウンタイムを実現したい場合は、SKIP_POST_DEPLOYMENT_MIGRATIONS を使用してから、新しいコンテナが起動した後に再度移行する可能性があります)とアセットのプリコンパイルも必要になります。
一部の設定はデータベースに保存されます。その他は、DISCOURSE_SETTING_NAME(例: DISCOURSE_TITLE='my great communiyt')のような環境変数で設定できます。
より軽量な戦略は、これを使用することです。
右上にある「オーバーライドのみ表示」に注意してください。
これにより、デフォルトではないもののリストが表示され、手動で転送できる可能性があります。
必要に応じて、こちらの方が簡単な場合があります。(とはいえ、私の数年使用しているインスタンスには、デフォルトではない設定が100以上あります。)
app.yml は部分的にコピーできます。
もちろん、これによりカテゴリなどは引き継がれません。
これはスタンドアロンのアプローチで達成できますか、それとも2つのコンテナ(1つはデータベース用、もう1つはWeb用)が必要ですか?
もしあなたが趣味でやっているわけではないなら、コンテナを2つ使うことをお勧めします。新しいコンテナを起動する際にデータベースをシャットダウンする必要があるため、ゼロダウンタイムは実現できません。しかし、コンテナ1つでも機能します。