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:
1 | $ kubectl apply --server-side -f deploy/bundle.yaml |
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:
1 2 3 4 5 6 7 | metadata: name: appdb spec: users: - name: djangoapp databases: - pgtest |
Now you can apply the manifest to provision the cluster:
1 | $ kubectl apply -f deploy/cr.yaml |
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:
1 2 3 4 | django.db.migrations.exceptions.MigrationSchemaMissing: Unable to create the django_migrations table (permission denied for schema public LINE 1: CREATE TABLE "django_migrations" ("id" bigint NOT NULL PRIMA... ^ ) |
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:
1 2 | pgtest=# GRANT ALL ON SCHEMA public TO djangoapp; GRANT |
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:
1 | django.core.exceptions.ImproperlyConfigured: Error loading psycopg2 or psycopg module |
Install psycopg2 by following its documentation. If you are installing it with pip, be aware that it might look for pg_config to build:
1 2 3 4 5 6 7 8 9 10 11 | $ pip3 install psycopg2 … Error: pg_config executable not found. pg_config is required to build psycopg2 from source. Please add the directory containing pg_config to the $PATH or specify the full executable path with the option: python setup.py build_ext --pg-config /path/to/pg_config build ... |
The easiest way to fix it is to install the psycopg2-binary instead:
1 | $ pip3 install psycopg2-binary |
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:
1 2 3 4 5 | $ kubectl get secret appdb-pguser-djangoapp --template='{{.data.password | base64decode}}' 4<_R|8O/@:.2>PnO+DyEW1Kd $ kubectl get secret appdb-pguser-djangoapp --template='{{index .data "pgbouncer-host" | base64decode}}' appdb-pgbouncer.default.svc |
Your settings.py DATABASES section will look the following way:
1 2 3 4 5 6 7 8 9 10 | DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql', 'NAME': 'pgtest', 'USER': 'djangoapp', 'PASSWORD': '4<_R|8O/@:.2>PnO+DyEW1Kd', 'HOST': 'appdb-pgbouncer.default.svc’, 'PORT': '5432', } } |
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:
1 2 | $ kubectl get secret appdb-pguser-djangoapp --template='{{index .data "pgbouncer-uri" | base64decode}}' |
The recommended way for Django is to store environment variables in .env file:
1 |
For using the database URL, use dj_database_url. Install it as usual with pip:
1 | $ pip3 install dj_database_url |
Now you can have something like this in your settings.py:
1 2 3 4 5 6 7 | import dj_database_url import os if os.environ.get('DATABASE_URL'): DATABASES['default'] = dj_database_url.config(default=os.environ['DATABASE_URL']) DATABASES['default']['ENGINE'] = 'django.db.backends.postgresql' |
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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | apiVersion: v1 kind: Secret metadata: name: my-db-secret stringData: --- apiVersion: apps/v1 kind: Deployment metadata: name: django-deploy spec: replicas: 3 spec: containers: - name: mydjango image: mydjangoapp:1.2.3 ports: - containerPort: 8000 env: - name: DATABASE_URL valueFrom: secretKeyRef: name: my-db-secret key: pgbouncer-uri |
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
