Django App deployment on Azure — Azure Plugin, CI/CD, security configurations, and data persistence

As in this article, I will just focus on Azure Plug-in, Azure web app service and Deployment services, please see the official documentation to create your first Django project.

Once an MVP (a minimum valuable product) of your project is set up, we can explore how to deploy by using Azure.

Azure Plugin

It is now possible to create and manage Azure resources by installing the Azure plugin.

In Visual Studio Code, is possible to get from the plugin marketplace and install the official Azure Tools plugin.

Django App Deployment via Azure Plugin

Once have installed the Azure plug-in, you will be asked to log in to your Azure Account.

Once have logged in, you can pick up one of your Azure account subscriptions, and create a new App Service instance (as shown in the picture below).

You will be asked to indicate:

• Application Name
• Technology slack
• Azure Tier

Once have indicated all the project details, Azure will ask you for the deployment of your project, indicating a unique URL related to your app.

Security concerns

Before deploying our Django application, two main actions must be taken:

• Remove app secret key from settings.py
• Set DEBUG=False

The Debug configuration, if enabled (set to True), will show to video the traceback of each error, including possible metadata or sensitive information that may compromise privacy.

Instead to keep the secret key and Debug status on the default settings.py file, the secret key and debug status should be stored inside a .env file (created in the same folder of the settings.py file).

Once have created the .env file, we can dynamically import values stored in the .env as indicated below:

Is good practice (that least where I was born), to not commit the .env file, you can both access your Django application via ssh or via sftp.
In case you wish to access via ssh and manually create your .env file, you can scroll down and select ssh access.

For further improvements (and best practice configuration) related to email alerts, database management, logging system and 404 error handlings, you may need to check the official Django deployment checklist.

CI/CD

As redhat.com states, “CI/CD is a method to frequently deliver apps to customers by introducing automation into the stages of app development.”

To quickly deploy our application, we can use the Deployment Center offered by Azure, choose the build provider (Github in my case), login, select repository and branch used to automate the CI/CD;

According to my personal configuration, at each push (or merge) into the develop branch of my repository, a pipeline will be triggered, will be triggered and the new version of the branch will be deployed.

Data Persistence on Azure App Service

When you create a Django App, by default you are using the sqllite3 database. All data of the sqlite3 database are stored in a sqlite3 file.

You cannot adopt this database in both production and development environments in Azure. By ignoring the main differences between sqlite3 and PostgreSQL or any other database that you may want to use, at each deployment on azure, the sqlite3 file may be overwritten and so, all data are lost.

To avoid losing data at each deployment, it is necessary to create a database service and link it to our web app.

Before deploying in production

Before deploying in production, make sure to check legal requirements related to the data usage of your user.

If you are going to expose your Django app to European users, your data management policy must be in line with the GDPR privacy law.

Personally, for my next release, I have seen and decided to adopt: the django-GDPR package.

Thank you for having read this article.

Let’s connect: linkedin.com/in/davidepollicino7/