I had heard of HTTPS before, but I didn’t really know what happens behind the scenes. So I went deep, step by step. This is what I learned

The Traffic Path: User → Cloudflare → My Domain

Let’s start with the big picture.

• User/Visitor (Browser) → opens my website (https://jaivardhan.online)

• Cloudflare → sits in the middle, protects my site, and handles a lot of stuff (security, caching, SSL).

• My Domain Host (Hostinger) → actually stores the site files.

So the path is:
Client/User ↔ Cloudflare ↔ Domain (Hostinger)

SSL/TLS decides how secure each leg of this journey is.

Cloudflare’s Role in SSL

When I added my domain to Cloudflare, I noticed something cool:

• Cloudflare automatically gave me a Universal SSL certificate for free.

• That certificate covers the first half of the path: User ↔ Cloudflare.

That’s why, even though I hadn’t installed anything on Hostinger, my site was already showing as Secure in the browser!
Because Cloudflare was handling HTTPS for visitors.

So basically, Cloudflare acted like:

“Don’t worry, I’ll take care of the visitors. Even if your server is plain old HTTP, I’ll still show them HTTPS.”

Encryption Modes in Cloudflare

In Cloudflare’s SSL/TLS settings, there are different modes:

1. Off (not secure)

   • No HTTPS at all. Browsers will warn visitors.

2. Flexible

   • User ↔ Cloudflare = HTTPS

   • Cloudflare ↔ Hostinger (origin) = HTTP

   • Safer than nothing, but origin side is still plain and vulnerable.

3. Full

   • User ↔ Cloudflare = HTTPS

   • Cloudflare ↔ Hostinger = HTTPS (but Cloudflare doesn’t check if the origin’s certificate is valid).

   • Works if your host has SSL (even self-signed).

4. Full (Strict) —> (the best)

   • User ↔ Cloudflare = HTTPS

   • Cloudflare ↔ Hostinger = HTTPS (and the certificate must be valid & trusted).

   • Ensures true end-to-end encryption.

5. Strict (SSL-Only Origin Pull)

   • Forces encryption with origin no matter what.

   • Useful for locked-down setups.

So the key takeaway for me:

• Cloudflare always covers User ↔ Cloudflare with its Universal SSL.

• But for Cloudflare ↔ Hostinger, I need SSL installed at my host if I want Full Strict security.

Free SSL at Hostinger (Cloudflare — Domain)

Good news: I didn’t have to buy anything. Hostinger automatically provides a free SSL certificate (via Let’s Encrypt) for domains that are bought using Hostinger.

This means:

• Cloudflare ↔ Hostinger is also encrypted (when set to Full Strict).

• My site has true end-to-end HTTPS.

Big Question: If Hostinger already gives SSL, why still use Cloudflare?

At this point, I thought:

“Hostinger already gave me a free SSL certificate. So why do I even need Cloudflare? Isn’t SSL the main goal?”

Here’s the reality

Cloudflare ≠ just SSL. It’s much more:

• Extra Layer of SSL → Even if Hostinger handles SSL, Cloudflare ensures your visitors get HTTPS instantly without waiting for setup.

• DDoS Protection → Shields your site if someone floods it with fake traffic.

• CDN (Content Delivery Network) → Cloudflare has servers worldwide. Visitors get your site from the nearest Cloudflare location, so it loads faster.

• Firewall & Security → Blocks bots, attackers, and suspicious requests before they even hit your Hostinger server.

• Free Extras → Like Always Online (shows cached version if your site is down).

So think of it this way:

• Hostinger SSL = Your server has a lock on its door.

• Cloudflare SSL + Features = A security guard at the gate + faster delivery service + backup plan.

That’s why we can keep Cloudflare even though Hostinger already provides SSL.

Testing My SSL

I ran my domain on SSL Labs Test and got a B rating.
That means my setup works, but there are still optimizations I can do later (A+ is the best)

It turned into a fun learning journey where I not only connected my domain but also finally understood what all these “DNS records” mean. Here’s the full story — step by step, just like I did it.

Step 1: Buying the Domain

I started with Hostinger because it had cheap domains. I bought jaivardhan.online. At this point, I thought, “Okay, cool, I own a website name.” But I soon realized: a domain is just a name — it doesn’t do anything by itself.

If I wanted to connect it to a server, add SSL, or protect it, I needed to manage its DNS (Domain Name System). And that’s where Cloudflare came in.

Step 2: Adding My Domain to Cloudflare

I created a free account on Cloudflare. The first thing Cloudflare asked was: What’s your domain?
So I typed in jaivardhan.online.

Cloudflare then gave me three options:

1. Scan existing DNS records automatically

2. Enter them manually

3. Upload a DNS file

I picked automatic scan, because why make life harder?

Within a few seconds, Cloudflare pulled in all the DNS records that were already on Hostinger. I was surprised at how many things were there.

Step 3: Understanding the DNS Records

When Cloudflare scanned my domain, here’s what I saw:

• 1 A Record → This was the main one pointing to my server’s IP (the “home address” of my website).

• 1 AAAA Record → Same as the A record, but for IPv6.

• 12 CAA Records → These were for SSL certificate providers. I didn’t know why there were so many.

• 1 CNAME Record → This pointed www.jaivardhan.online to jaivardhan.online.

• 2 NS Records → These were Hostinger’s default nameservers.

At first, this looked scary. But step by step, I figured them out:

• The A Record is the most important — it connects your domain to your server.

• The CNAME is just an alias (www → main domain).

• The CAA Records tell which companies are allowed to issue SSL certificates for your domain. But since Cloudflare provides its own SSL for free, I didn’t need them.

• The NS Records (name servers) were Hostinger’s. But soon, I’d have to replace them with Cloudflare’s.

Step 4: Cleaning Up

I went back to Hostinger’s DNS panel and deleted all the CAA records, because they were unnecessary once I moved to Cloudflare.

Then I noticed something interesting: even after deleting them in Hostinger, Cloudflare’s dashboard was still showing those old records. That’s because Cloudflare had copied them during the scan.

So I deleted them from Cloudflare too. I also saw some yellow warning icons on the AAAA and CNAME records saying “not covered by SSL yet.” I didn’t panic — Cloudflare was just waiting for me to finish setup.

Step 5: Switching Name Servers to Cloudflare

Now came the big moment: actually giving Cloudflare control of my domain.

Cloudflare gave me two new name servers:

• noor.ns.cloudflare.com

• chase.ns.cloudflare.com

I went back to Hostinger → “Domain” → “Nameservers” → and replaced Hostinger’s default ones with these two.

This basically told the internet: “Hey, from now on, Cloudflare is the manager of my domain.”

After saving, Cloudflare showed me a message: “Waiting for nameserver changes… this can take up to 24 hours.”
That was a little disappointing, but I learned it’s normal. DNS takes time to update all over the world.

Step 6: Checking Propagation

While waiting, I got curious: how do I know if the change is working?

That’s when I found WhatsMyDNS.net . This site lets you check if your domain is pointing to the right IP across different countries.

When I entered jaivardhan.online, I saw green ticks all over the map with the IP . That number was my domain’s server IP address. (Honestly, I was so happy seeing that. It felt like my domain was alive across the globe!)

I also checked on ICANN Lookup . and it confirmed my domain was now using Cloudflare’s nameservers (noor and chase). Success!

At the start, I thought moving my domain would just be clicking a few buttons. But it turned into a really useful exercise. I not only connected my Hostinger domain to Cloudflare but also learned the meaning of DNS records, what name servers do, and why SSL matters.

Minikube (Local Setup)

Best for beginners / local testing.

• Runs Kubernetes on your laptop (inside VM or Docker).

• Designed for learning and experimenting.

• You get 1 Node cluster (Control Plane + Worker on same machine).

• Very easy setup:

• But not production-grade.

Use case:

• Learning

• Running sample apps

• Small dev environment

Kubeadm (Self-Hosted Setup)

Best for hands-on understanding of real cluster setup.

• You provision real servers/VMs (on-prem or cloud, e.g., EC2).

• One machine = Control Plane (master)

• Other machines = Worker Nodes

• You run kubeadm init on master, and kubeadm join on workers.

• You manage everything yourself:

  • Installing Kubernetes components

  • Networking (CNI plugin like Flannel, Weave, Calico)

  • Upgrades

  • Security patches

Use case:

• Learning production-like setup

• Lab environments for deep understanding

• When you want full control

Cloud Managed Kubernetes (EKS, AKS, GKE)

Best for production.

• Here, cloud providers manage the Control Plane (master).

• You only manage Worker Nodes and Pods.

• Example:

  • EKS = Amazon Elastic Kubernetes Service

  • AKS = Azure Kubernetes Service

  • GKE = Google Kubernetes Engine

• Provider handles:

  • Control Plane HA & upgrades

  • etcd database backups

  • API server scaling

• You handle:

  • Worker nodes (sometimes even these can be auto-managed)

  • Deployments, Services, Ingress, monitoring

Use case:

• Enterprise production clusters

• High availability, scalability, security

• Teams who don’t want to babysit the Control Plane

How to implement kubeadm on your cloud/local

Just open any cloud provider you use whether it maybe AWS/Azure/GCP be it anything, All you need to do is Just launch 3 Virtual Machines, In those 3 three machines one should be bigger and the rest should be smaller in configuration wise, The bigger one will be used for Master machine and the rest two will be used for node machines

In Master machine you need to setup the following things

1. Root User Validation – Ensures the script runs as root.

2. Swap Disable – Disable swap (K8s requirement).

3. Kernel Modules – Load overlay and br_netfilter.

4. Sysctl Configuration – Enable packet forwarding and bridge network rules.

5. Containerd Installation – Set SystemdCgroup = true for Kubernetes compatibility.

6. Kubernetes Installation – Install kubeadm, kubelet, and kubectl.

7. Cluster Initialization – Run kubeadm init.

8. Kubeconfig Setup – Configure kubeconfig for both root and a non-root user (default: ubuntu).

9. CNI Installation – Install Weave Net for pod networking.

10. Join Command Display – Print the command for workers to join the cluster.

In Node machine you need to do the following things

1. Root User Check

2. Swap Disable

3. Kernel Modules Load

4. Sysctl Setup

5. Containerd Installation

6. Kubernetes Installation

7. Join Cluster – Use the join command from the master node output.

You don’t need to worry about doing all these manually, There is a repository named K8-s-Architecture-Shell-Script in my Github where you can see the shell script and see the required instructions to be follow and setup your first k8s cluster

Kubernetes is just an orchestrator of containers, If you don’t know what are containers, you might feel nothing

With Docker you learn:

• How to package an app into a container (Dockerfile).

• How to run and manage containers (docker run, docker ps, docker exec).

• How to expose ports, map volumes, and define multiple services (docker-compose).

Once you’re comfortable with that, you’re ready to explore how Kubernetes scales this idea to hundreds or thousands of containers running across many machines.

What is Kubernetes?

Kubernetes (often called K8s) is a container orchestration platform.

It answers real-world questions like:

• How do I run containers across multiple machines?

• How do I restart containers automatically if they fail?

• How do I balance traffic between multiple container replicas?

• How do I update apps without downtime?

In short: Docker runs containers, Kubernetes manages them at scale.

🏛 Kubernetes Architecture (Deep Dive)

Let’s break the architecture into two sides:

• Control Plane → the brain of the cluster

• Worker Nodes/Nodes → the muscle that actually runs your containers in the form of Pods which are controlled by Control Place/Master Machine

Pod — The Smallest Unit

• A Pod is the smallest deployable object in Kubernetes.

• Think of a pod as a wrapper around one or more containers.

• Every pod gets:

  • A unique IP address in the cluster.

  • Optionally shared storage volumes.

  • Shared lifecycle (if pod dies, all containers inside die).

Example:
If you deploy an app in Tomcat container , then that container here can be referred to as pod, Most of the pods contains single container and at some times there might be multiple containers in a single pod

Node — The Worker Machine

• A Node is a physical or virtual machine in your cluster, like a VM in local cloud, or an EC2 instance in AWS or a Azure VM in Azure

• It runs pods assigned by the control plane(Master Machine).

• Each Node has three main components:

  • Kubelet → agent that talks to control plane and manages pods(receives instruction from Master Machine and implement them in Nodes)

  • Container Runtime (Docker, containerd, CRI-O) → actually runs the containers.

  • Kube-proxy → handles pod-to-pod networking and load balancing.

Example:
A Node could run 5 Nginx pods + 3 Redis pods.

Cluster — Group of Nodes

• A Cluster = control plane + worker nodes.

• From your perspective, you don’t care which specific machine your app runs on — you just tell Kubernetes “I want 5 replicas” and the cluster ensures it happens.

Example:
Your cluster may have 3 Nodes. Kubernetes decides how to spread 10 Pods across them.

Control Plane — The Brain

The Control Plane makes global decisions about the cluster. It ensures the actual state matches your desired state.

Components of the control plane:

• API Server

  • The front door.

  • Every request (kubectl apply, kubectl get pods) goes here.

  • Exposes Kubernetes API.

• etcd

  • A distributed key-value store.

  • Stores the cluster’s state (which pods exist, which nodes are alive, configs, etc.).

• Scheduler

  • Decides where new Pods should run.

  • Example: If Node A is overloaded, it sends new Pods to Node B.

• Controller Manager

  • Ensures the cluster state matches what you declared.

  • Example: If you said “3 replicas” and 1 pod dies, the controller recreates it.

Together, these components form the city government of Kubernetes, while worker nodes are the buildings running your workloads.

Namespace — Logical Separation

• A Namespace is like a folder inside your cluster. There will be multiple pods across multiple nodes so it is difficult to organise them, so namespace comes handy here

• Helps organize resources (dev, staging, prod). You can distribute you pods across these namespaces

• These namespaces are irrespective of nodes,

• You create pods in the dev namespace asking for 4 pods of various application containers.

  • Pod 1 → scheduled on Node 1

  • Pod 2 → scheduled on Node 2

  • Pod 3 → also on Node 2

  • Pod 4 → back on Node 1

All 4 Pods belong to the dev namespace, but they are spread across multiple Nodes.

# Run the Spring Boot app
docker run -d -p 8080:8080 --name springapp \
  --network jionetwork \
  -e MONGO_DB_HOSTNAME=mongo \
  -e MONGO_DB_USERNAME=devdb \
  -e MONGO_DB_PASSWORD=dev@123 \
  kkdevopsb5/springwebapp:1.0.0

# Run the MongoDB database
docker run -d --name mongo \
  --network jionetwork \
  -e MONGO_INITDB_ROOT_USERNAME=devdb \
  -e MONGO_INITDB_ROOT_PASSWORD=dev@123 \
  mongo

The app worked fine after running these. But inside my head, one big question popped up:

👉 Why exactly are we running these commands in this way?
How did the Spring Boot container know that the mongo container is the database?

At first, I thought it was magic. Later, after some digging, it made complete sense. Let me share what I discovered.

Step 1: Spring Boot Doesn’t Hardcode DB Configs

In the source code, I found this application.yaml:

spring:
  data:
    mongodb:
      host: ${MONGO_DB_HOSTNAME}
      port: 27017
      username: ${MONGO_DB_USERNAME}
      password: ${MONGO_DB_PASSWORD}
      database: users
      authentication-database: admin

Notice the ${...} placeholders.
Spring Boot expects environment variables to fill these values at runtime.

That’s why the tutor passed:

• -e MONGO_DB_HOSTNAME=mongo

• -e MONGO_DB_USERNAME=devdb

• -e MONGO_DB_PASSWORD=dev@123

Without these, the app wouldn’t know where the database lives or how to log in.

👉 Learning point: As DevOps, our job is not to code the app, but to read the config files (like application.yaml) and know what environment variables the app expects.

Step 2: Why mongo Instead of an IP Address?

This is where Docker networks come in.
Both containers were attached to the same custom network jionetwork.

In Docker, when you create a custom network:

• Every container in that network can talk to others by name, not IP.

• Docker runs an internal DNS resolver that maps names → container IPs.

So when Spring Boot tries to connect to mongo:27017, Docker resolves mongo to the real container IP behind the scenes.

Analogy: Calling a Friend

Think of it like calling a friend:

• Without Docker network → you must remember your friend’s phone number (IP address).

• With Docker network → you just say their name (e.g., “Call mongo”), and your phone (Docker DNS) automatically finds the correct number.

This makes things stable: even if MongoDB container restarts and gets a new IP, the name mongo still works.

Learning point: The whole purpose of Docker networks is to allow containers to communicate using names instead of IPs.

Step 3: Separation of Build vs Runtime

Another thing that confused me:
“Why doesn’t the Dockerfile mention Mongo anywhere?”

Then I realized:

• Dockerfile = build instructions (package the JAR, set workdir, expose port)

• docker run with -e = runtime instructions (which DB host, which credentials)

This separation is good practice. It means the same app image can be reused for:

• Local environment → maybe DB host = localhost

• Staging → DB host = mongo-staging

• Production → DB host = mongo-prod

All without rebuilding the image.

What I Wish I Knew Earlier

• Every framework has its own config system:

  • Spring Boot → application.yaml

  • Node.js → .env

  • Python Django/Flask → settings.py or .env

• As DevOps, you don’t need to write app logic, but you must know where to look for DB configs, ports, and credentials.

• Docker custom networks give you name-based communication, powered by Docker’s built-in DNS.

Final Takeaway

At first, I thought my tutor skipped details. But later I realized this is real-world learning:
In companies, no one explains every line. You get a repo and some commands, and it’s your job to retrospect and figure out:

• Why these environment variables?

• How do containers find each other?

• What’s handled at build time vs runtime?

And that reflection — the “why” behind the command — is what transforms you from just running Docker to actually understanding DevOps.

Tip for beginners like me:
Whenever you see docker run with -e flags, pause and check the app’s config files.
That’s where the missing link hides — and once you see it, the whole flow makes sense.

✨ That’s the story of how I learned that docker run isn’t just about starting a container — it’s about passing the right environment and letting Docker networking + DNS do the magic.

You have a fresh Ubuntu instance (e.g., 22.04).

You have sudo access as your normal user.

Step 1: Install required software

sudo apt update

sudo apt install openjdk-17-jdk wget unzip ntp -y

Why:

• openjdk-17-jdk → Java 17, required by SonarQube.

• wget → to download SonarQube.

• unzip → to extract the .zip.

• ntp → keeps system clock synced (very important for token expiry, JWT, Elasticsearch timing).

Step 2: Find and confirm Java path (JAVA_HOME)

Find which Java was installed:

update-java-alternatives -l

Output looks like:

java-1.17.0-openjdk-amd64 1711 /usr/lib/jvm/java-1.17.0-openjdk-amd64

Use the part /usr/lib/jvm/java-1.17.0-openjdk-amd64 as JAVA_HOME.

(In most Ubuntu systems installed from apt, it usually is /usr/lib/jvm/java-17-openjdk-amd64.)

Verify Java works:

java -version

Should show:

openjdk version "17.x.x"

Step 3: Create a dedicated sonar user

sudo useradd -m -d /opt/sonarqube -U -r -s /bin/bash sonar

Why:

Step 4: Give sonar user sudo access without password

sudo visudo

At the end of the file, add:

sonar ALL=(ALL) NOPASSWD:ALL

Why:

• Allows sonar user to run any sudo command on any host.

• NOPASSWD → no password prompt.
  (handy in dev; risky in prod).

Step 5: Download and extract SonarQube

cd /opt

sudo wget https://binaries.sonarsource.com/Distribution/sonarqube/sonarqube-10.6.0.8109.zip

sudo unzip sonarqube-10.6.0.8109.zip

sudo mv sonarqube-10.6.0.8109/* /opt/sonarqube/

Why:

• /opt is standard for optional/3rd party apps.

• We move everything into /opt/sonarqube so it’s clean.

Step 6: Change ownership to sonar user

sudo chown -R sonar:sonar /opt/sonarqube

Why:

• Make sure sonar user can read/write all files.

• -R → recursive.

Step 7: Configure JAVA_HOME and PATH for sonar user

Switch to sonar user:

sudo su - sonar

Edit .bashrc:

echo 'export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64' >> ~/.bashrc

echo 'export PATH=$JAVA_HOME/bin:$PATH' >> ~/.bashrc

Then apply immediately:

source ~/.bashrc

Why:

• SonarQube scripts use Java.

• sonar user must know where Java is installed.

Verify:

java -version

Step 8: Set kernel and system parameters (important)

As your main sudo user (not sonar):

8.1 Increase max map count (needed by Elasticsearch inside SonarQube):

sudo nano /etc/sysctl.conf

Add:

vm.max_map_count=262144

fs.file-max=65536

Apply:

sudo sysctl -p

8.2 Increase user limits (number of open files and processes):

sudo nano /etc/security/limits.conf

Add:

sonar - nofile 65536

sonar - nproc 4096

Why:

Step 9: Enable and start NTP (time sync)

Why: Elasticsearch uses tokens with expiry; time drift can break login or cause cluster errors.

sudo systemctl enable ntp

sudo systemctl start ntp

timedatectl status

Make sure it says NTP synchronized: yes.(if you find some error and this line means just leave that error its due to some depreciated packages)

Step 10: Start SonarQube

Switch to sonar user:

sudo su - sonar

Start:

cd /opt/sonarqube/bin/linux-x86-64

./sonar.sh start

Check status:

./sonar.sh status

Step 11: Access SonarQube UI

• Open browser:

http://<your-server-ip>:9000

Default login:

• Username: admin

• Password: admin (you’ll be asked to change).

  

  After Successful Login It prompts you to change the default password, Change it and you are good to go !