I'm running a Django website in a Vagrant box that (roughly) mirrors a Heroku set-up. It uses Foreman with a Procfile like this:
web: gunicorn projectname.wsgi > /vagrant/gunicorn.log 2>&1
However, when I change my Django code, the server doesn't restart or reload the code, which makes development... painful!
How can I make Foreman serve the new code when it changes?
Related
i'm kind of new to Heroku, but got a question in relation to dynos.
My situation is as follows. I'm running on main application in django that runs the following dyno command
"web gunicorn DJANGO_WEBPAGE.wsgi --log-file - ", and inside my main project there is a streamlit app that runs the following command
"streamlit run geo_dashboard.py", but it seems i can't run both commands on the same dyno.
1.- Is there a way to accomplish this?
2.- Do they need to be on separate apps?
3.- In case of limitations do to being a free user, does the hobby plan covers it?
I've tried running my procfile this way
web: gunicorn DJANGO_WEBPAGE.wsgi --log-file - && web: sh setup.sh && streamlit run geo_dashboard.py
Even though i get no errors, only the streamlit app appears leaving the django app shutdown.
I am learning Django so I've created many Django webapps under one directory. For example,
\webapps
\polls
\polls
\api
\manage.py
...
\ponynote
\ponynote
\frontend
\manage.py
...
I didn't use a virtualenv for developing django apps. I don't know whether it's the reason that causes the problem as below.
App 1
python manage.py runserver works all fine. (default port 8000)
App 2
python manage.py runserver still shows the App 1 page.
Method I tried:
change the port python manage.py runserver 8001, it shows App 2 page.
try to find the process ID PID, and kill it. No sign of port 8000.
However, this isn't the best solution since I can't change the port everytime when developing a new django app. Does anyone have a clue why this happens? Kudos.
Problem solved:
remove web browser cache. In my case, it's Chrome.
One effective solution would be to create a bash script for your use. Create 2 separate bash scripts for your projects (The same dir where your project's manage.py can be found).
For App 1:
# script- App 1
python manage.py runserver 0.0.0.0:8000
For App 2:
# script- App 2
python manage.py runserver 0.0.0.0:8080
And for running:
./yourbashscriptfile
I made some updates to a project: add 1 admin model, add 1 template
I'm using wagtail. I pulled the updates to my server, ran migrations, got success. I restart nginx and gunicorn, I even rebooted the server.
When I go to the wagtail admin, my adminmodel is missing (it exists locally). when I go to create a new page, my template is available, but when I select it I get taken to a wagtail 404 page.
Ubuntu 20.04
ngnix
gunicorn
django/wagtail
digital ocean vpc
digital ocean postgres database cluster
The site works like normal, only a template is available I can't select, and the Model, that migrated, isn't available and isn't showing up in admin. my local version is working perfectly, with no differences. it seems like the server is both updating and not updating. I don't get it. running makemigrations or migrate returns no changes. even when running on the specific app. Do I need to do something to rebot the database?
Listen it looks like caching issue with Nginx. Try clearing the cache.
I have 2 settings files: dev.py, production.py
dev.py is connected to a sqlite3 db and production is connected to the digitalocean postgres cluster.
python manage.py automatically uses dev.py (at least in my setup) so my migrations were working, but they were targeting an old copy of the sqlite.db I had on the server, or perhaps created one as it does when one doesn't exist. Either way, the live site runs on the production.py settings and this is why the changes were being made but not reflecting.
The correct way to run migrations when you have a production.py file is similar to:
python manage.py migrate --settings=<settings app>.<settings folder>.production
I'm also going to add that I found that you need to collectstatic each time you update your css stylesheet. that is a little tedious, and maybe I am missing an automation step, but considering that is the case, just to be safe, I run like this:
python manage.py collectstatic --settings=<settings app>.<settings folder>.production
It doesn't cause any issues and it works, so I use the --settings flag to be safe.
git pull
python manage.py migrate --settings=app.settings.production
python manage.py collectstatic --settings=app.settings.production
sudo systemctl restart ngix
sudo systemctl restart gunicorn
I don't know that restarting ngix is necessary except it solved something with my static files updating I believe.
My Problem:
When using gunicorn as my WSGI HTTP server, foreman fails to find the Django (wsgi?) application.
Application Structure:
In my Django application, I have things structured like this:
<git_repository_root>/
<django_project_root>/
<configuration_root>/
The <git_repository_root> contains the project management and deployment related things (requirements.txt, Procfile, fabfile.py, etc.)
The <django_project_root> contains my Django apps and application logic.
Finally, the <configuration_root> contains my settings.py and wsgi.py.
What I have tried:
My Procfile should look like this (according to the Heroku Docs):
web: gunicorn myapp.wsgi
When running foreman start with this project layout, I get an error:
ImportError: Import by filename is not supported.
What works:
If I move my Procfile from <git_repository_root> to <git_repository_root> it works locally. After pushing to Heroku (note: Heroku sees <git_repository_root>) I can't scale any workers / add processes. I get the following:
Scaling web dynos... failed
! No such process type web defined in Procfile.
I believe I want Procfile in my <git_repository_root> anyway though - so why isn't it working? I also tried changing the Procfile to:
web: gunicorn myapp/myapp.wsgi
but no luck. Any help would be much appreciated!
Treat the entry in your Procfile like a bash command. You can cd into your <django_project_root> and then run the server.
For example, your Procfile (which should be in your <git_repository_root>) might look something like this:
web: cd <django_project_root> && gunicorn
--env DJANGO_SETTINGS_MODULE=<configuration_root>.settings
<configuration_root>.wsgi
Move your Procfile back to <git_repository_root> and use:
web: gunicorn <django_project_root>.myapp:myapp
replacing the final "myapp" with your app's class name, presumably it is indeed "myapp".
... and read the error message: it is telling you that you can't import your worker class (app) by filename (myapp.wsgi), so of course saying dirname/myapp.wsgi won't work as well. You need a Python module:class syntax.
According to the Heroku site when I get error H14 "No Web Processes Running" it's because I need to scale up dynos by:
heroku ps:scale web=1
However, when I do that I get the following error:
Scaling web processes... failed
! No such type as web
Does anyone know how to fix this? I want to get my site back up!
When I run heroku ps I see nothing.
UPDATE: It's not detecting my Procfile. I don't have a Procfile explicitly and didn't use one before... is it absolutely necessary?
I ran into this recently as well, my web was working fine without any Procfile, until recently...
My fix was simply to add a Procfile as follows:
web: python manage.py runserver 0.0.0.0:$PORT --noreload
Then push to heroku.
For Heroku you need to add a Procfile.
add a Procfile on same level like your manage.py file. It should be in your root directory. Be sure that you create a Procfile not a Procfile.txt or else just Procfile
in your Procfile add:
web: gunicorn projectname.wsgi
add in your requirements.txt gunicorn
gunicorn==20.0.4
If you activate automatic deploy you can try it again.
If you can remove the app, remove it and deploy it again.