DEV Community: Mahesh Prajapati

Django Admin Mazer - Custom Django-admin replacement

Mahesh Prajapati — Thu, 24 Feb 2022 10:03:23 +0000

I am currently working on a Django admin templates replacement app, named django-admin-mazer. Available to install with pip for your testing.

The templates are taken from an open-source admin template available here.

Installation process:

pip install django-admin-mazer
Add 'django_admin_mazer' in your INSTALLED_APPS and you are good to go.

Github: https://github.com/mahyess/django-admin-mazer

Some screenshots taken while in development:

Be warned, this project is bootstrapped in a short amount of time, so expect some glitches here and there. So, there are unfinished tasks that I may not have found out just yet.

Please feel free to point out problems, or even contribute to the project.

Github: https://github.com/mahyess/django-admin-mazer

Docker-compose-ing a Django App - for complete starters

Mahesh Prajapati — Mon, 31 Jan 2022 14:08:18 +0000

In the earlier post, in which I described about writing a simple Dockerfile for a Django App.

We will pickup where we left off earlier. If you are completely new to Docker, I recommend checking the previous post first.

The starter code that we are using for this post is available in GitHub if you want to follow along.

Let's see how the file structure looks before we start:

├── Dockerfile
├── manage.py
├── README.md
├── requirements.txt
└── main
    ├── asgi.py
    ├── __init__.py
    ├── settings.py
    ├── urls.py
    └── wsgi.py

If you are following from the previous post, you will notice I have renamed the 'main' project folder from todo to main. It's because I want to scale this tutorial series to use as a starting template for future projects. So I felt it's important to keep the folders' name as generic as they can be.

The folder structure shouldn't seem to be too confusing as they are not complicated to understand.

Let's go forward. First of all, create a directory in project root called app and move all existing contents to the app folder, so the folder structure now looks like:

.
├── app
│   ├── Dockerfile
│   ├── entrypoint.sh
│   ├── main
│   │   ├── asgi.py
│   │   ├── __init__.py
│   │   ├── settings.py
│   │   ├── urls.py
│   │   └── wsgi.py
│   ├── manage.py
│   └── requirements.txt
└── README.md

3 directories, 12 files

Why do this? It's because we are incorporating docker-compose which by its nature, allows us to manage multiple tools for our project, django being one of them. Each of those tools and their configs should go to their respective directory for clear code and readability.

Now, let's create a docker-compose.yml file at the root directory, which now contains the app directory and write the following lines of code.

version: "3.8"

services:
  app:
    build:
      context: ./app
      dockerfile: Dockerfile
    command: python manage.py runserver 0.0.0.0:8000
    volumes:
      - ./app:/app
    ports:
      - "8000:8000"
    env_file:
      - ./app/.env
    environment:
      - DEBUG=1

Let's go through the code and see what's happening
1.

version: "3.8"

We want to use docker-compose version 3.8. How does this versioning matter? That's a lot of complex topics for this post, but if you want to know more, you can check official docker website.

services:

We want to list the 'tools' as mentioned earlier as array items within the services.

  app:

Each of the 'tools' needs their own name as recognition. app is just a generic name for the django container. You can put anything instead of app like django, server or even labrador.

    build:
      context: ./app
      dockerfile: Dockerfile

As we know, each 'tool' or container in docker languages, needs to build before we run. We learnt that in the previous post as well. docker-compose needs to know which folder to look for to build the container app. So, naturally, we put all the files related to the app container into app folder and gave the context name to ./app, as in app folder from where docker-compose.yml file is located.

At the same time, it also asks for Dockerfile location. So the name and location, relative to the folder provided in context. We may want to have multiple Dockerfiles later on, so it is convenient to have them in easy-to-remember place

    command: python manage.py runserver 0.0.0.0:8000

If you understand Django, this is just a standard run command which we want to do when we start the server later on.

    volumes:
      - ./app:/app

The volumes mapping allows us to map local folders to folders inside the container. If you look into Dockerfile, we created a folder named app. The folder inside the container and local system stay synchronized with this command. It also triggers hot reloading of server whenever we change something in local system, so it's very important to keep it on while debugging. Else, we will have to restart the server on every code change.

    ports:
      - "8000:8000"

Just like the previous post, we want to map our local port 8000 to container's port 8000 to access the server.

With this, you can remove the lines 7. EXPOSE 8000 and 8. CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"] Since, both of them are now managed by docker-compose herein.

    env_file:
      - ./app/.env
    environment:
      - DEBUG=1

Both env_file and environment can be used to set environment variables to the container. environments are preferred when the variables are public, whereas env_files which are usually git-ignored, can be used to set private environment variables like secret-keys, tokens and even passwords. We will look into how to use them later on.

For now, lets go to the terminal and hit up

docker-compose build

If everything went fine, you may now see Successfully built in the terminal.

So, we may now fire up the server by running

docker-compose up

We should now be presented with this beautiful screen when we navigate to localhost:8000 in our browser.

That's all it takes to run our django project with docker-compose. As simple as it can get.

All the code is available in GitHub

Up next, we will add postgres database and nginx reverse proxy to the setup and find-out how docker-compose systems can be scaled up.

Dockerizing a Django App - for complete starters

Mahesh Prajapati — Wed, 19 Jan 2022 12:21:32 +0000

As starters, the term docker can be quite daunting and may seem a big cliff to overcome but it shouldn't be as such.

The vast amounts of tutorials covering a lot of information at once, doesn't help the starters, speaking from personal experience. That's why, this post is a single step towards the complete new world of docker. So, let's begin.

First thing first, you need to have a existing Django project that you are willing to Dockerize.

I have created a new Django project for this very purpose and going to use it as a starting template. Let's see files that are here inside this folder.

├── db.sqlite3
├── manage.py
├── requirements.txt
└── todo
    ├── asgi.py
    ├── __init__.py
    ├── settings.py
    ├── urls.py
    └── wsgi.py

As a complete boilerplate, when run the server with python manage.py runserver, we are presented with our starting page.

So far, so good.

Let's create a file named Dockerfile in the root directory. The files tree needs to look like

├── db.sqlite3
├── Dockerfile
├── manage.py
├── requirements.txt
└── todo
    ├── asgi.py
    ├── __init__.py
    ├── settings.py
    ├── urls.py
    └── wsgi.py

Now, let's quote what Dockerfile is:

A Dockerfile is a text document that contains all the commands a user could call on the command line to assemble an image.

This is where we put the commands to build our image.

FROM python:3.10

RUN mkdir /app

COPY requirements.txt /app/

WORKDIR /app

RUN pip install -r requirements.txt

COPY . /app/

EXPOSE 8000

CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"]

Let's go through these commands one by one.

FROM python:3.10-slim

We are using python:3.10-slim as our base image from which we build our image. We can use python:3.10 but it will generate larger build file, which we should be trying to reduce. Also, we can use python:3.10-alpine which reduces the size even further, but this will require extra care from our end. That's a topic for some other time. If you are interested in knowing further, you can go through here.

RUN mkdir /app

It is pretty straight-forward. It creates a new directory called app in root directory of the image.

COPY requirements.txt /app/

It copies the requirements.txt file from our project to the directory we just created. If you don't have this file yet, you can create one by entering the command pip freeze > requirements.txt which gets all packages that are currently installed in our django project and writes them into the said file.

WORKDIR /app

It sets the current working directory to the directory we created. In other words, we cded to this directory. Any commands we enter from herein are triggered from this directory.

RUN pip install -r requirements.txt

The image we used from line 1, python:3.10-slim as pip installed into it by default. So we can run any pip commands in the image. This command installs all the packages that we had installed in our local system previously.

COPY . /app/

Similar to line 3, but now we copy all files and folders in the local system into the image. Now, why didn't we did this in line 3 itself? If you wondered, that's good. It's because docker caches all the commands while building the image, so if we haven't changes requirements.txt further down the line in future, all commands from 1-5 aren't triggered again. Else, even if there aren't any changes in packages, but have changes in our project, docker will unnecessarily installs all the packages again.

EXPOSE 8000

We are almost done. It exposes the port 8000 to "outside world" from image. Since we are going to run Django in port 8000, this is a gateway to the server we are going to run later.

CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"]

Finally, it runs the command python manage.py runserver 0.0.0.0:8000 inside the image. That means, our server will now be up and running.

We have completed writing a very basic Dockerfile that works. Now, head up to the terminal and enter the command:

docker build -t todo/latest .

Let's wait for some time as docker builds our image. If you are wondering what's todo/latest, its a tag name. You can put anything as you want or even skip it to just run docker build ., but we will have to search for our image by going to through a list of images built in the system by going through docker ps. Let's not go out of our way for now. If you are interested, you can certain try it by yourself.

So, after waiting a couple of minutes, or seconds, depending on several factors, to complete the build, let's trigger the final command.

docker run -p 8000:8000 todo/latest

This command runs the CMD that we have provided in the Dockerfile. As for 8000:8000, we are binding our local port 8000 to the image's port 8000. If you wish, you can put 80:8000, so it binds to local port 80 to the image's port.

If everything goes well, your terminal should get a normal Django server log. For me, it's

╰─ docker run -p 8000:8000 todo/latest
Watching for file changes with StatReloader
Performing system checks...

System check identified no issues (0 silenced).

You have 18 unapplied migration(s). Your project may not work properly until you apply the migrations for app(s): admin, auth, contenttypes, sessions.
Run 'python manage.py migrate' to apply them.
January 19, 2022 - 11:55:15
Django version 4.0.1, using settings 'todo.settings'
Starting development server at http://0.0.0.0:8000/
Quit the server with CONTROL-C.

Let's check our browser for confirmation. We should be presented again with this beautiful page.

Congratulations, you have successfully "Dockerize" your Django application.

As for the migrations warnings, you can add a line RUN python manage.py migrate after line 6 and before line 8, and build again.

This is a very basic Dockerfile as mentioned. I want it to be understood by a complete beginner so haven't included a number of "gotcha"s to the Dockerfile, they can be learnt as we go and code.

The complete code can be found in my GitHub. Feel free to check it out, if you are having any problems.