I was trying to make an existing PersistentVolumeClaim (PVC) work with ReadWriteMany (RWX) and a different Azure StorageClass. At first, it felt like this should be a simple YAML update but it wasn’t that easy.

What I Tried to Do

I’d set up a PVC earlier inside a space called demo-ns. This one came into being through:

• A single user can write to it, while others just read. Mode set to allow one writer at a time

• Azure Disk (so basically a single-writer style volume)

After a while, my mind shifted toward changing it into:

• ReadWriteMany (RWX) a different azure storageclass supporting rwx

Fiddling with the PVC settings took a turn when changes wouldn’t stick. Things just froze up instead of moving forward.

Here's why it trips people up

Things get complicated here - two reasons are behind it

1. PVC specs are mostly immutable after creation

After a PVC exists - particularly if it's bound - Kubernetes blocks modifications to critical fields such as accessModes. Though set at creation, those settings stay locked by design. Only certain attributes remain adjustable once established. The rest resist updates without exception.

Editing the YAML file fails to behave as anticipated.

1. Storage choice shapes how RWX behaves - the application plays a role too

It isn’t enough to just set ReadWriteMany in Kubernetes. The real work happens behind the scenes - your storage system has to allow many nodes reading and writing at once. Without that ability, the label means nothing. What matters is whether the hardware underneath can handle shared access across machines. A setting alone won’t create functionality out of thin air.

A change to a StorageClass with RWX capability? It's needed. Yet even then, altering a current PVC right where it sits won't work.

Even when storage allows RWX, problems might pop up if multiple Pods access the same data folder together - this hits databases hard. One Pod writes while another reads mid-step, chaos follows. Sharing isn’t always safe, especially when timing slips. Data gets tangled fast. Sudden crashes creep in. Locks fail. Files corrupt. All it takes is overlap. Systems assume control - but lose it quick. Conflicts rise without warning. Expect mismatches. Assume nothing stays clean.

What happened next (the unexpected part)

Starting fresh, we switched from RWO to RWX. This shift led us to adopt an Azure files(CSI) StorageClass capable of handling RWX mode instead.

Yet the system froze when too many users accessed it at once.

It hit me right then. RWX lets many Pods attach to one volume together, yet opens the door for those same Pods to launch at once - clashing over identical database files without warning.

How we kept things steady

Eventually things landed back where they started - basic, quiet, nothing fancy

Back on RWO now. A single pod now handles tasks one after another. Instead of running many at once, it follows a sequence. The approach shifts how work gets done. One job finishes before the next begins. This method limits active pods to just one. Execution becomes more controlled. Timing changes under the new flow. Each step waits its turn.

Usually, the system picks a standard storage type right away. That choice sticks when setting up storage volumes. Changing it later can cause problems. So instead of swapping things out under the hood, it just keeps the original setup running. This avoids breaking what is already connected. The method focuses on stability over changes. Picking one at the start makes everything line up correctly. Once active, it stays that way through the process.

Takeaway

Possibly switching the accessMode to ReadWriteMany won’t go smoothly - Kubernetes might step in, or your app could simply refuse. Changing the StorageClass at the same time? That often triggers a halt. Some setups reject the combo outright. Others let it start, then fail quietly. It looks like it should work until it does not. The cluster enforces rules behind the scenes. What seems logical on paper hits invisible walls. Attempts usually end with stalled pods or rejected mounts. Not every storage backend supports shared writes. Even when they do, mismatched settings stop progress. You are left troubleshooting without clear clues.

Most times, changing how storage works involves setting up a fresh PVC. Checking if RWX fits the job matters a lot - databases especially need close attention. What happens next depends on the app's needs, not just default choices.

References

• https://kubernetes.io/docs/concepts/storage/storage-classes/

• https://marcbrandner.com/blog/your-very-own-kubernetes-readwritemany-storage/

• https://github.com/rancher/local-path-provisioner/issues/70

• https://medium.com/@golusstyle/demystifying-the-multi-attach-error-for-volume-causes-and-solutions-595a19316a0c

• https://stackoverflow.com/questions/55474193/volume-is-already-attached-by-pod

In addition to virtual networks and connectivity options, Azure provides tools to monitor and manage network traffic, perform load balancing, and ensure secure user connections.

What is an Azure Virtual Network (VNet)?

An Azure Virtual Network (VNet) is a private, secure network in the cloud that links your Azure resources, such as virtual machines, databases, and apps. It allows you to manage how these resources communicate with each other and the internet, ensuring privacy and security. Essentially, it's like having your own isolated network in the cloud.

Think of it as your own private, isolated “office” in the Azure cloud. The resources in this VNet can talk to each other, but they’re shielded from the outside world unless you explicitly allow it.

Key Benefits of Azure VNets

• Isolation: Just like a physical network in your office, you can control which resources can communicate with each other. This is done using subnets, which divide your VNet into smaller, more manageable sections.

• Security: Using Network Security Groups (NSGs), you can restrict traffic between resources, like a security guard at the entrance of your office only letting authorized people in.

• Flexibility: VNets can easily grow or shrink as your cloud needs change. Add more resources, or scale down based on demand — just like rearranging your office layout to accommodate a growing team.

• Connectivity: You can even connect your VNet to other VNets or extend it to your on-premises office network using VPN Gateways or ExpressRoute for hybrid cloud solutions.

Core Concepts of Azure Networking

1. Subnets

Let’s understand this with a example, Let’s think of subnets as different floors or rooms in your office. Each room has a specific function, and you control who can enter each room. For example:

• One room (subnet) could house your web servers.

• Another room could be reserved for your database servers.

• A third room might host your application servers.

VNets can be divided into subnets, which help segregate resources logically and apply specific security policies. Common subnet use cases include:

• Web Tier Subnet: Hosts frontend applications.

• App Tier Subnet: Runs backend services and APIs.

• Database Subnet: Stores and processes data with restricted access.

2. Application Gateway

Now, imagine that your office has a receptionist who directs visitors to the right department. Azure Application Gateway works in a similar way—it is a traffic manager for your web applications. It ensures that web requests are routed efficiently to the right backend services.

It operates at the application layer (Layer 7), and it’s responsible for:

• Load balancing web traffic to different servers.

• SSL termination, meaning it handles encrypted connections to improve performance.

• URL-based routing, sending traffic to specific backend pools based on the URL. For example:

  • Traffic going to www.yourcompany.com/frontend/* can be routed to the frontend servers.

  • Traffic going to www.yourcompany.com/api/* can be routed to the backend servers.

It can also provide security through a Web Application Firewall (WAF), protecting your application from threats like SQL injection and cross-site scripting (XSS).

2. IP Addressing

When you assign an IP address to a resource in your VNet, it's like giving each phone in your office a unique extension number. With both private IPs (for communication within the VNet) and public IPs (for communication with the outside world), you can control how each resource interacts externally.

Each VNet needs an address space (CIDR block) that sets its IP range. These addresses can be assigned as:

• Private IPs (for internal communication)

• Public IPs (for internet-facing services)

3. Network Security Groups (NSGs)

Think of NSGs as the security team for your office network. They define who can access what. Want to restrict access to certain resources? An NSG can enforce these security rules to only allow certain types of traffic, ensuring unauthorized users don’t enter restricted areas.

NSGs act as firewalls for filtering inbound and outbound traffic based on rules. Example rules:

• Allow HTTP (80) traffic to web servers

• Restrict access to database subnet from the public internet

4. Azure Firewall

It works like the firewall at your office's main entrance, filtering incoming and outgoing traffic to protect against potential threats. It add’s a additional layer of protection to the network and resources.

5. Routing & User Defined Routes (UDRs)

Just like your office has clearly defined paths for communication between departments, User Defined Routes (UDRs) ensure that data flows efficiently between resources within and outside your VNet. You can customize these routes to ensure the right connections are made.

By default, Azure automatically routes traffic between subnets and connected networks. However, you can define User Defined Routes (UDRs) to customize how traffic flows.

6. Load Balancer

If you're running a high-traffic website or application, the Azure Load Balancer helps distribute traffic evenly across your VNet's resources. This Azure networking service automatically adjusts itself when administrators scale an instance..

7. ExpressRoute

Azure ExpressRoute is a networking service that creates a private connection between a company’s on-premises infrastructure and Microsoft Azure. Unlike the public internet, this private link offers lower latency and greater reliability.

ExpressRoute supports four connectivity models:

• CloudExchange Colocation

• Point-to-point Ethernet Connection

• Any-to-any Connection

• ExpressRoute Direct

8. Azure Network Watcher

Azure Network Watcher is a monitoring tool that provides insights into your Azure network resources. It helps IT teams track, diagnose, and analyze network performance by offering tools to view metrics, logs, and resource interconnections. Unlike individual resource monitoring, Network Watcher gives a comprehensive view of IaaS products, such as Azure VMs and VNets. Charges apply based on the features used.

9. Content Delivery Network

Azure CDN is a service that delivers high-bandwidth content, like documents and files, through cached copies stored at edge locations around the world. This ensures content is delivered closer to end users, minimizing latency. While Azure CDN optimizes content delivery, it focuses more on performance and less on load balancing and security compared to Azure Front Door. It's ideal for serving static content quickly and efficiently.

As Kubernetes pods can have more than one container.
Init containers are specialized containers that run before app containers in a Kubernetes Pod. Unlike regular containers, init containers must complete successfully before the main application containers can start. This sequential execution pattern makes them perfect for setup tasks.

Why Use Init Containers?

1. Separating initialization logic from application code

2. Delaying application startup until dependencies are ready

3. Running setup operations with different security contexts

4. Pre-populating volumes with configuration or data

How Init Containers Work?

Before jumping into the example, let’s see how it works step by step.

1. When a Pod is created, the kubelet initializes all volumes and networks

2. Kubelet starts init containers sequentially in the order defined in Pod spec

3. Each init container must terminate completely before the next one starts

4. The kubelet waits for each init container to have exit code 0 before proceeding

5. If an init container fails, kubelet restarts it according to the Pod's restartPolicy

6. Once all init containers complete successfully, kubelet initializes and starts all app containers simultaneously

7. Status of init containers is exposed in the Pod's .status.initContainerStatuses field

8. Init containers rerun completely during Pod restarts (unlike regular containers)

9. Kubelet retains init container logs until the Pod is deleted, even after container termination

Let’s see a example: Django with PostgreSQL

In this example, Let’s start with the scenario where PostgreSQL database is ready before starting your Django application.

apiVersion: v1
kind: Pod
metadata:
  name: django
spec:
  initContainers:
  - name: wait-for-postgres
    image: postgres:13
    command: [
        'sh',
        '-c',
        'until pg_isready -h postgres-service -p 5432; do echo waiting for postgres; sleep 2; done;'
    ]

  containers:
  - name: django
    image: <Image-name>:<Tag>
    env:
    - name: DATABASE_URL
      value: "postgres://user:password@postgres-service:5432/app_db"
    ports:
    - containerPort: 8000
  - name: nginx
    image: nginx:1.21
    ports:
    - containerPort: 80
    volumeMounts:
    - name: nginx-config
      mountPath: /etc/nginx/conf.d/
  volumes:
  - name: nginx-config
    configMap:
      name: nginx-config

In this example, the init container uses pg_isready from the official PostgreSQL image to check if the database is accepting connections. The Django application and Nginx containers only start after this verification succeeds.

Let’s deploy this pod.

Save the YAML as web-app.yaml and apply it:

kubectl apply -f web-app.yaml

Check the pod status:

kubectl get pods

You’ll see the init container running first. Once it’s done, your app starts.

Resources and Volumes for Init Containers

Init containers can define resources and access volumes just like regular containers, with some important considerations:

• Resource Requests and Limits

  • The highest resource request/limit for each resource across all init containers is used

  • The Pod's effective request/limit is the higher of the sum of app containers and the highest init container

  • This ensures init containers have enough resources without permanently reserving them

• Volume Usage

  • Init containers can mount and modify volumes that app containers will later use

  • Volumes created by init containers are available to app containers

  • Changes made to shared volumes by init containers persist for app containers

  • Empty directories and persistent volumes can be shared across container

apiVersion: v1
kind: Pod
metadata:
  name: django
spec:
  initContainers:
  - name: wait-for-postgres
    image: postgres:13
    command: ['sh', '-c', 'pg_isready -h postgres-service && echo "DB schema initialized" > /data/status.txt']
    resources:
      limits:
        memory: "256Mi"
        cpu: "500m"
      requests:
        memory: "128Mi"
        cpu: "250m"
    volumeMounts:
    - name: shared-data
      mountPath: /data

  containers:
  - name: django
    image: <Image>:<Tag>
    resources:
      limits:
        memory: "512Mi"
        cpu: "500m"
      requests:
        memory: "256Mi"
        cpu: "250m"
    volumeMounts:
    - name: shared-data
      mountPath: /app/data

  volumes:
  - name: shared-data
    emptyDir: {}

Init container vs Sidecar container

1. Init Container performs tasks that need to be completed before the main container can start, while Sidecar Container provides supplementary functionality to the main container.

2. Init Container runs to completion and must succeed before the main container starts, while Sidecar Container runs continuously alongside the main container.

3. Init Container is used for setup tasks like waiting for dependencies, fetching configs, or running migrations, while Sidecar Container is used for tasks like logging, monitoring, or proxying.

4. Init Container always runs first in the pod lifecycle, while Sidecar Container runs concurrently with the main container.

5. If an Init Container fails, the pod restarts it until it succeeds, while a failing Sidecar Container may or may not impact the main container depending on its role.

6. Init Container does not run simultaneously with the main container, while Sidecar Container shares resources and runs in parallel with the main container.

So, Init containers always run to completion and each init container must complete successfully before the next one begins. If any init container fails, Kubernetes restarts the Pod repeatedly until initialization succeeds and Init containers can access secrets, while preventing app containers from having these privileges. Thank you.

References:

https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

https://www.loft.sh/blog/kubernetes-init-containers

https://www.alibabacloud.com/blog/kubernetes-init-containers_594725

Mock() object

The Mock() object from the unittest.mock class is at the heart of mocking in Python. It serves as a versatile tool for creating mock objects that behave like real ones but don't have actual functionality. We can set attributes, define return values for methods, and even assert how these mock objects are used in tests.

Example:

from unittest.mock import Mock

# Create a mock object
mock_obj = Mock()

# Set an attribute
mock_obj.attribute = 'value'

# Define a method's return value
mock_obj.some_method.return_value = 10

# Usage in a test scenario
result = mock_obj.some_method()
assert result == 10

mock_obj is a mock object where attribute is set to 'value', and some_method() is mocked to return 10. This allows to simulate different behaviors without accessing real resources.

patch()

The patch function from unittest.mock acts as a decorator or a context manager. It temporarily replaces objects or functions during testing, allowing to control their behavior within a specific scope.

Example:

from unittest.mock import patch

# Example of patching a function
def original_function():
    return 'Real function'

@patch('__main__.original_function')
def test_mocked_function(mock_function):
    mock_function.return_value = 'Mocked function'
    result = original_function()
    assert result == 'Mocked function'

patch temporarily replaces original_function with a mock version defined within test_mocked_function. This ensures that the test test_mocked_function runs with the mocked behavior, validating expected outcomes without altering the original function's behavior outside the test.

side_effect

The side_effect attribute of a mock object allows to define what happens when the mock object is called. It can be set to a function, an exception, or a sequence of return values, making it versatile for testing different scenarios.

Example:

from unittest.mock import MagicMock

# Example using side_effect with MagicMock
mock = MagicMock()

# Define side_effect as a sequence
mock.side_effect = [1, 2, 3]

print(mock())   # Output: 1
print(mock())   # Output: 2
print(mock())   # Output: 3

mock() is called three times, and each time it returns the next value from the side_effect list [1, 2, 3]. This demonstrates how side_effect can be used to simulate different return values sequentially during testing.

Magicmock()

MagicMock() is a subclass of Mock() that automatically provides all attributes and methods. It's useful when you need a mock object that behaves like a real one without needing to manually define every aspect.

from unittest.mock import MagicMock

# Example of MagicMock usage
mock_obj = MagicMock()

# Set a method's return value
mock_obj.some_method.return_value = 'Mocked result'

result = mock_obj.some_method()
print(result)   # Output: 'Mocked result'

mock_obj is a MagicMock object where some_method() is mocked to return 'Mocked result'. This simplifies mocking by automatically providing all necessary attributes and methods of the mocked object.

By leveraging these mocking techniques in Python, It helps to effectively isolate components for testing, simulate diverse scenarios, and ensure robustness in their codebases.

What is the N+1 Problem?

The N+1 problem occurs when an application makes N+1 database queries to fetch related data, where N represents the number of primary objects. This leads to inefficient database queries, resulting in poor performance and increased response times. To illustrate this problem, let's consider a simple example.

Imagine you have a Django model called "Author" that has a foreign key relationship with a model called "Book."

from django.db import models

class Author(models.Model):
    name = models.CharField(max_length=100)

class Book(models.Model):
    title = models.CharField(max_length=100)
    author = models.ForeignKey(
                Author,
                on_delete=models.CASCADE,
                related_name="books" )

Now, suppose you want to retrieve a list of authors along with their respective books.

authors = Author.objects.all()

for author in authors:
    books = Book.objects.filter(author=author)

In a naive implementation, you might iterate over the authors and fetch their associated books one by one, resulting in N+1 queries.

Impact on Performance:

The N+1 problem can have a significant impact on the performance of your Django application. Each additional query introduces a round trip to the database, causing latency and slowing down the overall response time. As the number of primary objects increases, the problem exacerbates, leading to a substantial performance degradation.

How to Solve the N+1 Problem in Django?

Fortunately, Django provides several powerful techniques to solve the N+1 problem and optimize database queries. Let's explore some effective solutions.

1. Select_related():

   One of the simplest ways to mitigate the N+1 problem is through eager loading. Django's ORM provides the select_related() method, which allows you to fetch related objects in a single query.

   To apply eager loading in our example, modify the code as follows:

    authors = Author.objects.select_related('book').all()
   
    for author in authors:
        books = author.book_set.all()
   

   In our previous example, instead of fetching the books one by one, you can modify the query to prefetch the related books using select_related('book'). This way, Django fetches the authors and their books in a single query, eliminating the N+1 problem.

2. Prefetch_related():

   In scenarios where the relationship is more complex, and eager loading alone may not be sufficient, Django offers the prefetch_related() method. This method efficiently fetches the related objects in a separate query, minimizing the impact of the N+1 problem. By using prefetch_related('books'), Django retrieves all the books associated with the authors using a single query, resulting in improved performance.

   Consider the following example using prefetch_related():

    authors = Author.objects.prefetch_related('books').all()
   
    for author in authors:
        books = author.books.all()
   

   Important: It's worth noting that the use of select_related() is more suitable for foreign key and one-to-one relationships, while prefetch_related() is recommended for many-to-many and many-to-one relationships or scenarios involving more complex relationships.

3. Use Annotations and Aggregations:

   By leveraging these features, you can reduce the number of database queries and optimize performance. For instance, you can annotate the queryset with the count of related books using annotate(num_books=Count('books')). This way, you can fetch both authors and the count of their books in a single query.

You can find these techniques in the Django Documentation.

Thanks for reading.👋

Docker is a widely used platform that enables developers to package their applications, along with their dependencies and configurations, into containers that can seamlessly run across various environments.

With Docker commands, you gain the power to effortlessly create, run, stop, remove, and manage Docker containers. These commands prove to be invaluable in automating and streamlining the process of deploying and managing your applications within a containerized environment. By leveraging Docker commands, you can ensure a smooth and efficient workflow for your container-based applications.

You can easily visit the Docker Documentation for more information.

Docker version :

The docker version displays the installed versions of the Docker, Nothing more than that.

docker version

Docker search :

"docker search" finds and displays relevant Docker images from registries, helping you discover and choose base containers for your applications.

docker search nginx

Docker pull :

The "docker ps" command is valuable for efficiently checking the status and essential information of your active containers. It enables effective container monitoring and management, including tasks like identifying running containers, restarting or stopping specific containers, and inspecting their configurations.

To see the previously stopped containers use the option “-a”

sudo docker ps 
#you can user the command to get the images status
sudo docker ps -a

Docker run :

Create and start a container from an image.

docker run <image>

To run a container in the background and regain control of the current terminal, use the "-d" option with the "docker run" command.

docker run -d <image_name>

To specify specific ports for Docker containers, use the "-p" option to map host ports to container ports, enabling communication between the host machine and the container.

docker run -p <host_port_number>:<container_port> <image_name>

To give the name to your container, use the option “ — name”.

docker run -p <host_port_number>:<container_port> <image_name> --name docker-image

Docker stop :

Gracefully stop a running container.

 docker stop <container>

Docker rm :

Remove one or more stopped containers.

docker rm <container>

Docker images :

List available Docker images on your system.

 docker images

Docker rmi :

It is used to remove one or more Docker images from your system. You need to stop the running container to delete the image.

docker rmi <image1> <image2> <image3>
or,
docker image prune -a

Docker build :

Build a Docker image from a Docker file.

docker build <path/to/Dockerfile>

Docker-compose up :

Start containers defined in a Docker Compose file.

docker-compose up

Docker-compose down :

Stop and remove containers defined in a Docker Compose file.

docker-compose down

Docker network ls :

List Docker networks on your system.

docker network ls

Docker stats :

Display real-time resource usage statistics of running containers.

docker stats

Docker Logs :

Display the logs of a specific container

docker logs <container>

And with that, we've covered the majority of the important commands in this post. If there are any commands I missed, feel free to mention them in the comments. That concludes our discussion for now. Happy Dockerizing!

Please Checkout Dockerizing Django With Postgres, NGINX, and Gunicorn (PART-1)

In this tutorial, We'll be configuring our Postgres in our Django application.So,Let's get started.

Checkout the Git repository for reference: Git Repository

Postgres

In order to set up Postgres, we will have to perform the following steps:

• Include a new service to the docker-compose.yml file

• Modify the Django settings

• Install Psycopg2 package

Let's update the docker-compose.yml file

version: '3.10'

services:
  web:
    build: .
    command: python manage.py runserver 0.0.0.0:8000
    volumes:
      - static_data:/app/static
    ports:
      - "8000:8000"
    restart: always
    env_file:
      - ./.env
    depends_on:
      - db
  db:
    image: postgres:13.0-alpine
    restart: always
    volumes:
      - postgres_data:/var/lib/postgresql/data:rw
    env_file:
      - .env
#or, use environment variable directly
    # environment:
    #    - POSTGRES_USER=${DB_USERNAME}
    #    - POSTGRES_PASSWORD=${DB_PASSWORD}
    #    - POSTGRES_DB=${DB_NAME}
volumes:
  static_data:
  postgres_data:

To ensure that the data is retained beyond the container's lifespan, we set up a volume configuration that maps the "postgres_data" directory to the "/var/lib/postgresql/data/" directory inside the container.

To properly configure the web service, it is necessary to update the .env file with additional environment variables.

SECRET_KEY=
ALLOWED_HOSTS= localhost 127.0.0.1 [::1]
DEBUG=True

# Database
DB_NAME=testing
DB_USERNAME=postgres
DB_PASSWORD=36050
DB_HOSTNAME=localhost
DB_PORT=5432

Update the DATABASES setting in your settings.py file with the following code

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': config('DB_NAME'),
        'USER': config('DB_USERNAME'),
        'PASSWORD': config('DB_PASSWORD'),
        'HOST': config('DB_HOSTNAME'),
        'PORT': config('DB_PORT', cast=int),
    }
}

Next, we will modify the Dockerfile to include the necessary packages for Psycopg2 installation.

# official base image
FROM python:3.10.9-alpine3.17

#set work directory
RUN mkdir /app
WORKDIR /app

#set environment variable
ENV PYTHONDONTWRITEBYCODE 1
ENV PYTHONUNBUFFERED 1

#install pyscopg2 dependencies
RUN apk update && apk add postgresql-dev gcc python3-dev musl-dev linux-headers

#install dependencies
RUN pip install --upgrade pip
COPY ./requirements.txt .
RUN pip install -r requirements.txt

# copy project
COPY . .

Make sure to install psycopg,create Database and add psycopg to your requirement.txt file using pip freeze > requirements.txt

After that, Build the new image with two services:

$ docker-compose up -d --build

Then run the migrations:

$ docker-compose exec app python manage.py migrate --noinput

You can check that the volume was created as well by running:

$ docker volume inspect django-on-docker_postgres_data

You should see something similar to:

[
    {
        "CreatedAt": "2021-08-23T15:49:08Z",
        "Driver": "local",
        "Labels": {
            "com.docker.compose.project": "django-on-docker",
            "com.docker.compose.version": "1.29.2",
            "com.docker.compose.volume": "postgres_data"
        },
        "Mountpoint": "/var/lib/docker/volumes/django-on-docker_postgres_data/_data",
        "Name": "django-on-docker_postgres_data",
        "Options": null,
        "Scope": "local"
    }
]

Afterward, create a new file named "entrypoint.sh" in the "root" directory of your project to ensure that Postgres is functioning correctly before applying the migrations and launching the Django development server.

#!/bin/sh

if [ "$DATABASE" = "postgres" ]
then
    echo "Waiting for postgres..."

    while ! nc -z "$DB_HOSTNAME " "$DB_PORT"; do
      sleep 0.1
    done

    echo "PostgreSQL started"
fi
#python manage.py collectstatic --no-input
exec "$@"

Update the file permissions locally:

$ chmod +x app/entrypoint.sh

Then, update the Dockerfile to copy over the entrypoint.sh file:

# official base image
FROM python:3.10.9-alpine3.17

#set work directory
RUN mkdir /app
WORKDIR /app

#set environment variable
ENV PYTHONDONTWRITEBYCODE 1
ENV PYTHONUNBUFFERED 1

#install pyscopg2 dependencies
RUN apk update && apk add postgresql-dev gcc python3-dev musl-dev linux-headers

#install dependencies
RUN pip install --upgrade pip
COPY ./requirements.txt .
RUN pip install -r requirements.txt

#media files
RUN mkdir -p /media
RUN mkdir -p /static

# copy entrypoint.sh
COPY ./entrypoint.sh .
RUN sed -i 's/\r$//g' /app/entrypoint.sh
RUN chmod +x /app/entrypoint.sh

# copy project
COPY . .

# run entrypoint.sh
ENTRYPOINT ["/app/entrypoint.sh"]

After that test it out:

1. Re-build the images

2. Run the containers

3. Try http://localhost:8000/

Gunicorn

To prepare for production environments, we will include Gunicorn, which is a WSGI server that is suitable for production use, in the requirements file.So, Firstof all install Gunicorn and add it to the requirements.txt file.

To continue utilizing Django's internal server for development, you can generate a fresh compose file named docker-compose.prod.yml solely for production purposes.

version: '3.10'

services:
  web:
    build: .
    command: gunicorn personal.wsgi:application --bind 0.0.0.0:8000
    volumes:
      - static_data:/app/static
    ports:
      - "8000:8000"
    restart: always
    env_file:
      - ./.env.prod
    depends_on:
      - db
  db:
    image: postgres:13.0-alpine
    restart: always
    volumes:
      - postgres_data:/var/lib/postgresql/data:rw
    env_file:
      - .env.prod
volumes:
  static_data:
  postgres_data:

Here, We're running Gunicorn rather than the Django development server.

Now Let's create .env.prod file for environemental variables:

SECRET_KEY=
ALLOWED_HOSTS= localhost 127.0.0.1 [::1]
DEBUG=True

# Database
DB_NAME=testing
DB_USERNAME=postgres
DB_PASSWORD=36050
DB_HOSTNAME=localhost
DB_PORT=5432

Bring down the development containers (and the associated volumes with the -v flag):

$ docker-compose down -v

Then, build the production images and spin up the containers:

$ docker-compose -f docker-compose.prod.yml up -d --build

Now, we need to create a production Dockerfile (Dockerfile.prod) and an entrypoint.prod.sh file inside the scripts directory of the project's root. The entrypoint.prod.sh file will serve as the production script file for the entrypoint.

#!/bin/sh

if [ "$DATABASE" = "postgres" ]
then
    echo "Waiting for postgres..."

    while ! nc -z "$DB_HOSTNAME " "$DB_PORT"; do
      sleep 0.1
    done

    echo "PostgreSQL started"
fi
python manage.py collectstatic --no-input
exec "$@"

# official base image
FROM python:3.10.9-alpine3.17

#set work directory
RUN mkdir /app
WORKDIR /app

#set environment variable
ENV PYTHONDONTWRITEBYCODE 1
ENV PYTHONUNBUFFERED 1

#install pyscopg2 dependencies
RUN apk update && apk add postgresql-dev gcc python3-dev musl-dev linux-headers

or you can use
#install dependencies
RUN pip install --upgrade pip
COPY ./requirements.txt .
RUN pip install -r requirements.txt

#media files
RUN mkdir -p /media
RUN mkdir -p /static

# copy entrypoint.sh
COPY ./entrypoint.sh .
RUN sed -i 's/\r$//g' /app/entrypoint.sh
RUN chmod +x /app/entrypoint.sh

# copy project
COPY . .

# run entrypoint.sh
ENTRYPOINT ["/app/entrypoint.sh"]

Now, update the compose production file with docker production file:

services:
  web:
    build:
     context: .
     dockerfile: Dockerfile.prod
    command: gunicorn personal.wsgi:application --bind 0.0.0.0:8000
    volumes:
      - static_data:/app/static
    expose:
      - 8000
    restart: always
    env_file:
      - ./.env.prod
    depends_on:
      - db

Try it out:

$ docker-compose -f docker-compose.prod.yml down -v
$ docker-compose -f docker-compose.prod.yml up -d --build
$ docker-compose -f docker-compose.prod.yml exec app python manage.py migrate --noinput

Ngnix

In terms of flexibility, Nginx offers an unparalleled degree of control. By configuring it as a reverse proxy for Gunicorn, you can achieve almost anything. To accomplish this, add the Nginx service to the production docker-compose file.

version: '3.10'

services:
  web:
    build:
      context: .
    command: gunicorn config.wsgi:application --bind 0.0.0.0:8000
    volumes:
      - static_data:/app/static
      - media_data:/app/media
    expose:
      - 8000
    restart: always
    env_file:
      - ./.env
    depends_on:
      - db
  db:
    image: postgres:13.0-alpine
    restart: always
    volumes:
      - postgres_data:/var/lib/postgresql/data:rw
    environment:
      - POSTGRES_USER=${DB_USERNAME}
      - POSTGRES_PASSWORD=${DB_PASSWORD}
      - POSTGRES_DB=${DB_NAME}
  nginx:
    build: ./nginx
    volumes:
      - static_data:/app/static
      - media_data:/app/media
    ports:
      - "8008:80"
    depends_on:
      - web
volumes:
  static_data:
  media_data:
  postgres_data:

Create the following files and folders:

└── nginx
    ├── Dockerfile
    └── nginx.conf
    └── uwsgi_params

Add these code inside Dockerfile:

FROM nginx:1.21-alpine

RUN rm /etc/nginx/conf.d/default.conf
COPY nginx.conf /etc/nginx/conf.d
COPY uwsgi_params /etc/nginx/uwsgi_params

Create uwsgi_params and add

uwsgi_param  QUERY_STRING       $query_string;
uwsgi_param  REQUEST_METHOD     $request_method;
uwsgi_param  CONTENT_TYPE       $content_type;
uwsgi_param  CONTENT_LENGTH     $content_length;

uwsgi_param  REQUEST_URI        $request_uri;
uwsgi_param  PATH_INFO          $document_uri;
uwsgi_param  DOCUMENT_ROOT      $document_root;
uwsgi_param  SERVER_PROTOCOL    $server_protocol;
uwsgi_param  REQUEST_SCHEME     $scheme;
uwsgi_param  HTTPS              $https if_not_empty;

uwsgi_param  REMOTE_ADDR        $remote_addr;
uwsgi_param  REMOTE_PORT        $remote_port;
uwsgi_param  SERVER_PORT        $server_port;
uwsgi_param  SERVER_NAME        $server_name;

create nginx.conf and add

upstream django_project {
    server web:8000;
}

server {
    listen 80;

    location /static {
        alias /static;
    }

    location /media {
        alias /media;
    }

    location / {
        uwsgi_pass web:8000;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        proxy_redirect off;
        include /etc/nginx/uwsgi_params;
    }
}

for the static and media file, add inside settings.py

#for static files
STATIC_URL = "/static/"
STATIC_ROOT = BASE_DIR / "staticfiles"

#for media files
MEDIA_URL = "/media/"
MEDIA_ROOT = BASE_DIR / "mediafiles"

For the last time,re-build run and try it out:

$ docker-compose -f docker-compose.prod.yml down -v
$ docker-compose -f docker-compose.prod.yml up -d --build
$ docker-compose -f docker-compose.prod.yml exec web python manage.py migrate --noinput

Summary:

So here's the end, We learned each steps to containerize a Django web application along with Postgres for development purposes. Additionally, it illustrated the creation of a Docker Compose file suitable for production environments, which incorporated Gunicorn and Nginx to manage static and media files. This enables local testing of a production setup.

Thank you so much, Bye.

Prerequisites

Before we begin, make sure that you have the following installed on your local machine:

• Python 3.7 or higher

• Django

• Django Rest Framework

• Docker and Docker-compose

Make sure to set up your Django project and run it locally. After everything is ready, let's make your Django application ready for deployment.

Create a Dockerfile

The Dockerfile is a script that contains instructions on how to build a Docker image for your application. Create a new file named Dockerfile in the root directory of your Django project with the following content:

# official base image
FROM python:3.10.9-alpine3.17

#set work directory
RUN mkdir /app
WORKDIR /app

#set environment variable
ENV PYTHONDONTWRITEBYCODE 1
ENV PYTHONUNBUFFERED 1

#install dependencies
RUN pip install --upgrade pip
COPY ./requirements.txt .
RUN pip install -r requirements.txt

# copy project
COPY . .

Let's understand the code Line by Line,

So basically, The first line specifies the official base image to use, which is the Python 3.10.9-alpine3.17 image. This image is a lightweight version of Python that runs on Alpine Linux, which is a small, secure, and efficient Linux distribution.

Next, the working directory is set to /app, which is where the application code will reside inside the container.

Two environment variables are set to ensure that the Python application runs correctly in the container. The PYTHONDONTWRITEBYCODE environment variable is set to 1, which instructs Python not to write bytecode files to disk. The PYTHONUNBUFFERED environment variable is also set to 1, which disables the buffering of standard output and standard error streams by Python.

The dependencies for the Django application are installed via pip. First, pip is upgraded to the latest version, and then the contents of requirements.txt are copied into the container and installed using pip.

Finally, the entire contents of the application's directory are copied into the Docker image. This includes the Django project files, any static files, templates, or media files, as well as any other necessary files for the application to run.

This Dockerfile sets up the basic environment required to run a Django application in a containerized environment and is a good starting point for building more complex Docker images for Django applications.

Let's go on more,

Docker Compose

Docker Compose is a tool that allows you to define and run multi-container Docker applications. With Compose, you can define the services that make up your application, how they should be configured, and how they should interact with each other.

A Docker Compose file is a YAML file that defines the services, networks, and volumes required for your application. In a typical Django application, you might have several services, such as the Django web server, a database service like Postgres, and a web server like Nginx.

In a Docker Compose file, you would define each of these services as a separate container, along with their configuration options. You can also define networks and volumes that are shared between the containers.

So Let's Make a docker-compose.yml file to the root project

version: '3.10'

services:
    app:
        build: .
        command: python manage.py runserver 0.0.0.0:8000
        volumes:
            - static_data:/app/static
        ports:
            - "8000:8000"
        env_file:
            - ./.env

Let's understand the code line by line,

The command instruction specifies the command to run when the container starts up. In this case, it's running the runserver command for Django, which starts a development server that listens on all available network interfaces (0.0.0.0) on port 8000.

The volumes instruction creates a named volume named static_data that will be mounted inside the container at the path /app/static. This allows the container to access static files that are generated by Django and stored outside of the container.

The ports instruction maps port 8000 on the host machine to port 8000 inside the container, so that the Django application can be accessed by visiting http://localhost:8000 in a web browser.

Finally, the env_file instruction specifies a path to a file containing environment variables that should be loaded into the container. In this case, the file is located at ./.env.

Now, create a .env file in the project root to store environment variables for development:

SECRET_KEY=
ALLOWED_HOSTS= localhost 127.0.0.1 [::1]
DEBUG=True

You need to change the SECRET_KEY, ALLOWED_HOST and DEBUG in your project Setting file. Make sure to add import os in your setting file

import os
# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = config('SECRET_KEY')

# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = config('DEBUG', default=False, cast=bool)

ALLOWED_HOSTS = config('ALLOWED_HOSTS', cast=Csv())

Now, Build the image:

$ docker-compose build

Once the image is built, run the container:

$ docker-compose up -d

Now Go to http://localhost:8000/ to see the project running.

Summary:

Up to now We built a Docker image of our application and run into a container that is running successfully. In the next part, We'll see how to integrate PostgreSQL with your application and dockerize further until then have a great time. Bye!

Part-2: Dockerizing Django With Postgres, NGINX, and Gunicorn (PART-2)

Luckily, I was able to set everything up correctly and get my Django applications up and running in no time.

If you are unfamiliar with PostgreSQL, It is a high-performance, enterprise-grade, open-source relational database system. SQL (relational) and JSON (non-relational) querying are both supported by PostgreSQL.

PostgreSQL is a very reliable database that has been developed by the open-source community for over 20 years.

Many online apps, as well as mobile and analytics applications, use PostgreSQL as their primary database

Here are some steps you may follow to simply install PostgreSQL on your PC if you wish to utilize it.

Installation

1. First, update the package manager's cache with the following command

    $ sudo apt-get update
   

2. Install PostgreSQL with the following command

    sudo apt-get install postgresql postgresql-contrib
   

3. Enable and start Postgresql

    systemctl enable postgresql
    systemctl start postgresql
   

   Once the installation is complete, we can check that the service is running by using the following command

    sudo systemctl status postgresql
   

4. By default, PostgreSQL creates a user named "Postgres" during the installation process. We can switch to this user by using the following command:

    sudo -u postgres psql
   

Using PostgreSQL Roles and Databases

"Roles" are a tool used by Postgres for authentication and authorization. The only user who can connect to the server by default is the Postgres user, which is created by Postgres. To create our superuser role to connect to the server.

sudo -u Postgres createuser --superuser $USER

After that, since Postgres by default expects a database with that $USER login name, we must build one.

$ sudo -u Postgres createdb $USER

We can create a new database and a new user with the following commands:

sudo su - postgres
createdb db_name
echo "CREATE ROLE db_user WITH PASSWORD 'DUDTL39YHa91x4Y';" | psql
echo "ALTER ROLE db_user WITH LOGIN;" | psql
echo "GRANT ALL PRIVILEGES ON DATABASE "db_name" to db_user;" | psql
exit

To enter inside Postgres, use this command:

psql -U postgres -h localhost

Some useful commands:

List database: \l

List users: \du

To exit the PostgreSQL shell, use the following command:

\q

To stop the PostgreSQL service, use the following command

sudo systemctl stop postgresql

Install pgadmin4

pgAdmin4 isn't accessible within the Ubuntu stores. We ought to introduce it from the pgAdmin4 Well-suited store. Begin by setting up the store. Include the open key for the store and make the store arrangement record.

$ curl https://www.pgadmin.org/static/packages_pgadmin_org.pub | sudo apt-key add
$ sudo sh -c 'echo "deb https://ftp.postgresql.org/pub/pgadmin/pgadmin4/apt/$(lsb_release -cs) pgadmin4 main" > /etc/apt/sources.list.d/pgadmin4.list && apt update'

Then install pgAdmin4,

$sudo apt install pgadmin4

Boom! It's Done.

That’s all! For more data, see the PostgreSQL documentation and pgAdmin 4 documentation. Keep in mind to share your considerations with us using the comment segment underneath.

Hey Guys, Today We'll look at installing and configuring Tailwind CSS in Nuxt.js 3. Server-side rendering (SSR) and static site generation work well with Nuxtjs (SSG). For speedier performance and a better developer experience, Nuxt 3 has been re-architected with a smaller core. A utility-first CSS framework is Tailwind CSS. The combination of Nuxt js with tailwind CSS is ideal.

Before getting started, make sure you have the following installed on your machine:

• Node.js and npm (or yarn)

• Nuxt.js 3

Create a New Project

1. Open a terminal and navigate to the directory where you want to create your project.

2. Open your project folder in Visual Studio Code

3. Run the following command to create a new Nuxt.js project

npx nuxi init <project-name>

Replace <project-name> with the desired name for your project. It looks like this in Visual Studio Code. I am running on the same directory npx nuxi init .

Now, Go to your project folder using this command.

cd <project-name>

1. Install the dependencies

   `yarn install` or `npm install`

After installing the prerequisites for our application, we will set up Tailwind CSS and all of the other components it needs to function properly.

Installing Tailwind dependencies

1. Run the following command in your project directory:

   yarn add -D tailwindcss@latest postcss@latest autoprefixer@latest

Generating a Tailwind config

1. Generate a Tailwind CSS configuration file by running

   npx tailwindcss init -p

Configuring Tailwind Config file

1. You'll need to configure Tailwind and let it know which files to purge. Open tailwind.config.js and add the following:

    /** @type {import('tailwindcss').Config} */
    module.exports = {
      content: [
        "./components/**/*.{js,vue,ts}",
        "./layouts/**/*.vue",
        "./pages/**/*.vue",
        "./plugins/**/*.{js,ts}",
        "./nuxt.config.{js,ts}",
        "./app.vue",
      ],
      theme: {
        extend: {},
      },
      plugins: [],
    };
   

Adding Tailwind to project styles

1. You can customize the theme, variants, and plugins by adding properties to the corresponding objects.

   Next, create a tailwind.css file in the assets directory:

@tailwind base;
@tailwind components;
@tailwind utilities;

1. Now, we move to the nuxt.config.ts file to add some configuration related to Tailwind CSS.

export default defineNuxtConfig({
  css: ['~/assets/tailwind.css'],
  postcss: {
    plugins: {
      tailwindcss: {},
      autoprefixer: {},
    },
  },
});

Testing out Tailwind CSS

Open the app. vue file and Replace the <NuxtWelcome> inside the div with

<div class="flex h-20 items-center m-auto bg-red-500 justify-center text-3xl text-white font-medium ">
 Hello world
</div>

Run your build process with yarn dev or npm run dev

Now Goto http://localhost:3000/ in a web browser.

BOOM! We did it.

Finally, We configure Tailwind CSS in Nuxt.js 3.

Thank you for being here Bye.👋