Plan A - Plone via uwsgi
I'm trying to deploy plone via wsgi on dotcloud.
So far I've installed the dotcloud tools and created a git repository that successfully deploys all the pieces to dotcloud. I use github to store all the relevant configuration. If you'd like to try it out these are the commands I'm currently using to deploy:
git clone [email protected]/pigeonflight/stack-python-plone
cd stack-python-plone
dotcloud create plone
dotcloud push
After deployment I was able to confirm (after "sshing" in to my dotcloud instance) that I am able to launch the stack using paster with the following command:
cd current
bin/paster serve production.ini
But when I try to visit the application at its url I get a uwsgi error, python application not found.
My wsgi.py file looks like this:
import os
from paste.deploy import loadapp
current_dir = os.getcwd()
application = loadapp('config:production.ini', relative_to=current_dir)
Update
Plan A is not working out for me. I initially started with the assumption that uwsgi was the only option for a Python app on dotcloud.
Plan B - Plone on a port proxied by webserver
I'm now open to Plan B which would use Plone as a worker running on a port and then make use of a proxy_pass to serve the site. As an added benefit, the "Plone on a port proxied by webserver" would be closer to the standard deployment approach for Plone in other scenarios.
The answers from Ken Cochrane and jpetazzo were both helpful in guiding me to the solution. I decided to abandon wsgi for the moment. The solution required digging deeper into the dotcloud python service and accompanying nginx webserver. I found a way to pass directives to nginx that would configure a proxy_pass.
The resulting stack is now hosted at: https://github.com/pigeonflight/stack-python-plone
The key breakthrough came when I realized that I could pass commands to nginx by creating a plone-uwsgi.conf file, for my purposes I'm "hijacking" a file that was intended to pass addition wsgi configuration and using it for something different. The nginx server is configured to read *uwsgi.conf files after other key directives in the nginx.conf file (such as the location / {} directive. This provided an ideal way for me to override the (unneeded) wsgi code. In my case I use the file to "inject" a proxy_pass directive.
Here's how my plone-uwsgi.conf file looks:
# 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;
}
I also stored additional configuration in a file called proxy.conf which I included in the plone-uwsgi.conf file.
Here's my proxy.conf file:
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;
In summary it should be possible to launch a new plone site in a dotcloud sandbox using the following commands:
instance=instancename
git clone git://github.com/pigeonflight/stack-python-plone.git $instance
cd $instance
dotcloud create $instance
Followed by:
dotcloud push
Possible Issues: I don't know whether the precompiled packages that are downloaded by my custom script will continue to work if dotcloud makes changes to their worker instances.