• Git and GitHub

• AWS IAM

• Amazon S3

• AWS CLI

• GitHub Actions

• GitHub Secrets

• CI/CD

• Static Website Hosting

• Automated Deployment

In this project, I built a personal portfolio website using HTML, CSS, and JavaScript, stored the source code on GitHub, created an Amazon S3 bucket for hosting, and configured GitHub Actions to automatically deploy the website to S3 whenever I push new changes.

The final workflow looks like this:

Developer
    |
    | git push
    ↓
GitHub Repository
    |
    ↓
GitHub Actions
    |
    ↓
Ubuntu Runner
    |
    ↓
AWS Authentication
    |
    ↓
AWS S3
    |
    ↓
Live Portfolio Website

The main idea is simple:

Write code → Push to GitHub → GitHub Actions runs automatically → Website is updated on AWS S3.

This project is based on the Git & GitHub for DevOps workshop, starting from approximately 02:54:02.

🎥 Workshop Reference:

https://www.youtube.com/live/DyqAdz96mok?si=yTWM7TqpWvtRsDTU&t=10442

📌 Project Overview

The goal of this project is to deploy a static portfolio website to an Amazon S3 bucket and automate the deployment using GitHub Actions.

The portfolio is built with:

HTML
CSS
JavaScript

The source code is stored in GitHub.

AWS S3 is used to host the static website.

GitHub Actions is used to automate deployment.

🎯 What We Are Building

Our final architecture looks like this:

                 GitHub Repository
                        |
                        |
                    git push
                        |
                        ↓
                GitHub Actions
                        |
                        ↓
                Ubuntu Runner
                        |
                AWS Authentication
                        |
                        ↓
                  AWS S3 Bucket
                        |
                        ↓
              Static Website Hosting
                        |
                        ↓
              🌐 Live Portfolio

Whenever we make a change to the website:

Change Code
    ↓
git add .
    ↓
git commit
    ↓
git push
    ↓
GitHub Actions
    ↓
AWS S3
    ↓
Website Updated

This eliminates the need to manually upload website files to S3 every time.

🛠️ Technologies Used

This project uses:

📂 My GitHub Repository

The complete project source code is available here:

https://github.com/hritikranjan1/hritik-portfolio1

The repository contains the main website files along with the GitHub Actions workflow.

The current repository structure includes:

hritik-portfolio1/
│
├── .github/
│   └── workflows/
│
├── css/
│   └── style.css
│
├── js/
│   └── script.js
│
├── index.html
│
└── README.md

The GitHub repository confirms the presence of the .github/workflows, css, js, index.html, and README.md structure.

🌐 Final Live Website

The final portfolio is hosted on Amazon S3.

You can access it here:

http://hritik-portfolio1.s3-website-us-east-1.amazonaws.com

The website is a static portfolio built using:

HTML
CSS
JavaScript

🤔 Why Use Amazon S3 for a Static Website?

Amazon S3 is an object storage service provided by AWS.

Although S3 is commonly used to store files, it can also serve static website content.

Static websites generally contain files such as:

index.html
style.css
script.js
images
fonts

For a simple portfolio website, we don't need a traditional backend server.

Instead:

Browser
   |
   ↓
S3
   |
   ├── index.html
   ├── CSS
   ├── JavaScript
   └── Images

S3 can serve these files to users.

🧠 What is Static Website Hosting?

A static website does not require server-side application processing.

For example:

HTML
CSS
JavaScript
Images

are delivered directly to the browser.

Examples of static websites:

• Portfolio

• Resume website

• Documentation

• Landing page

• Product information page

• Simple business website

For this project, our portfolio is a static website.

☁️ Why S3 Instead of a Traditional Server?

For a simple static website, using a full EC2 server can be unnecessary.

With S3:

No EC2 server
No operating system management
No web server installation
No manual server deployment

Instead:

Website Files
      ↓
AWS S3
      ↓
Website

This makes S3 a simple option for static content hosting.

🔐 Step 1 — Create an IAM User

Before GitHub Actions can upload files to S3, it needs permission to access AWS.

For this project, we create an IAM user for programmatic access.

IAM stands for:

Identity and Access Management

AWS IAM allows us to control:

• Who can access AWS

• What resources they can access

• What actions they can perform

👤 Why Do We Need IAM?

GitHub Actions needs to communicate with AWS.

The workflow needs AWS credentials so it can perform actions such as uploading website files.

The basic flow is:

GitHub Actions
      |
      | AWS Credentials
      ↓
     IAM
      |
      ↓
    S3 Bucket

⚠️ Important Security Rule

Never write AWS credentials directly inside your GitHub workflow.

❌ Don't do this:

aws_access_key_id: AKIAxxxxxxxx
aws_secret_access_key: xxxxxxxxx

If your repository is public, this can expose your credentials.

Instead, use:

GitHub Secrets

We will configure this later.

📸 Screenshot 1 — IAM User

Screenshot: IAM User Creation

This screenshot shows the IAM user created for the project.

The IAM user is used to provide controlled AWS access for the deployment workflow.

🪣 Step 2 — Create an S3 Bucket

Now we create an S3 bucket.

The bucket name used for this project is:

hritik-portfolio1

The bucket will store the files of our portfolio.

For example:

hritik-portfolio1
│
├── index.html
├── css/
├── js/
└── other assets

🏷️ Why Is the Bucket Name Important?

S3 bucket names must follow AWS naming requirements and are globally unique within the S3 namespace.

For this project, our bucket is:

hritik-portfolio1

📸 Screenshot 2 — S3 Bucket Creation

Screenshot: S3 Bucket

This screenshot shows the S3 bucket created for hosting the portfolio website.

The bucket acts as the storage location for our static website files.

⚙️ Step 3 — Configure Static Website Hosting

Creating the bucket is not enough.

We also need to configure it to serve our website as a static website.

The important file is:

index.html

This is the entry point of our portfolio.

The basic structure becomes:

S3 Bucket
    |
    └── index.html
            |
            ├── CSS
            ├── JavaScript
            └── Other Assets

When a visitor opens the website, the index.html page is served as the main page.

🌐 Step 4 — Configure Website Access

For an S3 static website endpoint to serve content publicly, the required bucket/object access configuration must allow the intended website access.

This is an important AWS security concept.

You should avoid making more permissions public than necessary.

For a simple learning project, you may configure public website access as required by S3 static website hosting.

For a production website, consider a more secure architecture such as:

CloudFront
    ↓
S3

instead of directly exposing the S3 website endpoint.

🧑‍💻 Step 5 — Prepare the Portfolio Website

Our portfolio is built using:

HTML
CSS
JavaScript

The main file is:

index.html

CSS:

css/style.css

JavaScript:

js/script.js

The project repository currently follows this basic structure.

📁 Project Structure

hritik-portfolio1/
│
├── .github/
│   └── workflows/
│       └── deploy.yml
│
├── css/
│   └── style.css
│
├── js/
│   └── script.js
│
├── index.html
│
└── README.md

Let's understand it.

.github/workflows/

This directory contains GitHub Actions workflow files.

Example:

.github/workflows/deploy.yml

GitHub automatically detects workflow files stored in this directory.

index.html

This is the main page of the portfolio.

css/style.css

Contains the styling of the website.

js/script.js

Contains JavaScript functionality.

README.md

Contains project documentation.

🔄 Step 6 — Git Workflow

Before creating the CI/CD pipeline, our website source code needs to be available on GitHub.

The basic Git workflow is:

git status

Check the project status.

Then:

git add .

Stage all changes.

Then:

git commit -m "Add portfolio website"

Create a commit.

Finally:

git push

Push the changes to GitHub.

🤖 Step 7 — Create GitHub Actions Workflow

Now we create the CI/CD pipeline.

Inside the project:

.github/
└── workflows/
    └── deploy.yml

The workflow file uses YAML.

GitHub Actions reads this file and executes the instructions automatically.

📝 GitHub Actions Workflow

A basic workflow for this project can look like this:

name: Deploy Portfolio to AWS S3

on:
  push:
    branches:
      - main

jobs:

  deploy:

    runs-on: ubuntu-latest

    steps:

      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1

      - name: Deploy website to S3
        run: |
          aws s3 sync . s3://hritik-portfolio1 --delete

Let's understand this workflow step by step.

🧩 Understanding the Workflow

1. Workflow Name

name: Deploy Portfolio to AWS S3

This gives the workflow a readable name.

On GitHub, you can see this name in the Actions section.

2. Trigger

on:
  push:
    branches:
      - main

This means:

Run the workflow whenever code is pushed to the main branch.

For example:

Developer
    ↓
Modify index.html
    ↓
git add .
    ↓
git commit
    ↓
git push
    ↓
GitHub Actions starts

3. Runner

runs-on: ubuntu-latest

GitHub Actions creates a temporary Ubuntu environment to execute the workflow.

You can think of it as:

GitHub
   ↓
Temporary Ubuntu Machine
   ↓
Execute Commands
   ↓
Finish

4. Checkout Repository

- name: Checkout repository
  uses: actions/checkout@v4

This action downloads the repository files into the GitHub Actions runner.

Without checking out the repository, the runner would not have the website files available for deployment.

5. Configure AWS Credentials

- name: Configure AWS credentials
  uses: aws-actions/configure-aws-credentials@v4

This allows the GitHub Actions runner to authenticate with AWS.

The credentials are retrieved from GitHub Secrets.

🔐 Step 8 — GitHub Secrets

This is one of the most important parts of the project.

We don't put AWS credentials directly in our code.

Instead, GitHub provides:

Repository
   ↓
Settings
   ↓
Secrets and variables
   ↓
Actions

We can create secrets such as:

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY

The workflow then references:

${{ secrets.AWS_ACCESS_KEY_ID }}

and:

${{ secrets.AWS_SECRET_ACCESS_KEY }}

🔒 Why GitHub Secrets?

Imagine writing:

aws-access-key-id: AKIAxxxxxxxx

in a public repository.

Anyone could potentially see it.

Instead:

GitHub Secret
     ↓
Encrypted/managed by GitHub
     ↓
GitHub Actions
     ↓
AWS

The actual secret value is not written into the workflow file.

⚠️ Very Important AWS Security Note

For a real production setup, avoid using a long-lived AWS access key when possible.

A stronger approach is GitHub Actions OIDC with an AWS IAM role.

The architecture becomes:

GitHub Actions
      |
      | OIDC Identity
      ↓
AWS IAM Role
      |
      ↓
S3

This avoids storing long-lived AWS access keys in GitHub.

However, for a beginner learning project, understanding GitHub Secrets first is useful because it clearly demonstrates the basic authentication flow.

📤 Step 9 — Upload Website to S3

The most important deployment command is:

aws s3 sync . s3://hritik-portfolio1 --delete

Let's understand it.

🔄 What is aws s3 sync?

aws s3 sync synchronizes files between a local directory and an S3 bucket.

In our project:

GitHub Actions Runner
        |
        | aws s3 sync
        ↓
S3 Bucket

The command:

aws s3 sync . s3://hritik-portfolio1

means:

Upload/synchronize the files from the current directory to the S3 bucket.

🗑️ What Does --delete Do?

The workflow uses:

--delete

This makes the S3 bucket reflect the current contents of the source directory by deleting destination files that no longer exist in the source.

For example:

Initial version:

index.html
old-page.html
style.css

Later you delete:

old-page.html

After running:

aws s3 sync . s3://hritik-portfolio1 --delete

the old file can also be removed from the bucket.

This helps keep the deployed website synchronized with the repository.

🔁 Complete CI/CD Flow

Now let's connect everything.

                 Developer
                     |
                     ↓
               Edit Website
                     |
                     ↓
                  Git
                     |
                git commit
                     |
                git push
                     |
                     ↓
              GitHub Repository
                     |
                     ↓
             GitHub Actions
                     |
                     ↓
             Ubuntu Runner
                     |
                     ↓
             Checkout Code
                     |
                     ↓
          Configure AWS Credentials
                     |
                     ↓
               AWS CLI
                     |
                     ↓
             aws s3 sync
                     |
                     ↓
              S3 Bucket
                     |
                     ↓
         Static Website Hosting
                     |
                     ↓
             🌐 Live Website

This is our CI/CD pipeline.

🚀 Step 10 — Push the Workflow to GitHub

Once deploy.yml is created:

git add .

Then:

git commit -m "Add S3 deployment workflow"

Then:

git push origin main

GitHub detects the workflow.

Because our workflow has:

on:
  push:
    branches:
      - main

the pipeline starts automatically.

👀 Step 11 — Check GitHub Actions

Open your GitHub repository.

Go to:

Actions

You should see:

Deploy Portfolio to AWS S3

Click the workflow run.

You can see steps such as:

✓ Checkout repository
✓ Configure AWS credentials
✓ Deploy website to S3

If every step succeeds:

✓ Workflow completed successfully

🧪 Step 12 — Test Automatic Deployment

Now comes the most important part of the project.

Modify your portfolio.

For example:

Change:
"DevOps Learner"

to:

"DevOps & Cloud Engineer"

Save the file.

Then:

git add .

git commit -m "Update portfolio content"

git push

Now:

git push
    ↓
GitHub
    ↓
GitHub Actions
    ↓
AWS S3
    ↓
Updated Website

You don't manually upload anything.

That's the power of CI/CD.

🔥 Before Automation vs After Automation

❌ Traditional Manual Deployment

Without GitHub Actions:

Change Website
     ↓
Build/Prepare Files
     ↓
Open AWS Console
     ↓
Open S3
     ↓
Upload Files
     ↓
Replace Old Files
     ↓
Check Website

Every update requires manual work.

✅ Automated Deployment

With GitHub Actions:

Change Website
     ↓
git push
     ↓
GitHub Actions
     ↓
AWS S3
     ↓
Live Website Updated

Much simpler.

📊 Manual vs Automated Deployment

📸 Screenshot 3 — Final Live Portfolio

Screenshot: Final AWS S3 Hosted Portfolio

This screenshot shows the final portfolio website successfully running after deployment.

The website is accessible through the S3 static website endpoint:

http://hritik-portfolio1.s3-website-us-east-1.amazonaws.com

🎯 What Happens When I Push New Code?

Let's say I modify:

index.html

Then:

git add .

git commit -m "Update portfolio"

git push

GitHub receives the code.

Because the workflow listens for pushes to main:

on:
  push:
    branches:
      - main

GitHub Actions starts automatically.

Then:

Checkout
   ↓
AWS Authentication
   ↓
AWS CLI
   ↓
S3 Sync
   ↓
Deployment Complete

The updated website is now available from S3.

🧠 Important DevOps Concepts Learned

This small project teaches several important concepts.

1️⃣ Version Control

Git tracks changes to the website.

Code
 ↓
Git
 ↓
GitHub

2️⃣ CI/CD

GitHub Actions automates deployment.

Push
 ↓
Pipeline
 ↓
Deploy

3️⃣ Cloud Storage

S3 stores the website files.

S3
 ↓
index.html
CSS
JavaScript
Assets

4️⃣ IAM

IAM controls AWS access.

Identity
 +
Permissions
 =
Controlled AWS Access

5️⃣ Secrets Management

GitHub Secrets protect sensitive credentials from being hardcoded into the repository.

6️⃣ AWS CLI

AWS CLI allows us to interact with AWS from commands and automation.

Example:

aws s3 sync

7️⃣ Infrastructure + Automation

AWS provides the infrastructure.

GitHub Actions provides the automation.

Together:

AWS
 +
GitHub Actions
 =
Automated Deployment

🏗️ Project Architecture

The final architecture can be represented as:

                  ┌──────────────────┐
                  │    Developer     │
                  └────────┬─────────┘
                           │
                       git push
                           │
                           ↓
                  ┌──────────────────┐
                  │     GitHub       │
                  │   Repository     │
                  └────────┬─────────┘
                           │
                           ↓
                  ┌──────────────────┐
                  │ GitHub Actions   │
                  │      CI/CD       │
                  └────────┬─────────┘
                           │
                           ↓
                  ┌──────────────────┐
                  │   AWS CLI /      │
                  │ AWS Credentials  │
                  └────────┬─────────┘
                           │
                           ↓
                  ┌──────────────────┐
                  │    AWS S3        │
                  │     Bucket       │
                  └────────┬─────────┘
                           │
                           ↓
                  ┌──────────────────┐
                  │ Static Website   │
                  │    Hosting       │
                  └────────┬─────────┘
                           │
                           ↓
                       🌐 User

📁 Final Repository Structure

The project structure is:

hritik-portfolio1/
│
├── .github/
│   └── workflows/
│       └── deploy.yml
│
├── css/
│   └── style.css
│
├── js/
│   └── script.js
│
├── index.html
│
└── README.md

The repository currently shows this core structure on GitHub.

🧩 Understanding Each Component

HTML

Responsible for the structure.

<h1>My Portfolio</h1>

CSS

Responsible for styling.

body {
    font-family: Arial, sans-serif;
}

JavaScript

Adds functionality.

console.log("Portfolio loaded");

Git

Tracks changes.

git add .
git commit -m "Update portfolio"

GitHub

Stores the source code remotely.

GitHub Actions

Automates deployment.

IAM

Provides AWS identity and permissions.

S3

Stores and serves the static website files.

🔐 Security Considerations

Security is extremely important in AWS projects.

There are several things to remember.

❌ Never Commit AWS Credentials

Never put this directly into:

deploy.yml
README.md
index.html

or any other repository file:

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY

✅ Use GitHub Secrets

Store sensitive credentials in:

GitHub Repository
      ↓
Settings
      ↓
Secrets and variables
      ↓
Actions

✅ Use Least Privilege

The IAM identity used for deployment should have only the permissions required for the deployment.

For this project, that generally means restricting access to the target S3 bucket and only the necessary S3 actions.

Avoid giving broad permissions such as unrestricted administrator access just to make the deployment work.

🔐 Production-Level Improvement: OIDC

For learning purposes, GitHub Secrets are easy to understand.

But for a more production-oriented setup, GitHub Actions can authenticate to AWS using OIDC and an IAM role.

Instead of:

GitHub
   ↓
Long-Lived AWS Access Key

you can use:

GitHub Actions
       ↓
OIDC
       ↓
AWS IAM Role
       ↓
S3

Advantages include:

• No long-lived AWS access keys in GitHub

• Short-lived credentials

• Better security

• Fine-grained trust policies

This is an excellent next step after completing this beginner project.

🌍 Why This Project is Useful for DevOps Beginners

At first glance, this looks like a simple website deployment.

But it teaches the complete idea behind a CI/CD pipeline.

You learn:

Source Code
    ↓
Version Control
    ↓
Remote Repository
    ↓
Automation
    ↓
Cloud Authentication
    ↓
Cloud Storage
    ↓
Deployment

These same concepts appear in much larger systems.

For example:

Java Application
      ↓
GitHub
      ↓
GitHub Actions
      ↓
Docker
      ↓
AWS ECR
      ↓
EC2 / ECS / Kubernetes

The technology changes, but the DevOps workflow remains similar.

📈 How This Project Can Be Improved

This project can be extended in several ways.

🚀 Improvement 1 — Add CloudFront

Instead of directly serving the website from S3:

User
 ↓
CloudFront
 ↓
S3

CloudFront provides a CDN layer.

🔒 Improvement 2 — Use HTTPS

Instead of relying on the basic S3 website endpoint, a production architecture can use:

CloudFront
   ↓
HTTPS
   ↓
S3

🌐 Improvement 3 — Add a Custom Domain

For example:

www.example.com

using:

Route 53
+
CloudFront
+
S3

🔐 Improvement 4 — Use OIDC

Replace long-lived AWS credentials with:

GitHub Actions
       ↓
OIDC
       ↓
IAM Role
       ↓
S3

🧪 Improvement 5 — Add Testing

Before deployment:

Push
 ↓
HTML Validation
 ↓
CSS Validation
 ↓
JavaScript Check
 ↓
Deploy

🔍 Improvement 6 — Add Security Scanning

The workflow can also include:

Secret Scanning
Dependency Scanning
Security Checks

before deployment.

🧪 Example Improved Pipeline

A more advanced version could look like:

Developer
    ↓
git push
    ↓
GitHub
    ↓
GitHub Actions
    ↓
Checkout
    ↓
Validate
    ↓
Test
    ↓
Security Scan
    ↓
AWS Authentication
    ↓
S3 Sync
    ↓
CloudFront Cache Invalidation
    ↓
Production

This is much closer to a real-world DevOps workflow.

🧑‍💻 Complete Deployment Commands

Here are the important commands used in the project.

Check Git status

git status

Stage files

git add .

Commit changes

git commit -m "Update portfolio"

Push changes

git push origin main

AWS S3 synchronization

aws s3 sync . s3://hritik-portfolio1 --delete

The last command is the core deployment command used by the CI/CD workflow.

🔄 Complete Project Workflow in One Diagram

                ┌───────────────────┐
                │   Portfolio Code  │
                │ HTML/CSS/JS       │
                └─────────┬─────────┘
                          │
                       Git Push
                          │
                          ↓
                ┌───────────────────┐
                │      GitHub       │
                │    Repository     │
                └─────────┬─────────┘
                          │
                          ↓
                ┌───────────────────┐
                │  GitHub Actions   │
                │      CI/CD        │
                └─────────┬─────────┘
                          │
                          ↓
                ┌───────────────────┐
                │ Checkout Source   │
                └─────────┬─────────┘
                          │
                          ↓
                ┌───────────────────┐
                │ AWS Authentication│
                └─────────┬─────────┘
                          │
                          ↓
                ┌───────────────────┐
                │     AWS CLI       │
                │   aws s3 sync     │
                └─────────┬─────────┘
                          │
                          ↓
                ┌───────────────────┐
                │    S3 Bucket      │
                │ hritik-portfolio1 │
                └─────────┬─────────┘
                          │
                          ↓
                ┌───────────────────┐
                │ Static Website    │
                │     Hosting       │
                └─────────┬─────────┘
                          │
                          ↓
                🌐 Live Portfolio

💡 What I Learned From This Project

This project helped me understand how a simple website can become an automated DevOps deployment.

The major concepts I practiced were:

Git
GitHub
GitHub Actions
AWS IAM
AWS S3
AWS CLI
GitHub Secrets
CI/CD
Static Website Hosting
Cloud Deployment

The most important lesson was:

Deployment does not have to be a manual process.

Instead of uploading files manually every time, we can automate the entire process:

Code Change
    ↓
git push
    ↓
GitHub Actions
    ↓
AWS S3
    ↓
Live Website

🏆 Final Result

The final result is a portfolio website hosted on Amazon S3 and deployed through a GitHub Actions workflow.

GitHub Repository

https://github.com/hritikranjan1/hritik-portfolio1

Live Portfolio

http://hritik-portfolio1.s3-website-us-east-1.amazonaws.com

Workshop

https://www.youtube.com/live/DyqAdz96mok?si=yTWM7TqpWvtRsDTU&t=10442

📸 Project Screenshots

1. IAM User Creation

What it demonstrates: Creation/configuration of the AWS identity used for the deployment process.

2. S3 Bucket Creation

What it demonstrates: The hritik-portfolio1 S3 bucket created to store the static website files.

3. Final Live Portfolio

What it demonstrates: The final portfolio successfully deployed and accessible through the AWS S3 website endpoint.

📌 Key Takeaways

If you are a beginner, remember these five things:

1. GitHub stores the source code

Portfolio → GitHub

2. GitHub Actions automates the deployment

git push → GitHub Actions

3. IAM controls AWS access

IAM → Permissions

4. S3 stores and serves the static website

S3 → Website Files

5. CI/CD removes repetitive manual deployment

Code Change
     ↓
Push
     ↓
Automatic Deployment

🎯 Final DevOps Architecture

The complete project can be summarized as:

                 👨‍💻 Developer
                       |
                       |
                    Git Push
                       |
                       ↓
              ☁️ GitHub Repository
                       |
                       ↓
               ⚙️ GitHub Actions
                       |
                       ↓
                🐧 Ubuntu Runner
                       |
                       ↓
                🔐 AWS IAM
                       |
                       ↓
                 ☁️ AWS S3
                       |
                       ↓
             🌐 Static Website
                       |
                       ↓
                👥 End Users

This is a small project, but it demonstrates a real DevOps concept: automatically moving code from source control to a cloud-hosted environment through a CI/CD pipeline.

🚀 Conclusion

Deploying a portfolio website to S3 manually is easy.

But automating the deployment with GitHub Actions is where the DevOps learning begins.

In this project, we connected:

HTML
CSS
JavaScript
   +
Git
   +
GitHub
   +
GitHub Actions
   +
IAM
   +
AWS CLI
   +
Amazon S3

The final result is an automated deployment pipeline:

                    CODE
                     ↓
                  GITHUB
                     ↓
              GITHUB ACTIONS
                     ↓
                AWS AUTH
                     ↓
                  AWS S3
                     ↓
              LIVE WEBSITE

Now, whenever I update my portfolio and push the changes to GitHub, GitHub Actions can automatically synchronize the latest files with my S3 bucket.

That's the real power of CI/CD:

Build once. Automate the process. Deploy consistently. 🚀

If you're a beginner learning DevOps, this is a great project to build yourself because it combines Git, GitHub, CI/CD, AWS IAM, S3, AWS CLI, secrets management, and static website hosting in one practical project.

Happy Dockering!

🚀 Complete Learning & Career Resources | 2027–2028

A curated collection of learning resources for AI, Data Analytics, Python, Data Engineering, Cybersecurity, Cloud, Networking, Finance, Digital Marketing, Project Management, DevOps and Generative AI.

📚 Learn  →  🧪 Practice  →  🛠️ Build  →  🐙 Share  →  🚀 Grow

🌟 About This Repository

Welcome to the Complete Learning & Career Resources Repository! 🚀

This repository is designed as a centralized learning hub for students, developers, QA engineers, DevOps engineers, cloud learners, cybersecurity enthusiasts, data professionals, project managers, business professionals and anyone interested in continuous learning.

The goal is simple:

Learn → Practice → Build → Document → Share → Grow

Instead of searching for useful resources again and again, this repository brings them together in one place.

🎯 What You Will Find Here

• 🤖 Artificial Intelligence

• 🧠 Generative AI

• 📊 Data Analytics

• 🐍 Python

• ⚙️ Data Engineering

• ☁️ Cloud Computing

• 🌐 Computer Networking

• 🔐 Cybersecurity

• ⚙️ DevOps

• 📋 Project Management

• 💰 Finance

• 📈 Digital Marketing

• 🧩 Business Analysis

• 🚀 Career Development

• 🎓 Professional Learning

• 🛠️ Project Ideas

• 📚 Learning Roadmaps

📊 Repository Overview

📚 Table of Contents

• 🌟 About This Repository

• 🎯 What You Will Find Here

• 📊 Repository Overview

• 🤖 AI Courses

• 🔵 Google Courses

• 🟣 IBM Courses

• 🔥 Best Courses 2027–2028

• 🌟 Learning & Career Resources

• 🗺️ Recommended Learning Roadmaps

• 📊 Data Analytics Roadmap

• 🐍 Python Roadmap

• ☁️ Cloud & DevOps Roadmap

• 🔐 Cybersecurity Roadmap

• 🤖 AI Roadmap

• 🧪 How to Learn Effectively

• 🛠️ Project Ideas

• 📂 Recommended GitHub Project Structure

• 📈 Career Roadmap

• 💡 Learning Checklist

• 🧠 Golden Rules

• 📖 My Resources

• 🌐 Useful Links

• ⭐ Support This Repository

• 🔄 Future Updates

• ⚠️ Affiliate Disclosure

🤖 AI Courses

🚀 Explore AI fundamentals, Python, AI infrastructure, Generative AI, AI governance and specialized AI applications.

🔵 Google Courses

🌐 Explore Data Analytics, AI, Cybersecurity, Networking, Cloud, Digital Marketing and Project Management.

🟣 IBM Courses

💙 Explore SQL, Python, Data Analytics, Deep Learning, RAG and Generative AI resources.

🔥 Best Courses 2027–2028

🎯 A broader collection covering AI, Data, Python, Finance, Cybersecurity, Marketing, Networking, Management and Data Engineering.

🌟 Learning & Career Resources

💡 Additional resources for learning, career development, language learning, hosting, education and professional growth.

🗺️ Recommended Learning Roadmaps

Choose one roadmap according to your career goal. You don't need to learn everything at once.

🤖 AI Roadmap

AI Fundamentals
      ↓
Python Basics
      ↓
Mathematics & Statistics
      ↓
Data Fundamentals
      ↓
Machine Learning
      ↓
Deep Learning
      ↓
Generative AI
      ↓
Prompt Engineering
      ↓
RAG
      ↓
Vector Databases
      ↓
Agentic AI
      ↓
AI Applications
      ↓
Real-World Projects
      ↓
GitHub Portfolio

Developers write code → Git tracks the changes → GitHub stores and collaborates on the code → CI/CD tools test and deploy it.

A simple DevOps workflow looks like this:

Developer
    ↓
Git
    ↓
GitHub
    ↓
GitHub Actions / CI Pipeline
    ↓
Build
    ↓
Test
    ↓
Deploy
    ↓
Production

In this blog, we will understand Git and GitHub from the basics to practical DevOps workflows.

We will cover:

• What is Version Control?

• What is Git?

• What is GitHub?

• Git vs GitHub

• Git installation and configuration

• Git repository

• Git working areas

• Git status

• Git add

• Git commit

• Git log

• Git diff

• Git reset

• Git revert

• Git restore

• Git clone

• Git remote

• Git push

• Git pull

• Git fetch

• Git branches

• Git merge

• Git rebase

• Git stash

• Git tags

• GitHub repositories

• Pull Requests

• Git Hooks

• Pre-commit hooks

• GitHub Actions

• CI/CD

• Common Git problems

• Git interview questions

• Complete Git workflow

Let's start from the beginning.

📌 Table of Contents

1. What is Version Control?

2. Why Do We Need Version Control?

3. What is Git?

4. What is GitHub?

5. Git vs GitHub

6. Git Installation

7. Configure Git

8. What is a Git Repository?

9. Git Working Areas

10. git status

11. git init

12. git add

13. git commit

14. git log

15. git show

16. git diff

17. git restore

18. git reset

19. git revert

20. git clone

21. git remote

22. git push

23. git pull

24. git fetch

25. Git Branches

26. Creating Branches

27. Switching Branches

28. Deleting Branches

29. Git Merge

30. Git Rebase

31. Git Stash

32. Git Tags

33. GitHub Repository

34. Pull Requests

35. Code Review

36. Git Hooks

37. Pre-Commit Hooks

38. GitHub Actions

39. GitHub Actions Workflow

40. CI/CD with GitHub Actions

41. .gitignore

42. Git Aliases

43. Common Git Errors

44. Recommended Git Workflow

45. DevOps Git Workflow

46. Git Cheat Sheet

47. Interview Questions

48. What I Learned

49. Conclusion

🔄 What is Version Control?

A Version Control System (VCS) is a system that tracks changes made to files over time.

Imagine you are working on a project.

Initially:

project/
└── app.py

You modify it.

Then you modify it again.

Without version control, you might create:

app-final.py
app-final-new.py
app-final-new-2.py
app-final-latest.py
app-final-latest-working.py

😅 This quickly becomes difficult to manage.

Version control solves this problem.

It keeps a history of your changes.

Version 1
   ↓
Version 2
   ↓
Version 3
   ↓
Version 4

You can see what changed and, when necessary, return to an earlier version.

🤔 Why Do We Need Version Control?

Version control provides several benefits.

1. Track Changes

You can see who changed what and when.

2. Collaboration

Multiple developers can work on the same project.

3. Backup

The code history is preserved.

4. Branching

Developers can work on different features independently.

5. Rollback

You can undo unwanted changes.

6. Code Review

Teams can review changes before merging them.

7. CI/CD Integration

Git repositories can trigger automated testing and deployment.

🐙 What is Git?

Git is a distributed version control system.

Git runs on your local machine and tracks changes to your project.

You can use Git without GitHub.

For example:

Your Computer
     |
     ↓
Git Repository
     |
     ↓
Commits

Git stores your project's history locally.

☁️ What is GitHub?

GitHub is a platform for hosting Git repositories and collaborating on software projects.

It provides features such as:

• Remote repositories

• Pull Requests

• Code Reviews

• Issues

• Discussions

• GitHub Actions

• Project management

• Collaboration

The relationship can be understood as:

Git
 ↓
Version Control

GitHub
 ↓
Hosting + Collaboration + Automation

⚔️ Git vs GitHub

In simple words:

Git manages your code history. GitHub helps you store, share, review, and automate that Git-based project online.

💻 Installing Git

Check whether Git is installed:

git --version

Example:

git version 2.x.x

If Git is not installed, install it for your operating system and run the command again.

⚙️ Configure Git

Before making commits, configure your identity.

Set your username:

git config --global user.name "Your Name"

Set your email:

git config --global user.email "you@example.com"

Check configuration:

git config --list

You can also check individual values:

git config user.name

git config user.email

📦 What is a Git Repository?

A Git repository is a project directory that Git tracks.

Create a project:

mkdir my-project

Move inside:

cd my-project

Initialize Git:

git init

Git creates a hidden directory:

.git/

This directory contains Git's internal information and history.

🧩 Git Working Areas

One of the most important concepts for beginners is understanding Git's working areas.

Working Directory
       ↓
   git add
       ↓
Staging Area
       ↓
 git commit
       ↓
Local Repository

Let's understand each one.

1️⃣ Working Directory

This is where you create or modify files.

Example:

my-project/
└── app.py

You edit:

app.py

Git detects the modification.

2️⃣ Staging Area

You tell Git:

I want this change to be included in my next commit.

Command:

git add app.py

3️⃣ Local Repository

You permanently record the staged changes:

git commit -m "Add application file"

🔍 git status

One of the most frequently used Git commands is:

git status

It shows:

• Current branch

• Modified files

• Untracked files

• Staged files

• Files ready to commit

Example:

git status

You might see:

Untracked files:
    app.py

After:

git add app.py

the file becomes staged.

Run:

git status

again.

Now Git will show that the file is ready to be committed.

🆕 git init

Create a new Git repository:

git init

Example:

mkdir devops-project
cd devops-project
git init

Output may indicate that an empty Git repository has been initialized.

➕ git add

Add one file:

git add app.py

Add multiple files:

git add app.py index.html

Add all changed files:

git add .

Another common form:

git add -A

Example

Suppose:

app.py
README.md
Dockerfile

You can stage everything:

git add .

Then check:

git status

💾 git commit

A commit saves staged changes into Git history.

git commit -m "Add initial application"

A good commit message should describe what changed.

Good:

git commit -m "Add login functionality"

Bad:

git commit -m "changes"

Better commit messages make project history easier to understand.

📜 git log

View commit history:

git log

A shorter format:

git log --oneline

Example:

a82f123 Add login functionality
7bc1234 Add database configuration
3af4567 Initial commit

👀 git show

Display information about a particular commit:

git show <commit-id>

Example:

git show a82f123

It shows information about the commit and the changes introduced by it.

🔎 git diff

git diff shows changes that have not been staged.

Suppose you modify:

app.py

Run:

git diff

Git shows the differences.

After staging:

git add app.py

use:

git diff --staged

to see staged changes.

↩️ git restore

git restore can discard changes in the working directory.

For example:

git restore app.py

This restores the working-tree version of the file from Git's tracked version.

⚠️ Be careful because this can discard local changes.

To unstage a file:

git restore --staged app.py

The file remains modified but is removed from the staging area.

🔄 git reset

git reset moves the current branch to another commit and can modify the staging area or working tree depending on the option.

View recent commits:

git log --oneline

Then, for example:

git reset --soft HEAD~1

This moves HEAD back one commit while keeping the changes staged.

A common option:

git reset --mixed HEAD~1

keeps the changes in the working directory but unstages them.

Another option:

git reset --hard HEAD~1

can discard local changes.

⚠️ --hard should be used carefully.

↩️ git revert

git revert creates a new commit that reverses an earlier commit.

Example:

git revert <commit-id>

This is often safer for shared branches because it doesn't rewrite existing commit history.

Conceptually:

Commit A
   ↓
Commit B
   ↓
Commit C
   ↓
Revert B
   ↓
New Commit D

The original commit remains in history.

📥 git clone

git clone downloads an existing remote repository.

Example:

git clone https://github.com/username/project.git

Then:

cd project

Now you have a local copy of the repository.

🔗 git remote

A remote is a reference to a remote Git repository.

Check remotes:

git remote -v

Add GitHub as origin:

git remote add origin https://github.com/username/project.git

Check again:

git remote -v

You may see:

origin  https://github.com/username/project.git (fetch)
origin  https://github.com/username/project.git (push)

⬆️ git push

git push sends your local commits to a remote repository.

Example:

git push origin main

The first push for a branch is often:

git push -u origin main

The -u option establishes the upstream relationship, making later pushes simpler:

git push

⬇️ git pull

git pull retrieves changes from a remote repository and integrates them into your current branch.

git pull origin main

In simple terms:

Remote Repository
       ↓
     pull
       ↓
Local Repository

It generally performs a fetch followed by an integration step.

📡 git fetch

git fetch downloads information from a remote repository without automatically integrating those changes into your current branch.

git fetch origin

You can then inspect the remote changes before deciding what to merge or rebase.

A useful difference:

git fetch
    ↓
Download remote changes
    ↓
Do not automatically integrate

git pull
    ↓
Fetch
    ↓
Integrate

🌿 What is a Git Branch?

A branch allows you to work on changes independently.

Suppose the main project is:

main
 |
 +-- Production Code

You want to develop a login feature.

Create:

feature/login

Now:

main
 |
 +-- Production Code

feature/login
 |
 +-- Login Development

Your feature work does not have to directly modify main.

🌱 Create a Branch

Create:

git branch feature-login

List branches:

git branch

The current branch is usually marked with *.

🔀 Create and Switch to a Branch

Traditional command:

git checkout -b feature-login

Modern command:

git switch -c feature-login

The second command is easier to understand:

switch -c
     ↓
create + switch

🔄 Switch Branch

Using:

git switch main

or:

git checkout main

🗑️ Delete a Branch

Delete a local branch:

git branch -d feature-login

Force deletion:

git branch -D feature-login

Use -D carefully because it can delete a branch containing unmerged work.

🌍 Push a New Branch to GitHub

Create:

git switch -c feature-login

Make changes.

Then:

git add .

git commit -m "Add login feature"

Push:

git push -u origin feature-login

Now the branch exists on GitHub.

🔀 Git Merge

Suppose:

main
 |
 A---B

feature
 |
 A---B---C---D

After completing the feature, switch to main:

git switch main

Then:

git merge feature

The feature changes are integrated into main.

⚠️ Merge Conflicts

Sometimes two branches modify the same part of a file.

Example:

main:
username = "Hritik"

feature:
username = "Developer"

Git may not know which version should be used.

You may see:

<<<<<<< HEAD
username = "Hritik"
=======
username = "Developer"
>>>>>>> feature

You must manually decide which code should remain.

Then:

git add <file>

and:

git commit

The conflict is resolved.

🔄 Git Rebase

Rebase moves or reapplies commits onto another base.

Example:

Before:

main:
A---B---C

feature:
     \
      D---E

After rebasing the feature onto the latest main:

A---B---C---D'---E'

Command:

git switch feature
git rebase main

Rebase can create a cleaner linear history, but it rewrites commit history.

⚠️ Avoid rebasing shared public history unless you understand the consequences.

📦 Git Stash

Sometimes you are working on something but need to switch branches before committing.

Instead of committing incomplete work, you can temporarily stash it.

git stash

Your working changes are stored temporarily.

Switch branch:

git switch main

Do your work.

Return:

git switch feature

Restore stashed changes:

git stash pop

List stashes:

git stash list

🏷️ Git Tags

Tags are commonly used to mark releases.

For example:

v1.0.0
v1.1.0
v2.0.0

Create a tag:

git tag v1.0.0

List tags:

git tag

Push a tag:

git push origin v1.0.0

Push all tags:

git push origin --tags

Tags are useful for release management.

🚫 .gitignore

.gitignore tells Git which files should not be tracked.

Example:

node_modules/
.env
*.log
__pycache__/
target/
.idea/
.vscode/

For example:

.env

may contain secrets.

You generally don't want it committed to a public repository.

🧹 Example .gitignore

For a Java project:

target/
*.class
*.log
.env
.idea/
.vscode/

For a Python project:

__pycache__/
*.pyc
.env
.venv/

For Node.js:

node_modules/
.env
dist/

☁️ Creating a GitHub Repository

A common workflow is:

Create GitHub Repository
          ↓
Clone Repository
          ↓
Create/Edit Files
          ↓
git add
          ↓
git commit
          ↓
git push

After creating a repository on GitHub, connect your local project:

git remote add origin <repository-url>

Then:

git branch -M main

and:

git push -u origin main

🔀 What is a Pull Request?

A Pull Request (PR) is a GitHub feature used to propose changes from one branch to another.

Typical workflow:

Developer
    ↓
Feature Branch
    ↓
Push to GitHub
    ↓
Pull Request
    ↓
Code Review
    ↓
Tests
    ↓
Approval
    ↓
Merge
    ↓
main

For example:

main
  ↑
  |
feature/login

A developer creates a PR from:

feature/login

to:

main

👀 Why Are Pull Requests Important?

Pull Requests provide:

Code Review

Other developers can inspect the changes.

Discussion

Team members can comment on specific lines.

Automated Testing

CI pipelines can run automatically.

Quality Control

Changes can be verified before merging.

Collaboration

Multiple developers can work safely on the same project.

🔍 Code Review

A reviewer may check:

✓ Code quality
✓ Functionality
✓ Security
✓ Tests
✓ Performance
✓ Naming
✓ Documentation

Only after the required checks pass should the PR be merged.

🪝 What are Git Hooks?

Git Hooks are scripts that Git runs automatically when specific Git events occur.

Examples:

pre-commit
post-commit
pre-push
post-checkout

Hooks are located inside:

.git/hooks/

They can automate checks before code is committed or pushed.

🛡️ Pre-Commit Hooks

A pre-commit hook runs before a commit is created.

Example workflow:

Developer
   ↓
git commit
   ↓
Pre-commit Hook
   ↓
Lint / Security Check
   ↓
Pass?
  / \
Yes  No
 |    |
 ↓    ↓
Commit Blocked

For example, a Python project can run a linting tool before allowing a commit.

🧪 Example Pre-Commit Concept

Suppose you have:

app.py

You attempt:

git commit -m "Update application"

The hook can run:

flake8 .

If the check fails:

Linting failed
Commit blocked

The developer fixes the issue and tries again.

This helps prevent low-quality code from entering the repository history.

🔐 Git Hooks for Secret Detection

Hooks can also help detect accidental secrets.

For example:

AWS_ACCESS_KEY
API_KEY
PASSWORD
PRIVATE_KEY
TOKEN

before they are committed.

Conceptually:

git commit
    ↓
Secret Scan
    ↓
Secret Found?
   / \
 Yes  No
  |    |
Block  Commit

However, local hooks should be considered a helpful layer, not the only security control.

🤖 What is GitHub Actions?

GitHub Actions is GitHub's automation and CI/CD platform.

It allows you to automatically run workflows when events occur in your repository.

For example:

git push
   ↓
GitHub
   ↓
GitHub Actions
   ↓
Build
   ↓
Test
   ↓
Docker Build
   ↓
Deploy

📂 GitHub Actions Directory

Workflows are stored in:

.github/workflows/

Example:

.github/
└── workflows/
    └── ci.yml

Workflow files use YAML.

📝 Simple GitHub Actions Workflow

Example:

name: CI

on:
  push:
    branches:
      - main

  pull_request:
    branches:
      - main

jobs:
  test:

    runs-on: ubuntu-latest

    steps:

      - name: Checkout code
        uses: actions/checkout@v4

      - name: Run tests
        run: echo "Running tests..."

Let's understand it.

🧩 GitHub Actions Workflow Explained

name

name: CI

Name of the workflow.

on

on:
  push:
    branches:
      - main

Defines when the workflow runs.

For example:

push
pull_request
workflow_dispatch

jobs

jobs:

Defines the work that GitHub Actions should perform.

runs-on

runs-on: ubuntu-latest

Defines the runner environment.

steps

steps:

Defines individual commands/actions.

Checkout

- uses: actions/checkout@v4

This checks out the repository code into the runner.

🔄 GitHub Actions CI Workflow

A more realistic Java workflow could look like:

name: Java CI

on:
  push:
    branches:
      - main

  pull_request:
    branches:
      - main

jobs:

  build:

    runs-on: ubuntu-latest

    steps:

      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Java
        uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: '17'

      - name: Build with Maven
        run: mvn clean test

The workflow becomes:

Developer Push
      ↓
GitHub
      ↓
GitHub Actions
      ↓
Ubuntu Runner
      ↓
Checkout Code
      ↓
Install Java
      ↓
Maven Test
      ↓
PASS / FAIL

🚀 GitHub Actions for Docker

GitHub Actions can also build Docker images.

Conceptually:

Git Push
   ↓
GitHub Actions
   ↓
Checkout
   ↓
Run Tests
   ↓
Docker Build
   ↓
Docker Image
   ↓
Docker Registry
   ↓
Deployment

This creates the foundation of a CI/CD pipeline.

🔐 GitHub Actions Secrets

Never hardcode sensitive credentials directly into workflow files.

GitHub provides repository/environment secrets.

Examples:

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
DOCKER_USERNAME
DOCKER_PASSWORD

A workflow can reference secrets using:

${{ secrets.SECRET_NAME }}

This is safer than writing credentials directly into YAML.

🔁 Complete Git + GitHub Workflow

A beginner-friendly workflow looks like:

1. Create project
       ↓
2. git init
       ↓
3. Create files
       ↓
4. git status
       ↓
5. git add .
       ↓
6. git commit
       ↓
7. git remote add origin
       ↓
8. git push
       ↓
9. Create feature branch
       ↓
10. Make changes
       ↓
11. git add
       ↓
12. git commit
       ↓
13. git push
       ↓
14. Create Pull Request
       ↓
15. Code Review
       ↓
16. GitHub Actions
       ↓
17. Tests
       ↓
18. Merge
       ↓
19. Deploy

🧑‍💻 Complete Practical Example

Let's build a small project from scratch.

Create:

mkdir git-demo
cd git-demo

Initialize:

git init

Create a file:

echo "# Git Demo" > README.md

Check:

git status

Stage:

git add README.md

Commit:

git commit -m "Add README"

Create a branch:

git switch -c feature-update

Modify the README.

Then:

git add .

git commit -m "Update README"

Push:

git push -u origin feature-update

Create a Pull Request on GitHub.

After review:

feature-update
      ↓
Pull Request
      ↓
Review
      ↓
GitHub Actions
      ↓
Merge
      ↓
main

🧰 Essential Git Commands Cheat Sheet

🧹 git clean

git clean removes untracked files.

First preview what would be removed:

git clean -n

Then remove untracked files:

git clean -f

⚠️ Use carefully because it can permanently remove untracked files.

🧭 git reflog

git reflog records updates to local references such as HEAD.

git reflog

It can be extremely useful when you accidentally reset or move a branch and need to locate previous states.

Example:

HEAD@{0}
HEAD@{1}
HEAD@{2}

This is one of the most useful Git recovery commands to learn.

📚 Recommended Git Workflow for Beginners

Don't try to memorize hundreds of commands.

Start with these:

git status
git add
git commit
git log
git branch
git switch
git merge
git clone
git pull
git push

Once these become comfortable, learn:

git fetch
git stash
git rebase
git reset
git revert
git reflog
git tag

🏢 Git Workflow in a DevOps Team

A professional development workflow may look like:

Developer
    |
    ↓
Feature Branch
    |
    ↓
Code Changes
    |
    ↓
git add
    |
    ↓
git commit
    |
    ↓
git push
    |
    ↓
Pull Request
    |
    ↓
Code Review
    |
    ↓
Automated Tests
    |
    ↓
Security Scan
    |
    ↓
Build
    |
    ↓
Merge
    |
    ↓
CI/CD Pipeline
    |
    ↓
Deployment

Git is therefore not just a version control tool.

It becomes an important part of the complete DevOps lifecycle.

🔥 Git in CI/CD

A modern pipeline can look like:

GitHub
   ↓
Push / Pull Request
   ↓
GitHub Actions
   ↓
Lint
   ↓
Unit Tests
   ↓
Build
   ↓
Docker Build
   ↓
Security Scan
   ↓
Push Image
   ↓
Deploy

This creates a connection between:

Source Control
      +
Automation
      +
Testing
      +
Deployment

🐳 Git + Docker + DevOps

For a Docker project, the repository may contain:

project/
│
├── src/
├── Dockerfile
├── docker-compose.yml
├── .gitignore
├── README.md
└── .github/
    └── workflows/
        └── ci.yml

Then:

Developer
   ↓
Git Commit
   ↓
GitHub
   ↓
GitHub Actions
   ↓
Docker Build
   ↓
Docker Registry
   ↓
Server

This is a very common DevOps pattern.

⚠️ Common Git Mistakes

Mistake 1 — Forgetting to check status

Always start with:

git status

Mistake 2 — Committing secrets

Never commit:

.env
passwords
API keys
private keys
cloud credentials

Use .gitignore and proper secret management.

Mistake 3 — Using meaningless commit messages

Avoid:

update
changes
test
final

Prefer:

Add login validation
Fix database connection
Update Docker configuration
Add CI workflow

Mistake 4 — Working directly on main

For team projects, use feature branches.

main
  ↑
feature/login

Mistake 5 — Using git reset --hard carelessly

This can permanently discard local changes.

Understand the command before using it.

Mistake 6 — Force pushing shared branches

Commands such as:

git push --force

can overwrite remote history.

Use force push only when you understand the consequences and have a valid reason.

🔐 Git Security Best Practices

Never commit secrets

Use:

.env

with .gitignore, and use a proper secret manager for production.

Use Pull Requests

Don't allow unreviewed changes into important branches.

Enable branch protection

Protect your main branch.

Require CI checks

Require tests to pass before merging.

Use secret scanning

Detect accidentally committed credentials.

Keep dependencies updated

Security vulnerabilities can exist in dependencies even when your own code is secure.

🎯 Git Interview Questions

1. What is Git?

Git is a distributed version control system used to track changes and manage source code history.

2. What is GitHub?

GitHub is a platform for hosting Git repositories and providing collaboration and automation features.

3. What is the difference between Git and GitHub?

Git is the version control system.

GitHub is a platform that hosts Git repositories and provides collaboration and automation features.

4. What is a repository?

A repository is a project tracked by Git, including its files and version history.

5. What is staging?

Staging is the process of selecting changes that should be included in the next commit.

Command:

git add .

6. What is a commit?

A commit records a set of staged changes in Git history.

7. What is a branch?

A branch is an independent line of development.

8. What is a Pull Request?

A Pull Request is a proposal to merge changes from one branch into another, usually with review and automated checks.

9. What is git pull?

It fetches remote changes and integrates them into the current branch.

10. What is git fetch?

It downloads remote changes without automatically integrating them into the current branch.

11. What is git merge?

It combines the histories of two branches.

12. What is git rebase?

It reapplies commits onto another base commit and can create a more linear history.

13. What is Git Stash?

Git stash temporarily stores local changes so you can work on something else without committing incomplete work.

14. What are Git Hooks?

Scripts automatically triggered by Git events such as commits or pushes.

15. What is GitHub Actions?

GitHub Actions is a platform for automating workflows such as testing, building, security checks and deployment.

💡 The Most Important Git Concept

If you remember only one workflow from this blog, remember:

                Git Workflow

        Working Directory
                |
                | git add
                ↓
          Staging Area
                |
                | git commit
                ↓
        Local Repository
                |
                | git push
                ↓
       Remote GitHub Repository
                |
                | Pull Request
                ↓
            Code Review
                |
                ↓
        GitHub Actions / CI
                |
                ↓
             Deploy

Once you understand this flow, most Git concepts become much easier.

📈 From Git to DevOps

Git is one of the foundations of DevOps.

A typical learning path can be:

Git
 ↓
GitHub
 ↓
Linux
 ↓
Shell Scripting
 ↓
Docker
 ↓
CI/CD
 ↓
AWS / Cloud
 ↓
Kubernetes
 ↓
Monitoring

Git comes first because CI/CD systems need a reliable source code repository.

🧠 What I Learned

From this Git and GitHub workshop, I learned how version control fits into the DevOps lifecycle.

The important concepts include:

• Version Control

• Git

• GitHub

• Repository management

• Working directory

• Staging area

• Commits

• Branches

• Merging

• Rebasing

• Remote repositories

• Push and Pull

• Fetch

• Pull Requests

• Code Review

• Git Hooks

• Pre-commit checks

• GitHub Actions

• CI/CD automation

The biggest takeaway is that Git is much more than a collection of commands.

It provides the foundation for collaborative development and automated DevOps workflows.

🚀 Complete DevOps Workflow

Let's put everything together:

                DEVELOPER
                    |
                    ↓
               Local Git
                    |
              git add/commit
                    |
                    ↓
              Feature Branch
                    |
                git push
                    ↓
                 GitHub
                    |
              Pull Request
                    |
                    ↓
               Code Review
                    |
                    ↓
             GitHub Actions
                    |
          ┌─────────┴─────────┐
          ↓                   ↓
       Testing              Build
          |                   |
          └─────────┬─────────┘
                    ↓
              Security Scan
                    |
                    ↓
              Docker Image
                    |
                    ↓
             Container Registry
                    |
                    ↓
                 Deploy
                    |
                    ↓
               Production

This is where Git becomes an important part of DevOps.

🎬 Workshop Reference

These notes are based on the Git & GitHub for DevOps workshop session through approximately 02:54:02.

The session covered:

• Version control fundamentals

• Git and GitHub

• Git workflow

• Commits

• Branches

• Merging

• Pull Requests

• Git Hooks

• Pre-commit checks

• GitHub Actions

• CI/CD concepts

🎥 Workshop: Git & GitHub for DevOps

https://www.youtube.com/live/DyqAdz96mok?si=yTWM7TqpWvtRsDTU

🏁 Conclusion

Git and GitHub are essential skills for anyone entering DevOps.

Git helps us:

Track
Manage
Branch
Merge
Rollback
Collaborate

GitHub adds:

Remote Repositories
Pull Requests
Code Reviews
Issues
Automation
CI/CD

And when GitHub is combined with GitHub Actions, Docker, cloud platforms and deployment tools, we can build complete automated DevOps pipelines.

The journey looks like:

Git
 ↓
GitHub
 ↓
GitHub Actions
 ↓
Docker
 ↓
Cloud
 ↓
CI/CD
 ↓
Production

So don't just memorize Git commands.

Create a repository, make changes, create branches, open Pull Requests, resolve conflicts, write GitHub Actions workflows, and build real projects.

That's how Git becomes a real DevOps skill. 🚀

⭐ Quick Git Command Reference

# Configuration
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

# Repository
git init
git clone <url>

# Status & Changes
git status
git diff
git diff --staged

# Staging
git add <file>
git add .

# Commit
git commit -m "message"

# History
git log
git log --oneline
git show <commit>

# Undo / Recovery
git restore <file>
git restore --staged <file>
git reset
git revert <commit>
git reflog

# Remote
git remote -v
git remote add origin <url>

# Sync
git fetch
git pull
git push

# Branches
git branch
git branch <name>
git switch <name>
git switch -c <name>
git branch -d <name>

# Integration
git merge <branch>
git rebase <branch>

# Temporary Work
git stash
git stash list
git stash pop

# Releases
git tag
git tag v1.0.0
git push origin v1.0.0

# Cleanup
git clean -n
git clean -f

Save this section — it works as a quick Git reference while practicing. 🚀

Happy Dockering!

🚀 Complete Learning & Career Resources | 2027–2028

A curated collection of learning resources for AI, Data Analytics, Python, Data Engineering, Cybersecurity, Cloud, Networking, Finance, Digital Marketing, Project Management, DevOps and Generative AI.

📚 Learn  →  🧪 Practice  →  🛠️ Build  →  🐙 Share  →  🚀 Grow

🌟 About This Repository

Welcome to the Complete Learning & Career Resources Repository! 🚀

This repository is designed as a centralized learning hub for students, developers, QA engineers, DevOps engineers, cloud learners, cybersecurity enthusiasts, data professionals, project managers, business professionals and anyone interested in continuous learning.

The goal is simple:

Learn → Practice → Build → Document → Share → Grow

Instead of searching for useful resources again and again, this repository brings them together in one place.

🎯 What You Will Find Here

• 🤖 Artificial Intelligence

• 🧠 Generative AI

• 📊 Data Analytics

• 🐍 Python

• ⚙️ Data Engineering

• ☁️ Cloud Computing

• 🌐 Computer Networking

• 🔐 Cybersecurity

• ⚙️ DevOps

• 📋 Project Management

• 💰 Finance

• 📈 Digital Marketing

• 🧩 Business Analysis

• 🚀 Career Development

• 🎓 Professional Learning

• 🛠️ Project Ideas

• 📚 Learning Roadmaps

📊 Repository Overview

📚 Table of Contents

• 🌟 About This Repository

• 🎯 What You Will Find Here

• 📊 Repository Overview

• 🤖 AI Courses

• 🔵 Google Courses

• 🟣 IBM Courses

• 🔥 Best Courses 2027–2028

• 🌟 Learning & Career Resources

• 🗺️ Recommended Learning Roadmaps

• 📊 Data Analytics Roadmap

• 🐍 Python Roadmap

• ☁️ Cloud & DevOps Roadmap

• 🔐 Cybersecurity Roadmap

• 🤖 AI Roadmap

• 🧪 How to Learn Effectively

• 🛠️ Project Ideas

• 📂 Recommended GitHub Project Structure

• 📈 Career Roadmap

• 💡 Learning Checklist

• 🧠 Golden Rules

• 📖 My Resources

• 🌐 Useful Links

• ⭐ Support This Repository

• 🔄 Future Updates

• ⚠️ Affiliate Disclosure

🤖 AI Courses

🚀 Explore AI fundamentals, Python, AI infrastructure, Generative AI, AI governance and specialized AI applications.

🔵 Google Courses

🌐 Explore Data Analytics, AI, Cybersecurity, Networking, Cloud, Digital Marketing and Project Management.

🟣 IBM Courses

💙 Explore SQL, Python, Data Analytics, Deep Learning, RAG and Generative AI resources.

🔥 Best Courses 2027–2028

🎯 A broader collection covering AI, Data, Python, Finance, Cybersecurity, Marketing, Networking, Management and Data Engineering.

🌟 Learning & Career Resources

💡 Additional resources for learning, career development, language learning, hosting, education and professional growth.

🗺️ Recommended Learning Roadmaps

Choose one roadmap according to your career goal. You don't need to learn everything at once.

🤖 AI Roadmap

AI Fundamentals
      ↓
Python Basics
      ↓
Mathematics & Statistics
      ↓
Data Fundamentals
      ↓
Machine Learning
      ↓
Deep Learning
      ↓
Generative AI
      ↓
Prompt Engineering
      ↓
RAG
      ↓
Vector Databases
      ↓
Agentic AI
      ↓
AI Applications
      ↓
Real-World Projects
      ↓
GitHub Portfolio

The application contains:

• ☕ Java Spring Boot backend

• 🗄️ MySQL database

• 🐳 Docker containers

• ⚙️ Docker Compose

• 📦 Maven

• 🔗 Docker networking

• 💾 Docker volumes

• ❤️ Healthchecks

• 🔐 Environment variables

• 🏗️ Multi-stage Docker build

• 🔄 Automatic restart policies

The goal was not simply to run a Java application inside Docker.

The goal was to understand how a Java application, database, networking, configuration, persistence, and container orchestration work together.

📌 Table of Contents

1. What Are We Building?

2. Project Overview

3. Why Dockerize a Spring Boot Application?

4. Application Architecture

5. Technology Stack

6. How the Application Works

7. Project Structure

8. Spring Boot Application

9. Maven and pom.xml

10. Application Properties

11. Environment Variables

12. Dockerfile

13. Why Use a Multi-Stage Dockerfile?

14. Docker Build Stage

15. Docker Runtime Stage

16. MySQL Database

17. Docker Networking

18. Docker Volumes

19. Docker Compose

20. Healthchecks

21. Restart Policies

22. Complete Setup

23. Clone the Project

24. Build and Start Containers

25. Check Running Containers

26. Access the Application

27. Check Application Logs

28. Check MySQL Logs

29. Connect to MySQL

30. Useful Docker Commands

31. Troubleshooting

32. Common Problems

33. Security Best Practices

34. Why Multi-Stage Builds Matter

35. DevOps Concepts Demonstrated

36. Interview Explanation

37. Interview Questions

38. Future Improvements

39. What I Learned

40. Conclusion

🚀 What Are We Building?

We are taking a Java Spring Boot application and converting it into a containerized application.

The final architecture contains two main Docker services:

                    USER
                     |
                     ↓
              Spring Boot App
                     |
                     ↓
                  MySQL
                     |
                     ↓
              Docker Volume

Docker Compose manages these services.

Instead of installing Java, Maven and MySQL directly on the host machine, we package the application and database into containers.

The result is a reproducible environment that can be started with a single command.

📋 Project Overview

This project demonstrates how to deploy a Spring Boot application using Docker Compose.

The architecture contains:

☕ Application

A Java Spring Boot application built using Maven.

🗄️ Database

A MySQL database responsible for storing application data.

🐳 Docker

Docker packages the application and its environment into containers.

⚙️ Docker Compose

Docker Compose manages the complete multi-container environment.

💾 Volume

A Docker volume keeps MySQL data persistent.

❤️ Healthcheck

A healthcheck verifies whether MySQL is actually ready.

🤔 Why Dockerize a Spring Boot Application?

Normally, deploying a Spring Boot application requires:

Java
Maven
Application dependencies
MySQL
Database configuration
Environment configuration

Different machines can have different versions of these components.

For example:

Developer Machine
Java 17
Maven version A
MySQL version X

        ↓

Production Machine
Java 21
Maven version B
MySQL version Y

This can create compatibility problems.

Docker allows us to package the application environment into reproducible containers.

The deployment becomes:

Source Code
     ↓
Docker Image
     ↓
Container
     ↓
Application

The same image can then be used in:

Development
     ↓
Testing
     ↓
Staging
     ↓
Production

🏗️ Application Architecture

The project follows a simple three-tier architecture:

┌─────────────────────────┐
│          USER           │
│       Web Browser       │
└────────────┬────────────┘
             │
             │ HTTP
             ↓
┌─────────────────────────┐
│     SPRING BOOT APP     │
│                         │
│        Java             │
│        Spring Boot      │
│        Thymeleaf        │
└────────────┬────────────┘
             │
             │ MySQL :3306
             ↓
┌─────────────────────────┐
│          MYSQL          │
│                         │
│       Database          │
└────────────┬────────────┘
             │
             ↓
┌─────────────────────────┐
│     DOCKER VOLUME       │
│   Persistent Database   │
│          Data           │
└─────────────────────────┘

Docker Compose manages the application and database services.

🧰 Technology Stack

🔄 How the Application Works

When the user opens the application:

Browser
   |
   ↓
Spring Boot Container
   |
   ↓
Spring Boot processes request
   |
   ↓
Application communicates with MySQL
   |
   ↓
MySQL returns data
   |
   ↓
Spring Boot processes data
   |
   ↓
Thymeleaf generates response
   |
   ↓
Browser

The important part is that the Java application and MySQL database are running in separate containers.

📁 Project Structure

A typical structure can look like:

java-docker-project/
│
├── src/
│   ├── main/
│   │   ├── java/
│   │   └── resources/
│   │       ├── templates/
│   │       └── application.properties
│   │
│   └── test/
│
├── pom.xml
├── Dockerfile
├── docker-compose.yml
└── README.md

The most important files are:

pom.xml
Dockerfile
docker-compose.yml
application.properties

Each file has a different responsibility.

☕ Spring Boot Application

Spring Boot provides the main application framework.

It handles:

• HTTP requests

• Business logic

• Database communication

• Application configuration

• Dependency management

• Web interface

The application can use Thymeleaf for server-side HTML rendering.

The architecture is therefore:

Browser
   ↓
Spring Boot
   ↓
Thymeleaf
   ↓
MySQL

📦 Maven and pom.xml

Maven is the build and dependency management tool used by the Java application.

The main configuration file is:

pom.xml

The POM defines project information and dependencies.

For example:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<parent>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-parent</artifactId>
		<version>3.2.2</version>
		<relativePath/> <!-- lookup parent from repository -->
	</parent>
	<groupId>com.Spring-Boot-MVC</groupId>
	<artifactId>ExpensesTracker</artifactId>
	<version>0.0.1-SNAPSHOT</version>
	<name>ExpensesTracker</name>
	<description>Demo project for Spring Boot</description>
	<properties>
		<java.version>17</java.version>
	</properties>
	<dependencies>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-data-jpa</artifactId>
		</dependency>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-security</artifactId>
		</dependency>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-thymeleaf</artifactId>
		</dependency>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-validation</artifactId>
		</dependency>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-web</artifactId>
		</dependency>
		<dependency>
			<groupId>org.thymeleaf.extras</groupId>
			<artifactId>thymeleaf-extras-springsecurity6</artifactId>
		</dependency>

		<dependency>
			<groupId>com.mysql</groupId>
			<artifactId>mysql-connector-j</artifactId>
			<scope>runtime</scope>
		</dependency>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-test</artifactId>
			<scope>test</scope>
		</dependency>
		<dependency>
			<groupId>org.springframework.security</groupId>
			<artifactId>spring-security-test</artifactId>
			<scope>test</scope>
		</dependency>
	</dependencies>

	<build>
		<plugins>
			<plugin>
				<groupId>org.springframework.boot</groupId>
				<artifactId>spring-boot-maven-plugin</artifactId>
			</plugin>
		</plugins>
	</build>

</project>

The exact dependencies depend on the application.

🔨 Maven Build

Maven can compile and package the application.

A common command is:

mvn clean install

Let's understand it.

clean

Removes previously generated build files.

install

Compiles, tests and packages the application and installs the generated artifact into the local Maven repository.

The final output is generally a JAR file:

target/
    application.jar

This JAR file is what we ultimately need in the runtime Docker container.

⚙️ Application Properties

Spring Boot commonly stores configuration in:

application.properties

For example:

spring.datasource.url=jdbc:mysql://db:3306/testdb
spring.datasource.username=root
spring.datasource.password=root

spring.jpa.hibernate.ddl-auto=update

Here:

db

is the MySQL service name.

This is important.

Inside Docker Compose:

Spring Boot Container
        |
        ↓
      db:3306
        |
        ↓
MySQL Container

We don't normally use:

localhost

for the database hostname when the database is in another container.

🔐 Environment Variables

Hardcoding database credentials inside source code is not recommended.

Instead, Spring Boot properties can be overridden using environment variables.

For example:

spring.datasource.url

can be mapped to:

SPRING_DATASOURCE_URL

Similarly:

spring.datasource.username

becomes:

SPRING_DATASOURCE_USERNAME

and:

spring.datasource.password

becomes:

SPRING_DATASOURCE_PASSWORD

The naming convention is:

spring.datasource.url
        ↓
SPRING_DATASOURCE_URL

spring.datasource.username
        ↓
SPRING_DATASOURCE_USERNAME

spring.datasource.password
        ↓
SPRING_DATASOURCE_PASSWORD

This is a very useful Spring Boot + Docker concept.

🐳 Dockerfile

The Dockerfile describes how the Java application image is built.

Instead of creating a single huge image, this project uses a multi-stage Docker build.

The architecture is:

Stage 1
Maven Builder
      ↓
Compile Application
      ↓
Create JAR
      ↓
Stage 2
Runtime Image
      ↓
Run JAR

This is an important Docker optimization technique.

🏗️ Why Use a Multi-Stage Dockerfile?

Suppose we use one image for everything:

Java
+
Maven
+
Source Code
+
Build Tools
+
Dependencies
+
JAR

The final image may become unnecessarily large.

But the production container only needs:

Java Runtime
+
Application JAR

Therefore, multi-stage builds separate:

BUILD ENVIRONMENT

from:

RUNTIME ENVIRONMENT

🔨 Docker Build Stage

The first stage uses a Maven image.

Conceptually:

# Stage 1: Build JAR
FROM maven:3.9-eclipse-temurin-17-alpine AS builder
WORKDIR /app

COPY . .

# Build the executable jar (skipping unit tests)
RUN mvn clean package -DskipTests

# Stage 2: Run Application
FROM eclipse-temurin:17-jre-alpine
WORKDIR /app

COPY --from=builder /app/target/*.jar /app/expenseapp.jar

EXPOSE 8080

CMD ["java", "-jar", "expenseapp.jar"]

The builder stage:

1. Starts with Maven

2. Sets working directory

3. Copies project files

4. Downloads dependencies

5. Compiles the application

6. Runs the Maven build

7. Produces the JAR file

The result may look like:

target/
   └── application.jar

🚀 Docker Runtime Stage

The second stage uses a smaller Java runtime image.

Conceptually:

FROM eclipse-temurin:...-jre

WORKDIR /app

COPY --from=builder /app/target/*.jar app.jar

EXPOSE 8080

ENTRYPOINT ["java", "-jar", "app.jar"]

The important line is:

COPY --from=builder

This means:

Copy the required application artifact from the builder stage into the runtime stage.

The final image doesn't need:

Maven
Source Code
Build Tools

It only needs the application runtime and JAR.

📦 Multi-Stage Build Flow

The complete process is:

pom.xml
   |
   ↓
Maven Builder Container
   |
   ↓
mvn clean install
   |
   ↓
application.jar
   |
   ↓
Runtime Java Image
   |
   ↓
Java + application.jar

This produces a cleaner and more efficient final image.

🗄️ MySQL Database

MySQL runs in its own container.

For example:

MySQL Container
      |
      ↓
Database

The Spring Boot application communicates with MySQL through the Docker network.

Example:

Spring Boot
     |
     ↓
db:3306
     |
     ↓
MySQL

The default MySQL port is:

3306

🔗 Docker Networking

Docker Compose creates a network for the services.

For example:

┌───────────────────────────────────┐
│          Docker Network           │
│                                   │
│  ┌─────────────┐   ┌───────────┐ │
│  │ Spring Boot │──→│   MySQL   │ │
│  │    app      │   │    db     │ │
│  └─────────────┘   └───────────┘ │
│                                   │
└───────────────────────────────────┘

The application can connect using:

db:3306

instead of using a hardcoded container IP.

Docker's internal DNS resolves the service name.

This is one of the biggest advantages of Compose networking.

💾 Docker Volumes

Database persistence is extremely important.

Without a volume:

MySQL Container
       ↓
Database Data

If the container is removed, database data can be lost.

With a volume:

MySQL Container
       ↓
Docker Volume
       ↓
Persistent Data

For example:

volumes:
  mysql_data:

Then:

services:

  db:
    volumes:
      - mysql_data:/var/lib/mysql

Now the lifecycle becomes:

Container Deleted
       ↓
Volume Remains
       ↓
Database Data Remains

This is why Docker volumes are critical for stateful services such as databases.

⚙️ Docker Compose

Docker Compose is the central orchestration file.

Usually:

docker-compose.yml

contains:

services:

version: "3.8"

services:
  mysql_db:
    image: mysql:8.0
    container_name: mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: "Test@123"
      MYSQL_DATABASE: expenses_tracker
    ports:
      - "3306:3306"
    networks:
      - expense-app-nw
    healthcheck:
      test: ["CMD-SHELL", "mysqladmin ping -pTest@123 --silent"]
      interval: 5s
      timeout: 5s
      retries: 10
      start_period: 30s
    volumes:
      - mysql_data:/var/lib/mysql

  java_app:
    build:
      context: .
    container_name: expenseapp
    restart: always
    ports:
      - "8081:8080"
    environment:
      SPRING_DATASOURCE_URL: "jdbc:mysql://mysql_db:3306/expenses_tracker?allowPublicKeyRetrieval=true&useSSL=false"
      SPRING_DATASOURCE_USERNAME: root
      SPRING_DATASOURCE_PASSWORD: "Test@123"
    depends_on:
      mysql_db:
        condition: service_healthy
    networks:
      - expense-app-nw

networks:
  expense-app-nw:
    driver: bridge

volumes:
  mysql_data:

Compose can define:

• Services

• Images

• Builds

• Ports

• Environment variables

• Networks

• Volumes

• Healthchecks

• Dependencies

• Restart policies

Instead of manually running multiple Docker commands, Compose lets us define the entire application architecture as code.

🧩 Example Docker Compose Structure

A simplified example:

services:

  app:
    build: .
    container_name: java_app
    ports:
      - "8080:8080"

    environment:
      SPRING_DATASOURCE_URL: jdbc:mysql://db:3306/testdb
      SPRING_DATASOURCE_USERNAME: root
      SPRING_DATASOURCE_PASSWORD: root

    depends_on:
      db:
        condition: service_healthy

    restart: always

  db:
    image: mysql:8
    container_name: mysql_db

    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: testdb

    volumes:
      - mysql_data:/var/lib/mysql

    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      timeout: 5s
      retries: 5

    restart: always

volumes:
  mysql_data:

This is a simplified example. Adjust image versions, credentials, database names and application configuration according to your actual project.

❤️ Healthchecks

One of the most important parts of this project is the MySQL healthcheck.

Simply checking:

Container = Running

does not necessarily mean:

MySQL = Ready

MySQL may take some time to initialize.

Without a healthcheck:

MySQL Container Starts
        ↓
Spring Boot Starts
        ↓
Spring Boot Connects
        ↓
MySQL Not Ready
        ↓
Connection Failure

With a healthcheck:

MySQL Starts
    ↓
Healthcheck
    ↓
MySQL Ready?
    ↓
YES
    ↓
Spring Boot Starts

🩺 MySQL Healthcheck

A common healthcheck is:

healthcheck:
  test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
  interval: 10s
  timeout: 5s
  retries: 5

The command:

mysqladmin ping

checks whether MySQL is responding.

🔄 depends_on with Healthcheck

Docker Compose can use the health status:

depends_on:
  db:
    condition: service_healthy

This tells Compose:

Start the application after the database service reports a healthy status.

This is better than relying only on container startup order.

🔁 Restart Policies

A container may stop because of:

• Application crash

• Temporary failure

• Server issue

• Unexpected error

A restart policy can automatically restart it.

For example:

restart: always

This means Docker should restart the container when appropriate.

Restart policies improve application resilience.

However, restart policies are not a replacement for proper monitoring and troubleshooting.

💻 Complete Setup

Let's now deploy the application.

1️⃣ Install Docker

First install Docker Desktop or Docker Engine depending on your operating system.

Verify:

docker --version

Then:

docker compose version

2️⃣ Clone the Repository

Clone the project:

git clone https://github.com/hritikranjan1/Expenses-Tracker-WebApp.git

Move into the project:

cd Expenses-Tracker-WebApp

3️⃣ Check Project Files

Verify:

pom.xml
Dockerfile
docker-compose.yml
src/

For example:

ls

On Windows:

dir

4️⃣ Configure Database Properties

Configure Spring Boot to use the MySQL service.

For example:

spring.datasource.url=jdbc:mysql://db:3306/testdb
spring.datasource.username=root
spring.datasource.password=root

Or provide these through environment variables.

5️⃣ Build and Start Containers

Run:

docker compose up -d --build

This command:

Reads docker-compose.yml
        ↓
Builds Spring Boot image
        ↓
Pulls MySQL image
        ↓
Creates network
        ↓
Creates volume
        ↓
Creates containers
        ↓
Starts MySQL
        ↓
Runs healthcheck
        ↓
Starts Spring Boot

🔍 Check Running Containers

Run:

docker compose ps

or:

docker ps

You should see something similar to:

NAME        STATUS
java_app    Up
mysql_db    Up (healthy)

The important thing is that MySQL should eventually show:

healthy

🌍 Access the Application

If Spring Boot exposes port 8080:

http://localhost:8080

Open it in your browser.

The request flow becomes:

Browser
   ↓
localhost:8080
   ↓
Spring Boot Container
   ↓
MySQL Container

📜 Check Application Logs

To see Spring Boot logs:

docker logs java_app

Follow logs:

docker logs -f java_app

You may see Spring Boot startup information.

Look for messages indicating that the application has successfully started.

🗄️ Check MySQL Logs

Run:

docker logs mysql_db

Follow:

docker logs -f mysql_db

Look for messages indicating MySQL is ready to accept connections.

🔌 Connect to MySQL

You can enter the MySQL container:

docker exec -it mysql_db mysql -uroot -p

Enter the configured password.

Then:

SHOW DATABASES;

Select the application database:

USE testdb;

Check tables:

SHOW TABLES;

Exit:

exit;

🧪 Test the Application

Testing should happen at multiple levels.

Test 1 — Container

docker ps

Test 2 — MySQL

docker exec -it mysql_db mysqladmin ping -uroot -p

Test 3 — Spring Boot

Open:

http://localhost:8080

Test 4 — Logs

docker logs java_app

This gives a structured way to verify the deployment.

🧰 Useful Docker Commands

Build image

docker compose build

Start containers

docker compose up -d

Build and start

docker compose up -d --build

Stop containers

docker compose stop

Stop and remove containers

docker compose down

Remove containers and volumes

docker compose down -v

⚠️ Be careful with:

docker compose down -v

because it can remove the MySQL volume and therefore the persistent database data.

📦 Image Commands

List Docker images:

docker images

Remove an image:

docker rmi <image-name>

Build manually:

docker build -t springboot-app .

Run manually:

docker run -p 8080:8080 springboot-app

For this project, Docker Compose is preferred because we have multiple services.

🔎 Container Inspection

Inspect the application container:

docker inspect java_app

Inspect MySQL:

docker inspect mysql_db

This can help investigate:

• Network

• Volumes

• Environment

• Container configuration

• IP addresses

• Mounts

🌐 Check Docker Network

List networks:

docker network ls

Inspect a network:

docker network inspect <network-name>

This can show which containers are connected.

For example:

java_app
   |
   +------ Docker Network ------+
                              |
                              ↓
                           mysql_db

💾 Check Docker Volumes

List volumes:

docker volume ls

Inspect a volume:

docker volume inspect <volume-name>

The volume is responsible for keeping MySQL data persistent.

🐞 Troubleshooting

Troubleshooting is an important DevOps skill.

When the application doesn't work, don't immediately rebuild everything.

Follow a structured process.

❌ Problem 1: Spring Boot Cannot Connect to MySQL

Possible error:

Communications link failure

or:

Connection refused

Check MySQL:

docker compose ps

Then:

docker logs mysql_db

Make sure MySQL is healthy.

Also verify:

Database hostname
Database port
Database name
Username
Password

❌ Problem 2: Using localhost for MySQL

A common mistake is:

spring.datasource.url=jdbc:mysql://localhost:3306/testdb

If MySQL is in another container, this may not work as expected.

Instead use the Compose service name:

spring.datasource.url=jdbc:mysql://db:3306/testdb

The concept is:

Spring Boot Container
       |
       ↓
       db:3306
       |
       ↓
MySQL Container

❌ Problem 3: MySQL Is Running But Application Still Fails

Check:

docker compose ps

A running container does not always mean the service is ready.

Check health:

docker inspect mysql_db

Check logs:

docker logs mysql_db

This is where healthchecks become useful.

❌ Problem 4: Port 8080 Already in Use

You may see:

Bind for 0.0.0.0:8080 failed

This means another application is using port 8080.

You can change:

ports:
  - "8081:8080"

Now access:

http://localhost:8081

The important distinction is:

Host Port : Container Port

So:

8081:8080

means:

Host → 8081
Container → 8080

❌ Problem 5: Docker Build Fails

Check:

docker compose build

Look carefully at the error.

Common causes:

• Incorrect Maven dependency

• Network issue while downloading dependencies

• Incorrect Java version

• Invalid Dockerfile

• Incorrect source path

• Build failure in Maven

You can test Maven locally:

mvn clean install

If the Maven build fails outside Docker, fix the application first.

❌ Problem 6: Container Keeps Restarting

Check:

docker ps -a

Then:

docker logs java_app

The logs usually provide the actual reason.

Possible causes:

Application crash
Database connection failure
Configuration error
Missing environment variable
Incorrect Java version
Incorrect JAR path

❌ Problem 7: Database Data Disappears

Check whether a volume is configured:

docker volume ls

If MySQL is running without persistent storage, removing the container may remove the database data.

Use:

volumes:
  - mysql_data:/var/lib/mysql

and define:

volumes:
  mysql_data:

🔐 Security Best Practices

For learning, you may see configurations such as:

root
root

But this should not be used in production.

Production systems should follow stronger security practices.

1. Don't use root for the application

Create a dedicated MySQL user.

2. Use strong passwords

Never use simple credentials in production.

3. Don't commit secrets

Never push:

.env

or credentials into GitHub.

4. Use secrets management

Use a proper secret-management system in production.

5. Keep database private

Don't expose MySQL publicly unless there is a specific requirement.

6. Use HTTPS

Production web applications should use TLS.

7. Scan Docker images

Use image scanning tools to identify vulnerabilities.

8. Keep dependencies updated

Regularly update:

Java
Spring Boot
Maven dependencies
MySQL
Docker base images

9. Use non-root containers

Where practical, run applications using a non-root user.

🏭 Why Multi-Stage Builds Matter

Multi-stage builds are one of the most useful Docker optimization techniques for compiled applications such as Java applications.

Without multi-stage builds:

Final Image
|
+-- Maven
+-- JDK
+-- Source Code
+-- Build Dependencies
+-- JAR

With multi-stage builds:

Builder Image
|
+-- Maven
+-- JDK
+-- Source
+-- Dependencies
|
↓
JAR
|
↓
Runtime Image
|
+-- JRE
+-- JAR

Benefits:

• Smaller final image

• Faster deployment

• Less unnecessary software

• Reduced attack surface

• Cleaner production containers

This is one of the major reasons to use multi-stage Docker builds for Java applications.

🎯 DevOps Concepts Demonstrated

This project demonstrates several important DevOps concepts.

🐳 Containerization

Java Application
      ↓
Docker Image
      ↓
Container

⚙️ Orchestration

Docker Compose
      ↓
Spring Boot + MySQL

🔗 Networking

Spring Boot
      ↓
Docker Network
      ↓
MySQL

💾 Persistent Storage

MySQL
  ↓
Docker Volume
  ↓
Persistent Data

❤️ Healthchecks

MySQL
  ↓
Healthcheck
  ↓
Healthy
  ↓
Spring Boot

🔐 Configuration Management

Environment Variables
        ↓
Docker Compose
        ↓
Spring Boot

🏗️ Build Optimization

Maven Builder
      ↓
JAR
      ↓
Lightweight Runtime Image

🧠 Complete Deployment Flow

The entire project can be represented as:

                Developer
                    |
                    ↓
               Source Code
                    |
                    ↓
             Dockerfile
                    |
                    ↓
          Multi-Stage Build
                    |
           ┌────────┴────────┐
           ↓                 ↓
      Maven Builder      Runtime Image
           |                 |
           ↓                 ↓
      application.jar    Java Runtime
                             |
                             ↓
                     Spring Boot App
                             |
                             ↓
                       Docker Network
                             |
                             ↓
                          MySQL
                             |
                             ↓
                      Docker Volume

Docker Compose manages the runtime architecture.

💼 How to Explain This Project in an Interview

If an interviewer asks:

"Explain your Docker project."

You can answer:

"I deployed a three-tier Java Spring Boot application using Docker and Docker Compose. The application uses Spring Boot for the backend, Maven for dependency management and building the application, and MySQL for persistent data storage. I created a multi-stage Dockerfile where the first stage uses Maven to build the application and generate the JAR file, while the second stage uses a lightweight Java runtime image to run only the required JAR. Docker Compose manages the application and database services, networking, environment variables, healthchecks, restart policies, and persistent volumes. The Spring Boot application connects to MySQL through the Docker network using the database service name rather than localhost. I also configured a MySQL healthcheck so the application doesn't attempt to connect before the database is ready."

This answer demonstrates that you understand both Docker commands and the underlying architecture.

❓ Interview Questions

1. Why did you use Docker Compose?

Because the project contains multiple services.

Docker Compose provides a simple way to define and manage those services together.

2. Why did you use a multi-stage Dockerfile?

To separate the build environment from the runtime environment and keep the final image smaller and cleaner.

3. What is the purpose of the Maven stage?

The Maven stage compiles the Java source code, downloads dependencies, runs the build and generates the JAR file.

4. Why don't you copy the complete source code into the runtime image?

The runtime container only needs the generated application artifact and Java runtime.

Keeping build tools and source code out of the runtime image reduces image size and attack surface.

5. Why does Spring Boot connect to db instead of localhost?

Because MySQL is running in a separate container.

Docker Compose provides service-name-based DNS, so the application can connect to:

db:3306

6. Why is a healthcheck needed?

Because MySQL may take time to become ready after its container starts.

The healthcheck lets Compose determine whether the database is actually ready.

7. Why use a Docker volume?

Because MySQL is stateful.

The volume keeps database data persistent even if the MySQL container is recreated.

8. What does restart: always do?

It tells Docker to restart the container when it stops according to the restart policy.

9. What is the purpose of pom.xml?

It defines the Maven project configuration, dependencies, plugins and build information.

10. How can Spring Boot properties be passed through Docker?

Using environment variables.

For example:

spring.datasource.url

can be represented as:

SPRING_DATASOURCE_URL

🚀 Future Improvements

This project can be extended into a complete production-style DevOps project.

1. Add Nginx

Architecture:

User
 ↓
Nginx
 ↓
Spring Boot
 ↓
MySQL

2. Add HTTPS

Configure SSL/TLS for secure communication.

3. Add CI/CD

For example:

GitHub
   ↓
GitHub Actions
   ↓
Maven Tests
   ↓
Docker Build
   ↓
Security Scan
   ↓
Docker Registry
   ↓
Deployment

4. Push Image to Docker Hub

Build:

docker build -t username/springboot-app .

Login:

docker login

Push:

docker push username/springboot-app

5. Deploy on AWS

The application can be deployed using:

AWS EC2

or container services such as:

Amazon ECS

6. Add Monitoring

Use:

Prometheus
+
Grafana

to monitor:

• CPU

• Memory

• Application metrics

• Request count

• Response time

7. Add Centralized Logging

Production environments can use centralized logging solutions to collect logs from containers.

8. Move to Kubernetes

The Docker Compose architecture can be converted into Kubernetes resources:

Docker Compose
      ↓
Kubernetes
      ↓
Deployment
      ↓
Service
      ↓
ConfigMap
      ↓
Secret
      ↓
PersistentVolume

This would be the next step toward a more advanced cloud-native deployment.

📚 What I Learned From This Project

This project helped me understand that Docker is not simply:

docker build
docker run

A real application requires:

Application
    +
Database
    +
Networking
    +
Storage
    +
Configuration
    +
Healthchecks
    +
Security
    +
Build Optimization

The most important concepts I practiced were:

• Docker containerization

• Docker images

• Docker Compose

• Spring Boot containerization

• Maven builds

• Multi-stage Dockerfiles

• Docker networking

• MySQL containers

• Docker volumes

• Healthchecks

• Environment variables

• Restart policies

• Container logs

• Container troubleshooting

• Database persistence

🏆 Why This Is a Good DevOps Portfolio Project

A basic Docker project might only demonstrate:

docker build
docker run

But this project demonstrates much more:

☕ Spring Boot
       +
📦 Maven
       +
🐳 Docker
       +
⚙️ Docker Compose
       +
🗄️ MySQL
       +
🔗 Networking
       +
💾 Volumes
       +
❤️ Healthchecks
       +
🔐 Environment Variables
       +
🏗️ Multi-Stage Builds

This makes it a strong beginner-to-intermediate DevOps portfolio project.

Instead of telling an interviewer:

"I know Docker."

you can explain a complete architecture and the problems you solved.

📋 Final Architecture

                         USER
                           |
                           ↓
                  ┌─────────────────┐
                  │  Spring Boot    │
                  │     App         │
                  │                 │
                  │ Java + Maven    │
                  └────────┬────────┘
                           |
                           | Docker Network
                           |
                           ↓
                  ┌─────────────────┐
                  │      MySQL      │
                  │    Database     │
                  └────────┬────────┘
                           |
                           ↓
                  ┌─────────────────┐
                  │ Docker Volume   │
                  │ Persistent Data │
                  └─────────────────┘

Docker Compose manages the complete stack.

🎯 Final Checklist

Before considering the project complete:

[✓] Java application created
[✓] Maven dependencies configured
[✓] pom.xml configured
[✓] Spring Boot properties configured
[✓] Dockerfile created
[✓] Multi-stage Docker build configured
[✓] MySQL service configured
[✓] Docker network configured
[✓] Environment variables configured
[✓] Docker volume configured
[✓] MySQL healthcheck configured
[✓] Restart policy configured
[✓] Docker Compose configured
[✓] Application image built
[✓] Containers started
[✓] MySQL verified
[✓] Application tested
[✓] Logs checked

🎥 Reference Tutorial

This project was learned and implemented as part of a Docker/DevOps learning series.

The relevant section starts around:

03:51:00

YouTube:

https://youtu.be/9bSbNNH4Nqw?t=13860

📝 Conclusion

This project gave me practical experience with deploying a Java Spring Boot application using Docker and Docker Compose.

The final environment contains:

Spring Boot
     ↓
Docker Container
     ↓
Docker Network
     ↓
MySQL Container
     ↓
Docker Volume

The most valuable part was understanding how all these components work together.

I learned that containerization is not just about packaging an application.

A production-oriented containerized application also needs:

• Reliable networking

• Persistent storage

• Proper configuration

• Database readiness

• Healthchecks

• Restart policies

• Optimized images

• Security practices

• Troubleshooting strategies

The multi-stage Docker build was particularly useful because it separates the Maven build environment from the runtime environment and helps keep the final image lightweight.

The next logical steps for this project are:

Docker
   ↓
CI/CD
   ↓
AWS
   ↓
Monitoring
   ↓
Kubernetes

For anyone learning DevOps, I highly recommend building projects like this.

Don't just learn Docker commands.

Build something. Break it. Troubleshoot it. Automate it. Deploy it.

That's where real DevOps learning begins. 🚀

🔗 Connect With Me

💼 LinkedIn: https://www.linkedin.com/in/hritikranjan1/

🌐 Website: https://hritikranjan.in

📝 DevOps Blogs: https://blogs.hritikranjan.in

💻 GitHub: https://github.com/hritikranjan1

⭐ If you found this project useful, consider giving the repository a Star!

🚀 Built with Java • Spring Boot • Maven • Docker • Docker Compose • MySQL

Happy Dockering!

🚀 Complete Learning & Career Resources | 2027–2028

A curated collection of learning resources for AI, Data Analytics, Python, Data Engineering, Cybersecurity, Cloud, Networking, Finance, Digital Marketing, Project Management, DevOps and Generative AI.

📚 Learn  →  🧪 Practice  →  🛠️ Build  →  🐙 Share  →  🚀 Grow

🌟 About This Repository

Welcome to the Complete Learning & Career Resources Repository! 🚀

This repository is designed as a centralized learning hub for students, developers, QA engineers, DevOps engineers, cloud learners, cybersecurity enthusiasts, data professionals, project managers, business professionals and anyone interested in continuous learning.

The goal is simple:

Learn → Practice → Build → Document → Share → Grow

Instead of searching for useful resources again and again, this repository brings them together in one place.

🎯 What You Will Find Here

• 🤖 Artificial Intelligence

• 🧠 Generative AI

• 📊 Data Analytics

• 🐍 Python

• ⚙️ Data Engineering

• ☁️ Cloud Computing

• 🌐 Computer Networking

• 🔐 Cybersecurity

• ⚙️ DevOps

• 📋 Project Management

• 💰 Finance

• 📈 Digital Marketing

• 🧩 Business Analysis

• 🚀 Career Development

• 🎓 Professional Learning

• 🛠️ Project Ideas

• 📚 Learning Roadmaps

📊 Repository Overview

📚 Table of Contents

• 🌟 About This Repository

• 🎯 What You Will Find Here

• 📊 Repository Overview

• 🤖 AI Courses

• 🔵 Google Courses

• 🟣 IBM Courses

• 🔥 Best Courses 2027–2028

• 🌟 Learning & Career Resources

• 🗺️ Recommended Learning Roadmaps

• 📊 Data Analytics Roadmap

• 🐍 Python Roadmap

• ☁️ Cloud & DevOps Roadmap

• 🔐 Cybersecurity Roadmap

• 🤖 AI Roadmap

• 🧪 How to Learn Effectively

• 🛠️ Project Ideas

• 📂 Recommended GitHub Project Structure

• 📈 Career Roadmap

• 💡 Learning Checklist

• 🧠 Golden Rules

• 📖 My Resources

• 🌐 Useful Links

• ⭐ Support This Repository

• 🔄 Future Updates

• ⚠️ Affiliate Disclosure

🤖 AI Courses

🚀 Explore AI fundamentals, Python, AI infrastructure, Generative AI, AI governance and specialized AI applications.

🔵 Google Courses

🌐 Explore Data Analytics, AI, Cybersecurity, Networking, Cloud, Digital Marketing and Project Management.

🟣 IBM Courses

💙 Explore SQL, Python, Data Analytics, Deep Learning, RAG and Generative AI resources.

🔥 Best Courses 2027–2028

🎯 A broader collection covering AI, Data, Python, Finance, Cybersecurity, Marketing, Networking, Management and Data Engineering.

🌟 Learning & Career Resources

💡 Additional resources for learning, career development, language learning, hosting, education and professional growth.

🗺️ Recommended Learning Roadmaps

Choose one roadmap according to your career goal. You don't need to learn everything at once.

🤖 AI Roadmap

AI Fundamentals
      ↓
Python Basics
      ↓
Mathematics & Statistics
      ↓
Data Fundamentals
      ↓
Machine Learning
      ↓
Deep Learning
      ↓
Generative AI
      ↓
Prompt Engineering
      ↓
RAG
      ↓
Vector Databases
      ↓
Agentic AI
      ↓
AI Applications
      ↓
Real-World Projects
      ↓
GitHub Portfolio

The project demonstrates several important DevOps concepts:

• 🐳 Docker Containerization

• ⚙️ Docker Compose

• 🐍 Django

• 🗄️ MySQL

• 🌐 Nginx Reverse Proxy

• 🔗 Docker Networking

• 💾 Docker Volumes

• ❤️ Healthchecks

• 🔐 Environment Variables

• 🛡️ Docker Scout

• 🚀 Application Deployment

• 🔍 Container Troubleshooting

The final architecture looks like this:

                    USER / BROWSER
                          |
                          | HTTP :80
                          ↓
                   +--------------+
                   |    NGINX     |
                   | Reverse Proxy|
                   +--------------+
                          |
                          | HTTP :8000
                          ↓
                   +--------------+
                   |    DJANGO    |
                   |   Backend    |
                   +--------------+
                          |
                          | MySQL :3306
                          ↓
                   +--------------+
                   |    MYSQL     |
                   |   Database   |
                   +--------------+
                          |
                          ↓
                    DOCKER VOLUME

This project helped me understand how multiple containers can work together as one application.

📌 Table of Contents

1. What Are We Building?

2. Project Overview

3. Why Dockerize a Django Application?

4. Architecture

5. Technology Stack

6. Project Structure

7. How the Application Works

8. Dockerfile

9. Environment Variables

10. MySQL Database

11. Docker Networking

12. Docker Volumes

13. Docker Compose

14. Healthchecks

15. Nginx Reverse Proxy

16. Setup Requirements

17. Clone the Project

18. Configure Environment Variables

19. Build and Start Containers

20. Check Containers

21. Access the Application

22. Run Django Migrations

23. Connect to MySQL

24. Useful Docker Commands

25. Logs and Troubleshooting

26. Common Problems

27. Docker Scout

28. Multi-Stage Docker Builds

29. .dockerignore

30. Security Best Practices

31. DevOps Concepts Demonstrated

32. What I Learned

33. Interview Explanation

34. Future Improvements

35. Conclusion

🚀 What Are We Building?

We are taking a Django Notes Application and converting it into a multi-container Docker application.

Instead of installing everything directly on the host machine:

Windows/Linux
    |
    +-- Python
    +-- Django
    +-- MySQL
    +-- Nginx
    +-- Dependencies

we run the application using separate containers:

Docker
 |
 +-- Django Container
 |
 +-- MySQL Container
 |
 +-- Nginx Container

Each component has its own responsibility.

This is one of the fundamental ideas behind containerized application architecture.

📋 Project Overview

The project uses:

• Django for application/backend logic

• MySQL for persistent application data

• Nginx as a reverse proxy

• Docker for containerization

• Docker Compose for multi-container orchestration

• .env for configuration

• Docker Volumes for persistent database storage

• Healthchecks to verify service readiness

The project follows a simple three-tier architecture:

User
 |
 ↓
Nginx
 |
 ↓
Django
 |
 ↓
MySQL
 |
 ↓
Docker Volume

The project structure and components are based on the uploaded project documentation.

🤔 Why Dockerize a Django Application?

Without Docker, developers may need to manually install:

Python
Django
MySQL
Nginx
Python packages
System dependencies

This can create the classic problem:

"It works on my machine."

For example:

Developer Machine
      |
      | Different Python version
      | Different packages
      | Different database configuration
      ↓
Application works differently

Docker solves much of this by packaging the application and its environment into reproducible containers.

The same Docker image can be used across:

Development
     ↓
Testing
     ↓
Staging
     ↓
Production

🏗️ Architecture

Our application contains three primary services.

1️⃣ Django Container

Django is responsible for the application logic.

It:

• Handles requests

• Processes application logic

• Communicates with MySQL

• Runs migrations

• Runs through Gunicorn

The internal application port is:

8000

2️⃣ MySQL Container

MySQL stores application data.

It runs on:

3306

The database configuration can look like:

DB_NAME=test_db
DB_USER=root
DB_PASSWORD=root
DB_HOST=db_cont
DB_PORT=3306

An important Docker concept here is:

db_cont

is the hostname used by Django to reach the MySQL container.

It is not the MySQL username.

The project documentation specifically uses db_cont as the database hostname.

3️⃣ Nginx Container

Nginx acts as the reverse proxy.

It accepts traffic on:

Port 80

and forwards requests to Django:

Nginx :80
      |
      ↓
Django :8000

So users don't need to directly access Django.

🧰 Technology Stack

📁 Project Structure

A typical project structure looks like this:

docker-devops-project/
│
├── app/
│   ├── backend/
│   │   ├── manage.py
│   │   ├── requirements.txt
│   │   ├── <django-project>/
│   │   └── <django-app>/
│   │
│   └── frontend/
│       ├── public/
│       └── src/
│
├── nginx/
│   └── nginx.conf
│
├── Dockerfile
├── docker-compose.yml
├── .env
├── .dockerignore
└── README.md

The exact directory names can vary depending on the repository implementation.

🔄 How the Application Works

When a user opens:

http://localhost

the request follows this path:

Browser
   |
   ↓
Nginx :80
   |
   ↓
Django/Gunicorn :8000
   |
   ↓
Django processes request
   |
   ↓
MySQL :3306
   |
   ↓
Database returns data
   |
   ↓
Django generates response
   |
   ↓
Nginx
   |
   ↓
Browser

This separation makes the application easier to maintain, troubleshoot and scale.

🐳 Dockerfile

A Dockerfile tells Docker how to build the application image.

The basic process is:

Base Python Image
       ↓
Install System Dependencies
       ↓
Install Python Dependencies
       ↓
Copy Application
       ↓
Configure Application
       ↓
Start Django/Gunicorn

A Dockerfile typically contains instructions such as:

FROM python:3.9

WORKDIR /app/backend

COPY requirements.txt /app/backend
RUN apt-get update \
    && apt-get upgrade -y \
    && apt-get install -y gcc default-libmysqlclient-dev pkg-config \
    && rm -rf /var/lib/apt/lists/*


# Install app dependencies
RUN pip install mysqlclient
RUN pip install --no-cache-dir -r requirements.txt

COPY . /app/backend

EXPOSE 8000
CMD ["python3", "manage.py", "runserver", "0.0.0.0:8000"]
#RUN python manage.py migrate
#RUN python manage.py makemigrations

The exact Dockerfile should follow the application's actual dependency and startup requirements.

The important DevOps concept is that the Dockerfile turns the application source code into a reproducible Docker image.

🔐 Environment Variables

Hardcoding configuration inside application code is not a good practice.

Instead, configuration can be stored in:

.env

For example:

DB_NAME=test_db
DB_USER=root
DB_PASSWORD=root
DB_PORT=3306
DB_HOST=db_cont

MySQL can use compatible variables such as:

MYSQL_DATABASE=test_db
MYSQL_ROOT_PASSWORD=root

What does each variable mean?

The .env file keeps configuration separate from application source code.

⚠️ Important Security Rule

Never commit real credentials to GitHub.

Add:

.env

to:

.env

For production, use a proper secrets-management solution.

🗄️ MySQL Database

The database runs inside its own Docker container.

Example:

MySQL Container
      |
      ↓
test_db

Django connects to MySQL through the Docker network.

Example:

DB_HOST=db_cont
DB_PORT=3306

Notice that we don't use:

localhost

for the Django-to-MySQL connection.

Why?

Because inside the Django container:

localhost

means:

Django container itself

It does not mean the MySQL container.

Instead, Docker provides service/container-name based communication:

Django Container
       |
       ↓
db_cont:3306
       |
       ↓
MySQL Container

🔗 Docker Networking

Docker Compose creates a network that allows containers to communicate.

For example:

django_cont
     |
     | Docker Network
     |
     ↓
db_cont:3306

This means Django can connect to MySQL using:

db_cont

rather than a hardcoded IP address.

This is much more reliable because container IP addresses can change.

Docker's internal DNS resolves the container/service name.

💾 Docker Volumes

One of the most important concepts in this project is persistent storage.

Containers are temporary.

Imagine:

MySQL Container
      |
      ↓
Database Data

If the container is deleted without persistent storage:

Container deleted
       ↓
Potential data loss

A Docker volume solves this problem.

MySQL Container
       |
       ↓
Docker Volume
       |
       ↓
Persistent Data

Example:

volumes:
  mysql_data:

and:

services:
  db:
    volumes:
      - mysql_data:/var/lib/mysql

Now:

Container removed
      ↓
Volume remains
      ↓
Database data remains

This is extremely important for databases.

⚙️ Docker Compose

Docker Compose is the central part of this project.

Instead of manually running several commands:

docker run ...
docker run ...
docker run ...

we define the complete architecture inside:

docker-compose.yml

Compose can define:

• Services

• Images

• Builds

• Ports

• Environment variables

• Networks

• Volumes

• Dependencies

• Healthchecks

• Restart policies

Conceptually:

version: "3.8"

services:
  nginx:
    build: ./nginx
    image: nginx
    container_name: "nginx_cont"
    ports:
      - "80:80"
    restart: always
    depends_on:
      - django_app
    networks:
      - notes-app-nw

  django_app:
    build:
      context: .
    image: django_app
    container_name: "django_cont"
    ports:
      - "8000:8000"
    command: sh -c "python manage.py migrate --noinput && gunicorn notesapp.wsgi --bind 0.0.0.0:8000"
    env_file:
      - ".env"
    depends_on:
      - db
    restart: always
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:8000/admin || exit 1"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 30s
    networks:
      - notes-app-nw

  db:
    image: mysql
    container_name: "db_cont"
    ports:
      - "3306:3306"
    environment:
      - MYSQL_ROOT_PASSWORD=root
      - MYSQL_DATABASE=test_db
    volumes:
      - ./data/mysql/db:/var/lib/mysql
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-uroot", "-proot"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 60s
    networks:
      - notes-app-nw

networks:
  notes-app-nw:

The project documentation identifies Compose as the blueprint for the complete application stack.

❤️ Healthchecks

A common problem with multi-container applications is startup order.

Suppose:

MySQL starts
       ↓
Django starts immediately
       ↓
Django tries connecting to MySQL
       ↓
MySQL is still initializing
       ↓
Connection fails

This can cause Django to restart.

A healthcheck allows Docker to determine whether MySQL is actually ready.

Example:

healthcheck:
  test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
  interval: 5s
  timeout: 5s
  retries: 10

The flow becomes:

MySQL starts
     ↓
Healthcheck
     ↓
MySQL ready
     ↓
Healthy
     ↓
Django starts/connects

This is different from simply checking whether the MySQL container is running.

A container can be running but its application may not yet be ready.

That's why healthchecks are useful.

🌐 Nginx Reverse Proxy

Nginx is the public entry point of our application.

Without Nginx:

User
  ↓
Django

With Nginx:

User
  ↓
Nginx
  ↓
Django

Nginx listens on:

80

and forwards traffic to:

Django :8000

Why use Nginx?

Nginx can provide:

• Reverse proxy

• Static file serving

• Centralized traffic handling

• SSL/TLS termination

• Access control

• Caching

• Better production architecture

• Easier future scaling

The project therefore exposes the application through Nginx instead of making Django the primary public entry point.

💻 Setup & Installation

Before starting the project, install:

1. Docker Desktop

2. Git

3. VS Code or another code editor

Check Docker:

docker --version

Check Docker Compose:

docker compose version

Check Git:

git --version

📥 Clone the Project

Clone the repository:

git clone https://github.com/hritikranjan1/django-notes-app.git

Move into the project directory:

cd django-notes-app

🔐 Configure Environment Variables

Create:

.env

Example:

DB_NAME=test_db
DB_USER=root
DB_PASSWORD=root
DB_PORT=3306
DB_HOST=db_cont

The MySQL service should use compatible configuration:

MYSQL_DATABASE=test_db
MYSQL_ROOT_PASSWORD=root

Make sure both Django and MySQL use matching database configuration.

For learning purposes, simple values can be used.

For production, use:

• Strong passwords

• Dedicated database users

• Secret managers

• Environment-specific configuration

🏗️ Build and Start Containers

The recommended modern Docker Compose command is:

docker compose up -d --build

Let's understand what happens.

docker compose

Runs Docker Compose.

up

Creates and starts the services.

-d

Runs containers in detached mode.

--build

Builds the application image before starting.

So:

docker compose up -d --build

will:

Build Images
     ↓
Create Network
     ↓
Create Volume
     ↓
Create Containers
     ↓
Start MySQL
     ↓
Check Health
     ↓
Start Django
     ↓
Start Nginx

🔍 Check Running Containers

Run:

docker ps

You should see containers similar to:

db_cont
django_cont
nginx_cont

You can also use:

docker compose ps

Example:

NAME          STATUS
db_cont       Up (healthy)
django_cont   Up
nginx_cont    Up

The project documentation uses these container names for the three-service architecture.

🌍 Access the Application

The recommended URL is:

http://localhost

because traffic goes through Nginx.

If Django port 8000 is exposed, you may also test:

http://localhost:8000

But this bypasses Nginx.

The architecture we want users to follow is:

Browser
   ↓
localhost:80
   ↓
Nginx
   ↓
Django:8000

🧪 Test Django

On Windows PowerShell:

curl.exe http://localhost:8000

A successful application should return an HTTP success response such as:

HTTP/1.1 200 OK

🌐 Test Nginx

Run:

curl.exe http://localhost

Then open:

http://localhost

in your browser.

If the application loads, the basic architecture is working.

🗄️ Connect to MySQL

If the MySQL container is:

db_cont

connect using:

docker exec -it db_cont mysql -uroot -proot

Once inside MySQL:

SHOW DATABASES;

Select the database:

USE test_db;

Check tables:

SHOW TABLES;

Exit:

exit;

This is useful when debugging database-related problems.

🔄 Run Django Migrations

Django migrations create and update the database schema required by the application.

Enter the Django container:

docker exec -it django_cont sh

Then:

python manage.py migrate

You can check migration status:

python manage.py showmigrations

Exit:

exit

You can also run migration directly:

docker exec -it django_cont python manage.py migrate

The project documentation specifically uses migrations to initialize the application's database tables.

📜 Logs and Troubleshooting

Logs are one of the most important tools when working with Docker.

View all Compose logs

docker compose logs

Follow logs continuously:

docker compose logs -f

Django Logs

docker logs django_cont

Follow:

docker logs -f django_cont

MySQL Logs

docker logs db_cont

Nginx Logs

docker logs nginx_cont

🔎 Check Container Status

Use:

docker compose ps

or:

docker ps

For deeper investigation:

docker inspect django_cont

This can show:

• Network configuration

• Environment

• Mounts

• Container settings

• IP information

• Runtime configuration

🛑 Stop the Project

To stop the application:

docker compose down

This removes the containers and Compose network.

Named volumes are normally preserved.

▶️ Start the Project Again

After stopping:

docker compose up -d

If code or Docker configuration changed:

docker compose up -d --build

🧹 Remove Containers and Volumes

To remove containers and volumes:

docker compose down -v

⚠️ Be careful.

Removing the MySQL volume can remove persistent database data.

Use:

docker compose down -v

only when you intentionally want to delete the stored database data.

🔄 Rebuild From Scratch

If you need a clean image rebuild:

docker compose down

Then:

docker compose build --no-cache

Then:

docker compose up -d

Avoid using:

docker compose down -v

unless you intentionally want to delete the database volume.

🧰 Useful Docker Commands

List running containers

docker ps

List all containers

docker ps -a

List images

docker images

List volumes

docker volume ls

List networks

docker network ls

Inspect container

docker inspect django_cont

Enter Django container

docker exec -it django_cont sh

Restart Django

docker compose restart django

Stop Django

docker compose stop django

Start Django

docker compose start django

🐞 Common Problems

❌ Problem 1: Django Cannot Connect to MySQL

You may see:

django.db.utils.OperationalError:
Can't connect to server on 'db_cont'

Possible reason

MySQL may still be initializing.

Check:

docker compose ps

Then:

docker logs db_cont

Look for:

ready for connections

If MySQL is not ready, Django may fail to connect.

Healthchecks and dependency configuration can help solve this startup timing issue.

❌ Problem 2: Django Container Keeps Restarting

Check:

docker logs django_cont

Possible causes:

• Database unavailable

• Incorrect .env

• Missing Python package

• Migration failure

• Incorrect Django settings

• Incorrect startup command

Always start troubleshooting with the logs.

❌ Problem 3: Nginx Is Running But Application Does Not Open

First check:

docker logs nginx_cont

Then:

docker logs django_cont

Test Django directly:

curl.exe http://localhost:8000

If:

localhost:8000

works but:

localhost

does not work, investigate the Nginx configuration.

❌ Problem 4: Port Already in Use

You may see:

port is already allocated

On Windows, check port 80:

netstat -ano | findstr :80

Check port 8000:

netstat -ano | findstr :8000

This helps identify whether another process is already using the port.

❌ Problem 5: Database Exists But Tables Are Missing

Run:

docker exec -it django_cont python manage.py migrate

Then connect to MySQL:

docker exec -it db_cont mysql -uroot -proot

Run:

USE test_db;
SHOW TABLES;

If migrations were successful, the required Django tables should be present.

❌ Problem 6: .env Changes Are Not Reflected

After changing environment variables, recreate the services:

docker compose down

Then:

docker compose up -d --build

If required:

docker compose up -d --force-recreate

This ensures the containers are recreated with the updated configuration.

🛡️ Docker Scout

Security is an important part of DevOps.

Docker Scout can be used to inspect Docker images for vulnerabilities.

Run:

docker scout quickview

You can also scan an image:

docker scout cves <image-name>

The goal is to identify vulnerable packages and update the relevant base images or dependencies.

A useful DevSecOps flow is:

Dockerfile
    ↓
Build Image
    ↓
Docker Scout
    ↓
Vulnerability Analysis
    ↓
Fix Vulnerabilities
    ↓
Build Again

🏭 Multi-Stage Docker Builds

For larger applications, multi-stage builds can reduce the final image size.

The basic concept is:

BUILD STAGE
-----------
Install build tools
Install dependencies
Build application
       |
       ↓
RUNTIME STAGE
-------------
Copy required output
Run application

Benefits include:

• Smaller images

• Fewer unnecessary packages

• Reduced attack surface

• Faster deployments

The project documentation lists multi-stage builds as a potential optimization concept.

📦 .dockerignore

A .dockerignore file prevents unnecessary files from being sent to Docker during the build.

Example:

.git
.gitignore
.env
__pycache__
*.pyc
venv
node_modules
README.md

Why is this useful?

Because we don't want unnecessary files inside our Docker build context.

It can:

• Reduce build context size

• Improve build performance

• Avoid copying unnecessary files

• Help prevent sensitive files from entering the build context

The project README includes .dockerignore as part of the recommended project setup.

🔐 Security Best Practices

For learning purposes, simple credentials such as:

DB_USER=root
DB_PASSWORD=root

may be used.

But never use this approach for a real production system.

For production:

1. Don't use MySQL root

Create a dedicated application user.

2. Use strong passwords

Avoid:

root
password
123456

3. Don't commit .env

Add:

.env

to:

.gitignore

4. Use secrets management

Examples include cloud secret-management solutions.

5. Scan Docker images

Use Docker Scout or another image scanning solution.

6. Keep images updated

Use maintained base images and update dependencies.

7. Follow least privilege

Give applications only the permissions they actually need.

8. Expose only required ports

Avoid unnecessarily exposing the database publicly.

9. Use HTTPS

Production applications should use SSL/TLS.

10. Keep the database internal

The database should generally communicate through the internal Docker network instead of being directly exposed to the internet.

These security recommendations are also included in the project's documentation.

🎯 DevOps Concepts Demonstrated

This project is more than just a Django application.

It demonstrates several real DevOps concepts.

🐳 Containerization

Application
     ↓
Docker Image
     ↓
Container

⚙️ Orchestration

Docker Compose
      ↓
Django + MySQL + Nginx

🔗 Networking

django_cont
      ↓
Docker Network
      ↓
db_cont:3306

🌐 Reverse Proxy

Client
  ↓
Nginx
  ↓
Django

💾 Persistent Storage

MySQL Container
      ↓
Docker Volume
      ↓
Persistent Database Data

❤️ Healthchecks

MySQL
  ↓
Healthcheck
  ↓
Healthy
  ↓
Django

🔐 Configuration

.env
  ↓
Docker Compose
  ↓
Container

🛡️ Image Security

Docker Image
     ↓
Docker Scout
     ↓
Vulnerability Analysis

The project's documentation explicitly identifies these as the key DevOps concepts demonstrated by the deployment.

🧠 What I Learned From This Project

After completing this project, I gained practical understanding of:

• What Docker is

• Why containers are useful

• Difference between Docker image and container

• What Docker Compose does

• How multiple containers communicate

• How Docker networking works

• Why service names can act as hostnames

• Why databases require persistent storage

• Why Docker volumes are important

• Why healthchecks matter

• What depends_on is used for

• Why Nginx is used as a reverse proxy

• How Django connects to MySQL

• How environment variables are passed to containers

• How to inspect container logs

• How to troubleshoot startup failures

• How to expose ports

• How to rebuild containers

• How to perform Django migrations inside a container

• How to scan container images for vulnerabilities

This turned Docker from a collection of commands into a practical deployment workflow.

💼 How to Explain This Project in an Interview

If an interviewer asks:

"Explain your Docker project."

You can answer:

"I created a multi-container Django Notes Application using Docker and Docker Compose. The application uses Django as the backend, MySQL for persistent data storage, and Nginx as a reverse proxy. Docker Compose manages the complete application stack, including networking, volumes, environment variables, service dependencies, and healthchecks. Django communicates with MySQL through the Docker network using the database container name as the hostname. I used Docker volumes to persist database data and healthchecks to ensure MySQL is ready before the application depends on it. Nginx acts as the public entry point on port 80 and forwards requests to the Django application running on port 8000."

This explanation covers the major DevOps concepts implemented in the project.

🔥 Important Interview Questions

1. Why did you use Docker Compose?

Because the application contains multiple services.

Instead of manually managing each container, Docker Compose allows us to define and manage the entire stack using one configuration file.

2. Why did you use a Docker volume?

Because database data needs to survive container recreation.

Container
   ↓
Volume
   ↓
Persistent Data

3. Why can't Django use localhost to connect to MySQL?

Because Django and MySQL run in separate containers.

Inside the Django container:

localhost

refers to the Django container itself.

Therefore Django uses:

db_cont:3306

to communicate with MySQL.

4. Why is Nginx used?

Nginx acts as a reverse proxy and provides a single public entry point.

User
 ↓
Nginx
 ↓
Django

5. Why are healthchecks required?

Because a container being started does not always mean the application inside it is ready.

MySQL may need several seconds before accepting connections.

Healthchecks help verify readiness.

6. What happens when you run docker compose down?

It stops and removes the Compose-managed containers and network.

Named volumes are normally preserved.

7. What happens with docker compose down -v?

It also removes the associated volumes.

For a database, this can mean losing persistent data.

8. How do you troubleshoot a container?

First:

docker compose ps

Then check logs:

docker logs <container>

For example:

docker logs django_cont
docker logs db_cont
docker logs nginx_cont

📊 Complete Project Flow

The complete deployment can be visualized as:

                    ┌───────────────────┐
                    │      Browser      │
                    └─────────┬─────────┘
                              │
                           HTTP :80
                              │
                              ▼
                    ┌───────────────────┐
                    │       Nginx       │
                    │  Reverse Proxy    │
                    └─────────┬─────────┘
                              │
                           :8000
                              │
                              ▼
                    ┌───────────────────┐
                    │      Django       │
                    │     Gunicorn      │
                    └─────────┬─────────┘
                              │
                           :3306
                              │
                              ▼
                    ┌───────────────────┐
                    │       MySQL       │
                    │      test_db      │
                    └─────────┬─────────┘
                              │
                              ▼
                    ┌───────────────────┐
                    │   Docker Volume   │
                    │ Persistent Storage│
                    └───────────────────┘

This is the overall flow implemented by the project.

📋 Quick Docker Command Cheat Sheet

# Build and start
docker compose up -d --build

# Check containers
docker compose ps

# View all logs
docker compose logs -f

# Django logs
docker logs -f django_cont

# MySQL logs
docker logs -f db_cont

# Nginx logs
docker logs -f nginx_cont

# Enter Django container
docker exec -it django_cont sh

# Run migrations
docker exec -it django_cont python manage.py migrate

# Connect to MySQL
docker exec -it db_cont mysql -uroot -proot

# Stop application
docker compose down

# Start application
docker compose up -d

# Rebuild
docker compose up -d --build

# Remove volumes
docker compose down -v

⚠️ Remember: use docker compose down -v carefully because database volumes contain persistent data.

🌐 Application URLs

When running locally:

Application through Nginx

http://localhost

Django direct access

http://localhost:8000

MySQL

localhost:3306

The preferred browser URL is:

http://localhost

because it represents the intended Nginx reverse-proxy architecture.

✅ Project Success Checklist

Before considering the deployment successful, verify:

[ ] Docker installed
[ ] Docker Compose available
[ ] Repository cloned
[ ] .env configured
[ ] Dockerfile available
[ ] docker-compose.yml available
[ ] Nginx configuration available
[ ] Images built successfully
[ ] MySQL container running
[ ] MySQL container healthy
[ ] Django container running
[ ] Nginx container running
[ ] Database migrations completed
[ ] Database volume configured
[ ] http://localhost works
[ ] Django logs show no critical errors

🔧 Troubleshooting Flow

When something doesn't work, don't randomly change configurations.

Follow a structured troubleshooting process:

1. Check Docker
       ↓
docker --version

2. Check containers
       ↓
docker compose ps

3. Check MySQL
       ↓
docker logs db_cont

4. Check Django
       ↓
docker logs django_cont

5. Check Nginx
       ↓
docker logs nginx_cont

6. Test Django
       ↓
curl.exe http://localhost:8000

7. Test Nginx
       ↓
curl.exe http://localhost

8. Check database
       ↓
docker exec -it db_cont mysql -uroot -proot

This approach helps identify whether the problem is related to:

Database
   ↓
Backend
   ↓
Networking
   ↓
Nginx
   ↓
Application Configuration

🚀 Future Improvements

This project can be extended into a more production-ready DevOps project.

1. Add HTTPS

Configure SSL/TLS for secure communication.

HTTPS
 ↓
Nginx
 ↓
Django

2. Use a Non-Root Database User

Instead of:

root

create a dedicated application user with only the required permissions.

3. Add Redis

Redis can be introduced for:

• Caching

• Session storage

• Background jobs

4. Add Celery

Celery can handle background tasks asynchronously.

Architecture:

Django
  ↓
Celery
  ↓
Redis

5. Add CI/CD

The project can be connected to:

• GitHub Actions

• Jenkins

Example:

Git Push
   ↓
CI Pipeline
   ↓
Run Tests
   ↓
Build Docker Image
   ↓
Security Scan
   ↓
Push Image
   ↓
Deploy

6. Push Images to a Registry

For example:

Docker Hub

or:

Amazon ECR

7. Deploy to AWS

The application could be deployed using:

AWS EC2

or:

AWS ECS

8. Add Monitoring

Add:

Prometheus
     +
Grafana

for monitoring and visualization.

9. Centralized Logging

A production environment should have centralized logging so that application and infrastructure logs can be searched and analyzed.

10. Kubernetes

A natural next step would be converting the Docker Compose architecture into Kubernetes manifests.

For example:

Docker Compose
      ↓
Kubernetes
      ↓
Deployments
Services
ConfigMaps
Secrets
Persistent Volumes

These improvements are listed in the project's documentation as possible next steps.

📚 What This Project Taught Me About DevOps

The biggest lesson from this project is that Docker is not just about creating containers.

A real application requires several components to work together:

Application
     +
Database
     +
Networking
     +
Persistent Storage
     +
Reverse Proxy
     +
Healthchecks
     +
Configuration
     +
Security

Docker Compose allows us to define this complete architecture in a repeatable way.

The result is:

One Application
       ↓
Multiple Containers
       ↓
One Managed Architecture

This is much closer to how modern applications are deployed than simply running a single Docker container.

🏆 Why This Is a Good DevOps Portfolio Project

A basic Docker project might only demonstrate:

docker build
docker run

This project goes much further.

It demonstrates:

🐳 Containerization
        +
⚙️ Orchestration
        +
🔗 Networking
        +
💾 Persistent Storage
        +
🌐 Reverse Proxy
        +
❤️ Healthchecks
        +
🔐 Environment Configuration
        +
🛡️ Security Scanning

That makes it a useful beginner-to-intermediate DevOps portfolio project.

It gives you something practical to discuss during interviews instead of only saying:

"I know Docker."

You can explain:

"I containerized a Django application, connected it to MySQL through a Docker network, persisted database data using volumes, placed Nginx in front of Django as a reverse proxy, configured service healthchecks, managed the entire stack with Docker Compose, and performed container troubleshooting and image security scanning."

That is a much stronger project explanation.

🎥 Reference Tutorial

This project was built while learning from the Docker-focused tutorial by Train with Shubham.

YouTube:

https://youtu.be/9bSbNNH4Nqw

The project documentation also references this tutorial as the learning source.

💻 Project Repository

GitHub:

https://github.com/hritikranjan1/django-notes-app.git

You can explore the complete Dockerized Django project, configuration files, Docker setup and documentation there.

📝 Conclusion

Building this Django Notes Application helped me understand how Docker can be used to deploy a complete multi-container application.

The final architecture contains:

                    Browser
                       ↓
                     Nginx
                       ↓
                  Django/Gunicorn
                       ↓
                     MySQL
                       ↓
                 Docker Volume

And Docker Compose manages the complete environment.

The most important concepts I learned were:

• Docker containerization

• Docker images

• Docker Compose

• Container networking

• Environment variables

• Docker volumes

• Database persistence

• Healthchecks

• Nginx reverse proxy

• Django migrations

• Container troubleshooting

• Docker image security

This project also provides a strong foundation for moving toward more advanced DevOps technologies such as:

CI/CD
 ↓
AWS
 ↓
Jenkins / GitHub Actions
 ↓
Monitoring
 ↓
Kubernetes

If you are a beginner learning Docker, I highly recommend building a project like this instead of only memorizing Docker commands.

Learn → Build → Break → Troubleshoot → Improve.

That's where the real DevOps learning happens. 🚀

🔗 Connect With Me

💼 LinkedIn: https://www.linkedin.com/in/hritikranjan1/

🌐 Website: https://hritikranjan.in

📝 DevOps Blogs: https://blogs.hritikranjan.in

💻 GitHub: https://github.com/hritikranjan1

⭐ If you found this project useful, consider giving the repository a Star!

🚀 Built with Docker • Django • MySQL • Nginx • DevOps

Happy Dockering!

🚀 Complete Learning & Career Resources | 2027–2028

A curated collection of learning resources for AI, Data Analytics, Python, Data Engineering, Cybersecurity, Cloud, Networking, Finance, Digital Marketing, Project Management, DevOps and Generative AI.

📚 Learn  →  🧪 Practice  →  🛠️ Build  →  🐙 Share  →  🚀 Grow

🌟 About This Repository

Welcome to the Complete Learning & Career Resources Repository! 🚀

This repository is designed as a centralized learning hub for students, developers, QA engineers, DevOps engineers, cloud learners, cybersecurity enthusiasts, data professionals, project managers, business professionals and anyone interested in continuous learning.

The goal is simple:

Learn → Practice → Build → Document → Share → Grow

Instead of searching for useful resources again and again, this repository brings them together in one place.

🎯 What You Will Find Here

• 🤖 Artificial Intelligence

• 🧠 Generative AI

• 📊 Data Analytics

• 🐍 Python

• ⚙️ Data Engineering

• ☁️ Cloud Computing

• 🌐 Computer Networking

• 🔐 Cybersecurity

• ⚙️ DevOps

• 📋 Project Management

• 💰 Finance

• 📈 Digital Marketing

• 🧩 Business Analysis

• 🚀 Career Development

• 🎓 Professional Learning

• 🛠️ Project Ideas

• 📚 Learning Roadmaps

📊 Repository Overview

📚 Table of Contents

• 🌟 About This Repository

• 🎯 What You Will Find Here

• 📊 Repository Overview

• 🤖 AI Courses

• 🔵 Google Courses

• 🟣 IBM Courses

• 🔥 Best Courses 2027–2028

• 🌟 Learning & Career Resources

• 🗺️ Recommended Learning Roadmaps

• 📊 Data Analytics Roadmap

• 🐍 Python Roadmap

• ☁️ Cloud & DevOps Roadmap

• 🔐 Cybersecurity Roadmap

• 🤖 AI Roadmap

• 🧪 How to Learn Effectively

• 🛠️ Project Ideas

• 📂 Recommended GitHub Project Structure

• 📈 Career Roadmap

• 💡 Learning Checklist

• 🧠 Golden Rules

• 📖 My Resources

• 🌐 Useful Links

• ⭐ Support This Repository

• 🔄 Future Updates

• ⚠️ Affiliate Disclosure

🤖 AI Courses

🚀 Explore AI fundamentals, Python, AI infrastructure, Generative AI, AI governance and specialized AI applications.

🔵 Google Courses

🌐 Explore Data Analytics, AI, Cybersecurity, Networking, Cloud, Digital Marketing and Project Management.

🟣 IBM Courses

💙 Explore SQL, Python, Data Analytics, Deep Learning, RAG and Generative AI resources.

🔥 Best Courses 2027–2028

🎯 A broader collection covering AI, Data, Python, Finance, Cybersecurity, Marketing, Networking, Management and Data Engineering.

🌟 Learning & Career Resources

💡 Additional resources for learning, career development, language learning, hosting, education and professional growth.

🗺️ Recommended Learning Roadmaps

Choose one roadmap according to your career goal. You don't need to learn everything at once.

🤖 AI Roadmap

AI Fundamentals
      ↓
Python Basics
      ↓
Mathematics & Statistics
      ↓
Data Fundamentals
      ↓
Machine Learning
      ↓
Deep Learning
      ↓
Generative AI
      ↓
Prompt Engineering
      ↓
RAG
      ↓
Vector Databases
      ↓
Agentic AI
      ↓
AI Applications
      ↓
Real-World Projects
      ↓
GitHub Portfolio

If you are learning DevOps, AWS, Kubernetes, CI/CD, or cloud computing, Docker is one of the tools you should become comfortable with.

But when beginners start learning Docker, one problem appears again and again:

There are so many Docker commands. Which command should I use, and when?

This guide is designed to solve that problem.

Instead of simply giving you a list of commands, we will understand:

• What each Docker command does

• Why we use it

• When we should use it

• Command syntax

• Real-world examples

• Important options

• Common mistakes

• Beginner tips

• Docker Compose commands

• Docker networking

• Docker volumes

• Docker image management

• Docker registry commands

• Docker Buildx

• Docker Swarm

• Troubleshooting commands

• A final Docker cheat sheet

By the end of this article, you should be able to use the Docker CLI confidently in your development and DevOps projects.

📌 Table of Contents

1. What Is Docker?

2. Docker Architecture in Simple Words

3. Docker Command Syntax

4. Check Docker Installation

5. Docker Container Commands

6. Docker Image Commands

7. Docker Registry Commands

8. Docker Logs and Debugging

9. Docker Volume Commands

10. Docker Network Commands

11. Docker Container Interaction

12. Docker File Copy Commands

13. Docker Cleanup Commands

14. Docker Commit, Export and Import

15. Docker Compose Commands

16. Docker Compose Example Project

17. Docker Context Commands

18. Docker Buildx Commands

19. Docker Manifest Commands

20. Docker Swarm Commands

21. Docker Plugin Commands

22. Useful Docker Filters

23. Useful Docker Formatting Commands

24. Common Docker Errors

25. Docker Commands Beginners Should Memorize

26. Docker Cheat Sheet

27. Docker Learning Roadmap

28. Conclusion

🐳 What Is Docker?

Docker is a platform used to build, package, distribute, and run applications inside containers.

A container packages an application together with the dependencies it needs to run.

For example, imagine your application requires:

Application
    +
Python
    +
Required Libraries
    +
Environment Variables
    +
System Dependencies

Docker allows you to package these requirements into an image and run that image as a container.

A simple way to remember the relationship is:

Dockerfile
     ↓
Docker Image
     ↓
Docker Container

Dockerfile

A Dockerfile contains instructions for creating an image.

Docker Image

An image is a reusable package/template containing the application and its required environment.

Docker Container

A container is a running instance of an image.

🏗️ Docker Architecture in Simple Words

A simplified Docker architecture looks like this:

                Docker CLI
                    |
                    ↓
              Docker Engine
                    |
          ---------------------
          |         |         |
       Images   Containers  Networks
                    |
                 Volumes

When you run:

docker run nginx

Docker approximately performs this flow:

Docker CLI
   ↓
Check local image
   ↓
Image not available?
   ↓
Pull image from registry
   ↓
Create container
   ↓
Start container

The Docker documentation describes docker run as creating and running a new container from an image; if the image is unavailable locally, Docker can pull it first.

💻 Docker Command Syntax

Most Docker commands follow this pattern:

docker <command> <options> <arguments>

For example:

docker run -d -p 8080:80 nginx

Here:

docker       → Docker CLI
run          → command
-d           → run in detached mode
-p            → publish a port
8080:80      → host:container port
nginx        → image

You can get help for almost any Docker command using:

docker --help

Or:

docker run --help

Docker officially supports the --help option for displaying command-specific help.

1️⃣ Check Docker Installation

Before learning Docker commands, verify that Docker is installed.

Check Docker Version

docker --version

Example:

Docker version 28.x.x, build xxxxx

This tells you the installed Docker CLI version.

Detailed Docker Version

docker version

This can show information about both the Docker client and server/engine.

Use it when troubleshooting version compatibility.

Docker System Information

docker info

This provides information about the Docker environment.

It can include:

• Containers

• Images

• Storage driver

• Docker root directory

• CPUs

• Memory

• Plugins

• Server information

Useful when troubleshooting Docker.

Docker Help

docker --help

For a specific command:

docker run --help

2️⃣ Docker Container Commands

Containers are where your applications actually run.

Let's learn the most important container commands.

docker run

The most important Docker command for beginners.

docker run nginx

It creates and starts a new container from the nginx image.

If the image isn't available locally, Docker can pull it from a registry.

Run in Background

docker run -d nginx

-d means:

Detached mode

The container runs in the background.

Give the Container a Name

docker run --name my-nginx -d nginx

Now instead of using a random container name, you can use:

docker stop my-nginx

Docker supports custom container names through the --name option.

Map a Port

docker run -d -p 8080:80 nginx

The format is:

-p HOST_PORT:CONTAINER_PORT

So:

8080 → Your computer
80   → Container

You can then access:

http://localhost:8080

Run an Interactive Ubuntu Container

docker run -it ubuntu /bin/bash

Meaning:

-i → interactive
-t → terminal

Now you can work inside the Ubuntu container.

Run a Specific Image Version

docker run nginx:1.27

Here:

nginx → image
1.27  → tag

Avoid blindly relying on latest in production deployments when reproducibility matters.

docker create

Creates a container but does not start it.

docker create --name mycontainer nginx

Then start it:

docker start mycontainer

Think:

docker create → Create
docker start  → Start

While:

docker run → Create + Start

docker start

Starts an existing stopped container.

docker start mycontainer

Important:

docker run

creates a new container.

docker start

starts an existing container.

docker stop

Stops a running container gracefully.

docker stop mycontainer

Example:

docker stop nginx-container

Use this when you want to shut down an application cleanly.

docker restart

Restarts a container.

docker restart mycontainer

Useful when a service needs to be restarted after a configuration change or temporary problem.

docker pause

Pauses all processes inside a container.

docker pause mycontainer

docker unpause

Resumes a paused container.

docker unpause mycontainer

docker kill

Forcefully stops a running container.

docker kill mycontainer

Use docker stop for normal shutdowns.

Use docker kill when the container is stuck or doesn't respond properly.

docker rm

Removes a container.

docker rm mycontainer

If the container is still running, Docker normally requires you to stop it first.

You can force removal:

docker rm -f mycontainer

⚠️ Be careful with -f.

docker rename

Renames a container.

docker rename old-name new-name

Example:

docker rename nginx-container web-server

docker wait

Waits until a container stops and then prints its exit code.

docker wait mycontainer

Useful in automation and scripts.

docker container prune

Removes all stopped containers.

docker container prune

Docker asks for confirmation before deleting them.

3️⃣ Docker Image Commands

An image is a package/template used to create containers.

Think:

Image
  ↓
Container

One image can be used to create many containers.

docker pull

Downloads an image from a registry.

docker pull nginx

Specific version:

docker pull nginx:1.27

Ubuntu:

docker pull ubuntu:24.04

docker images

Lists locally available images.

docker images

Example output:

REPOSITORY   TAG       IMAGE ID       CREATED       SIZE
nginx        latest    abc123         2 days ago    190MB
ubuntu       24.04     xyz456         3 days ago    78MB

docker image ls

Modern object-oriented form of listing images:

docker image ls

It is equivalent to:

docker images

docker build

Builds an image from a Dockerfile.

Suppose your project contains:

myapp/
├── Dockerfile
└── app.py

Build the image:

docker build -t myapp:1.0 .

Meaning:

-t myapp:1.0 → image name and tag
.            → current directory

Example Dockerfile

FROM python:3.12-slim

WORKDIR /app

COPY app.py .

CMD ["python", "app.py"]

Build:

docker build -t python-app:1.0 .

Run:

docker run python-app:1.0

docker rmi

Removes an image.

docker rmi nginx

Or:

docker rmi nginx:latest

Force removal:

docker rmi -f nginx

Be careful because removing an image can affect containers that depend on it.

docker image rm

Equivalent object-oriented form:

docker image rm nginx

docker tag

Creates another tag/reference for an image.

docker tag myapp:latest username/myapp:v1

This is commonly used before pushing an image to Docker Hub or another registry.

docker history

Shows the layers used to create an image.

docker history nginx

This can help you understand image construction and investigate image size.

docker inspect

Displays detailed information about Docker objects.

For an image:

docker image inspect nginx

For a container:

docker inspect mycontainer

The output is usually JSON.

It can contain information such as:

• Environment variables

• Network configuration

• Mounts

• IP addresses

• Image configuration

• Container state

docker save

Saves an image to a tar archive.

docker save -o myimage.tar myapp:latest

Useful when you need to transfer an image without directly pulling it from a registry.

docker load

Loads an image from a tar archive.

docker load -i myimage.tar

Typical workflow:

Machine A
   ↓
docker save
   ↓
myimage.tar
   ↓
Transfer file
   ↓
Machine B
   ↓
docker load

4️⃣ Docker Registry Commands

A registry stores Docker images.

Examples include:

• Docker Hub

• Amazon ECR

• GitHub Container Registry

• Google Artifact Registry

• Azure Container Registry

• Private registries

docker login

Log in to a container registry.