I am trying to get sentry running on my dreamhost server. Dreamhost uses passenger wsgi to serve python frameworks, like django. I am able to get django apps running.
I am using virtualenv and I install sentry using pip, so all the code for sentry sits under the virtualenv directory. The instructions given for sentry doesn't use the startproject to create a directory that you can place somewhere for the passenger_wsgi.py file to find.
The sentry website gives examples of the program running under Nginx and uWSGI, but I am limited to (in this case) to apache and passenger wsgi.
Is it possible to run sentry under dreamhost's configuration and if so how does one pass things in like the config file to get it working. I have been able to locally start and interact with sentry, using :
sentry --config=/home/user/.sentry/sentry.conf.py start
so I know that all the dependencies are present on the host system
OK it looks like I was over thinking it, I forgot from a python perspective the file wsgi.py (which is found in the sentry directory) is called as sentry.wsgi when imported as a module. I was confused by sentry being a module that was downloaded from pip and how to access it. This is the reduced solution that works:
passenger_wgsi.py
import sys, os
INTERP = "/home/user/.virtualenv/sentry2/bin/python"
if sys.executable != INTERP:
os.execl(INTERP, INTERP, *sys.argv)
os.environ['SENTRY_CONF'] = "/home/user/.virtualenv/sentry2/sentry.conf.py"
import sentry.wsgi
believe it or not, that's it. If you look at the wsgi file in the sentry directory under the virtualenv install you will see it does all the importing of the django.core.handlers.wsgi and kicks off the correct application.
Related
I have simple python script which I would like to host on Heroku and run it every 10 minutes using Heroku scheduler. So can someone explain me what I should type on the rake command at the scheduler and how I should change the Procfile of Heroku?
Sure, you need to do a few things:
Define a requirements.txt file in the root of your project that lists your dependencies. This is what Heroku will use to 'detect' you're using a Python app.
In the Heroku scheduler addon, just define the command you need to run to launch your python script. It will likely be something like python myscript.py.
Finally, you need to have some sort of web server that will listen on the proper Heroku PORT -- otherwise, Heroku will think your app isn't working and it will be in the 'crashed' state -- which isn't what you want. To satisfy this Heroku requirement, you can run a really simple Flask web server like this...
Code (server.py):
from os import environ
from flask import Flask
app = Flask(__name__)
app.run(environ.get('PORT'))
Then, in your Procfile, just say: web: python server.py.
And that should just about do it =)
If you use free account [unverified*] on Heroku (so you cannot install addons), instead of using "Heroku scheduler", use time.sleep(n). You don't need Flask or any server in this case, just place script, say, inside folder Scripts (in default app/project by Heroku) and add to Procfile: worker: python script.py. Of course you replace script.py with Path to your script, including name, ex. worker: python Scripts/my_script.py
Note: If your script uses third-party modules, say bs4 or requests, you need to install them in pipenv install MODULE_NAME or create requirements.txt and place it where manage.py, Procfile, Pipfile, (etc) are. Next place in that requirements.txt:
requirements.txt:
MODULE_NAME==MODULE_VERSION
You can check them in pip freeze | grep MODULE_NAME
Finally deploy to Heroku server using git and run following command:
heroku ps:scale worker=1
That's it! Bot/Script is running, check it in logs:
heroku logs --tail
Source: https://github.com/michaelkrukov/heroku-python-script
unverified* - "To help with abuse prevention, provisioning an add-on requires account verification. If your account has not been verified, you will be directed to visit the verification site." It redirects to Credit Card info. However you can still have Free Acc, but you will not be able to use certain options for free users, such as installing addons:https://devcenter.heroku.com/articles/getting-started-with-python#provision-add-ons
I have a Django project which I would like to run on my shared webspace (1und1 Webspace) running on linux. I don't have root access and therefore can not edit apache's httpd.conf or install software system wide.
What I did so far:
installed squlite locally since it is not available on the server
installed Python 3.5.1 in ~/.localpython
installed virtualenv for my local python
created a virtual environment in ~/ve_tc_lb
installed Django and Pillow in my virtual environment
cloned my django project from git server
After these steps, I'm able to run python manage.py runserver in my project directory and it seems to be running (I can access the login screen using lynx on my local machine).
I read many postings on how to configure fastCGI environments, but since I'm using Django 1.9.1, I'm depening on wsgi. I saw a lot about configuring django for wsgi and virtualenv, but all examples required access to httpd.conf.
The shared web server is apache.
I can create a new directory in my home with a sample hello.py and it is working when I enter the url, but it is (of course) using the python provided by the server and not my local installation.
When I change the first line indicating which python version to use to my virtual environment (#!/path/to/home/ve_tc_lb/bin/python), it seems to use the correct version in the virtual environment. Since I'm using different systems for developing and deployment, I'm not sure whether it is a good idea to e.g. add such a line in my djangoproject/wsgi.py.
Update 2016-06-02
A few more things I tried:
I learned that I don't have access to the apache error logs
read a lot about mod_wsgi and django in various sources which I just want to share here in case someone needs them in the future:
modwsgi - IntegrationWithDjango.wiki
debug mod_wsgi installation (only applicable if you are root)
mod_wsgi configuration guide
I followed the wsgi test script installation here - but the wsgi-file is just displayed in my browser instead of beeing executed.
All in all it seems like my provider 1und1 did not install wsgi extensions (even though the support told me a week ago it would be installed)
Update 2016-06-12: I got a reply from support (after a week or so :-S ) confirming that they dont have mod_wsgi but wsgiref...
So I'm a bit stuck here - which steps should I do next?
I'll update the question regularly based on comments and remarks. Any help is appreciated.
Since your apache is shared, I don't expect you can change the httpd.conf but use instead your solution. My suggestion is:
If you have multiple servers you will deploy your project (e.g. testing, staging, production), then do the following steps for each deploy target.
In each server, create a true wsgi.py file which you will never put in versioning systems. Pretty much like you would do with a local_settings.py file. This file will be named wsgy.py since most likely you cannot edit the apache settings (since it is shared) and that name will be expected for your wsgi file.
The content for the file will be:
#!/path/to/your/virtualenv/python
from my_true_wsgi import *
Which will be different for each deploy server, but the difference will be, most likely, in the shebang line to locate the proper python interpreter.
You will have a file named my_true_wsgi to have it matching the import in the former code. That file will be in the versioning systems, unlike the wsgi.py file. The contents of such file is the usual contents of the wsgi.py on any regular django project, just that you are not using that name directly.
With this solution you can have several different wsgi files with no conflict on shebangs.
You'll have to use a webhost that supports Django. See https://code.djangoproject.com/wiki/DjangoFriendlyWebHosts. Personally, I've used WebFaction and was quite happy with it, their support was great and customer service very responsive.
I have installed Django and mod_wsgi-express (the new way) on an ubuntu 15.10 server using:
pip install Django
pip install mod_wsgi
Currently I am starting/deploying my django application using a script that:
cd ~/.local/bin
./mod_wsgi-express start-server ~/mysite/mysite/wsgi.py
where my application is located in (as a git repository):
~/mysite/
Since ~/mysite/ is not on the PYTHONPATH I have modified the wsgi.py file to:
import os
from django.core.wsgi import get_wsgi_application
# Hardcode the path to the application/add it to the PYTHONPATH
import sys
path = '/home/user/mysite'
if path not in sys.path:
sys.path.append(path)
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "mysite.settings")
application = get_wsgi_application()
This works fine for now. But if I want to use this in production I see some problems:
wsgi.py contains hard coded path to the django web application to make sure its in the PYTHONPATH. Further its not guaranteed to be in the same path on the local developer machine. At least an improvement could be to use relative paths.
The web application is distributed as a git repository. E.g. in java you would package it into a war or an ear file.
Both django and mod_wsgi-express are located in the ~/.local folder for a specific local user.
Are there any obvious changes I should start looking into to eliminate bullet 1-3 above or is the above approach more or less how django deployment works?
I'll start out by saying that I'm assuming you're using the set up you describe for specific reasons and I won't try to steer you towards anything that might be more admin-friendly. If you're not and could use a friendly nudge, you can try Googling around for different people's pros/cons and examples or I would put in a good word for Gunicorn and an LTS version of Ubuntu.
Anyway.
When I was reading your question the first thing that popped into my head was that you could use something like Fabric or even just a deployment script that could do a string substitution in your wsgi.py file, putting in the correct path for you along with handling everything else in your deployment. I would say automated deployments are something of a standard and you might like the freedom of being able to throw out a server and spin up a new one in 5 minutes, but they can be a lot to learn if you're doing other things at the time.
Figuring that you probably didn't want to mess with all the automation rigmarole, I then popped over to Django's mod_wsgi deployment documentation (which is pretty good) because messing around with the Python path seemed weird and like something you shouldn't have to do. Sure enough, they recommend running mod_wsgi in daemon mode, which gives you an opportunity to set the Python path in the Apache config and keep it separate from the code you distribute. Then you can just have different boxes use different config files based on their needs.
That same documentation has notes on using a virtual environment (virtualenv) which you also want to probably do -- that virtualenv would then be portable and would handle your concerns with point 3.
With point 2 you should probably just think of the git distribution as a feature -- no need to run a build process and upload WAR files and all the etceteras. Java people only put up with that because they theoretically get something from having their code compiled into bytecode; Python, for better or for worse, doesn't do any compilation so you can deploy your code transparently and use git to handle your files at all points in the application's life without worrying about keeping the artifact versions straight and all that.
EDIT:
You could also probably avoid any issues with PYTHONPATH by adding your ~/.local/bin folder to your path (export PATH=~/.local/bin:$PATH from command line) and then cding into your site's directory and just running mod_wsgi-express start-server mysite/wsgi.py. By adding the local bin folder to your PATH you gain the ability to reference any applications in it implicitly from any directory while still having everything rooted in the directory you cd into, which should keep Python from getting confused.
I would still prefer to link mod_wsgi into your main Apache installation and run it in daemon mode so that you can control bringing it up/down from systemd/systemctl instead of forking processes from your terminal and having to look up the process ID in ps to kill it.
Better something like this:
import os
import sys
sys.path.append("add/Your/Path")
os.environ.setdefault("DJANGO_SETTINGS_MODULE","mysite.settings")
import django
django.setup
import django.core.handlers.wsgi
application = get_wsgi_application()
application = django.core.handlers.wsgi.WSGIHandler()
check that You project is named a mysite, If You project have other name change mysite on name of You django-project. You will use to production apache?
import os
import sys
sys.path.append("add/Your/Path")
os.environ.setdefault("DJANGO_SETTINGS_MODULE","mysite.settings")
import django
django.setup()
import django.core.handlers.wsgi
application = get_wsgi_application()
application = django.core.handlers.wsgi.WSGIHandler()
Since the latest release of the Google App Engine Python SDK, it's possible to use modules. I have a Python application with a default module and another module. To start the module in the development server, the development server has to be run like this:
dev_appserver.py app.yaml othermodule.yaml
When I add app.yaml othermodule.yaml to "Additional options" in the Run/Debug configuration of PyCharm and then run the development server, I get the following error message:
google.appengine.tools.devappserver2.errors.InvalidAppConfigError: "."
is a directory and a yaml configuration file is required
This is because PyCharm adds a dot at the end of the command to run the development server, like this:
dev_appserver.py app.yaml othermodule.yaml .
Is it possible to remove the dot, or do I have to wait until this is fixed in PyCharm? Before there were modules, there was no need for this.
You can go around this for the time being by just creating a new Run Configuration.
Chose Python configuration, then fill like this:
script: /path/to/your/dev_appserver.py
script parameters: dispatch.yaml module1.yaml module2.yaml
working directory: /path/to/your/appengine/project
It works just fine like this for me. The dispatcher is launching properly and I've got all the logs like before in PyCharm.
I have working project built with djangoappengine and running under App Engine dev server. So I run "manage.py runserver" and all works as appreciated. All requirements (django, djangoappengine etc) are located in project root dir. Now I am trying to use virtualenv (I am running commands in project root):
virutalenv --no-site-packages env
env\Scripts\python manage.py runserver
Server starts, but when I try to access any page I get such exception:
ImportError: Could not import settings 'settings' (Is it on sys.path? Does it have syntax errors?): No module named mimetypes
How can I fix this?
PS I am trying to use this idea on Windows: https://bitbucket.org/imbolc/gae-virtualenv/src
Edit 1. The same behaviour is under Ubuntu 10.10.
Edit 2. The same behaviour is under Mac OS X: How to use virtualenv with Google App Engine SDK on Mac OS X 10.6 . Question can be closed.
This is described in Issue 4339 for GAE. Here's how to fix it:
Download patch from this Issue comment: patch
Move the patch to google_appengine/google/appengine/tools/
Change your working directory to the same path as above
Type: patch -p0 < dev_appserver.patch
Virtualenv does not copy full Python standard library, but instead bootstraps the loading of these modules with setting sys.path (PYTHONPATH). Looks like Google App Engine does not like this.
I suggest you file a bug against Google App Engine.