Readable Dockerfile and Docker-Compose.yml

Signed-off-by: thisisankit27 <[email protected]>

MasterProject/docker-compose-documented.yml

@@ -0,0 +1,57 @@
+# YML is data serializatio language, very readable and easy to use than JSON
+
+version: "3.8"
+services:
+  app:
+    build: . #. indicated that we are copying everything from the root directory
+    volumes:
+      - .:/django # Volume means that this 'WORKDIR /django' will be mapped to '/django' in the container and encapslated the project files
+    ports:
+      - 8000:8000 # Port mapping, host_port '8000' will be mapped to '8000' in the container, basically bridge the connection between the host and the container
+    image: application:django
+    container_name: app_container_django
+    command: gunicorn MasterProject.wsgi:application --bind 0.0.0.0:8000
+
+# docker-compose build
+# docker-compose up
+# docker-compose down
+# docker builder prune -> clears the cache
+# docker image prune -> Remove all dangling/unused images
+
+# Docker Desktop: 
+# masterproject: C:\Users\thisi\Desktop\SnapSpeak\MasterProject -> Docker Compose looks for the docker-compose.yml file in the directory: section represents the project directory on your host machine
+
+# Services:
+# A service is a definition for a containerized application. It typically represents an individual component or unit of your application stack, such as a web server, a database, or any other service that your application requires
+# Each service runs in its own isolated container. This isolation ensures that each component of your application operates independently and can be scaled, updated, or replaced without affecting other components
+
+# app
+# Here 'app' is a service. you might have separate services for your Django application, database (such as PostgreSQL or MySQL), caching server (like Redis), message broker (like RabbitMQ), etc.
+# Each service runs in its own isolated container. This isolation ensures that each component of your application operates independently and can be scaled, updated, or replaced without affecting other components.
+# Docker Compose manages the lifecycle of these containers and handles the networking between them based on the configuration you provide.
+
+# build: .
+# The Dockerfile contains the instructions for building the Docker image.
+# The build directive in the Docker Compose configuration tells Docker Compose to use the Dockerfile to build the image for the specified service.
+# Docker Compose orchestrates the build process according to the instructions provided in the Dockerfile and any additional configuration specified in the Docker Compose file.
+
+# .:/django
+# The . volume is mapped to the entire project directory to the /django directory in the container.
+# mount the current directory on the host machine (where the docker-compose.yml file is located) to the /django directory inside the container, live changes in host machine is reflected on the container
+
+# 8000:8000
+# when you access port 8000 on the host machine, the traffic will be forwarded to port 8000 inside the container, where your application (or service) is listening for incoming connections. This allows you to access your application running inside the container from the host machine
+
+# image: application:django
+# When you specify image: application:django in your Docker Compose configuration, you're telling Docker Compose to use a Docker image named application with the tag django for the service defined in your docker-compose.yml file.
+# When you specify the image in this way, Docker Compose will look for an existing Docker image named application with the tag django in your local Docker registry. If the image does not exist locally, Docker Compose will attempt to pull it from a remote registry (such as Docker Hub) unless you've already built it locally.
+# In this case, application is the name of the image, and django is the tag. These are not default values; rather, they're specified by you in your Docker Compose file.
+# If you run docker-compose build, Docker Compose will build the image based on the Dockerfile in the current directory and tag it with application:django
+# when you run docker-compose build, Docker Compose will use the information specified in your docker-compose.yml file to build the image for the service(s) defined in the file.
+
+# container_name: app_container_django
+# container_name directive in Docker Compose allows you to specify a custom name for the container that will be created based on the service defined in your docker-compose.yml file
+
+# command: gunicorn MasterProject.wsgi:application --bind 0.0.0.0:8000
+# Both gunicorn and python manage.py runserver are valid options for serving a Django application within a Docker container. However, gunicorn is often preferred for production deployments due to its ability to handle more concurrent connections and better performance compared to the Django development server
+# MasterProject.wsgi:application: This specifies the WSGI application that Gunicorn should serve. MasterProject.wsgi refers to the WSGI module within your Django project, and application is the callable object within that module

MasterProject/docker-compose.yml

@@ -1,57 +1,11 @@
-# YML is data serializatio language, very readable and easy to use than JSON
-
 version: "3.8"
 services:
   app:
-    build: . #. indicated that we are copying everything from the root directory
+    build: .
     volumes:
-      - .:/django # Volume means that this 'WORKDIR /django' will be mapped to '/django' in the container and encapslated the project files
+      - .:/django
     ports:
-      - 8000:8000 # Port mapping, host_port '8000' will be mapped to '8000' in the container, basically bridge the connection between the host and the container
+      - 8000:8000
     image: application:django
     container_name: app_container_django
-    command: gunicorn MasterProject.wsgi:application --bind 0.0.0.0:8000
-
-# docker-compose build
-# docker-compose up
-# docker-compose down
-# docker builder prune -> clears the cache
-# docker image prune -> Remove all dangling/unused images
-
-# Docker Desktop: 
-# masterproject: C:\Users\thisi\Desktop\SnapSpeak\MasterProject -> Docker Compose looks for the docker-compose.yml file in the directory: section represents the project directory on your host machine
-
-# Services:
-# A service is a definition for a containerized application. It typically represents an individual component or unit of your application stack, such as a web server, a database, or any other service that your application requires
-# Each service runs in its own isolated container. This isolation ensures that each component of your application operates independently and can be scaled, updated, or replaced without affecting other components
-
-# app
-# Here 'app' is a service. you might have separate services for your Django application, database (such as PostgreSQL or MySQL), caching server (like Redis), message broker (like RabbitMQ), etc.
-# Each service runs in its own isolated container. This isolation ensures that each component of your application operates independently and can be scaled, updated, or replaced without affecting other components.
-# Docker Compose manages the lifecycle of these containers and handles the networking between them based on the configuration you provide.
-
-# build: .
-# The Dockerfile contains the instructions for building the Docker image.
-# The build directive in the Docker Compose configuration tells Docker Compose to use the Dockerfile to build the image for the specified service.
-# Docker Compose orchestrates the build process according to the instructions provided in the Dockerfile and any additional configuration specified in the Docker Compose file.
-
-# .:/django
-# The . volume is mapped to the entire project directory to the /django directory in the container.
-# mount the current directory on the host machine (where the docker-compose.yml file is located) to the /django directory inside the container, live changes in host machine is reflected on the container
-
-# 8000:8000
-# when you access port 8000 on the host machine, the traffic will be forwarded to port 8000 inside the container, where your application (or service) is listening for incoming connections. This allows you to access your application running inside the container from the host machine
-
-# image: application:django
-# When you specify image: application:django in your Docker Compose configuration, you're telling Docker Compose to use a Docker image named application with the tag django for the service defined in your docker-compose.yml file.
-# When you specify the image in this way, Docker Compose will look for an existing Docker image named application with the tag django in your local Docker registry. If the image does not exist locally, Docker Compose will attempt to pull it from a remote registry (such as Docker Hub) unless you've already built it locally.
-# In this case, application is the name of the image, and django is the tag. These are not default values; rather, they're specified by you in your Docker Compose file.
-# If you run docker-compose build, Docker Compose will build the image based on the Dockerfile in the current directory and tag it with application:django
-# when you run docker-compose build, Docker Compose will use the information specified in your docker-compose.yml file to build the image for the service(s) defined in the file.
-
-# container_name: app_container_django
-# container_name directive in Docker Compose allows you to specify a custom name for the container that will be created based on the service defined in your docker-compose.yml file
-
-# command: gunicorn MasterProject.wsgi:application --bind 0.0.0.0:8000
-# Both gunicorn and python manage.py runserver are valid options for serving a Django application within a Docker container. However, gunicorn is often preferred for production deployments due to its ability to handle more concurrent connections and better performance compared to the Django development server
-# MasterProject.wsgi:application: This specifies the WSGI application that Gunicorn should serve. MasterProject.wsgi refers to the WSGI module within your Django project, and application is the callable object within that module
+    command: gunicorn MasterProject.wsgi:application --bind 0.0.0.0:8000

MasterProject/dockerfile

@@ -1,53 +1,19 @@
-# The whole point of docker image is to build a compressed version of our entire project in a single image, this is called Dockerized or Compartmentalized 
-
-# In summary, using Gunicorn to serve your Dockerized application as a WSGI application means you're employing Gunicorn as the HTTP server, while Gunicorn is indeed running inside the Docker container, it serves as the HTTP server for your Django application, making your application accessible from external clients via HTTP requests.,
-# This setup is common in deploying Python web applications in production environments.
-# pip install gunicorn
-
-
-# Image build command: Docker container will be built on top of the Python 3.10 image using the Debian "bullseye" distribution as the base. This provides a pre-configured environment with Python already installed, allowing you to run Python applications within the Docker container.
 FROM python:3.10-bullseye
 
-# Set environment variables: The PYTHONBUFFERED environment variable is used to control the buffering behavior for standard output (stdout) and standard error (stderr) streams when running Python in buffered mode. Setting it to 1 ensures that Python outputs are immediately flushed to the corresponding streams, rather than being buffered, which can be useful for logging and debugging purposes when running Python applications inside Docker containers.
 ENV PYTHONBUFFERED=1
 
-# Set work directory: it'll encapsulate all the files present in same root directory inside it, and further commands will be executed in this directory
 WORKDIR /django
 
-# Install dependencies: The COPY instruction in a Dockerfile is used to copy files or directories from the host machine (the machine where you're building the Docker image) into the Docker image being created.
-# The first requirements.txt refers to the path of the file or directory on the host machine.
-# The second requirements.txt refers to the path where the file or directory should be copied to inside the Docker image.
 COPY requirements.txt requirements.txt
-# now it'll be like-> django/requirements.txt
 
-# Install dependencies:  Dockerfile installs the Python dependencies listed in the requirements.txt file into the Docker image being built
 RUN pip install -r requirements.txt
 
-# Install tesseract OCR engine
-# apt-get update: It ensures that your package manager has the latest information about available packages and their versions.
-# -y: This flag automatically answers "yes" to all prompts
 RUN apt-get update && apt-get install -y tesseract-ocr
 
-# Copy project (Copy everything in our root directory into the image)
-# The first . refers to the path of the files or directories on the host machine.
-# The second . refers to the path where the files or directories should be copied to inside the Docker image.
 COPY . .
 
-# Run collectstatic to collect static files
-# --noinput is an option that suppresses any interactive prompts during the execution of the collectstatic command. It's commonly used in automated scripts or Dockerfiles where there's no human interaction.
 RUN python manage.py collectstatic --noinput
 
-#setting.py: WSGI_APPLICATION = 'MasterProject.wsgi.application' (Name of WSGI Application)
-#Purpose of this is to expose the WSGI application to the web server on port 8000
-#0.0.0.0 means all IP addresses
-#  CMD instruction in a Dockerfile specifies the command that will be executed when a container is started from the image
-# --bind 0.0.0.0:8000, you're instructing Gunicorn to start serving your Django application on port 8000
-#  IP address 0.0.0.0, meaning it will listen for incoming connections on all network interfaces
 CMD gunicorn MasterProject.wsgi:application --bind 0.0.0.0:8000
-# You don't need to rebuild the Docker image every time you want to change the port number for serving your Django application
-# You simply need to restart your Docker container (or create a new one if it's not running), and the Gunicorn server will start serving your Django application on port 8080 within the container.
 
-# EXPOSE 8000 in your Dockerfile, you're essentially indicating that your containerized application listens on port 8000 for incoming connections.
-# However, for the ports to be accessible from outside the container, you still need to explicitly map or publish them when running the container, 
-# a Docker Compose configuration (ports directive). This allows the host machine to route incoming traffic to the specified ports on the container.
 EXPOSE 8000

MasterProject/dockerfile documented

@@ -0,0 +1,53 @@
+# The whole point of docker image is to build a compressed version of our entire project in a single image, this is called Dockerized or Compartmentalized 
+
+# In summary, using Gunicorn to serve your Dockerized application as a WSGI application means you're employing Gunicorn as the HTTP server, while Gunicorn is indeed running inside the Docker container, it serves as the HTTP server for your Django application, making your application accessible from external clients via HTTP requests.,
+# This setup is common in deploying Python web applications in production environments.
+# pip install gunicorn
+
+
+# Image build command: Docker container will be built on top of the Python 3.10 image using the Debian "bullseye" distribution as the base. This provides a pre-configured environment with Python already installed, allowing you to run Python applications within the Docker container.
+FROM python:3.10-bullseye
+
+# Set environment variables: The PYTHONBUFFERED environment variable is used to control the buffering behavior for standard output (stdout) and standard error (stderr) streams when running Python in buffered mode. Setting it to 1 ensures that Python outputs are immediately flushed to the corresponding streams, rather than being buffered, which can be useful for logging and debugging purposes when running Python applications inside Docker containers.
+ENV PYTHONBUFFERED=1
+
+# Set work directory: it'll encapsulate all the files present in same root directory inside it, and further commands will be executed in this directory
+WORKDIR /django
+
+# Install dependencies: The COPY instruction in a Dockerfile is used to copy files or directories from the host machine (the machine where you're building the Docker image) into the Docker image being created.
+# The first requirements.txt refers to the path of the file or directory on the host machine.
+# The second requirements.txt refers to the path where the file or directory should be copied to inside the Docker image.
+COPY requirements.txt requirements.txt
+# now it'll be like-> django/requirements.txt
+
+# Install dependencies:  Dockerfile installs the Python dependencies listed in the requirements.txt file into the Docker image being built
+RUN pip install -r requirements.txt
+
+# Install tesseract OCR engine
+# apt-get update: It ensures that your package manager has the latest information about available packages and their versions.
+# -y: This flag automatically answers "yes" to all prompts
+RUN apt-get update && apt-get install -y tesseract-ocr
+
+# Copy project (Copy everything in our root directory into the image)
+# The first . refers to the path of the files or directories on the host machine.
+# The second . refers to the path where the files or directories should be copied to inside the Docker image.
+COPY . .
+
+# Run collectstatic to collect static files
+# --noinput is an option that suppresses any interactive prompts during the execution of the collectstatic command. It's commonly used in automated scripts or Dockerfiles where there's no human interaction.
+RUN python manage.py collectstatic --noinput
+
+#setting.py: WSGI_APPLICATION = 'MasterProject.wsgi.application' (Name of WSGI Application)
+#Purpose of this is to expose the WSGI application to the web server on port 8000
+#0.0.0.0 means all IP addresses
+#  CMD instruction in a Dockerfile specifies the command that will be executed when a container is started from the image
+# --bind 0.0.0.0:8000, you're instructing Gunicorn to start serving your Django application on port 8000
+#  IP address 0.0.0.0, meaning it will listen for incoming connections on all network interfaces
+CMD gunicorn MasterProject.wsgi:application --bind 0.0.0.0:8000
+# You don't need to rebuild the Docker image every time you want to change the port number for serving your Django application
+# You simply need to restart your Docker container (or create a new one if it's not running), and the Gunicorn server will start serving your Django application on port 8080 within the container.
+
+# EXPOSE 8000 in your Dockerfile, you're essentially indicating that your containerized application listens on port 8000 for incoming connections.
+# However, for the ports to be accessible from outside the container, you still need to explicitly map or publish them when running the container, 
+# a Docker Compose configuration (ports directive). This allows the host machine to route incoming traffic to the specified ports on the container.
+EXPOSE 8000