1

プランA-uwsgi経由でPlone

dotcloudにwsgi経由でploneをデプロイしようとしています。

これまで、dotcloudツールをインストールし、すべての要素をdotcloudに正常にデプロイするgitリポジトリを作成しました。githubを使用して、関連するすべての構成を保存します。試してみたい場合は、現在デプロイに使用しているコマンドを次に示します。

git clone github@github.com/pigeonflight/stack-python-plone
cd stack-python-plone
dotcloud create plone
dotcloud push

デプロイ後、（dotcloudインスタンスに「sshing」した後）次のコマンドでpasterを使用してスタックを起動できることを確認できました。

cd current
bin/paster serve production.ini

しかし、そのURLでアプリケーションにアクセスしようとすると、uwsgiエラーが発生し、Pythonアプリケーションが見つかりません。

私のwsgi.pyファイルは次のようになります。

import os
from paste.deploy import loadapp
current_dir = os.getcwd()
application = loadapp('config:production.ini', relative_to=current_dir)

アップデート

プランAはうまくいきません。私は当初、uwsgiがdotcloud上のPythonアプリの唯一のオプションであるという仮定から始めました。

プランB-ウェブサーバーによってプロキシされたポートでPlone

私は今、Ploneをポートで実行しているワーカーとして使用し、次にproxy_passを使用してサイトにサービスを提供するプランBを開いています。追加の利点として、「Webサーバーによってプロキシされたポート上のPlone」は、他のシナリオでのPloneの標準的なデプロイメントアプローチに近くなります。

4

3 に答える 3

2

Ken Cochraneとjpetazzoからの回答は、どちらも私を解決策に導くのに役立ちました。私は今のところwsgiを放棄することにしました。このソリューションでは、dotcloudpythonサービスとそれに付随するnginxWebサーバーをさらに深く掘り下げる必要がありました。proxy_passを構成するディレクティブをnginxに渡す方法を見つけました。

結果のスタックは、https ：//github.com/pigeonflight/stack-python-ploneでホストされます。

重要なブレークスルーは、 plone-uwsgi.confファイルを作成することでnginxにコマンドを渡すことができることに気付いたときでした。私の目的では、追加のwsgi構成を渡すことを目的としたファイルを「ハイジャック」し、それを別の目的に使用しています。nginxサーバーは、nginx.confファイル内の他のキーディレクティブ（location / {}ディレクティブなど）の後に* uwsgi.confファイルを読み取るように構成されています。これにより、（不要な）wsgiコードをオーバーライドするための理想的な方法が提供されました。このファイルを使用してproxy_passディレクティブを「挿入」する場合。

私のplone-uwsgi.confファイルは次のようになります。

  # This configuration file overrides the default file and allows you to run
  # your zope instance at the root of your dotcloud instance
  location ^~ / {
     rewrite ^(.*)$ /VirtualHostBase/http/$http_host:80/VirtualHostRoot$1 break;
     proxy_pass   http://127.0.0.1:8080;
     include /home/dotcloud/current/proxy.conf;
  }

また、plone-uwsgi.confファイルに含めたproxy.confというファイルに追加の設定を保存しました。

これが私のproxy.confファイルです：

client_max_body_size            0;
client_body_buffer_size    128k;
client_body_temp_path      /home/dotcloud/current/var/client_body_temp;

proxy_connect_timeout      90;
proxy_send_timeout         90;
proxy_read_timeout         90;
proxy_buffer_size          4k;
proxy_buffers              4 32k;
proxy_busy_buffers_size    64k;
proxy_temp_file_write_size 64k;
proxy_temp_path            /home/dotcloud/current/var/proxy_temp;
proxy_redirect                  off;
proxy_set_header                Host $host;
proxy_set_header                X-Real-IP $remote_addr;
proxy_set_header                X-Forwarded-For $proxy_add_x_forwarded_for;

要約すると、次のコマンドを使用して、dotcloudサンドボックスで新しいploneサイトを起動できるはずです。

instance=instancename
git clone git://github.com/pigeonflight/stack-python-plone.git $instance
cd $instance
dotcloud create $instance

に続く：

dotcloud push

考えられる問題： dotcloudがワーカーインスタンスに変更を加えた場合に、カスタムスクリプトによってダウンロードされたプリコンパイル済みパッケージが引き続き機能するかどうかはわかりません。

于 2012-11-14T04:51:18.943 に答える
0

私はしばらくの間Ploneを実行しようとしませんでした。前回（〜1年前）、「pip install Plone」でインストールすることは可能でしたが、（IIRCがZopeやその他のものをコンパイルするところまで行ったため）永遠にかかり、機能しませんでした（卵のため） -プロジェクトの具体化は100％完了していませんでした）。

物事がまだその状態にあると仮定するとpython-worker、HTTPポートを公開するサービス内でPloneのデフォルトレシピ（それまではビルドアウトを使用）を使用します。通常のpythonサービスとの主な違いは、python-worker + HTTPソリューションにはuwsgiが付属していないため、pasterPlone統合インストーラーによってデプロイされたものを実行できることです。

最終結果は標準のPloneインストールに近くなります。これはおそらく良いことです！

于 2012-11-12T21:19:47.507 に答える
0

いくつかの質問/コメント。

  1. getplone.shスクリプトで、新しいvirtualenvを作成していますか？なぜあなたはこれをやっている？〜/ envの下にすでにvirtualenvが作成されています（/ home / dotcloud / envはフルパスです）。

    何かをインストールしたい場合は、〜/ env / bin / pipを使用できます。さらに良いのは、requirements.txt現在空になっていることに気付いたファイルに要件を入れることです。

    dotCloudのコード依存関係の詳細については、次のリンクを参照してください：http: //docs.dotcloud.com/0.9/services/python/#code-dependencies

  2. Python 2.7が必要な場合は、で設定する必要がありますdotcloud.yml。詳細については、このリンクを参照してください。http://docs.dotcloud.com/0.9/services/python/#python-versions

    これは、Pythonバージョンを追加した後のdotcloud.ymlの外観です。

dotcloud.yml

www:
    type: python
    postinstall: ./getplone.sh
    config:
        python_version: v2.7
db:
    type: postgresql

結論として、それが機能しない理由は、wsgiが〜/ env virtualenvを使用するように設定されているためだと思います。また、独自のvirtualenvを作成し、そこにコードを配置しているため、uWSGIは使用できません。アプリケーションを見つけます。したがって、デフォルトのvirtualenvを使用するように変更すると、計画どおりに機能するはずです。私が提案した変更を試してみて、それらがあなたのために働くかどうかを確認してください。

于 2012-11-12T14:29:56.633 に答える