Share via

Django Web App Stopped Working

DrBash 15 Reputation points
2023-12-13T19:00:52.33+00:00

My Django Azure Web App was running perfectly, until today. I get the error "Internal Server Error" or more precicely 

"2023-12-13T10:46:35.558223022Z set_urlconf(settings.ROOT_URLCONF)
2023-12-13T10:46:35.558227622Z ^^^^^^^^^^^^^^^^^^^^^
2023-12-13T10:46:35.558232122Z File "/tmp/8dbef7534e54292/antenv/lib/python3.11/site-packages/django/conf/__init__.py", line 94, in __getattr__
2023-12-13T10:46:35.558236723Z val = getattr(_wrapped, name)
2023-12-13T10:46:35.558241323Z ^^^^^^^^^^^^^^^^^^^^^^^
2023-12-13T10:46:35.558245823Z File "/tmp/8dbef7534e54292/antenv/lib/python3.11/site-packages/django/conf/__init__.py", line 270, in __getattr__
2023-12-13T10:46:35.558250723Z return getattr(self.default_settings, name)
2023-12-13T10:46:35.558255323Z ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2023-12-13T10:46:35.558259923Z AttributeError: module 'django.conf.global_settings' has no attribute 'ROOT_URLCONF' "

from the log stream. When looking in the Gunicorn debug I am suspucios about the following:

2023-12-13T17:24:02.731335180Z [2023-12-13 17:24:02 +0000] [85] [DEBUG] Current configuration: 2023-12-13T17:24:02.731366980Z config: ./gunicorn.conf.py 2023-12-13T17:24:02.731373780Z wsgi_app: None

I changed nothing in the code, this is my start command:

gunicorn --bind=0.0.0.0 --timeout 600 --workers=4 --log-level=debug config.wsgi:application

and this is my wsgi.py (I changed my appname to APPNAME):

import os
import sys
from pathlib import Path

from django.core.wsgi import get_wsgi_application
BASE_DIR = Path(__file__).resolve(strict=True).parent.parent
sys.path.append(str(BASE_DIR / "APPNAME"))

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "config.settings.production")

application = get_wsgi_application()

Did Azure change something? As it stopped working out of the blue....

I hope someone can help me.

Azure App Service
Azure App Service
Azure App Service is a service used to create and deploy scalable, mission-critical web apps.
7,245 questions

6 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Leon Kunert 5 Reputation points
    2023-12-16T14:50:54.8133333+00:00

    We found out that the settings are not loaded propperly.

    So now we use the global settings and copy ours behind it.

    Making a backup of the existing global settings to /home.

    This is our current startup command, that is working:

    cp $APP_PATH/antenv/lib/python3.11/site-packages/django/conf/global_settings.py /home/ && cat $APP_PATH/<our application name>/settings.py >> $APP_PATH/antenv/lib/python3.11/site-packages/django/conf/global_settings.py && GUNICORN_CMD_ARGS="--timeout 600 --access-logfile '-' --error-logfile '-' -c /opt/startup/gunicorn.conf.py --chdir=$APP_PATH" gunicorn <our application name>.wsgi
    0 comments
  2. DrBash 15 Reputation points
    2023-12-17T07:41:27.6766667+00:00

    Alright guys, I fixed it by building the docker myself, creating an azure container registry and pushing it over my existing azure web app (I first tried it with a new one). Note: You must have VNET and your database set up properly to get this running, also a understanding of docker is required but I try to be as detailed in this post as I can. Here is what I did:

    1. I created a dockerfile on the root level of my django app. Note: The Django_Settings_Module is specifically set to the settings I want to use in my docker, this might differ in your setup. Same goes for the requirements.txt location as it is also in my root directory. Make sure to test it with your local settings first before proceeding.
    FROM python:3.9
# Set environment variables
ENV PYTHONDONTWRITEBYTECODE 1
ENV PYTHONUNBUFFERED 1
ENV DJANGO_SETTINGS_MODULE=config.settings.production
# Set the working directory in the container
WORKDIR /app
# Copy the current directory contents into the container at /app
COPY . /app
# Install any needed packages specified in requirements.txt
RUN pip install --no-cache-dir -r requirements.txt
# Make port 8000 available to the world outside this container
EXPOSE 8000
# Run Gunicorn
CMD ["gunicorn", "--bind", "0.0.0.0:8000", "--timeout", "120", "--workers", "4", "--log-level", "debug", "config.wsgi:application"]
    1. I logged in to azure with the command "az login" then I created an Azure Container Registry to push my container to, so it can be pulled from my webapp (from https://learn.microsoft.com/en-us/azure/container-registry/container-registry-get-started-azure-cli)
    az acr create --resource-group myResourceGroup \
  --name mycontainerregistry --sku Basic
    1. I now can build my docker (remember to test it locally first):

    docker build -t app .

    1. You now need to docker tag my created docker with its version to the created ACR

    docker tag app mycontainerregistry.azurecr.io/app:latest

    1. Login to you ACR az acr login --name mycontainerregistry and push your docker docker push

    mycontainerregistry.azurecr.io/app:latest 6. At this point you could create a new service plan or just use our old one

    New: az appservice plan create --name NewAppService --resource-group ExistignRessourceGroup --is-linux --sku B1 --location YourLocation location names for the CLI can be found here: https://azuretracks.com/2021/04/current-azure-region-names-reference/

    1. Now you create the webapp, I first created a new webApp to test if everythings running. Note:
      1. I use a flexible prostgres database on azure, so it is very important, that my web app is on the same plan as my database to ensure they can be in the same (sub)vnet.
        1. after I tested my container with a new app, I overwrote my existing app (DANGER, Dont overwrite anything if you did not test the new app fully etc.,) 
                      az webapp create --resource-group NewOrExistingRG --plan NewOrExistingPlan --name NewOrExistingApp --deployment-container-image-name mycontainerregistry.azurecr.io/app:latest
    2. After this you need to find your credentials for the app to set them properly

    az acr credential show --name mycontainerregistry

    Configure the container

    az webapp config container set --name App--resource-group RG --docker-custom-image-name mycontainerregistry.azurecr.io/app:latest --docker-registry-server-url https://mycontainerregistry.azurecr.io --docker-registry-server-user mycontainerregistry --docker-registry-server-password GeneratedPassword

    Lastly, you need get to remove your startup command, as it is set in the docker and find "Networking" in your App, find the "Outbound traffic configuration" and click on "not configured". There should be your Subnet to enable a communication with you database

    This is the process to get your App back to live, everything works for my. Note: This completelly excludes any Git Workflows and is simply a workaround for now! As my app runs in productive with mutliple companies accessing it, it was important to find a quick solution for this mess.

    I hope this helps someone.

    DrBash

    0 comments
  3. brtrach-MSFT 15,701 Reputation points Microsoft Employee
    2023-12-22T17:46:53.6166667+00:00

    @DrBash I'm glad that you were able to resolve your issue and thank you for posting your solution so that others experiencing the same thing can easily reference this! Since the Microsoft Q&A community has a policy that "The question author cannot accept their own answer. They can only accept answers by others (Opens in new window or tab)", I'll repost your solution in case you'd like to "Accept (Opens in new window or tab)" the answer.

    Issue: Your Django Web App stopped working and you noticed a Internal Server Error.

    Solution: "Alright guys, I fixed it by building the docker myself, creating an azure container registry and pushing it over my existing azure web app (I first tried it with a new one). Note: You must have VNET and your database set up properly to get this running, also a understanding of docker is required but I try to be as detailed in this post as I can. Here is what I did:

    1. I created a dockerfile on the root level of my django app. Note: The Django_Settings_Module is specifically set to the settings I want to use in my docker, this might differ in your setup. Same goes for the requirements.txt location as it is also in my root directory. Make sure to test it with your local settings first before proceeding.
    FROM python:3.9
# Set environment variables
ENV PYTHONDONTWRITEBYTECODE 1
ENV PYTHONUNBUFFERED 1
ENV DJANGO_SETTINGS_MODULE=config.settings.production
# Set the working directory in the container
WORKDIR /app
# Copy the current directory contents into the container at /app
COPY . /app
# Install any needed packages specified in requirements.txt
RUN pip install --no-cache-dir -r requirements.txt
# Make port 8000 available to the world outside this container
EXPOSE 8000
# Run Gunicorn
CMD ["gunicorn", "--bind", "0.0.0.0:8000", "--timeout", "120", "--workers", "4", "--log-level", "debug", "config.wsgi:application"]
    1. I logged in to azure with the command "az login" then I created an Azure Container Registry to push my container to, so it can be pulled from my webapp (from https://learn.microsoft.com/en-us/azure/container-registry/container-registry-get-started-azure-cli)
    az acr create --resource-group myResourceGroup \   --name mycontainerregistry --sku Basic
    1. I now can build my docker (remember to test it locally first):

    docker build -t app

    1. You now need to docker tag my created docker with its version to the created ACR

    docker tag app mycontainerregistry.azurecr.io/app:latest

    1. Login to you ACR az acr login --name mycontainerregistry and push your docker docker push

    mycontainerregistry.azurecr.io/app:latest

    1. At this point you could create a new service plan or just use our old one

    New: az appservice plan create --name NewAppService --resource-group ExistignRessourceGroup --is-linux --sku B1 --location YourLocation location names for the CLI can be found here: https://azuretracks.com/2021/04/current-azure-region-names-reference/

    1. Now you create the webapp, I first created a new webApp to test if everythings running. Note:
      1. I use a flexible prostgres database on azure, so it is very important, that my web app is on the same plan as my database to ensure they can be in the same (sub)vnet. 
          1. after I tested my container with a new app, I overwrote my existing app (**DANGER**, Dont overwrite anything if you did not test the new app fully etc.,)

                            az webapp create --resource-group NewOrExistingRG --plan NewOrExistingPlan --name NewOrExistingApp --deployment-container-image-name mycontainerregistry.azurecr.io/app:latest
                        
                        
                        
                        ```

1. After this you need to find your credentials for the app to set them properly

`az acr credential show --name mycontainerregistry`

Configure the container

`az webapp config container set --name App--resource-group RG --docker-custom-image-name mycontainerregistry.azurecr.io/app:latest --docker-registry-server-url https://mycontainerregistry.azurecr.io --docker-registry-server-user mycontainerregistry --docker-registry-server-password GeneratedPassword`

Lastly, you need get to remove your startup command, as it is set in the docker and find "Networking" in your App, find the "Outbound traffic configuration" and click on "not configured". There should be your Subnet to enable a communication with you database

This is the process to get your App back to live, everything works for my. Note: This completelly excludes any Git Workflows and is simply a workaround for now! As my app runs in productive with mutliple companies accessing it, it was important to find a quick solution for this mess.

I hope this helps someone." Source: [@](/users/na/?userid=0bba7cd6-cd8d-44bc-9de7-a08836880e36)

If you have any other questions or are still running into more issues, please let me know.  
Thank you again for your time and patience throughout this issue.

Please remember to "Accept Answer" if any answer/reply helped, so that others in the community facing similar issues can easily find the solution.
    0 comments
  4. Markus Kessler 0 Reputation points
    2024-04-10T12:31:29.1133333+00:00

    This issue also emerged for us from one deployment to the next for our Azure App Service. The deeper cause, that led to the same error of the missing ROOT_URLCONF, was that the oryx build system was not properly used. Instead it would generate it's own build script and mention it in the deployment logs like this:

    2024-04-10T12:16:20.561Z - Generating deployment script.
2024-04-10T12:16:20.728Z - Using cached version of deployment script (command: 'azure -y --no-dot-deployment -r "/home/site/repository" -o "/home/site/deployments/tools" --python --sitePath "/home/site/repository"').

    But instead, with a working one we would expect these lines:

    2024-04-10T12:18:35.884Z - Running oryx build...
2024-04-10T12:18:35.891Z - Command: oryx build /home/site/repository -o /home/site/wwwroot --platform python --platform-version 3.11 -p virtualenv_name=antenv --log-file /tmp/build-debug.log  -i /tmp/8dc59585864dc7c --compress-destination-dir | tee /tmp/oryx-build.log

    To enforce this, we set the environment variable (or app service configuration) ENABLE_ORYX_BUILD = true. Make sure to just use the word true without any quotation marks, as this led to a false negative for us for this fix.

    0 comments
  5. Sayak Dasgupta 25 Reputation points
    2024-04-15T13:39:55.4666667+00:00

    was there any direct fix for this (other than building the entire docket container yourself as mentioned) as I am still getting this issue ?

    0 comments