I was running Django 1.11 with Python 3.5 and I decided to upgrade to Python 3.6.
Most things worked well, but I am having issues connection to AWS S3. I know that they have a new boto version boto3 and that django-storages is a little outdated, so now there is django-storages-redux.
I've been trying multiple combinations of boto/boto3 and django-storages-redux/django-storages to see if it works. But I'm getting a lot of erros, from SSL connection failing to the whole website being offline due to server errors. The newest is my website throwing a 400 Bad Request to all urls.
My app does run on Python 3.5, so I'm confident that the issue is around collectstatic and S3.
Is there anybody here who made a similar update work and tell me what configuration was used?
Thanks a lot!
Found the issue.
Django-storages-redux was temporarily replacing django-storages since it's development had been interrupted.
Now the django-storages team restarted to support it.
That means that the correct configuration to use is: django-storages + boto3
Related
I'm trying to upgrade an existing application on AWS from the now deprecated Python 3.4 platform to 3.7 with Amazon Linux 2/3.0.1, and in the process I ran into an issue with where the application source code is deployed on the EC2 instance.
From some empirical testing, I found that instead of /opt/python/current/app directory that most if not all AWS documentations say (e.g Troubleshooting issues with the EB CLI - AWS Elastic Beanstalk), with Python 3.7 it is actually deployed in /var/app/current/. I wasn't able to find any documentation regarding this change, and it is causing some issues with the application. I'm wondering is there any reason that this change is made? And if it is possible to revert it, how to do so?
Thanks in advance!
This is because the 3.7 Python Elastic Beanstalk distribution uses Amazon Linux 2 which is fundamentally different from the AMI predecessor. If you opt to use Python 3.6 instead you should be able to avoid this issue, as it runs on the earlier Linux version where deployments still occur in /opt/var/app/current. Most tutorials I've found are designed to work with this older rollout, including the most up-to-date Amazon start guide.
If you have the time, try migrating your code to the newer version, as this seems to be the workflow Amazon is embracing going forward, for all newer versions of Python (such as 3.8 and others yet to come).
I've got 2 Python 3.6 pods currently running. They both used to run collectstatic upon redeployment, but then one wasn't working properly, so I deleted it and made a new 3.6 pod. Everything is working perfectly with it, except it no longer is running collectstatic on redeployment (so I'm doing it manually). Any thoughts on how I can get it running again?
I checked the documentation, and for the 3.11 version of openshift still looks like it has a variable to disable collectstatic (which i haven't done), but the 4.* versions don't seem to have it. Don't know if that has anything to do with it.
Edit:
So it turns out that I had also updated the django version to 2.2.7.
As it happens, the openshift infrastructure on openshift online is happy to collectstatic w/ version 2.1.15 of Django, but not 2.2.7 (or 2.2.9). I'm not quite sure why that is yet. Still looking in to it.
Currently Openshift Online's python 3.6 module doesn't support Django 2.2.7 or 2.2.9.
I'm building a Django app in Python 3.3.1 to be deployed on Heroku. Due to its ephemeral filesystem, Heroku can't serve the app's static files from a local filesystem, so they need to be located elsewhere, and Amazon S3 is where I'd like to put them.
I've found a number of helpful tutorials (Deploying Django on Heroku, among others), all of which make use of the django-storages app and boto to collect the static files and store them on S3. Unfortunately, work on porting boto to Python3 is still incomplete. There are other S3 storage providers that django-storages can work with (Apache Libcloud or the simple Amazon S3 Python library), but django-storages itself doesn't run on Python3, either.
I've also seen hacks that add a collectstatic call to the Heroku app's Procfile, which does put the files somewhere that they can be used by the Django app, but it slows down deployment; the files must be collected and uploaded every time the app deploys. Heroku dynos aren't well-suited to serving static files, anyhow, and I'd eventually like to store user data, as well, which will require a non-Heroku data store like S3.
Is there a Python3-compatible storage backend for Django other than those provided in django-storages? Or am I stuck with Python 2.7 for the time being?
django-storages-redux (now just django-storages) is working for me very nicely in conjunction with boto which now has Python 3 support for its s3 functionality.
django-storages-p3 looks promising. Give it a try and let me know :D.
I am following the tutorial for deploying a django project on AWS elastic beanstalk here:
http://docs.amazonwebservices.com/elasticbeanstalk/latest/dg/create_deploy_Python_django.html
My app works when I test locally but when I deploy, I'm getting a 404 error. Looking at the event logs, I see this message:
Error running user's commands : An error occurred running '. /opt/python/ondeck/env && PYTHONPATH=/opt/python/ondeck/app: django-admin.py syncdb --noinput' (rc: 127) /bin/sh: django-admin.py: command not found
That leads me to believe that the tutorial is missing a part about installing django files on the server or at least configuring my project to recognize django-admin.py. I have django installed on my local machine so it works there.
I know python support is brand new for elastic beanstalk but has anyone deployed django to it?
I believe you don't need to put container_commands in .config because there is no database or table at this moment.
Did you made the step?: Freeze the requirements.txt file.
(djangodev)# pip freeze > requirements.txt
Note
Make sure your requirements.txt file contains the following:
Django==1.4.1
MySQL-python==1.2.3
I had the same problem because I skipped it. Once I did it, add, commit and push. It works!
I followed the same tutorial recently and had a similar result.
At step 6, upon seeing the default django 'congrats' page render locally, I deployed to EB as instructed and got a 404 instead of the default 'congrats' page.
I decided to use the code up to that point as a foundation for following the 'getting started with django tutorial' which led me to a successful rendering of a 'home' view. This is a much more useful place to be anyway. I do agree that there is something wrong with the AWS tutorial and posted to the AWS forums here.
If you can, you should try to access the log file; it might give you a better idea of what's going on. Here's a link that might help:
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.loggingS3.title.html
I have version 1.3.1 Django installed on my shared hosting plan. It works fine. The problem is i need to update it to 1.4 but i'm getting an error
error: could not delete '/usr/lib/python2.6/site-packages/django/templatetags/__init__.py': Permission denied
I contacted their support, they said they can't update it. They said that i should check the Django forums for any possible solution.
Anyone had such an issue and was able to solve it? I'm hosting with Hostgator.
solved:
python setup.py install --user