こんにちは、皆さん。
私は自分のローカルコンピュータに Discourse をインストールしています。
http://localhost:4200/
これはこのガイドに従って行いました。ここでは Discourse、テーマ、プラグインの開発を行っています。
また、仮想マシン上にも Docker を使用して Discourse をインストールしています。これはこのガイドに従ったものです。
これらのインストールは非常にうまく機能しています。
しかし、Docker が何なのか、なぜ仮想マシンのファイルとローカルコンピュータのファイルが異なるのか、理解できていません。
仮想マシンで d/shutdown_dev コマンドを使って Docker を停止するとどうなるのでしょうか?
Git を使ってこれらの 2 つのインストールを同期するにはどうすればよいでしょうか?
ローカルマシンに Docker をインストールすることは可能でしょうか?また、それは何のために必要なのでしょうか?
これらの疑問についてご教授ください。
rudzainy
(Rudzainy Rahman)
2
処理の流れを説明してみましょう。
- コードベース(
/discourse 内)で作業する。
- コードベースを Docker コンテナにコンパイルする。
- その Docker コンテナを本番サーバーにデプロイする。
ローカルで Docker を実行する用途の 1 つは、本番サーバーにデプロイする前に、新しくコンパイルした Docker コンテナをテストすることです。
「いいね!」 1
Docker の有無は、プラグインやテーマコンポーネントの開発のほとんどにおいて、ほぼ無関係です。これは別の問題です。私は開発環境で Docker インスタンスを実行していません。
Discourse 用のアドオンを開発する際、開発環境と本番環境の正確なバージョンや設定に固執する必要はありません。オープンソースの場合、プラグインが最終的にデプロイされるインスタンスのほとんどをあなたが制御できないことが通常だからです。最も重要なのは、Discourse コアの変更に対してアドオンをより堅牢にするためのベストプラクティスに従うことです。たとえ自分自身の Discourse インスタンスのみを対象に開発している場合でも、Discourse コアの変更を制御できないため、同じアプローチが適用されます。
わずかなバージョンの違いが、通常、プラグインやテーマコンポーネントの失敗を引き起こすべきではありません。起こり得ることはありますが、一貫性はありません。私のプラグインやテーマコンポーネントは、数ヶ月にわたって変更を必要とせず、コアのコミットが数ヶ月離れていても動作します。
私は通常、プラグインの変更(修正や機能強化)に取り組む際、開発環境を最新の master ブランチに更新します。これにより、破壊的変更をすべて拾うことができます。これは、git pull、bundle install、db:migrate を実行するだけで簡単に実現できます。
本番環境のインスタンスは、フロントエンドから、またはコマンドラインでのリビルドを通じて更新するだけです。
私のアドバイスとしては、プラグインを公開してユーザーを集め、経験を通じて道中の課題を学んでください。先送りにしすぎず、実際に行動しましょう。また、間違いを恐れないでください。それらは学びの助けになります。
「いいね!」 6
ご回答いただき、誠にありがとうございます。
開発を試みてみます。
つまり、app.yaml ファイルから「git clone /github…docker」を削除して、再ビルドすればよいのでしょうか?
そのような質問は、Docker 開発に関するトピック で尋ねることをお勧めします。現時点では、非常に明確な理由がない限り、Docker 開発環境の維持に使用されるデフォルトのスクリプトを変更しないでください。それらはあなたを支援するために用意されているはずです。
「いいね!」 1