Please provide us with the following information:

This issue is for a: (mark with an x)

- [ ] bug report -> please search issues before submitting
- [ x] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

It would be helpful to have an example and tutorial of deploying static assets to the Azure storages and CDN.

https://docs.djangoproject.com/en/3.1/howto/static-files/deployment/#serving-static-files-from-a-cloud-service-or-cdn

Minimal steps to reproduce

Any log messages given by the failure

Expected/desired behavior

OS and Version?

Windows 7, 8 or 10. Linux (which distribution). macOS (Yosemite? El Capitan? Sierra?)

Versions

Mention any other details that might be useful

---

Thanks! We'll be in touch soon.

Please provide us with the following information:

This issue is for a: (mark with an x)

- [x] bug report -> please search issues before submitting
- [ ] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

1. Deploy demo into app service with Linux, Python 3.7.7
2. Set pwd in Application settings. The pwd contains $, like 123$123
3. SSH to app service and run python manage.py migrate

Any log messages given by the failure

django.db.utils.OperationalError: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
FATAL: password authentication failed for user "xxx"

Expected/desired behavior

Should connect with DB successfully

OS and Version?

PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"

Versions

Mention any other details that might be useful

App itself can connect with db successfully. It seems caused by migrate command. If you try print variable from console, the following character will be escaped too.

---

Thanks! We'll be in touch soon.

This issue is for a: (mark with an x)

- [ ] bug report -> please search issues before submitting
- [ ] feature request
- [x] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

With the adjustment of removing DJANGO_ENV in favor of WEBSITE_HOSTNAME in pull request #18, documentation shown on Microsoft Docs may no longer be correct as it still notes to configure a DJANGO_ENV variable in settings:
https://docs.microsoft.com/en-us/azure/postgresql/flexible-server/tutorial-django-app-service-postgres?tabs=clone

Any log messages given by the failure

Expected/desired behavior

In the Docs, the following command is to be issued in the Azure CLI:
az webapp config appsettings set --settings DJANGO_ENV="production" DBHOST=".postgres.database.azure.com" DBNAME="postgres" DBUSER="" DBPASS=""
This command, however, sets DJANGO_ENV and makes no mention of setting WEBSITE_HOSTNAME

OS and Version?

Any OS

Versions

Mention any other details that might be useful

I'm new to setting up Python/Django into Azure Web Apps, so my apologies if I'm missing something. I'm not sure te exact changes/commands necessary to swap out this configuration change.

Shouldn't the following line be in the production.py file since it is used to deploy to a public environment:
DEBUG = True

Please provide us with the following information:

This issue is for a: (mark with an x)

- [ ] bug report -> please search issues before submitting
- [ ] feature request
- [X] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

I'm looking to connect with the regular Azure SQL Server db instead of the Postgres db, However I'm running into an issue regarding the ODBC connector. In VMs and local I'm able to install the required ODBC connector via the docs that are there which are complete and accurate. Is there a way to deploy the needed tools via the build_and_deploy.yaml template that you have? Or is the ODBC driver simply not available through the app service?

the specificic error is this:

django.db.utils.Error: ('01000', "[01000] [unixODBC][Driver Manager]Can't open lib 'ODBC Driver 13 for SQL Server' : file not found (0) (SQLDriverConnect)")

But that's obvious given that the App Service never installed the ODBC driver. My question is: where does that step go and where in the deploy.yaml file would it go?

OS and Version?

ubuntu-latest

I'm basically using a clone of the deployment you have. The full code is here, but the deployment is the same.

Versions

Mention any other details that might be useful

---

Thanks! We'll be in touch soon.

Shouldn't the SECRET_KEY go to Azure's environment variables?

Please provide us with the following information:

This issue is for a: (mark with an x)

- [ ] bug report -> please search issues before submitting
- [ X] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

While this doesn't pertain to this repo exactly, it would be great to add support for Azure in cookiecutter-django. In addition to this example repo, it would be great to see an example / cookiecutter of a production ready django project on Azure.

https://github.com/pydanny/cookiecutter-django

Feel free to close this out, but wanted to raise this as I'm navigating how to deploy a prod django app on Azure.

This repo is referenced in the Microsoft Azure doc, "Build a Python (Django) web app with PostgreSQL in Azure App Service". However, the requirements.txt file in this repo uses pyscopg2-binary which is not the recommended library for production. There is nothing in the doc that suggests that the pyscopg2-binary libary should be avoided for production which can give developers the impression that this is the standard library that should be used.

The problem is that pyscopg2 does not install on Azure App Service for Linux because the container doesn't have the dependency to build pyscopg2. So there is no choice but to use pyscopg2-binary. If there is a walk-through on the Azure docs to deploy a Django app with Postgres then the container that is used for Azure app service should be able to build psycopg2 which is the recommendation for production. I think it is very misleading otherwise.