Containers and Containerization

What is a Container?

A container is a lightweight, standalone package that holds everything needed to run an application: the code, libraries, dependencies, and settings.

Example: Think of a tiffin box. It has rice, curry, roti, and pickle, so it's a complete meal. A container is the same: one package with everything the app needs.

Key Features

• Portable: Runs the same way on any environment

• Isolated: Each container works independently of the others

• Lightweight: Shares the host OS instead of needing a full virtual machine, so many containers can run on one machine

How Containers Work

1. A developer builds the app and packages it as a container.

2. The container runs on any system with Docker installed (Linux, Mac, or Windows).

3. Multiple containers can run on the same host, isolated from each other.

What is Containerization?

Containerization is the process of packaging an application with all its files and dependencies into a container.

Example: Someone likes your lunch. If you give them only the recipe, they may lack the same spices or stove, so the taste may differ. If you pack the food in a tiffin and give it to them, they get exactly the same taste.

Containerization works the same way. Instead of asking others to set up the app themselves, you hand them a ready-to-run package that behaves the same everywhere.

Benefits of Containerization

• Consistency: Works the same in development, testing, and production

• Efficiency: Uses fewer resources than traditional VMs

• Scalability: Easy to scale from a few to many containers, which suits microservices

• Rapid deployment: Speeds up the build, test, and deploy cycle.

Popular Tools

Tool	Purpose
Docker	Most widely used container platform
Kubernetes	Orchestration: manages and scales containers across many servers

containerd: Alternative container runtime

Docker remains the most popular tool, and its commands and concepts carry over to the other tools.

Quick Revision

• Container = App + dependencies in one package

• Containerization = The process of creating that package

• Why use it? Portable, isolated, lightweight, consistent

• Container vs VM: A container shares the host OS, while a VM needs a full OS of its own.

Virtual Machines vs Containers

What is a Virtual Machine (VM)?

A VM is a software copy of a physical computer. It runs a full operating system on virtual hardware, and a hypervisor manages it.

Example: Think of a big house (the physical machine) divided into apartments (the VMs).

• The hypervisor is the property dealer who splits the house into apartments.

• Each apartment (VM) has its own family with its own full setup (its own OS and software).

This makes VMs heavier than containers.

Key Components of a VM

• Guest OS: Separate from the host OS. The host can run Linux while VMs run Windows, Mac, Ubuntu, and so on.

• Virtual hardware: Virtual CPU, memory, and disk

• Hypervisor: Creates and manages VMs, for example VMware, Hyper-V, and KVM

VM Use Cases

• Running multiple operating systems on one machine

• Supporting legacy and monolithic applications

• Strong isolation for security, since each VM has its own OS

How Containers Differ

• Containers share the host OS kernel, so they need no guest OS.

• They only need a container engine like Docker Installed.

• This makes them lightweight, fast, and portable.

Architecture comparison:

• VM: Hardware → Host OS → Hypervisor → Guest OS → App

• Container: Hardware → Host OS → Docker → App

VM vs Container

Feature	Virtual Machine	Container
Operating system	Each VM has its own OS	Shares the host OS
Size	Heavy (GBs)	Lightweight (MBs)
Performance	Slower	Faster
Isolation	Stronger (hardware level)	Process level
Boot time	Minutes	Seconds
Resource usage	High	Low, so many containers fit on one machine
Portability	Less portable	Highly portable
Best for	Monolithic and legacy apps	Microservices and cloud-native apps

Quick Revision

• VM = A full computer inside a computer, with its own OS, managed by a hypervisor.

• Container = A lightweight package that shares the host OS and runs on Docker.

• VMs give stronger isolation but are heavy and slow to boot.

• Containers are light, fast, portable, and ideal for microservices.

Docker Architecture

Overview

• Docker uses a client-server architecture.

• The client is where you type commands.

• The server (Docker daemon) does the heavy work of building, running, and distributing containers.

Main Components

1. Docker Client

• The user interface you work with after installing Docker

• Sends commands like docker build, docker run, and docker pull to the Docker daemon

2. Docker Daemon (dockerd)

• The background service that runs on the host. The "d" stands for daemon, meaning a system process (like systemd).

• Listens for API requests from the client

• Builds, runs, and manages images and containers

• Handles the full container lifecycle

3. Docker Images

• Read-only templates used to create containers

• Can be downloaded from a registry (for example Ubuntu or Nginx)

• Custom images can be built using a Dockerfile.

4. Docker Containers

• Running instances of Docker Images

• Lightweight and isolated, and they hold the app plus its dependencies

• Example: A Node.js app container includes the npm dependencies it needs.

5. Docker Registry

• A storage place for Docker images, like an app store for images

• Can be public (such as Docker Hub) or private

• Commands: docker pull downloads an image, and docker push uploads one.

How It Works

Example: docker run ubuntu

1. The client sends the command to the daemon.

2. The daemon checks whether the Ubuntu Image exists locally.

3. If it doesn't, the daemon pulls it from the registry.

4. The daemon creates and starts a container from that image.

Quick Revision

Component	Role
Client	Where you type commands
Daemon	Background service that does the actual work
Image	Read-only template
Container	Running instance of an image
Registry	Storage for images (pull and push)

Key idea: The client sends commands, the daemon processes them, images create containers, and the registry stores images.

Installing Docker on AWS (Amazon Linux)

Docker can run on any cloud (AWS, Azure, GCP) because they all provide virtual servers that work the same way. These steps use AWS EC2 with Amazon Linux.

Step 1: Launch an EC2 Instance

1. Go to EC2→ Instances → Launch Instance

2. Name: Docker-Server

3. OS: Amazon Linux

4. Instance type: t2.micro) (free tier, no extra cost)

5. Key pair:
   Not needed if you connect through the browser.
   Needed if you connect remotely through PuTTY, Git Bash, or a terminal

6. Security group: Allow SSH (plus HTTP if needed)

7. Click Launch

Step 2: Allow Traffic (For Learning Only)

To avoid port issues while learning:

Instance → Security > Security Group → Edit Inbound Rules

Add rule: All Traffic

▲ This isn't a best practice. Once you understand ports, allow only the ones you need.

Step 3: Connect to the Server

Select instance → Connect → Connect (opens a terminal in the browser) or use putty to connect to server with .ppk file.

Step 4: Install Docker

sudo yum install docker

docker --version -y #Check installed version

At this point docker ps fails because the Docker service isn't running yet.

Step 5: Post-Installation Setup

sudo groupadd docker #Create the docker group

sudo usermod -aG docker ec2-user # Add user to docker group

sudo systemctl start docker # Start Docker now

sudo systemctl enable docker # Start Docker on every boot

sudo docker ps # Test with sudo (works immediately)

docker ps #Test without sudo (fails — and that's expected)

Step 6: Fix "Permission Denied"

If docker ps still shows permission denied:

newgrp docker #Log out and log back in (exit SSH/VM session and reconnect).

groups #Confirm the group was added 'docker'

docker ps #This should now work cleanly, with no permission errors.

Step 7: Verify

docker ps #Should run without errors

sudo systemctl status docker #Should show "active (running)"

Quick Revision

Task	Command
Install Docker	sudo yum install docker -y
Check version	docker --version
Add user to group	sudo usermod -aG docker ec2-user
Enable on boot	sudo systemctl enable docker
Start Docker	sudo systemctl start docker
Check status	sudo systemctl status docker
List containers	docker ps

How to Install Docker on Ubuntu Server

Step 1: Update the package index

sudo apt-get update

Refreshes your local package list so you get the latest available versions.

Step 2: Install Docker

sudo apt-get install docker.io -y

Installs Docker directly from Ubuntu's default repositories. (Note: this installs a slightly older, distro-packaged version of Docker. For the latest version, Docker's official repo/docker-ce package is the alternative — worth mentioning as an option in your post.)

Step 3: Start the Docker service

sudo systemctl start docker

Starts the Docker daemon immediately.

Step 4: Enable Docker on boot

sudo systemctl enable docker

Ensures Docker starts automatically every time the server reboots.

Step 5: Verify Docker is running

sudo systemctl status docker

Should show active (running) in green.

Step 6: Add your user to the docker group

sudo usermod -aG docker ubuntu

This lets you run docker commands without typing sudo every time. Replace ubuntu with your actual username if different.

Step 7: Test with sudo (works immediately)

sudo docker ps

This works right away since it uses elevated privileges.

Step 8: Test without sudo (fails — and that's expected)

docker ps

This will likely throw a permission denied error, because your current shell session hasn't picked up the new group membership yet.

Step 9: Refresh your group membership

Log out and log back in (exit SSH/VM session and reconnect), or run:

newgrp docker

as a quicker alternative that avoids a full logout.

Step 10: Confirm the group was added

groups

You should now see docker listed among your groups.

Step 11: Run Docker without sudo

docker ps

This should now work cleanly, with no permission errors.

Optional tip to add: mention that newgrp docker is a handy shortcut so readers don't have to fully log out during testing — but a real logout/login (or reboot) is the more reliable way to make sure the group change sticks across all future sessions