If the intention is still to try and do it yourself with one Apache instance, 
the description given before is still valid.

So not sure I have anything more to add at this point. Personally I am a fan of 
PaaS, but cost can be a concern with those.

Can perhaps go more into it when you start progressing more with the setup.

Graham 

> On 21 Sep 2016, at 3:57 PM, Jaqen Nki <projan...@gmail.com> wrote:
> 
> Hey Graham, been awhile.  Glad I could help ya out with that amzn gift.  Got 
> busy doing other crap and on road trips this summer so took a break from 
> programming.  Also hit a wall with flask where it became difficult to build a 
> dynamic user dashboard system so got discouraged.  I like flask but Im 
> finding its extensibility and total freedom to craft your own web app to be a 
> double edged sword.  I may use it for simple static sites but for more 
> complexity I may have to abandon it because it feels like the things I want 
> to do become too convoluted and require skill on the level of a web/software 
> engineer.  Not sure why I would reinvent the proverbial 'wheel' when at my 
> level it will be inferior and may be bottlenecked or have security breaches 
> Im unaware of when someone at a much higher level has built something much 
> better.  Not only that, to manually edit every sql query, every init.py 
> change, every html change is going to be a logistical nightmare if Im 
> managing like 20 websites.  So Im knocking out a good django series and I 
> like how its structured, more split up, easier to manage via admin panel, 
> apps can be reused etc.  I hope its going to solve some of these logistical 
> and efficiency issues as far as building and managing websites.  My short 
> term goal is to build sites like a blog with commenting system, a forum, 
> dynamic user dashboard, and later on a basic ecommerce store, and to be able 
> to manage these sites easier via django admin (or partially hand the reins to 
> the site owner for basic content posting/editing).   That way my time is 
> freed up from doing menial edits and whatnot for client's sites.  I hope 
> django can be my answer to these dilemmas.
> 
> Anyways I was curious if you have experience / advice in this area, and 
> currently Im revisiting how to properly set up numerous projects each with 
> their own separate virtual environment, as we previously discussed below.  I 
> plan on using this local ubuntu VM as my local dev server, hosting all my 
> projects (5-10 short term, 20-50+ eventually) and then uploading them to 
> digital ocean for production.  All I need at the moment is to set up a few 
> projects and make sure their virtualenvs are separate but sharing the same 
> IP.  Thanks.
> 
> 
> **********
> On 12 May 2016, at 6:32 PM, Jaqen Nki <proj...@gmail.com <>> wrote: 
> So I take it for a new project, I repeat the process, new vhost and .wsgi 
> file, and create a wsgi.load file for each site? 
> 
> The wsgi.load file should only have in it the LoadModule, WSGIPythonHome and 
> WSGIRestrictEmbedded directives. They applied to the server as a whole and 
> not specific VirtualHosts. 
> 
> When you talk about adding more VirtualHost’s, that is when you will need to 
> be a bit careful with respect to virtual environments. 
> 
> First up, a separate VirtualHost is used for each distinct site hostname. 
> Don’t use separate VirtualHost’s if only trying to mount different 
> applications at different sub URLs of the same site. Seen people try and use 
> multiple VirtualHost’s for same site hostname too many times. Is wrong way. 
> 
> Because you are going to have multiple VirtualHost’s would suggest doing 
> things a little differently. 
> 
> First up, the wsgi.load file would only have LoadModule and 
> WSGIRestrictEmbedded directives in it. Not WSGIPythonHome. 
> 
> In that file the WSGIPythonHome was acting as a fallback for both embedded 
> mode and daemon mode. With WSGIRestrictEmbedded set to On, don’t need the 
> fallback. Instead, we want to set python-home for each daemon process group 
> setup using WSGIDaemonProcess directive. 
> 
> Thus: 
> 
> # wsgi.load 
> 
> LoadModule … 
> WSGIRestrictEmbedded On 
> 
> # site1.conf 
> 
> <VirtualHost *:80> 
> ServerName site1.host.name <http://site1.host.name/> 
> 
> WSGIDaemonProcess site1 python-home=/some/path/site1/
> venv 
> WSGIProcessGroup site1 
> WSGIApplicationGroup %{GLOBAL} 
> 
> WSGIScriptAlias / /some/path/site1/app.wsgi 
> 
> ... 
> </VirtualHost> 
> 
> # site2.conf 
> 
> <VirtualHost *:80> 
> ServerName site2.host.name <http://site2.host.name/> 
> 
> WSGIDaemonProcess site2 python-home=/some/path/site2/venv 
> WSGIProcessGroup site2 
> WSGIApplicationGroup %{GLOBAL} 
> 
> WSGIScriptAlias / /some/path/site1/app.wsgi 
> 
> ... 
> </VirtualHost> 
> 
> If you do need to host multiple applications under same VirtualHost at 
> different sub URLs, you would use something like: 
> 
> # site3.conf 
> 
> <VirtualHost *:80> 
> ServerName site3.host.name <http://site3.host.name/> 
> 
> WSGIDaemonProcess site3_main python-home=/some/path/site3_main/venv 
> WSGIDaemonProcess site3_suburl python-home=/some/path/site3_suburl/venv 
> 
> WSGIProcessGroup site3 
> WSGIApplicationGroup %{GLOBAL} 
> 
> WSGIScriptAlias /suburl /some/path/site3_suburl/app.wsgi 
> process-group=site3_suburl 
> WSGIScriptAlias / /some/path/site3_main/app.wsgi 
> 
> ... 
> </VirtualHost>
> **********
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "modwsgi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to modwsgi+unsubscr...@googlegroups.com 
> <mailto:modwsgi+unsubscr...@googlegroups.com>.
> To post to this group, send email to modwsgi@googlegroups.com 
> <mailto:modwsgi@googlegroups.com>.
> Visit this group at https://groups.google.com/group/modwsgi 
> <https://groups.google.com/group/modwsgi>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to modwsgi+unsubscr...@googlegroups.com.
To post to this group, send email to modwsgi@googlegroups.com.
Visit this group at https://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.

Reply via email to