© Faisal Memon | EmbarkX.

com

Full Stack AI DevOps for Software Developers

(AWS, Azure, GCP)

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]
Usage Policy for Course Materials

Instructor: Faisal Memon

Company: [Link]

1. Personal Use Only

The materials provided in this course, including but not limited to PDF presentations, are intended for your personal use only. They are to be
used solely for the purpose of learning and completing this course.

2. No Unauthorized Sharing or Distribution

You are not permitted to share, distribute, or publicly post any course materials on any websites, social media platforms, or other public
forums without prior written consent from the instructor.

3. Intellectual Property
All course materials are protected by copyright laws and are the intellectual property of Faisal Memon and EmbarkX. Unauthorized use,
reproduction, or distribution of these materials is strictly prohibited.

4. Reporting Violations
If you become aware of any unauthorized sharing or distribution of course materials, please report it immediately to
[embarkxofficial@[Link]].

5. Legal Action
We reserve the right to take legal action against individuals or entities found to be violating this usage policy.

Thank you for respecting these guidelines and helping us maintain the integrity of our course materials.

Contact Information
embarkxofficial@[Link]
[Link]
 © Faisal Memon | [Link]

The Ultimate Java and Spring Boot Mastery

Welcome to your one-stop-shop for mastering Java and Spring Boot! This repository offers a comprehensive
learning experience with high-quality resources and community support. Dive into over 150+ hours of
premium content, with everything you need to excel at Java and Spring Boot development.

🎓 Learning Roadmap
Most of the courses below are available in Udemy For Business, so if you have subscription - you can get
FREE access. Here’s a structured path to enhance your skills with detailed courses available:
1. Spring Boot Full Stack By Building eCommerce Application Step by Step (90+ Hours of Content)
2. Master Spring Boot Microservices (70+ Hours of Content)
3. Learn Java with 60+ Hours of Content (60+ Hours of Content)
4. Master Spring Security with React JS + OAuth2 (34+ Hours of Content)
5. Master IntelliJ IDEA (3+ Hours of Content)

🌟 With All Our Courses You Gain Access To

● 📝 Notes: Detailed and downloadable notes to accompany each lesson.
● 💻 Source Code: Full access to the source code used in the tutorials.
● 🤔 Doubt Solving: Responsive instructor and community support.
● 🎥 High-Quality HD Videos: Easy to understand, high-definition video tutorials.
● 🔄 Free Lifetime Updates: Continuous updates to course content at no extra cost.
 © Faisal Memon | [Link]

Introduction to Docker

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Shared Environment

CODE <> COMMIT &

COMMIT &
PUSH
PUSH

JOHN UPDATES
A LIBRARY

SARAH JOHN
 © Faisal Memon | [Link]

Welcome Docker
 © Faisal Memon | [Link]

Shared Environment

CODE <>
 © Faisal Memon | [Link]

Shared Environment

CODE <>

Includes the application code, its

dependencies, and the required
environment configuration
 © Faisal Memon | [Link]

Shared Environment

CODE <> COMMIT &

COMMIT &
PUSH
PUSH

CODE <>

SARAH JOHN
 © Faisal Memon | [Link]

Shared Environment

CODE <> COMMIT &

COMMIT &
CODE <> PUSH
PUSH

CODE <> CODE <>

SARAH JOHN
 © Faisal Memon | [Link]

Let’s Define Docker

Docker is an open-source platform that allows you to automate the
deployment, scaling, and management of applications using
containerization
 © Faisal Memon | [Link]

Docker Container

CODE <>
RUNTIME
LIBRARIES
SYSTEM TOOLS
 © Faisal Memon | [Link]

Virtual Machines
→ VMs act like separate computers inside your computer

→ Each virtual machine behaves like a separate computer

→ Virtual machines are created and managed by virtualization software

→ They provide a flexible and scalable way to utilize hardware resources

 © Faisal Memon | [Link]

Docker over VM’s

App A App B App B

Libs / Bins Libs / Bins Libs / Bins App A App B App B

Guest OS Guest OS Guest OS Libs / Bins Libs / Bins Libs / Bins

Hypervisor Docker Engine

Host OS Host OS

Machine Machine
 © Faisal Memon | [Link]

Parameters Virtual Machines (VMs) Docker Containers

Relatively large and Lightweight and
Size
resource-intensive resource-efficient
Longer boot time as full OS Almost instant startup as no
Startup Time
needs to start OS boot required
Resource Utilizes more system Utilizes fewer system
Utilization resources (CPU, memory) resources
Strong isolation between Isolated, but shares host OS
Isolation
VMs kernel
Portable, but requires OS Highly portable, independent
Portability
compatibility of host OS
 © Faisal Memon | [Link]

Parameters Virtual Machines (VMs) Docker Containers

Scaling requires provisioning Easy to scale by creating
Scalability
of new VMs more containers
VM-specific tools and Docker ecosystem with
Ecosystem
management frameworks extensive tooling
Development Slower setup and Faster setup and
Workflow provisioning process dependency management
Deployment More overhead due to larger Efficient deployment with
Efficiency VM size smaller container
 © Faisal Memon | [Link]

Docker Concepts

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

→ Images: Docker images are templates that define the

container and its dependencies.

→ Containers: Containers are runtime environments created

from Docker images.

→ Dockerfile: A Dockerfile is a file that contains instructions

to build a Docker image.
 © Faisal Memon | [Link]

Dockerfile

Image Running
Docker Image
definition Container
 © Faisal Memon | [Link]

Running
Container
Dockerfile

Image Running
Docker Image
definition Container

Running
Container
 © Faisal Memon | [Link]

→ Image Layer: Every image is made up of multiple layers

stacked on top of each other.

Layer 6

Layer 5

Layer 4
Docker Image
Layer 3

Layer 2

Layer 1
 © Faisal Memon | [Link]

→ Docker Registry: A Docker Registry is just a storage service

for Docker images.

Docker Image
h
pus

Docker Image

Image on your local

Docker Registry
machine
 © Faisal Memon | [Link]

→ Docker Tag: A tag is simply a name or label assigned to an

image version.

myapp:latest

myapp:v2

myapp:prod
 © Faisal Memon | [Link]

→ Docker Engine: The Docker Engine is the runtime that runs

and manages containers
 © Faisal Memon | [Link]

Docker Registries

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Docker Registry = stores your

container images
 © Faisal Memon | [Link]

Docker Architecture

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]
DOCKER ENGINE

Docker CLI

Docker API
Docker
Containers Docker
Registry
Docker
Daemon
Docker
Images

Host OS
 © Faisal Memon | [Link]

Docker

App A App B App B

CONTAINERS
Libs / Bins Libs / Bins Libs / Bins

Docker Engine

Host OS

Machine
 © Faisal Memon | [Link]

Port Mapping in Docker

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Port Mapping

localhost:8080

Browser on
Nginx (port:80)
host machine
-p host-port:container-port
 © Faisal Memon | [Link]

Container Lifecycle

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Create

Start

Stop

Restart

Remove
 © Faisal Memon | [Link]

Docker Image Tag &

Versioning

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Docker Tag: A tag is simply a name or label assigned to an

image version.

myapp:latest

myapp:v2

myapp:prod
 © Faisal Memon | [Link]

Docker Commands

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Image Commands
# Pull an image from a registry (Docker Hub by default)
docker pull <image-name>
# e.g.: docker pull nginx:latest

# List all images on your machine

docker images

# Remove an image (must not be used by any container)

docker rmi <image-id-or-image-name>

# Force remove image (even if in use — use carefully!)

docker rmi -f <image-id>

# Build an image from Dockerfile in current folder

docker build -t <username/image-name:tag> .
# e.g. docker build -t faisal/hello-node:1.0.0 .

# Tag an existing image (useful before pushing)

docker tag <source-image> <username/repo:tag>
# e.g. docker tag hello-node:latest faisal/hello-node:1.0.0
 © Faisal Memon | [Link]

Container Lifecycle Commands

# Create container but do NOT start it
docker create --name <container-name> <image>

# Start an existing container

docker start <container-id-or-name>

# Create AND start container (most used)

docker run <image>
# -> docker run = create + start

# Run container in interactive terminal mode

docker run -it <image>
# Use when testing inside container

# Run in detached mode (background)

docker run -d <image>
 © Faisal Memon | [Link]

Container Lifecycle Commands

# Run with port mapping
docker run -p <host-port>:<container-port> <image>
# e.g. docker run -p 8080:80 nginx

# Run with name + ports + detached

docker run -d --name <container-name> -p 3000:3000 <image>

# Stop a running container (graceful)

docker stop <container-id-or-name>

# Restart container
docker restart <container-id-or-name>

# Remove a stopped container

docker rm <container-id-or-name>

# Force remove a container (running or not)

docker rm -f <container-id-or-name>
 © Faisal Memon | [Link]

Inspecting & Debugging Containers

# View all running containers
docker ps

# View ALL containers (running + stopped)

docker ps -a

# Check container logs (useful for debugging)

docker logs <container-id-or-name>

# Follow logs in real-time

docker logs -f <container-id-or-name>

# Jump inside a running container

docker exec -it <container-name> bash
# If container doesn’t have bash, try:
docker exec -it <container-name> sh

# Inspect container details (ports, env, mounts, etc.)

docker inspect <container-id-or-name>
 © Faisal Memon | [Link]

Cleanup & Removing Everything

# Remove ALL stopped containers
docker container prune

# Remove ALL images not used by containers

docker image prune

# Remove all unused images, containers, networks, and build cache

docker system prune

# Remove EVERYTHING (images + containers + networks + cache)

docker system prune -a
# -a removes unused images too

# Remove all containers

docker rm $(docker ps -aq)

# Remove all images

docker rmi $(docker images -q)

# Remove all networks (not default ones)

docker network prune
 © Faisal Memon | [Link]

System Information Commands

# Docker version
docker --version
docker version

# Docker system-level info

docker info
 © Faisal Memon | [Link]

Understanding Dockerfile

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Image Layer: Every image is made up of multiple layers

stacked on top of each other.

Layer 6

Layer 5

Layer 4
Docker Image
Layer 3
1 layer = 1
Layer 2 instruction
Layer 1
 © Faisal Memon | [Link]

Dockerfile
FROM eclipse-temurin:21-jdk
WORKDIR /app
COPY target/*.jar [Link]
EXPOSE 8080
CMD ["java","-jar","[Link]"]
 © Faisal Memon | [Link]

Dockerfile
FROM eclipse-temurin:21-jdk
WORKDIR /app
COPY target/*.jar [Link]
EXPOSE 8080
CMD ["java","-jar","[Link]"]
 © Faisal Memon | [Link]

Dockerfile
FROM eclipse-temurin:21-jdk
WORKDIR /app
COPY target/*.jar [Link]
EXPOSE 8080
CMD ["java","-jar","[Link]"]
 © Faisal Memon | [Link]

Dockerfile
FROM eclipse-temurin:21-jdk
WORKDIR /app
COPY target/*.jar [Link]
EXPOSE 8080
CMD ["java","-jar","[Link]"]
 © Faisal Memon | [Link]

Dockerfile
FROM eclipse-temurin:21-jdk
WORKDIR /app
COPY target/*.jar [Link]
EXPOSE 8080
CMD ["java","-jar","[Link]"]
 © Faisal Memon | [Link]

Dockerfile
FROM eclipse-temurin:21-jdk
WORKDIR /app
COPY target/*.jar [Link]
EXPOSE 8080
CMD ["java","-jar","[Link]"]
 © Faisal Memon | [Link]

Essential Dockerfile Instructions

FROM — The Base Image

Sets the starting point for your container.
FROM node:20
FROM python:3.10
FROM openjdk:17-jdk

COPY — Bring Your App Code Into the Image

COPY moves your application files from your computer to the image. Without
COPY, your final image would be empty.
COPY . .
COPY [Link] .
COPY [Link] .
COPY target/[Link] [Link]
 © Faisal Memon | [Link]

Essential Dockerfile Instructions

RUN — Execute Commands During Image Build

RUN executes commands while building the image.
RUN npm install
RUN pip install -r [Link]
RUN ./mvnw clean package

CMD — What To Run When The Container Starts

CMD defines the default command that runs when your container starts.
CMD ["node", "[Link]"]
CMD ["python", "[Link]"]
CMD ["java", "-jar", "[Link]"]
 © Faisal Memon | [Link]

FROM eclipse-temurin:21-jdk
WORKDIR /app
COPY target/*.jar [Link]
EXPOSE 8080
Dockerfile for Spring Boot app
CMD ["java","-jar","[Link]"]

FROM python:3.10-slim
WORKDIR /app
COPY [Link] .
RUN pip install --no-cache-dir -r [Link] Dockerfile for Python app
COPY . .
EXPOSE 3000
CMD ["python", "[Link]"]

FROM node:18-slim
WORKDIR /app
COPY package*.json ./ Dockerfile for Node js app
RUN npm install --production
COPY . .
EXPOSE 3000
CMD ["node", "[Link]"]
 © Faisal Memon | [Link]

.dockerignore

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

docker build .
→ Docker sends your entire folder (called build context) to the Docker engine.

→ .dockerignore works exactly like .gitignore, but for Docker.

 © Faisal Memon | [Link]

Why .dockerignore is critical

→ Speeds up docker build

→ Makes images smaller

→ Prevents security issues

→ Avoids broken builds

 © Faisal Memon | [Link]

Using Environment Variables

in Containers

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Environment Variables: named values that store dynamic

data outside of your application code

DB_URL =
Docker Image
[Link]
 © Faisal Memon | [Link]

Docker Compose

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Docker Compose is a tool

for defining and running
multi-container applications
using a YAML file
 © Faisal Memon | [Link]

How many containers exist in

real-world production
grade apps?
 © Faisal Memon | [Link]

Typically
→ Frontend + API Gateway

→ Cache + Message Broker

→ Backend services (User, Order, Payment)

→ Database (PostgreSQL / MySQL)

→ Auth Server, Observability, Logging (ELK Stack)

 © Faisal Memon | [Link]

Life WITHOUT Docker Compose

docker run postgres
docker run redis
docker run kafka → Correct startup order
docker run user-service
docker run order-service → Correct networking
docker run payment-service → Correct environment variables
docker run frontend
docker run nginx → Correct ports
 © Faisal Memon | [Link]

Docker Compose Says

Here is my entire application stack.
Run it together. Stop it together.

Compose = Run multiple containers as ONE application

docker compose up
 © Faisal Memon | [Link]

Single Container VS Multi-Container

→ Just have one service running → Multiple services Frontend, Backend,

Database

→ Learning Docker basics, testing one service → This is how production grade apps function

→ Each service scales independently, each can

→ It’s a simple app with 1 service be written in different languages, matches real
production systems

→ Docker Compose not mandatory → Docker Compose mandatory to manage this

efficiently
 © Faisal Memon | [Link]

[Link]

services:
app:
image: my-backend-app A compose file describes:
ports: → What containers you need
- "8080:8080" → How they talk to each other
→ What ports they expose
db:
→ What environment variables they need
image: mysql
environment:
MYSQL_ROOT_PASSWORD: root
 © Faisal Memon | [Link]

Docker Compose Lifecycle

docker compose up
Starts everything. Creates network, starts containers in correct order, shows logs
in terminal

docker compose down

Stops and cleans up. Stops containers, removes containers, removes network

docker compose logs

View logs of all services. Debugging, teaching logs concept, showing errors live.
 © Faisal Memon | [Link]

Docker Compose Lifecycle

docker compose ps
See running services. Which containers are running, port mappings, status.
 © Faisal Memon | [Link]

Key Takeaways
→ Docker = runs one container

→ Docker Compose = runs multiple containers together

→ Compose uses a YAML file

up → start app
down → stop app
logs → debug
ps → inspect status
 © Faisal Memon | [Link]

How Many Containers Can a Production-Grade App Have?

Anywhere from 5 to 100+ containers
Netflix-scale systems → 1000s of containers (managed via Kubernetes)

App Type Containers

Small startup app 5-10

Medium SaaS 15-30

Large monolith + infra 20-40

Microservices system 50-200+

 © Faisal Memon | [Link]

Docker Networks

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Networks Created By Default

bridge

host

none
 © Faisal Memon | [Link]

bridge (the default network)

→ Any container you create without specifying a network goes here
automatically

→ Example: When you run “docker run nginx”, it connects to this bridge network

→ Containers can talk to each other using IP addresses, but not by container
names
 © Faisal Memon | [Link]

host
→ The container shares your computer's network directly

→ When you need maximum performance or want the container to act like it's
running directly on your machine

→ Container uses your computer's IP address

→ Ports are directly exposed on your machine

→ Use it when you need maximum network performance (no translation

overhead)
 © Faisal Memon | [Link]

none
→ A container with no network connection at all.

→ Security testing, Batch jobs, Work that need maximum security or isolation

→ No IP, No outbound / inbound traffic

 © Faisal Memon | [Link]

Understanding Our
Microservices

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Service A Service B

Frontend Price Tax

● Accepts amount and country ● Returns tax based on country

Frontend to input amount, code ● Accepts country code as IN, US,
country and get final price ● Returns final price based on tax in EU
as output country
● Gets the tax from Service B

GET /price?amount=100&country=IN GET /tax?country=IN

 © Faisal Memon | [Link]

Service A Service B

Frontend Price Tax

TAX_SERVICE_URL
VITE_API_URL
FRONTEND_URL
 © Faisal Memon | [Link]

What Is Kubernetes & Why It

Exists

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Docker solved “it works on my

machine” by packaging apps +
dependencies into containers.
 © Faisal Memon | [Link]

[Link]
WHAT HAPPENS IF?

→ A container crashes at 2 AM?

→ Traffic suddenly jumps 10×?
→ You need 5 instances of service-A?
Spring
Boot
→ One container runs on another
Frontend VM?
→ You deploy a new version without
downtime?

Python
 © Faisal Memon | [Link]

What is Orchestration?
Orchestration means automatically managing many containers
across machines — including running, scaling, networking, and
healing them.

Docker → runs one container

Orchestration → manages many containers together
 © Faisal Memon | [Link]

Chefs Dishes Kitchen Manager

 © Faisal Memon | [Link]

Orchestration is like a
manager coordinating
workers so work continues
smoothly even when things
go wrong.
 © Faisal Memon | [Link]

The Container Orchestration Problem

Problem Example

Container crashes Who restarts it?

Scaling How to run 10 copies?

Load balancing Which container gets traffic?

Service discovery How does service-A find service-B?

Zero downtime deploy How to update without outage?

Multi-machine setup Docker works per machine

Health checks How to detect broken containers?

 © Faisal Memon | [Link]

Kubernetes

Kubernetes is
A container orchestration platform that manages containers for you at scale.

→ Kubernetes automates deployment, scaling, healing, networking, and

management of containerized applications.
 © Faisal Memon | [Link]

Docker vs Kubernetes
Docker Kubernetes
Runs containers Manages containers
Single host focus Multi-node clusters
Manual scaling Auto scaling
Manual restart Self-healing
Manual networking Built-in service discovery

→ Docker is the engine

→ Kubernetes is the autopilot
 © Faisal Memon | [Link]

Without
Kubernetes
[Link] WHAT HAPPENS IF?

→ Nodejs service crashes

→ App breaks

Spring
Boot → Ops team wakes up
Frontend
→ SSH
→ restart container 😓

Python
 © Faisal Memon | [Link]

With
Kubernetes
[Link] KUBERNETES WILL

→ Detects crash
→ Restarts container
→ Maintains desired count (e.g. 3
replicas)
Spring
Boot
→ Routes traffic only to healthy pods
Frontend → Scales up/down based on load

👉 No human intervention needed

Python
 © Faisal Memon | [Link]

Key Problems Kubernetes Solves

Self-Healing: Container crashes?
→ Kubernetes restarts it automatically
→ If node dies → pod moves to another node
Scaling: Traffic spike?
→ replicas: 3 → 10
→ Manual or auto-scaling
→ Based on CPU / memory / metrics

Service Discovery & Networking

→ Instead of: [Link] , You get: [Link]
→ Built-in DNS
→ Stable service names
 © Faisal Memon | [Link]

Key Problems Kubernetes Solves

Zero-Downtime Deployments: Deploy v2 without breaking users
→ Rolling updates
→ Blue-Green / Canary deployments

Infrastructure Abstraction: Your app doesn’t care

→ Which VM? Which cloud? Which IP?
→ Kubernetes handles it.
 © Faisal Memon | [Link]

Why Every Company Uses Kubernetes

→ Because modern systems are:
Microservices-based, Cloud-native, Distributed, Always-on

→ Kubernetes gives:
Reliability, Scalability, Portability (AWS, GCP, Azure, on-prem)

→ That’s why:
Startups use it, Enterprises standardize on it, DevOps engineers must know it
 © Faisal Memon | [Link]

Docker packages applications.

Kubernetes runs and manages
them reliably at scale.
 © Faisal Memon | [Link]

History of Kubernetes

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

History of Kubernetes

The real problem (inside Google)

In the early 2000s, Google was running millions of applications (Search, Gmail,
YouTube). Manually managing servers was impossible.

Google built Borg (internal system)

Google built an internal system called Borg. Borg worked so well that Google ran
everything on it.

Containers became popular (Docker era 2013–2014)

Docker made containers easy for everyone but Docker could run containers. It
could NOT manage them at scale.
 © Faisal Memon | [Link]

History of Kubernetes

Kubernetes is born (2014)

Kubernetes = Borg ideas + containers + open source

Why Kubernetes exploded in popularity

Because it solved real production problems, worked on any cloud (AWS, GCP,
Azure), was open-source (no vendor lock-in)

Kubernetes was Donated

In 2015, Kubernetes was donated to Cloud Native Computing Foundation
(CNCF). This was done to ensure it was vendor-neutral and not controlled by a
single entity.
 © Faisal Memon | [Link]

History of Kubernetes

Kubernetes Today
→ Kubernetes is the industry standard
→ Almost every company uses it directly or indirectly
 © Faisal Memon | [Link]

What does K8s mean?

→ Kubernetes is long to say 😄 So engineers shorten it to:

K + 8 letters + s = K8s

Kubernetes = K8s
 © Faisal Memon | [Link]

Kubernetes started at Google to solve

large-scale container management
problems and became the global standard
for running applications reliably in
production.
 © Faisal Memon | [Link]

Kubernetes Architecture

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Kubernetes Cluster = Control Plane +

Worker Nodes
 © Faisal Memon | [Link]
CONTROL PANE

Controller
Scheduler etcd
Manager

API Server

POD 1 POD 1 POD 1 POD 1

Container 1 Container 1 Container 1 Container 1

Container 2 Container 2

Container Runtime Container Runtime

kubelet kube-proxy kubelet kube-proxy

Worker Node 1 Worker Node 2

 © Faisal Memon | [Link]

Control Plane → decides & manages

Worker Nodes → run your applications
 © Faisal Memon | [Link]

kubectl apply -f [Link]

API Server Desired Scheduler

receives state saved picks a
request in etcd worker node

Controller
Container kubelet
keeps
runtime runs creates the
watching &
container pod
fixing
 © Faisal Memon | [Link]

Setting Up k8s Locally

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Setting up k8s locally

Docker Desktop

Minikube

Kind
 © Faisal Memon | [Link]

Pods and Deployments

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Pod
→ The actual running app (container wrapped in Kubernetes layer)

→ Pod is where your app actually lives and runs.

→ It’s the smallest deployable unit in Kubernetes.

 © Faisal Memon | [Link]

Deployment
→ It runs your app continuously.

→ If the pod crashes, Kubernetes restarts it automatically.

→ If you want more copies (scaling), Deployment handles it.

→ If you want zero downtime updates, Deployment does rolling updates.

 © Faisal Memon | [Link]
CONTROL PANE

Controller
Scheduler etcd
Manager

API Server

POD 1 POD 1 POD 1 POD 1

Container 1 Container 1 Container 1 Container 1

Container 2 Container 2

Container Runtime Container Runtime

kubelet kube-proxy kubelet kube-proxy

Worker Node 1 Worker Node 2

 © Faisal Memon | [Link]

Deployment vs Controller Manager

→ Deployment is your instruction / desired state

→ Controller Manager (Deployment Controller) is the worker that makes it

happen

You create Controller Controller

API Server
Deployment Manager sees Manager
stores it
YAML it manages it
 © Faisal Memon | [Link]

Services in Kubernetes

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Service in k8s
Without a Service:
→ Your pod is NOT accessible
→ Your app is invisible outside the cluster
→ Every time pod restarts, new IP address is assigned & old connection breaks

What Service does:

→ Gives your app a permanent IP
→ Lets other apps inside the cluster talk to it
→ Lets you expose it to the browser (NodePort)

👉 Service = “Give my app a stable address so browsers and other apps can
reach it.”
 © Faisal Memon | [Link]

Service Types

ClusterIP

NodePort

LoadBalancer

ExternalName
 © Faisal Memon | [Link]

Service Types
ClusterIP (Default)
Exposes app inside the cluster only, won’t be accessible from browser. Useful
when - backend talking to backend & Microservices communication

NodePort
Exposes app on a node’s IP + port. Makes app accessible from browser. Port range
is of 30000–32767. Used generally for local testing, demos & learning
Kubernetes

LoadBalancer
Creates a cloud load balancer and gives public IP / DNS. Works best on Cloud
Services like AWS, GCP, Azure. Used majorly for production apps with real users
 © Faisal Memon | [Link]

Service Types

ExternalName
Maps Service to an external DNS. Example: [Link]
Used for external db or third party API.
 © Faisal Memon | [Link]

Summary

Type Accessible From When to Use

ClusterIP Inside cluster Microservices
NodePort Browser (IP:Port) Local / learning
LoadBalancer Public Internet Production
ExternalName External DNS Outside services
 © Faisal Memon | [Link]

Summary

Deployment → creates & manages Pods

Pod → runs your app (nginx)
Service → gives a stable connection to the Pod
NodePort → lets you access the Service from your laptop

Browser NodePort Service Pod Container

 © Faisal Memon | [Link]

Kubernetes on AWS Cloud

with Amazon EKS

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Kubernetes in Cloud

Amazon Elastic Kubernetes Service (EKS)

Google Kubernetes Engine (GKE)

Azure Kubernetes Service (AKS)

 © Faisal Memon | [Link]

Kubernetes on AWS
Means running Kubernetes using AWS infrastructure instead of
your own servers
 © Faisal Memon | [Link]

Kubernetes on AWS
→ AWS provides a managed Kubernetes service called Amazon Elastic
Kubernetes Service (EKS)

→ AWS runs the Kubernetes control plane for you

→ AWS handles availability, upgrades, security of K8s itself

 © Faisal Memon | [Link]

Why not run Kubernetes yourself?

Running Kubernetes Yourself = High operational burden

 © Faisal Memon | [Link]

Kubernetes on AWS

Your App (Containers) You talk to Kubernetes

Kubernetes (EKS) Kubernetes talks to AWS

AWS runs everything using its infrastructure (EC2,

AWS Infrastructure Networking, Load Balancers)
 © Faisal Memon | [Link]

Key AWS services involved

Amazon EC2
→ Virtual machines where your containers actually run

Amazon VPC
→ Private network for your cluster

AWS IAM
→ Who can access what (security)

Elastic Load Balancing

→ Exposes your app to the internet
 © Faisal Memon | [Link]

AWS Manages & You Manage

→ Kubernetes API Server
→ Your application containers
→ etcd (cluster data)
→ Kubernetes configs (Deployments,
→ High availability (multi-AZ) Services, etc.)

→ Control plane security & patches

→ and more…
 © Faisal Memon | [Link]

Things to know
→ Kubernetes is not AWS-specific

→ EKS is AWS’s managed way to run Kubernetes

→ Containers still run on VMs

→ Kubernetes orchestrates, AWS provides infra

 © Faisal Memon | [Link]

Clusters, Nodes with Local vs

Cloud K8s Setup

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Node & Clusters

Node
→ Node = one Virtual Machine
→ Node has CPU, Memory, Network, Runtime (container runtime)
→ Pods never run directly on cluster, they always run on a node
→ If node dies, pods on that node also die

Cluster
→ Cluster = control plane + one or more nodes
→ Cluster ≠ machine
→ Cluster can span 1 node or 1000 nodes
→ You deploy apps to the cluster, not to nodes directly
 © Faisal Memon | [Link]

Cluster

Node

Pods Pods Pods

Node

Pods Pods Pods

Node

Pods Pods Pods

 © Faisal Memon | [Link]

Local vs Cloud Setup

1 cluster → 1 node → many 1 cluster → many nodes →

pods many pods
 © Faisal Memon | [Link]

Understanding the Full Stack

Architecture with Microservices

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Full Stack
Architecture
/ Frontend

One
Browser Public URL
/api Service A Service B
 © Faisal Memon | [Link]

Ingress

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Ingress in Kubernetes is used to

expose multiple services to
external users in a clean, controlled
way using a single entry point.
 © Faisal Memon | [Link]

Ingress
Without Ingress
→ Every service needs its own LoadBalancer / NodePort
→ Expensive (cloud LB per service)
→ Hard to manage URLs

With Ingress
One Load Balancer
Smart HTTP/HTTPS routing to many services
Central place for TLS, auth, rate-limits
 © Faisal Memon | [Link]

What Ingress gives you

Single public endpoint

Path / host-based routing

Lower cloud cost

 © Faisal Memon | [Link]

Request Flow with Ingress

User Ingress Service Pod

 © Faisal Memon | [Link]

When you should use Ingress

When you don’t need it
→ Microservices
→ Single service
→ Single domain, many APIs
→ Local learning / quick
→ Production setups
demos
→ Need HTTPS + routing
 © Faisal Memon | [Link]

Ingress = HTTP/HTTPS traffic

manager for Kubernetes, sitting in
front of multiple services.
 © Faisal Memon | [Link]

Ingress Controller

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Ingress Controller is the actual

running software that reads
Ingress rules and handles real
HTTP traffic.
 © Faisal Memon | [Link]

Ingress Controller is…

→ A normal application

→ Running inside Kubernetes

→ Running as Pods

→ Is managed by a Deployment

→ Exposed via a Service

 © Faisal Memon | [Link]

What runs inside those Pods

A web
Controller
traffic
logic
engine
 © Faisal Memon | [Link]

Kubernetes doesn’t ship one by

default
 © Faisal Memon | [Link]

Understanding Ingress
Configurations

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Ingress Configuration
apiVersion: [Link]/v1
kind: Ingress
metadata:
name: simple-ingress
spec:
ingressClassName: nginx

rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: my-app
port:
number: 80
 © Faisal Memon | [Link]

How Traffic Flows

Ingress
my-app
Internet LoadBalancer Controller
service
Pod

my-app Pods
 © Faisal Memon | [Link]
apiVersion: [Link]/v1
kind: Ingress
metadata:
name: multi-service-ingress
spec:
ingressClassName: nginx Ingress with
rules:
- http:
paths:
Multiple
Services
# Backend API
- path: /api
pathType: Prefix
backend:
service:
name: backend
port: Example:
number: 80
GET /api/users → backend receives /api/users
# Frontend
- path: /
GET /about → frontend receives /about
pathType: Prefix
backend:
service:
name: frontend
port:
number: 80
 © Faisal Memon | [Link]
apiVersion: [Link]/v1
kind: Ingress
metadata:
name: rewrite-ingress
annotations:
# REQUIRED for regex paths
[Link]/use-regex: "true"
Ingress with Multiple
# Rewrite path using capture groups
[Link]/rewrite-target: /$1
Services, Regex &
spec:
ingressClassName: nginx
Rewriting Rules
rules:
- http:
paths:
- path: /api/(.*)
pathType: Prefix
backend:
service: EXAMPLE:
name: backend 1. Receives: GET /api/users
port:
number: 80 2. Checks rules (top to bottom)
3. Matches: /api/(.*)
- path: /(.*)
pathType: Prefix
4. Captures: "users" in $1
backend: 5. Applies rewrite-target: /$1
service: 6. Transforms to: GET /users
name: frontend
port: 7. Forwards to: service-a:80
number: 80
t
 © Faisal Memon | [Link]

Example Requests
User Request Matched Rule Captured ($1) Rewritten To Service

/api/users /api/(.*) users /users service-a

/api/products/5 /api/(.*) products/5 /products/5 service-a

/api/ /api/(.*) (empty) / service-a

/about /(.*) about /about frontend

/ /(.*) (empty) / frontend

/static/[Link] /(.*) static/[Link] /static/[Link] frontend

 © Faisal Memon | [Link]

Deploying Full Stack

Application on AWS EKS

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Request Flow in AWS EKS

Frontend [Link]
User / Service hello
Frontend Pod
Browser (Load (Kubernetes
Balancer) Service DNS)

Backend
Backend Pod Service
(ClusterIP)
 © Faisal Memon | [Link]

Before CI/CD

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Before CI/CD

Docker Registry
Test

Build app
Production

Build Docker Image

Verify

Push Docker Image

 © Faisal Memon | [Link]

Software Development Pipeline

Code Test Build Package Push Deploy Verify

 © Faisal Memon | [Link]

Before CI/CD
→ Manual Workflow

→ Human Dependency & Risk

→ Slow & Painful Feedback Loop

 © Faisal Memon | [Link]

Should growing team

trust humans every
time?
 © Faisal Memon | [Link]

Continuous Integration and

Continuous Deployment (CI/CD)

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Software Development Pipeline

Code Test Build Package Push Deploy Verify

 © Faisal Memon | [Link]

Software Development Pipeline

Code Test Build Package Push Deploy Verify

Continuous Integration

Continuous Integration ⇒ Every code change is automatically built and tested as

soon as it is pushed to the repository.
 © Faisal Memon | [Link]

Software Development Pipeline

Code Test Build Package Push Deploy Verify

Continuous Deployment

Continuous Integration ⇒ Every successful build is automatically deployed to an

environment without manual intervention.
 © Faisal Memon | [Link]

Manual vs CI/CD
In pre-CI/CD era, all these steps were:
→ Manually triggered
→ Inconsistent
→ Error-prone

This created:
→ Broken releases
→ Late feedback
→ Fear of deployments

→ CI/CD was created to automate this entire flow

 © Faisal Memon | [Link]

Before CI/CD, software quality

depended on human discipline,
not automation
 © Faisal Memon | [Link]

Understanding CI/CD
Pipelines & Pipeline Engines

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

A pipeline is a predefined sequence

of steps that run automatically to
take your code from developer to
production.
 © Faisal Memon | [Link]

Pipeline = Steps +
Order + Automation
 © Faisal Memon | [Link]

Jenkins & GitHub Actions are

tools that run pipelines.
 © Faisal Memon | [Link]

What Does a Pipeline Look Like?

pipeline:
trigger: code_push

stages:
- test
- build
- docker
- deploy
- verify
 © Faisal Memon | [Link]

CI/CD Fundamentals &

Terminology

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

CI/CD Fundamentals & Terminology

Workflows

Jobs

Steps

Runners
 © Faisal Memon | [Link]

CI/CD Fundamentals & Terminology

→ A workflow is the full automation process.

→ A job is a major task inside a workflow.

→ Steps are the individual commands inside a job.

→ A runner is the computer where your job runs.

 © Faisal Memon | [Link]

How They Fit Together

Workflow
├── Job (CI)
│ ├── Step 1: Checkout code
│ ├── Step 2: Run tests
│ └── Step 3: Build app
│
└── Job (CD)
├── Step 1: Deploy
└── Step 2: Verify
 © Faisal Memon | [Link]

Build & Test Build Image & Deploy

Step 1: Checkout code Step 1: Build Docker Image
Step 2: Run tests Step 2: Push Docker Image
Step 3: Build app Step 3: Deploy to Production

STEPS JOBS WORKFLOW

 © Faisal Memon | [Link]
What Really Happens?
Event Happens (Trigger)

Workflow Is Selected Runner Is Destroyed

Job Is Scheduled Job Finishes

Runner Is Provisioned Steps Execute on Runner

 © Faisal Memon | [Link]

Anatomy of a CI Pipeline

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]
Anatomy of CI Pipeline
name: Demo CI

on:
push

jobs:
build:
runs-on: ubuntu-latest

steps:
- name: Say Hello
run: echo "Hello from the second workflow!"
 © Faisal Memon | [Link]

name → Identity
name: Demo CI

on:
push

jobs:
build:
runs-on: ubuntu-latest

steps:
- name: Say Hello
run: echo "Hello from the second workflow!"
 © Faisal Memon | [Link]

on → Trigger
name: Demo CI

on:
push

jobs:
build:
runs-on: ubuntu-latest

steps:
- name: Say Hello
run: echo "Hello from the second workflow!"
 © Faisal Memon | [Link]

jobs → Work
name: Demo CI

on:
push

jobs:
build:
runs-on: ubuntu-latest

steps:
- name: Say Hello
run: echo "Hello from the second workflow!"
 © Faisal Memon | [Link]

steps → Actions
name: Demo CI

on:
push

jobs:
build:
runs-on: ubuntu-latest

steps:
- name: Say Hello
run: echo "Hello from the second workflow!"
 © Faisal Memon | [Link]

run / uses → Execution

name: Demo CI

on:
push

jobs:
build:
runs-on: ubuntu-latest

steps:
- name: Say Hello
run: echo "Hello from the second workflow!"
 © Faisal Memon | [Link]

Different Syntax, Same Meaning

on:
push

on:
push:
pull_request:

on:
push:
branches: ["working"]
pull_request:
branches: ["working"]
 © Faisal Memon | [Link]

Running Commands vs Using

Actions

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Every single step does only ONE of

two things

Run a command

Use a pre-built action

 © Faisal Memon | [Link]

Running a command
- name: Say Hello Create a Linux machine and run this command in its
run: echo "Hello from CI" terminal.

→ run executes shell commands

→ Same commands you run locally
→ Same syntax as Linux terminal

run: mvn test

run: npm install
run: docker build .
run: python [Link]
 © Faisal Memon | [Link]

Use a pre-built action

- name: Checkout Code
Run a pre-built automation written by someone else.
uses: actions/checkout@v4

→ You are NOT writing commands here.

→ You are reusing logic.
 © Faisal Memon | [Link]

What are these “pre-defined actions”?

→ Pre-defined actions = reusable automation packages

→ They are written by GitHub or the community, versioned (@v4), stored in

repositories, executed for you

actions/checkout@v4 # download your repo code

actions/setup-java@v4 # install Java
docker/login-action@v3 # login to Docker registry
actions/upload-artifact@v4
 © Faisal Memon | [Link]

Why do we even need uses? Why not just run?

Let’s take checkout as an example…

run: git clone [Link]

So github gives you:

uses: actions/checkout@v4
 © Faisal Memon | [Link]

The runner has NO CODE by default

→ GitHub creates a brand-new machine. That machine has no project code

- uses: actions/checkout@v4
- run: ls
 © Faisal Memon | [Link]

“run” and “uses” cannot be used together

Below is invalid
- name: Bad Step
run: echo "Hello"
uses: actions/checkout@v4

A step can only do one thing: Either run commands Or execute an action

Below is valid
steps:
- uses: actions/checkout@v4

- name: Build project

run: mvn clean package
 © Faisal Memon | [Link]

“run” vs. “use”

Use run when: Use uses when:

→ The command is specific → Task is common
to your project → Security matters
→ You control the logic → Setup is complex
→ It’s simple and → Best practices already
transparent exist
 © Faisal Memon | [Link]

Continuous Deployment (CD)

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

Software Development Pipeline

Code Test Build Package Push Deploy Verify

Continuous Deployment

Continuous Deployment ⇒ Every successful build is automatically deployed to

an environment without manual intervention.
 © Faisal Memon | [Link]

How CI/CD Talks to

Kubernetes

Faisal Memon (EmbarkX)

 © Faisal Memon | [Link]

kubeconfig is a config file that

tells kubectl how to connect to a
Kubernetes cluster.
 © Faisal Memon | [Link]

What’s inside a kubeconfig?

Cluster’s Information

Users Information & Credentials

Context Information
 © Faisal Memon | [Link]

Why do we use kubeconfig?

→ Switching Environments

→ Automation

→ Security

→ Ability to connect to clusters information

 © Faisal Memon | [Link]

Commands
kubectl config view

kubectl config current-context

kubectl config use-context <name>

 © Faisal Memon | [Link]

Default location

Linux / macOS: ~/.kube/config

Windows: %USERPROFILE%\.kube\config
 © Faisal Memon | [Link]

When is kubeconfig created?

Docker Desktop (local Kubernetes)

Automatically when you enable Kubernetes in Docker Desktop.

AWS (EKS)
When you create cluster, automatically - behind the scenes
 © Faisal Memon | [Link]

What happens inside GitHub Actions

→ A brand new VM

→ No memory

→ No files

→ No kubeconfig
 © Faisal Memon | [Link]

Create kubeconfig for CI/CD

aws eks update-kubeconfig --name <CLUSTER-NAME> --region ap-south-1

 © Faisal Memon | [Link]
Usage Policy for Course Materials

Instructor: Faisal Memon

Company: [Link]

1. Personal Use Only

The materials provided in this course, including but not limited to PDF presentations, are intended for your personal use only. They are to be
used solely for the purpose of learning and completing this course.

2. No Unauthorized Sharing or Distribution

You are not permitted to share, distribute, or publicly post any course materials on any websites, social media platforms, or other public
forums without prior written consent from the instructor.

3. Intellectual Property
All course materials are protected by copyright laws and are the intellectual property of Faisal Memon and EmbarkX. Unauthorized use,
reproduction, or distribution of these materials is strictly prohibited.

4. Reporting Violations
If you become aware of any unauthorized sharing or distribution of course materials, please report it immediately to
[embarkxofficial@[Link]].

5. Legal Action
We reserve the right to take legal action against individuals or entities found to be violating this usage policy.

Thank you for respecting these guidelines and helping us maintain the integrity of our course materials.

Contact Information
embarkxofficial@[Link]
[Link]
 © Faisal Memon | [Link]

If you think this course helped you, please do help provide an honest rating and
review of the course. Your insights help us improve and provide better content
for future learners.

We appreciate your support and look forward to hearing your thoughts!

 © Faisal Memon | [Link]

The Ultimate Java and Spring Boot Mastery

Welcome to your one-stop-shop for mastering Java and Spring Boot! This repository offers a comprehensive
learning experience with high-quality resources and community support. Dive into over 150+ hours of
premium content, with everything you need to excel at Java and Spring Boot development.

🎓 Learning Roadmap
Most of the courses below are available in Udemy For Business, so if you have subscription - you can get
FREE access. Here’s a structured path to enhance your skills with detailed courses available:
1. Spring Boot Full Stack By Building eCommerce Application Step by Step (90+ Hours of Content)
2. Master Spring Boot Microservices (70+ Hours of Content)
3. Learn Java with 60+ Hours of Content (60+ Hours of Content)
4. Master Spring Security with React JS + OAuth2 (34+ Hours of Content)
5. Master IntelliJ IDEA (3+ Hours of Content)

🌟 With All Our Courses You Gain Access To

● 📝 Notes: Detailed and downloadable notes to accompany each lesson.
● 💻 Source Code: Full access to the source code used in the tutorials.
● 🤔 Doubt Solving: Responsive instructor and community support.
● 🎥 High-Quality HD Videos: Easy to understand, high-definition video tutorials.
● 🔄 Free Lifetime Updates: Continuous updates to course content at no extra cost.