Podman: The Complete Guide to Rootless, Daemonless Containers

Podman is an open-source container engine designed to build, run, manage, and deploy OCI containers and pods. It provides a Docker-compatible CLI experience while taking a fundamentally different approach: Podman is daemonless and can run containers rootlessly as a regular Linux user.

For developers, DevOps engineers, SREs, platform engineers, and administrators, Podman is particularly interesting when you want containerization without depending on a permanently running privileged daemon.

---

1. What is Podman?

Podman originally stands for Pod Manager.

It provides commands for:

• Running containers
• Building images
• Managing images
• Managing pods
• Creating networks
• Managing volumes
• Running containers without root
• Integrating containers with systemd
• Running Kubernetes YAML locally
• Working with OCI-compatible images and runtimes

A major design characteristic is that Podman is daemonless. Unlike the traditional Docker architecture, there isn't a central Docker daemon that all local container operations must go through.

Conceptually:

Traditional Docker-style model

User
  |
  v
Docker CLI
  |
  v
Docker Daemon
  |
  +---- Container
  +---- Container
  +---- Image
  +---- Network

Podman:

User
  |
  v
Podman CLI
  |
  +---- Container
  +---- Container
  +---- Pod
  +---- Image
  +---- Network

That architectural difference becomes especially important for rootless containers and systemd-based deployments.

---

2. Podman vs Docker

HashiCorp Nomad: A Comprehensive Guide to Workload Orchestration

HashiCorp Nomad is a distributed workload orchestrator designed to deploy and manage containers, batch jobs, long-running services, legacy applications, and other workloads across clusters of machines.

If Docker answers:

“How do I run this container?”

and Kubernetes answers:

“How do I orchestrate containers across a cluster?”

Nomad takes a somewhat broader and simpler approach:

“How do I schedule and operate different kinds of workloads across my infrastructure?”

Nomad can run Docker containers, binaries, Java applications, QEMU workloads, and other task-driver-based workloads. HashiCorp describes it as a highly available, distributed, datacenter-aware scheduler designed for services, batch jobs, and more.

---

1. What Is HashiCorp Nomad?

Nomad is a cluster scheduler and workload orchestrator developed by HashiCorp.

Its core responsibilities include:

• Scheduling workloads
• Allocating CPU and memory
• Placing workloads on appropriate nodes
• Running long-lived services
• Running batch jobs
• Running jobs on every node
• Handling workload failures
• Rolling out updates
• Managing task lifecycle
• Service registration
• Integrating with Consul
• Integrating with Vault
• Supporting multiple datacenters
• Supporting heterogeneous workloads

A simplified architecture is:

                    NOMAD
                      │
             ┌────────┴────────┐
             │                 │
        Nomad Servers      Nomad Clients
             │                 │
        Scheduling         Run workloads
        Cluster State      Containers
        Coordination       Binaries
             │             Batch jobs
             │             Services
             ▼
          Allocations

Nomad's servers handle scheduling and cluster management, while clients execute the workloads assigned to them.

---

2. Why Nomad?

Traditional application deployment might look like:

Server 1 → Application A
Server 2 → Application B
Server 3 → Application C
Server 4 → Application D

As infrastructure grows, you need to answer:

• Where should an application run?
• Does the server have enough CPU?
• Does it have enough memory?
• Does it have the required runtime?
• What happens if the server fails?
• How do we deploy five copies?
• How do we update them?
• How do we run a job every night?
• How do we deploy something to every node?
• How do services discover each other?

Nomad provides a scheduling and reconciliation layer.

Desired State
      │
      ▼
   Nomad Job
      │
      ▼
   Scheduler
      │
      ▼
 Allocation Plan
      │
      ▼
 Nomad Clients
      │
      ▼
 Workloads

---

3. Nomad vs Kubernetes

Kubernetes: A Comprehensive Guide to Containers, Pods, Deployments, Services, Networking, Storage, Security & Production

 Kubernetes has become one of the most widely used platforms for running containerized applications at scale.

Docker makes it relatively easy to build and run containers.

Kubernetes answers the much larger question:

What happens when you have hundreds or thousands of containers running across multiple servers and those applications need to be deployed, scaled, monitored, updated, and recovered automatically?

Kubernetes provides an orchestration layer for that problem.

This guide starts with the fundamentals and progresses toward production architecture, networking, storage, security, troubleshooting, and real-world deployment patterns.

---

1. What Is Kubernetes?

Kubernetes, often abbreviated as K8s, is an open-source container orchestration platform.

It helps automate:

• Container deployment
• Scheduling
• Scaling
• Service discovery
• Load balancing
• Rolling updates
• Rollbacks
• Self-healing
• Configuration management
• Secret management
• Storage orchestration
• Workload placement

Without Kubernetes, you might manually manage:

Server 1
 ├── Container A
 ├── Container B
 └── Container C

Server 2
 ├── Container D
 ├── Container E
 └── Container F

Server 3
 ├── Container G
 └── Container H

Kubernetes turns this into a cluster that can manage workloads declaratively.

                  Kubernetes Cluster
                         │
        ┌────────────────┼────────────────┐
        ▼                ▼                ▼
      Node 1            Node 2            Node 3
        │                │                │
      Pods             Pods             Pods

---

2. Why Do We Need Kubernetes?

Imagine you have an application with:

Frontend
Backend API
Authentication
Payment
Redis
PostgreSQL
Kafka
Workers
Monitoring

Initially you might run:

10 containers

Then your application grows:

100 containers

Eventually:

1,000+ containers

Now several questions appear:

• Which server should run each container?
• What happens if a server fails?
• What happens if a container crashes?
• How do we deploy a new application version?
• How do we roll back?
• How do we expose applications to users?
• How do containers discover each other?
• How do we scale based on traffic?
• How do we manage configuration?
• How do we attach persistent storage?

Kubernetes automates many of these operations.

---

3. Kubernetes vs Docker

This distinction is extremely important.

Docker

Docker primarily provides container tooling:

Build image
    ↓
Store image
    ↓
Run container

Kubernetes

Kubernetes orchestrates containerized workloads:

Deploy
   ↓
Schedule
   ↓
Run
   ↓
Monitor
   ↓
Scale
   ↓
Replace failed workloads
   ↓
Update
   ↓
Rollback

A simplified relationship:

Docker / Build Tools
        │
        ▼
Container Image
        │
        ▼
Container Runtime
        │
        ▼
Kubernetes
        │
        ├── Scheduling
        ├── Networking
        ├── Scaling
        ├── Storage
        ├── Self-healing
        └── Deployments

Modern Kubernetes clusters commonly use containerd or another Kubernetes-compatible container runtime. Docker Engine itself is no longer required as Kubernetes' runtime.

---

4. Kubernetes Architecture

A Kubernetes cluster has two major conceptual parts:

Control Plane
      │
      ▼
Worker Nodes

For example:

                 Kubernetes Cluster
                         │
              ┌──────────┴──────────┐
              │                     │
         Control Plane          Worker Nodes
              │              ┌──────┼──────┐
              │              │      │      │
              ▼              ▼      ▼      ▼
         API Server         Node   Node   Node
         etcd
         Scheduler
         Controllers

---

5. Control Plane

Docker: A Comprehensive Guide to Containers, Images, Dockerfiles, Networking, Volumes, Compose, Security & Production

Docker has fundamentally changed how applications are developed, packaged, deployed, and operated.

Before containers became mainstream, deploying an application often meant dealing with differences between development, testing, staging, and production environments:

“It works on my machine.”

Docker's answer is simple:

Package the application together with its dependencies and run it consistently wherever Docker is available.

But Docker is much more than a command-line tool for running containers. It is an ecosystem involving images, containers, registries, networking, storage, Dockerfiles, Docker Compose, security, resource management, observability, and deployment strategies.

This guide takes you from Docker fundamentals to production-oriented concepts.

---

1. What Is Docker?

Docker is a platform for developing, packaging, distributing, and running applications using containers.

A container packages:

• Application code
• Runtime
• Libraries
• System utilities
• Configuration
• Dependencies

into an isolated execution environment.

Unlike a traditional virtual machine, a container normally does not contain an entire guest operating system.

Traditional VM

Physical Server
│
├── Hypervisor
│
├── VM 1
│   ├── Guest OS
│   └── Application
│
├── VM 2
│   ├── Guest OS
│   └── Application
│
└── VM 3
    ├── Guest OS
    └── Application

Docker containers

Physical Server
│
├── Linux Kernel
│
├── Docker Engine
│
├── Container 1
│   └── Application
│
├── Container 2
│   └── Application
│
└── Container 3
    └── Application

Containers share the host kernel, which generally makes them lighter and faster to start than full virtual machines.

---

2. Why Docker Became So Popular

Consider a Python application.

Your developer has:

Python 3.12
Flask 3.x
Requests
NumPy
PostgreSQL client

But production has:

Python 3.10
Older libraries
Different OS packages
Different environment variables
Different system configuration

The application works perfectly in development but fails in production.

Docker lets you define the environment explicitly.

Application
     +
Dependencies
     +
Runtime
     +
Configuration
     ↓
Docker Image
     ↓
Container

The same image can then be used across environments.

Developer Laptop
       ↓
      Test
       ↓
    Staging
       ↓
   Production

This improves consistency and simplifies deployment.

---

3. Docker vs Virtual Machines

Docker containers and virtual machines solve related but different problems.

Feature	Containers	Virtual Machines
Virtualization	OS-level	Hardware-level
Guest OS	Usually no	Yes
Startup	Usually seconds or less	Usually slower
Resource overhead	Low	Higher
Isolation	Process/kernel mechanisms	Stronger hardware/OS boundary
Density	High	Lower
Typical use	Microservices, CI/CD, applications	Full OS isolation, legacy workloads

A container is not simply a lightweight VM.

That distinction matters.

---

4. Docker Architecture

The Docker ecosystem can be understood through several components.

                 Docker CLI
                    │
                    ▼
              Docker Engine
                    │
          ┌─────────┼─────────┐
          ▼         ▼         ▼
       Images   Containers  Networks
                    │
                    ▼
                 Volumes

The major pieces are:

Docker CLI

The command-line interface used to interact with Docker.

Example:

docker ps

Docker Engine

The engine responsible for creating and managing containers, images, networks, volumes, and related resources.

Docker Image

A read-only template used to create containers.

Docker Container

A running or stopped instance created from an image.

Docker Registry

A repository for storing and distributing images.

Examples include Docker Hub and private registries.

Docker Compose

A tool for defining and running multi-container applications.

---

5. Docker Images

A Docker image is essentially a packaged filesystem and metadata used to create containers.

For example:

ubuntu
nginx
redis
postgres
python
node

You can download an image using:

docker pull nginx

Then list images:

docker images

or:

docker image ls

---

6. Image Layers