Deploy Django on Kubernetes With Percona Operator for PostgreSQL

Developers need an efficient, reliable way to run their Django applications with a robust PostgreSQL. Percona Operator for PostgreSQL offers a powerful solution for managing and scaling PostgreSQL databases in a Kubernetes environment, making it an ideal choice for developer use cases. In this blog post, we’ll explore what it takes to run Django on Kubernetes with Percona Operator.

Set up PostgreSQL

Use your favorite way to deploy PostgreSQL Operator. I will use the regular kubectl approach:

Django application would require its own user and database. Alter cluster custom resource (cr.yaml) manifest spec.users section. The following example will create the cluster appdb,  the user djangoapp and database pgtest. The user will have access to pgtest database only:

Now you can apply the manifest to provision the cluster:

The Operator will generate the secret for the user called CLUSTERNAME-pguser-djangoapp. Read on to learn how to get credentials and connection string from it.

PostgreSQL 15 public schema

PostgreSQL 15 removes the global write privilege from the public schema. As a result, you might see the following error when running migration in Django:

To fix that, it is necessary to explicitly allow djangoapp permissions to public schema. To do that, you need to connect to the cluster with superuser and run grants:

Learn how to connect with a superuser in our documentation.

Django and PostgreSQL

psycopg2

Psycopg is a PostgreSQL database adapter for the Python programming language. Django uses it to connect to the database. You will see the following error if you don’t have it installed and trying to connect to PostgreSQL:

Install psycopg2 by following its documentation. If you are installing it with pip, be aware that it might look for pg_config  to build:

The easiest way to fix it is to install the psycopg2-binary instead:

settings.py

settings.py  is the main configuration file for Django applications. It is where you should configure the database – provide credentials, set the correct engine, and more. You can read more about it in Django’s documentation.

There is nothing super specific about configuring Django and Percona Operator. First, get the connection string and credentials from the Operator. For the cluster appdb and the user djangoapp they are stored in a secret appdb-pguser-djangoapp. The following commands will get you what is needed:

Your settings.py DATABASES section will look the following way:

settings.py and Kubernetes

The recommended way to pass credentials to containers is through environment variables. In Kubernetes, it will be additionally wrapped into a Secret resource.

To make it work, we will put our database URI into an environment variable. You can get the database URI from the secret as well:

The recommended way for Django is to store environment variables in .env  file:

For using the database URL, use dj_database_url. Install it as usual with pip:

Now you can have something like this in your settings.py:

Note the ENGINE, as dj_database_url does not set it.

You can also avoid using dj_database_url  and pass each variable separately through os.environ.

Passing a variable in Kubernetes

In Kubernetes, you can pass the DATABASE_URL to a container through a Secret. You can mount a separate Secret or reuse the one that the Operator manages. The recommended way is to have a separate Secret object, as your application might be in a separate namespace, and you might not have enough permissions to mount the one that is managed by the Operator. The Secret and Deployment might look as follows:

Conclusion: Deploying Django with Percona Operator for PostgreSQL

Running Django on Kubernetes with Percona Operator for PostgreSQL offers developers an efficient and scalable solution for managing their database needs in a Kubernetes environment. While there are some caveats and potential issues to be aware of, the configuration examples and explanations provided in this blog post will help developers overcome any challenges they may encounter. With Percona Operators, developers can focus on building and delivering their applications with confidence and ease.

Learn more about Percona Operator for PostgreSQL in our documentation.

You can get early access to new product features, invite-only “ask me anything” sessions with Percona Kubernetes experts, and monthly swag raffles. Interested? Fill in the form at percona.com/k8s.

As more companies look at migrating away from Oracle or implementing new databases alongside their applications, PostgreSQL is often the best option for those who want to run on open source databases.

Read Our New White Paper:

Why Customers Choose Percona for PostgreSQL

Subscribe

Connect with

Login

Label

0 Comments