hlo, I have deployed a Django rest app in production. When I call a list API there is a pagination, and I am getting localhost for next page URL.
I am using GenericViewSet and LimitOffsetPagination for pagination. My app is running in docker container.And it is pointed to a specific domain. We can access it using domain name "https://abc.xyz.com". But I have used python manage.py runserver:0.0.0.0:8000(it's just for testing) CMD for running the server.
Here is the image for more detail.
I am calling an live hosted API to get a list from postman. In response data list contains pagination, which contains "http://localhost:8000/api/transaction/?limit=10&offset=10&ordering=-pk&purpose=1". for next page link instead of domain name.
I have hosted application using docker. Following is my docker file:
# Set the working directory
WORKDIR /app
# Copy requirements file
COPY requirements.txt .
# Install dependencies
RUN pip install --upgrade pip && pip install -r requirements.txt
# Copy project files
COPY . .
# Collect static files
RUN python manage.py collectstatic --noinput
# Run migrations
RUN python manage.py makemigrations
RUN python manage.py migrate
# Expose the port 8000
EXPOSE 8000
# Start the server
CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"]
What should I do to get "https://abc.xyz.com/api/transaction/" instead of "http://localhost:8000/api/transaction/"
You can use relative url in your html, something like this:
http://localhost:8000/nextpage/?page=2
to
<a href="/nextpage/?page=2" />
When you change to this, your url will be change to yourdomain/nextpage/?page2. So you can run your app in localhost or VM or in container without changing host or absolute url for one by one environment you set up in project.
Related
I am trying to configure web server for Django 2.2.8 on VPS Server as well as Shared Hosting but both are not working. I have configure python on the web server and its shell is working and giving output . But when I am trying to configure Django but its not working Its Giving the blank screen.
I have followed these steps for Django Configuration and followed this link
https://github.com/sparagus/django-shared-hosting-1and1
Access your server via SSH, which will most likely take you to your base directory (your htdocs directory where the directories to your websites are).
Make a directory where you want your Python files to reside and cd into it.
mkdir python_files
cd python_files
Run the build-python.sh
./build-python.sh
install/python3.6.3/bin/python3 -m venv venv
source venv/bin/activate
pip install --upgrade pip
pip install -r requirements.txt
If you get an SSL error here then there's a problem with OpenSSL.
Check if Django is installed correctly.
python -m django --version
Go back to your base directory and start a Django project.
cd ..
django-admin startproject your_site
and so on followed all the steps which are mentioned on the git link but it is showing blank when accessing the url
I have Django running in a Docker container. The CMD of my Docker file simply runs a script, launch.sh, which inter alia has the following commands:
python manage.py makemigrations --no-input --verbosity 1
python manage.py migrate --no-input --verbosity 1
So, these commands make migrations on my Django project, and then perform the migrations (if any), whenever my container launches. This works as intended for the specifically project-level migrations.
However, inevitably, only the project-level migrations are made — that is, the app-level migrations are never made and so are never performed. But if I log into the container (with docker exec -it ... bash) and execute the same migration commands manually, the app-level migrations are made and performed.
Googling and numerous variations to my code haven't turned up any explanations for this behavior or any fix, so I'm stumped.
Any ideas?
P.S. Here is my project and app structure:
/django/
project/
app/
static/
manage.py
Also, I tried executing the same set of commands twice in succession in my script, and also running the same set of commands in succession but with my app specified as the target option, but these attempts still produced the same results: only the project migrations are made, not the app migrations.
As asked, here's my Dockerfile:
FROM python:3-slim
ENV PYTHONUNBUFFERED 1
ADD django-requirements.pip .
RUN pip install --upgrade pip && \
pip install --no-cache-dir -r django-requirements.pip
WORKDIR /
ADD launch.sh .
CMD ./launch.sh
My Django project is mounted at launch at /django, and my launch script CDs to /django before running the migration commands.
Check your Django app Dokerfile for WORKDIR
# In my case it is /app
WORKDIR /app
and change your launch.sh file
# manage.py will be inside working dir
python /app/manage.py migrate --noinput
UPDATE
It depends on where you copied launch.sh file inside the
container.
If you copied all files of Django app inside /app dir
COPY . /app
and copy your launch.sh file outside it like
COPY ./<path to launch file>/launch.sh /launch.sh
then inside launch.sh you have to use manage.py as
# should prepend `/app/`
python /app/manage.py migrate --noinput
But if you copied launch.sh inside /app/ as.
COPY ./<path to launch file>/launch.sh /app/launch.sh
Then you can use migrate command as the traditional way
python manage.py migrate --noinput
Now When you run the command using docker exec -it container-id, Then it runs
inside working DIR and locates manage.py file.
I had exactly the same problem.
I think there must be a migrations/__init__.py in your Django app dir.
Be sure that you copied it to your container.
My solution was to change a line in .dockerignore:
app/migrations/* to app/migrations/0*.
I had a working Django project that had built and deployed many images over the last few weeks. My django project kept working fine when ran as "python manage.py runserver" and the Docker images kept being built fine (all successful builds). However the django app now doesn't deploy. What could be the issue and where should I start to look for it? I've tried the logs but they only say "Starting Django" without actually starting the service
I use github and have gone back to previous versions of the code and none of them now work, even though the code is exactly the same. It also fails to deploy the Django server on AWS Elastic Beanstalk infrastructure which is my ultimate goal with this code.
start.sh:
#!/bin/bash
echo Starting Django
cd TN_API
exec python ../manage.py runserver 0.0.0.0:8000
Dockerfile:
FROM python:2.7.13-slim
# Set the working directory to /app
WORKDIR /TN_API
# Copy the current directory contents into the container at /app
ADD . /TN_API
# COPY startup script into known file location in container
COPY start.sh /start.sh
# Install requirements
RUN pip install -r requirements.txt
# EXPOSE port 8000 to allow communication to/from server
EXPOSE 8000
# CMD specifcies the command to execute to start the server running.
CMD ["/start.sh"]
Commands:
sudo docker run -d tn-api
sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d28115a919f9 tn-api "/start.sh" 11 seconds ago Up 8 seconds 8000/tcp festive_darwin
sudo docker logs [container id]
Starting Django
(doesn't do the whole:
Performing system checks...
System check identified no issues (0 silenced).
August 06, 2017 - 20:54:36
Django version 1.10.5, using settings 'TN_API.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.)
I changed several things and although it doesn't work locally it seems to work fine when deployed to AWS. I still don't get the feedback I used to get such as below but that's ok. I can hit the server and it works. Thank you all for your help.
Performing system checks...
System check identified no issues (0 silenced). August 06, 2017 - 20:54:36 Django version 1.10.5, using settings 'TN_API.settings' Starting development server at http://127.0.0.1:8000/ Quit the server with CONTROL-C.
It looks like the path is wrong for the manage.py script in /start.sh.
Your start.sh:
#!/bin/bash
echo Starting Django
cd TN_API
exec python ../manage.py runserver 0.0.0.0:8000
Seeing that you set WORKDIR to you project directory in the Dockerfile, the start.sh script is actually run from inside the project directory - which means it is actually doing this:
cd /TN_API # WORKDIR directive in Dockerfile
echo Starting Django # from the start.sh script
cd /TN_API/TN_API # looking for TN_API within your current pwd
exec python /TN_API/manage.py runserver 0.0.0.0:8000 # goes up a level (..) to look for manage.py
So it could be that your context for running runserver is off.
You can avoid this path jumping by rewriting your Dockerfile to include an CMD directive as follows:
FROM python:2.7.13-slim
# Set the working directory to /app
WORKDIR /TN_API
# Copy the current directory contents into the container at /app
ADD . /TN_API
# Install requirements
RUN pip install -r requirements.txt
# EXPOSE port 8000 to allow communication to/from server
EXPOSE 8000
# CMD specifcies the command to execute to start the server running.
CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"]
Here using python manage.py runserver 0.0.0.0:8000 will work since you set the WORKDIR to your project directory already. So you wouldn't need your start.sh script necessarily.
I'm working on a simple implementation of Django hosted on Google's Managed VM service, backed by Google Cloud SQL. I'm able to deploy my application just fine, but when I try to issue some Django manage.py commands within the Dockerfile, I get errors.
Here's my Dockerfile:
FROM gcr.io/google_appengine/python
RUN virtualenv /venv -p python3.4
ENV VIRTUAL_ENV /venv
ENV PATH /venv/bin:$PATH
# Install dependencies.
ADD requirements.txt /app/requirements.txt
RUN pip install -r /app/requirements.txt
# Add application code.
ADD . /app
# Overwrite the settings file with the PROD variant.
ADD my_app/settings_prod.py /app/my_app/settings.py
WORKDIR /app
RUN python manage.py migrate --noinput
# Use Gunicorn to serve the application.
CMD gunicorn --pythonpath ./my_app -b :$PORT --env DJANGO_SETTINGS_MODULE=my_app.settings my_app.wsgi
# [END docker]
Pretty basic. If I exclude the RUN python manage.py migrate --noinput line, and deploy using the GCloud tool, everything works fine. If I then log onto the VM, I can issue the manage.py migrate command without issue.
However, in the interest of simplifying deployment, I'd really like to be able to issue Django manage.py commands from the Dockerfile. At present, I get the following error if the manage.py statement is included:
django.db.utils.OperationalError: (2002, "Can't connect to local MySQL server through socket '/cloudsql/my_app:us-central1:my_app_prod_00' (2)")
Seems like a simple enough error, but it has me stumped, because the connection is certainly valid. As I said, if I deploy without issuing the manage.py command, everything works fine. Django can connect to the database, and I can issue the command manually on the VM.
I wondering if the reason for my problem is that the sql proxy (cloudsql/) doesn't exist when the Dockerfile is being deployed. If so, how do I get around this?
I'm new to Docker (this being my first attempt) and newish to Django, so I'm unsure of what the correct approach is for handling a deployment of this nature. Should I instead be positioning this command elsewhere?
There are two steps involved in deploying the application.
In the first step, the Dockerfile is used to build the image, which can happen on your machine or on another machine.
In the second step, the created docker image is executed on the Managed VM.
The RUN instruction is executed when the image is being built, not when it's being run.
You should move manage.py to the CMD command, which is run when the image is being run.
CMD python manage.py migrate --noinput && gunicorn --pythonpath ./my_app -b :$PORT --env DJANGO_SETTINGS_MODULE=my_app.settings my_app.wsgi
I have an django project (RESTful API written using Django Rest Framework) which uses the Postgres database.
I have a local git repository of the project and also I have it on my github account, and I want to deploy the porject to heroku.
In the official heroku tutorials, they don't show anything about how to prepare your app to deployment - (requirements file, settings file, Proc File, maybe more stuff that I don't know - which I saw in different tutorials that you need to do).
At the moment I only have the django app without any added file.
My question is - what do I need to do to prepare my app to deployment to heroku? as I said at the moment I have a local git repository and its also on Github.
Thanks!
1) Create a file called Procfile (no extension) in your project root with the following inside:
web: gunicorn APP_NAME.wsgi (replace APP_NAME with your app's name).
2) Pip install gunicorn and dj-database-url
3) In your virtual env terminal, run pip freeze > requirements.txt in your project root (do this every time you pip install any new packages).
4) In your production settings file, add the following to make your database work on heroku:
import dj_database_url
DATABASES['default'] = dj_database_url.config()
Note: This will cause errors in your local environment, so make sure you have a prod.py settings file as well (ask if you need an explanation).
5) Add heroku to your git settings via git remote add heroku git#heroku.com:HEROKU_APP_NAME.git (replace HEROKU_APP_NAME with your Heroku app name).
6) Once you do git add --all, git commit -m "SOME MESSAGE HERE" and git push, you can do git push heroku master.