4

私は幸運にもdjango_compressorを発見し、それをスタック内に実装しました。これは多くのサーバーにデプロイされます (現在は 6 台ですが、より小さな仮想マシンをデプロイするにつれて成長しています)。

django_compressor を最高の状態で使用している場合、これはすべてうまくいきます。生の CSS/JS コードの圧縮

ただし、ここで、ある種のプリコンパイラを導入したいとします。この例では、LESS (css) としましょう。このための思考プロセスは非常に単純です。

  • node、npm、および less パッケージをサーバーにインストールします。

  • プリコンパイラへの追加を減らしましょう!

    COMPRESS_PRECOMPILERS = (('text/less', 'lessc {infile} {outfile}'), )

これでデプロイすると、サーバーが less ファイルをコンパイルします。すべてが素晴らしいです!

これにさらに 8 つのサーバーを追加して、各サーバーに node、npm、および less をインストールする必要がありますか?

これは何かが正しくないように思われる場所であり、何かが欠けているように感じます. Django コミュニティは以前にもこの問題に遭遇したことがあると思います。

これまでの私の考えは次のとおりです。

  • post-commit フックを使用して、開発者のマシンで CSS をコンパイルします。これは、django_compressor を介して、HTML 内のコンパイル済み静的ファイルにリンクし、リポジトリにはコンパイル済みバージョンとコンパイル済みバージョンの両方が含まれていることを意味します。これに対する私の唯一の欠点は、django_compressor の利点の半分を使用しないことになり、開発者にとって退屈になる可能性があることです?

  • それを吸い上げて、ノード、npm、およびサーバースタックの一部を少なくします。

アップデート

さらに調べてみたところCOMPRESS_OFFLINE、管理コマンドでフラグ (または単に --force) を使用すると、必要なことを実行するオフライン マニフェスト ファイルが生成されるようです (ローカルでのみテストされます)。そのため、デプロイ前のフックを使用してこれを設定することが答えになります。

もちろん、他のアイデアにもまだオープンです:-)

4

2 に答える 2

0

タスクにパペットを使用できます

于 2013-03-28T22:56:06.573 に答える
0

に関するコメントのヒントと合わせて、COMPRESS_OFFLINEdjango-staticfiles のストレージに関する情報を確認できます。たとえば、Amazon s3 で静的ファイルをホストできるので、1 つの静的ホスティング サーバーですべてをホストし、すべてのサーバーからそれを使用することも、優れたソリューションになる可能性があります。個々のサーバー上の静的 (および圧縮) ファイルに対して何もする必要はありません。

複数のサーバーに関する代替ソリューション: サーバーにインストール/構成するカスタム ファブリック (docs.fabfile.org) スクリプトを作成しました。私は最近、coffeescript 以下を使い始めたばかりですが、これら 2 つは確実に fabfile に入っています。これでインストールの問題は解決しました。

(fabfile に代わるものは、標準の依存関係を持つカスタム debian パッケージのようなものです。または、chef や puppet などです。)

于 2012-03-23T13:11:57.847 に答える