Forem: David Tio

Boot in Seconds: Cloud Images + cloud-init in Podman

David Tio — Wed, 15 Apr 2026 02:58:08 +0000

Boot in Seconds: Cloud Images + cloud-init

Quick one-liner: Skip the installer entirely — download a pre-built cloud image, seed it with cloud-init, and boot a fully configured VM in seconds.

💡 Why This Matters

Post #3 proved persistence works, but that interactive Alpine install took time. Download ISO, boot, run installer, answer prompts, wait, configure. Repeat that for every new VM and you'll spend more time installing than actually using them.

Cloud images solve this. They're pre-built disk images with an OS already installed. Ubuntu, Fedora, Debian, Rocky — they all publish ready-to-boot images. You download one, tell cloud-init your SSH key and username, and boot. No installer, no prompts, no waiting.

This post swaps the manual install for a cloud image. You'll download an Ubuntu cloud image, create a cloud-init seed, and boot straight into a configured VM.

📋 Prerequisites

qemu:base image from Post #1
~/vm directory from Post #3
genisoimage installed on your host (provides the mkisofs command)

📥 Step 1: Download a Cloud Image

Ubuntu publishes cloud images for every release. Grab the latest LTS (24.04 Noble Numbat):

$ cd ~/vm
$ curl -O https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img
$ ls -lh noble-server-cloudimg-amd64.img
-rw-rw-r-- 1 user user 650M Apr  1 12:00 noble-server-cloudimg-amd64.img

That 650 MB file is a complete Ubuntu 24.04 installation, ready to boot. No install needed.

🗺️ Where to Find Cloud Images

Most major Linux distributions publish cloud images. Here's where to get them:

Open Source Distributions

Distribution	Cloud Image Repository
Ubuntu	https://cloud-images.ubuntu.com/
Debian	https://cloud.debian.org/images/
Fedora	https://download.fedoraproject.org/pub/fedora/linux/releases/
CentOS Stream	https://cloud.centos.org/centos/
Rocky Linux	https://download.rockylinux.org/pub/rocky/9/images/x86_64/
AlmaLinux	https://repo.almalinux.org/almalinux/9/cloud/x86_64/images/
openSUSE	https://download.opensuse.org/tumbleweed/appliances/
Arch Linux	https://geo.mirror.pkgbuild.com/images/

Enterprise Distributions

Distribution	Cloud Image Repository	Access
RHEL	https://access.redhat.com/downloads/content/rhel	Subscription (free developer tier)
SLES	https://download.suse.com/	Account required (free trial available)
Oracle Linux	https://yum.oracle.com/oracle-linux-templates.html	Free
Amazon Linux	https://docs.aws.amazon.com/linux/al2023/ug/outside-ec2-download.html	Free

Format tips:

Look for qcow2 format — it's thin-provisioned and works best with QEMU/KVM
Some sites offer raw images (.img) — these work too but take more disk space
Avoid VMDK or VDI formats — those are for VMware and VirtualBox

Note: Alpine Linux offers cloud images but uses dynamic URLs based on provider, architecture, and firmware options. Visit https://alpinelinux.org/cloud/ to generate the correct download link.

⚙️ Step 2: Create a cloud-init Seed

cloud-init is the standard for first-boot VM configuration. It runs on the first boot, reads a small YAML file, and sets up users, SSH keys, hostnames, packages — whatever you tell it to.

🔑 Get Your SSH Public Key

Cloud images don't have passwords by default — they use SSH key authentication. You'll need a key pair to log in.

Check if you already have one:

$ ls -la ~/.ssh/id_ed25519.pub

If you see a file, skip ahead — you're set. If not, generate one. ed25519 is the modern standard: faster, smaller, and more secure than RSA:

$ ssh-keygen -t ed25519 -C "your-email@example.com"

Press Enter to accept the default location (~/.ssh/id_ed25519). Optionally set a passphrase for extra security.

Then grab your public key:

$ cat ~/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...your-key-here... your-email@example.com

Copy the entire line — you'll paste it into the user-data file below.

🔒 Creating a Hashed Password

Cloud images accept passwords in two formats: plain text (risky) or hashed (secure). We'll use a SHA-512 hash. Use read -s to enter your password without it appearing in shell history, then pipe it to openssl:

$ read -s -p "Password: " PW && echo && openssl passwd -6 "$PW" && unset PW
$6$randomsalt$hashedpasswordstring...

The -6 flag means SHA-512. The output starts with $6$ — that's the identifier. Copy the entire string.

📝 Build the user-data File

Create the user-data file for Ubuntu:

$ mkdir -p noble
$ cat > noble/user-data << 'EOF'
#cloud-config
preserve_hostname: false
hostname: kvmpodman
users:
  - name: sysadmin
    groups: sudo
    shell: /bin/bash
    ssh_authorized_keys:
      - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...your-key-here...
    lock_passwd: false
    passwd: '$6$randomsalt$your-hashed-password...'
runcmd:
  - echo "cloud-init completed" > /home/sysadmin/.cloud-init-done
EOF

Replace the SSH key with your own (cat ~/.ssh/id_ed25519.pub) and the passwd hash with the one you generated above.

This seed:

Sets the hostname to kvmpodman
Creates a user named sysadmin with sudo access
Enables password login (for console testing)
Leaves a marker file when cloud-init finishes

📄 Create meta-data

Create an empty meta-data file (required, but can be empty):

$ touch noble/meta-data

💿 Step 3: Build the cloud-init ISO

cloud-init reads its config from a CD-ROM attached to the VM. Use mkisofs to create a small ISO containing your seed files. Run this on your host, from ~/vm:

$ mkisofs -J -R -input-charset utf-8 -V cidata -o cloud-init-noble.iso noble/user-data noble/meta-data

You should see:

Total translation table size: 0
Total rockridge attributes bytes: 331
Total directory bytes: 0
Path table size(bytes): 10
Max brk space used 0
182 extents written (0 MB)

The -J flag enables Joliet extensions, -R adds Rock Ridge (Unix file permissions — this fixes the warning), and -V cidata sets the volume label to cidata — which is what cloud-init scans for on boot.

That small ISO contains your entire first-boot configuration.

🚀 Step 4: Boot the Cloud Image

Attach both the cloud image disk and the cloud-init ISO. The cloud image boots as normal, cloud-init detects the CD-ROM, and applies your seed on first boot:

$ podman run --rm -it \
    --device /dev/kvm \
    -v ~/vm:/vm:z \
    qemu:base \
    qemu-system-x86_64 \
        -enable-kvm -cpu host \
        -nographic \
        -m 1024 \
        -drive file=/vm/noble-server-cloudimg-amd64.img,format=qcow2 \
        -cdrom /vm/cloud-init-noble.iso \
        -boot c

The VM boots. Wait about 15-30 seconds for cloud-init to run. You'll see output like:

cloud-init 25.3-0ubuntu1~24.04.1 running 'modules:config' at Sat, 12 Apr 2026 12:34:56 +0000
cloud-init 25.3-0ubuntu1~24.04.1 running 'modules:final' at Sat, 12 Apr 2026 12:34:58 +0000
cloud-init 25.3-0ubuntu1~24.04.1 finished at Sat, 12 Apr 2026 12:35:02 +0000

Once you see finished, the VM is ready. Log in with the username and password you set:

kvmpodman login: sysadmin
Password:

Then shut down cleanly:

sysadmin@kvmpodman:~$ sudo poweroff

The container will exit automatically when the VM powers off, and the disk image persists.

✅ Step 5: Verify cloud-init Ran

Boot again, this time without the cloud-init ISO (it's only needed on first boot):

$ podman run --rm -it \
    --device /dev/kvm \
    -v ~/vm:/vm:z \
    qemu:base \
    qemu-system-x86_64 \
        -enable-kvm -cpu host \
        -nographic \
        -m 1024 \
        -drive file=/vm/noble-server-cloudimg-amd64.img,format=qcow2

sysadmin@kvmpodman:~$ sudo su -
[sudo] password for sysadmin: 
root@kvmpodman:~#

Check the disk layout:

root@kvmpodman:~# lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda       8:0    0  3.5G  0 disk 
├─sda1    8:1    0  2.5G  0 part /
├─sda14   8:14   0    4M  0 part 
├─sda15   8:15   0  106M  0 part /boot/efi
└─sda16 259:0    0  913M  0 part /boot

The cloud image is thin-provisioned — the disk is 3.5 GB total, with a 2.5 GB root partition, 913 MB for /boot, and 106 MB for EFI. The 4 MB sda14 is a BIOS boot partition (GRUB uses it on non-EFI boots). No swap is configured by default.

Memory-wise, this VM was given 1 GB (-m 1024), and Ubuntu reports about 961 MB available after kernel reservations.

Confirm cloud-init ran:

root@kvmpodman:~# cloud-init status
status: done

Then power off:

root@kvmpodman:~# poweroff

The container exits automatically when the VM shuts down, and the disk image persists.

🧪 Step 6: Mini Shootout — SLES 16 and Amazon Linux 2023

Cloud images skip the installer entirely, and cloud-init automates the rest of the setup. A working VM boots in seconds:

Method	Time to Working VM
Manual install (Post #3)	5-10 minutes
Cloud image + cloud-init (IDE/SATA)	~25s
Cloud image + cloud-init (VirtIO)	~10s

Ubuntu is the easy path. With a working VM in about 10 seconds, we have plenty of time to spin up different distributions and see how they compare. Let's try two I find interesting:

SLES 16 — enterprise Linux that rarely gets covered in tutorials. Most blog posts stop at RHEL or CentOS. SLES is what shops with a SUSE subscription actually run, and it's almost nowhere to be found in container or KVM content.

Amazon Linux 2023 — I know it exists, but I've never used it outside an EC2 instance. It's built exclusively for AWS, so booting it as a native KVM VM on my own hardware is something I've been curious about.

We'll download both, build cloud-init seeds for each, and boot with VirtIO.

📥 Download the Images

Head to the links in the table above and grab the qcow2 images for your distro:

SLES 16: SUSE Download Center — requires a free SUSE account. Look for SLES-16.0-Minimal-VM.x86_64-Cloud-GM.qcow2
Amazon Linux 2023: AWS Documentation — free, no account needed. Look for al2023-kvm-2023.10.20260325.0-kernel-6.1-x86_64.xfs.gpt.qcow2

Drop both files into ~/vm/.

⚙️ Build cloud-init Seeds

Create a directory for each distro:

$ mkdir -p sles16 al2023

SLES 16 — uses wheel group for sudo. SLES comments out %wheel in /etc/sudoers by default, so we need to uncomment it:

$ cat > sles16/user-data << 'EOF'
#cloud-config
preserve_hostname: false
hostname: kvmpodman
users:
  - name: sysadmin
    groups: wheel
    shell: /bin/bash
    ssh_authorized_keys:
      - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...your-key-here...
    lock_passwd: false
    passwd: '$6$randomsalt$your-hashed-password...'
runcmd:
  - sed -i 's/^#\s*%wheel\s*ALL=(ALL)\s*ALL\s*$/%wheel ALL=(ALL) ALL/' /etc/sudoers
  - echo "cloud-init completed" > /home/sysadmin/.cloud-init-done
EOF
$ touch sles16/meta-data

Amazon Linux 2023 — also uses wheel:

$ cat > al2023/user-data << 'EOF'
#cloud-config
preserve_hostname: false
hostname: kvmpodman
users:
  - name: sysadmin
    groups: wheel
    shell: /bin/bash
    ssh_authorized_keys:
      - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...your-key-here...
    lock_passwd: false
    passwd: '$6$randomsalt$your-hashed-password...'
runcmd:
  - echo "cloud-init completed" > /home/sysadmin/.cloud-init-done
EOF
$ touch al2023/meta-data

The SLES seed uses wheel and uncommented %wheel in /etc/sudoers. Amazon Linux also uses wheel but doesn't need the sed hack. The runcmd just leaves a marker file.

Build the ISOs on your host, from ~/vm:

$ mkisofs -J -R -input-charset utf-8 -V cidata -o cloud-init-sles.iso sles16/user-data sles16/meta-data
$ mkisofs -J -R -input-charset utf-8 -V cidata -o cloud-init-al2023.iso al2023/user-data al2023/meta-data

🚀 Boot

$ podman run --rm -it \
    --device /dev/kvm \
    -v ~/vm:/vm:z \
    qemu:base \
    qemu-system-x86_64 \
        -enable-kvm -cpu host \
        -nographic \
        -m 1024 \
        -drive file=/vm/SLES-16.0-Minimal-VM.x86_64-Cloud-GM.qcow2,format=qcow2,if=virtio \
        -cdrom /vm/cloud-init-sles.iso \
        -boot c

$ podman run --rm -it \
    --device /dev/kvm \
    -v ~/vm:/vm:z \
    qemu:base \
    qemu-system-x86_64 \
        -enable-kvm -cpu host \
        -nographic \
        -m 1024 \
        -drive file=/vm/al2023-kvm-2023.10.20260325.0-kernel-6.1-x86_64.xfs.gpt.qcow2,format=qcow2,if=virtio \
        -cdrom /vm/cloud-init-al2023.iso \
        -boot c

The first boot with the cloud-init ISO configures the VM. After that, drop the -cdrom flag — it's only needed once:

$ podman run --rm -it \
    --device /dev/kvm \
    -v ~/vm:/vm:z \
    qemu:base \
    qemu-system-x86_64 \
        -enable-kvm -cpu host \
        -nographic \
        -m 1024 \
        -drive file=/vm/SLES-16.0-Minimal-VM.x86_64-Cloud-GM.qcow2,format=qcow2,if=virtio

$ podman run --rm -it \
    --device /dev/kvm \
    -v ~/vm:/vm:z \
    qemu:base \
    qemu-system-x86_64 \
        -enable-kvm -cpu host \
        -nographic \
        -m 1024 \
        -drive file=/vm/al2023-kvm-2023.10.20260325.0-kernel-6.1-x86_64.xfs.gpt.qcow2,format=qcow2,if=virtio

📊 Results

Distribution	Disk Size	Boot Time	Root Usage	Notes
Ubuntu 24.04	3.5 GB	~10s	72%	Lightweight server, ext4
SLES 16	1.3 GB	~10s	97%	Minimal install, xfs, very tight on disk
Amazon Linux 2023	25 GB	~20s	7%	Cloud-optimized, xfs, plenty of room

🦎 SLES 16 — What's Different

SLES boots fine with its own cloud-init seed. The wheel group works for sudo. Boot time:

real    0m9.855s
user    0m0.085s
sys     0m0.055s

About 10 seconds — same ballpark as Ubuntu. QEMU defaults to the right boot device when there's only one disk, so -boot c isn't needed for subsequent boots.

sysadmin@kvmpodman:~> cloud-init --version
/usr/bin/cloud-init 25.1.3-160000.1.2

The disk layout tells a different story:

sysadmin@kvmpodman:~> lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sr0     11:0    1  364K  0 rom  
vda    253:0    0  1.3G  0 disk 
├─vda1 253:1    0    2M  0 part 
├─vda2 253:2    0  512M  0 part /boot/efi
└─vda3 253:3    0  806M  0 part /

Three partitions instead of four — no separate /boot, just EFI and root. The 2 MB vda1 is the BIOS boot partition. The root filesystem is xfs, not ext4.

And the disk is already 97% full:

sysadmin@kvmpodman:~> df -Th
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/vda3      xfs       742M  716M   27M  97% /
/dev/vda2      vfat      512M  3.9M  508M   1% /boot/efi

27 MB of free space on root is tight. Installing a single package with zypper will likely fill the remaining space. Ubuntu gave you 688 MB free on a 3.5 GB image. SLES is a true minimal image — but that means almost no headroom.

Memory-wise, both Ubuntu and SLES report about 960 MB from the 1 GB allocation — no surprise there.

☁️ Amazon Linux 2023 — What's Different

Amazon Linux takes a completely different approach. It ships a 25 GB image with only 7% used:

[sysadmin@localhost ~]$ lsblk
NAME     MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sr0       11:0    1  364K  0 rom  
vda      252:0    0   25G  0 disk 
├─vda1   252:1    0   25G  0 part /
├─vda127 259:0    0    1M  0 part 
└─vda128 259:1    0   10M  0 part /boot/efi

Three partitions — a single massive 25 GB root partition, a 1 MB BIOS boot partition, and a tiny 10 MB EFI partition. No separate /boot. The filesystem is xfs, same as SLES.

[sysadmin@localhost ~]$ df -Th
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/vda1      xfs        25G  1.7G   24G   7% /
/dev/vda128    vfat       10M  1.3M  8.7M  13% /boot/efi

24 GB of free space out of the box. This image is built for production use, not minimal testing. You can install packages, run services, and never worry about disk space.

Memory usage is similar — 964 MB total, 317 MB used:

[sysadmin@localhost ~]$ free -m
               total        used        free      shared  buff/cache   available
Mem:             964         317         433           2         213         508
Swap:              0           0           0

Cloud-init version:

[sysadmin@localhost ~]$ cloud-init --version
/usr/bin/cloud-init 22.2.2

One oddity: the hostname shows as localhost instead of kvmpodman. Amazon Linux ships with cloud-init 22.2.2, which is significantly older than Ubuntu's 25.3 or SLES's 25.1. The preserve_hostname: false directive may not be honored properly in this older version, or Amazon's own hostname logic overrides it during boot. Fix it manually:

[sysadmin@localhost ~]$ sudo hostnamectl set-hostname kvmpodman

Boot time:

real    0m19.998s
user    0m0.061s
sys     0m0.089s

About 20 seconds — the slowest of the three. Ubuntu and SLES both hit ~10 seconds. Amazon's extra startup time likely comes from its larger disk image, older cloud-init version, and the init services it brings up by default. Still, 20 seconds is nothing for a full production-grade Linux install.

The real kicker: this is an image designed exclusively for AWS EC2, and it boots natively as a KVM VM inside a Podman container. No AWS APIs, no special tooling — just qcow2 and VirtIO. It works.

🔍 Distro Comparison

Metric	Ubuntu 24.04	SLES 16	Amazon Linux 2023
Disk size	3.5 GB	1.3 GB	25 GB
Root usage	72%	97%	7%
Filesystem	ext4	xfs	xfs
Boot time	~10s	~10s	~20s
cloud-init	25.3	25.1	22.2
Partitions	4	3	3
Swap	None	None	None

⚠️ Distro-Specific Gotchas

SLES:

Uses zypper instead of apt/dnf
Root filesystem is xfs, not ext4
Disk is extremely tight (97% used out of the box) — not ideal for installing additional packages
The wheel group works for sudo access
Older images may have cloud-init issues — grab the latest from the SUSE download center

Amazon Linux 2023:

Uses dnf like RHEL/CentOS
Comes with cloud-init pre-installed (it's designed for AWS)
May try to reach AWS metadata services on boot — harmless but adds a few seconds
Default shell for root is bash, but the ec2-user default varies

✅ What You've Built

✅ Ubuntu cloud image downloaded and ready to boot
✅ cloud-init seed with user, SSH key, and hashed password
✅ VM boots in under 10 seconds with VirtIO, fully configured
✅ No manual installer, no interactive prompts
✅ SLES 16 and Amazon Linux 2023 running side by side

🔜 What's Next?

You can boot into the VM, but you're stuck in the console. Typing commands in the QEMU terminal is clunky — no copy/paste, no multiple windows, no real terminal features.

Post #5: We'll set up SSH networking so you can connect from your host terminal, use your favorite SSH client, and treat this VM like a real remote server.

This guide is Part 4 of the KVM Virtual Machines on Podman series.

Part 1: Build a KVM-Ready Container Image from Scratch
Part 2: KVM Acceleration in a Rootless Podman Container
Part 3: Persistent VMs in Podman: Install Alpine to a qcow2 Disk Image
Coming up in Part 5: SSH Into Your Podman VM — Container Networking for KVM

Found this helpful?

LinkedIn: Share with your network
Twitter: Tweet about it
Questions? Drop a comment below or reach out on LinkedIn

Docker Compose Explained: One File, One Container (2026)

David Tio — Mon, 13 Apr 2026 02:18:49 +0000

🐳 Docker Compose Explained: One File, One Container (2026)

Quick one-liner: Replace docker run commands with a docker-compose.yml file. One command to start or tear down any container, reproducibly, every time.

🤔 Why This Matters

In the last post, you connected containers by building a custom bridge network and running CloudBeaver + PostgreSQL by hand:

$ docker network create dtstack
$ docker run -d --rm --name dtpg \
    --network dtstack \
    -e POSTGRES_PASSWORD=docker \
    -e POSTGRES_DB=testdb \
    -v pgdata:/var/lib/postgresql/data \
    --tmpfs /var/run/postgresql \
    postgres:17
$ docker run -d --rm --name cloudbeaver \
    --network dtstack \
    -p 8978:8978 \
    -v cbdata:/opt/cloudbeaver/workspace \
    dbeaver/cloudbeaver:latest

Three commands. That's not the problem.

The problem is:

The second command is a 150-character wall of flags
One typo in --tmpfs and PostgreSQL silently starts but won't accept connections
Forget --network dtstack and the containers won't find each other
Tear it down and rebuild? Type it all again
What about when you have 5 containers? 10?

There's a better way.

Docker Compose lets you define this entire stack in a single YAML file:

$ docker compose up -d

One command. Same result. Every time.

Here's how it works. Instead of typing flags every time, you write a docker-compose.yml file that captures everything. You list the image, ports, volumes, environment variables, and networks. Then you run docker compose up -d and Docker does the rest. Start it, stop it, tear it down. All with one command.

We'll start by composing each of our containers individually. One compose file for PostgreSQL. One for CloudBeaver. You'll get comfortable with the up/ps/logs/down workflow.

By the end of this post, you'll never have to stare at another never-ending line of docker run flags again.

✅ Prerequisites

Ep 1-6 completed. Docker is installed and running, you know volumes, networking, and port mapping. Rootless mode recommended.
Docker Compose plugin. Already installed as part of Blog-01/02. Just run docker compose version to verify.

Compose v2: The old docker-compose (with hyphen) is deprecated. Modern Docker ships docker compose (space) as a plugin. If docker compose version doesn't work, go back and re-run the installation steps in Blog-01 or Blog-02. The plugin was included there.

📦 Your First docker-compose.yml

Create a directory for your PostgreSQL service:

$ mkdir -p dtstack-pg && cd dtstack-pg

Create docker-compose.yml:

services:
  dtpg:
    container_name: dtpg
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: docker
      POSTGRES_DB: testdb
    volumes:
      - pgdata:/var/lib/postgresql/data
    tmpfs:
      - /var/run/postgresql

volumes:
  pgdata:

Four things to notice:

services: is the top-level key. Each entry under services: is one container. We have one, and it's called dtpg.
container_name gives it a clean name. Instead of Compose's auto-generated dtstack-pg-dtpg-1, we get dtpg. Same as --name in docker run.
No --network flag. The network is implicit. We're not connecting to anything else yet. One container, one service.
Volumes are declared at the bottom. Named volumes are defined in the volumes: block and referenced by the service. Docker creates them on first use.

🚀 Start the Service

$ docker compose up -d

[+] Running 3/3
 ✔ Network dtstack-pg_default  Created
 ✔ Volume dtstack-pg_pgdata    Created
 ✔ Container dtpg              Started

One command creates a container, a network, and a volume. Everything you need.

Verify it's up:

$ docker compose ps
NAME   IMAGE         COMMAND                  SERVICE   CREATED         STATUS         PORTS
dtpg   postgres:17   "docker-entrypoint.s…"   dtpg      54 seconds ago  Up 54 seconds  5432/tcp

🔍 Inspect the Service

View logs:

$ docker compose logs

dtpg | PostgreSQL init process complete; ready for start up.
dtpg | database system is ready to accept connections

Follow logs in real-time (like docker logs -f):

$ docker compose logs -f

Press Ctrl-C to stop following.

Connect and verify:

$ docker compose exec dtpg psql -U postgres -c "SELECT version();"

                                                      version
--------------------------------------------------------------------------------------------------------------------
 PostgreSQL 17.9 (Debian 17.9-1.pgdg13+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit
(1 row)

PostgreSQL is running. We used dtpg to target the container, and Compose knows exactly which one to hit.

Let's bring it down before we make changes:

$ docker compose down

[+] Running 2/2
 ✔ Container dtpg              Removed
 ✔ Network dtstack-pg_default  Removed

The volume survives. Your data is safe.

📁 Using Environment Files

Hardcoding passwords in YAML is bad practice. Move secrets to a .env file:

$ cat > .env << EOF
POSTGRES_PASSWORD=docker
POSTGRES_DB=testdb
EOF

Update docker-compose.yml to reference them:

services:
  dtpg:
    container_name: dtpg
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
    volumes:
      - pgdata:/var/lib/postgresql/data
    tmpfs:
      - /var/run/postgresql

volumes:
  pgdata:

Now docker compose up -d reads the variables automatically. Same command, cleaner file.

🛑 Tear It Down

$ docker compose down

[+] Running 2/2
 ✔ Container dtpg              Removed
 ✔ Network dtstack-pg_default   Removed

The container and network are gone, but the volume survives. Your data is still right where you left it:

$ docker volume ls | grep dtstack

local  dtstack-pg_pgdata

To remove the volume too:

$ docker compose down --volumes

[+] Running 1/1
 ✔ Volume dtstack-pg_pgdata  Removed

Use --volumes when you want a clean slate. Leave it off when you want data to survive across restarts.

📦 Second Compose File: CloudBeaver

Now let's do the same for CloudBeaver. It gets its own directory and its own compose file.

First, go back to your home directory:

$ cd ~

Then create the CloudBeaver directory:

$ mkdir -p dtstack-cb && cd dtstack-cb

services:
  cloudbeaver:
    container_name: cloudbeaver
    image: dbeaver/cloudbeaver:latest
    ports:
      - "8978:8978"
    volumes:
      - cbdata:/opt/cloudbeaver/workspace

volumes:
  cbdata:

Start it:

$ docker compose up -d

[+] Running 3/3
 ✔ Network dtstack-cb_default  Created
 ✔ Volume dtstack-cb_cbdata    Created
 ✔ Container cloudbeaver       Started

Open http://localhost:8978. CloudBeaver loads. ✅

But there's no PostgreSQL on this network. CloudBeaver and PG live in separate compose projects. Different directories, different networks. They can't talk to each other yet.

Déjà vu. We solved this exact problem in the last post with custom bridge networks. Same concept, but this time we're doing it through Compose. We'll get there next post.

For now, let's clean up:

$ docker compose down --volumes

📋 Docker Run vs Docker Compose

Task	`docker run`	`docker compose`
Start	`docker run -d --name x --network n ...`	`docker compose up -d`
List	`docker ps`	`docker compose ps`
Logs	`docker logs x`	`docker compose logs`
Exec	`docker exec -it x sh`	`docker compose exec x sh`
Stop	`docker stop x`	`docker compose down`
Network	`docker network create`	Automatic

The docker compose commands are scoped to your project. docker compose ps only shows your stack's containers. It won't list everything running on your machine.

🧪 Exercise: Build Your Nextcloud Stack with Compose

Nextcloud is a self-hosted productivity platform. It functions just like Google Docs, but it runs on your own server. It needs four services: a database, a cache, a web server, and a PHP backend. You'll create four compose files, one per service, each in its own directory.

First, go back to your home directory:

$ cd ~

Part 1: MariaDB

$ mkdir -p nc-db && cd nc-db

Create .env:

$ cat > .env << EOF
MYSQL_ROOT_PASSWORD=nextcloud
MYSQL_DATABASE=nextcloud
MYSQL_USER=nextcloud
MYSQL_PASSWORD=nextcloud
EOF

Create docker-compose.yml:

services:
  db:
    container_name: nc-db
    image: mariadb:11
    ports:
      - "3306:3306"
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
    volumes:
      - dbdata:/var/lib/mysql

volumes:
  dbdata:

$ docker compose up -d

Verify:

$ docker compose exec db mariadb -u root -pnextcloud -e "SHOW DATABASES;"

+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| nextcloud          |
| performance_schema |
| sys                |
+--------------------+

$ docker compose down --volumes

Part 2: Redis

$ cd ~
$ mkdir -p nc-redis && cd nc-redis

services:
  redis:
    container_name: nc-redis
    image: redis:8.6
    ports:
      - "6379:6379"
    volumes:
      - redisdata:/data

volumes:
  redisdata:

$ docker compose up -d
$ docker compose exec redis redis-cli PING

You should get PONG.

$ docker compose down --volumes

Part 3: Nextcloud PHP-FPM

$ cd ~
$ mkdir -p nc-php && cd nc-php

services:
  php:
    container_name: nc-php
    image: nextcloud:fpm
    ports:
      - "9000:9000"
    volumes:
      - ./html:/var/www/html

$ docker compose up -d

Nextcloud's PHP-FPM image comes with Nextcloud pre-installed. On first start, it runs its setup scripts and copies the app files into the bind-mounted html/ directory. You can see it populate:

$ ls html/

You'll see Nextcloud's file structure. Things like index.php, core/, apps/, config/. The container put everything there for you.

$ docker compose down

Part 4: Nginx

$ cd ~
$ mkdir -p nc-nginx && cd nc-nginx

services:
  nginx:
    container_name: nc-nginx
    image: nginx:latest
    ports:
      - "8080:80"
    volumes:
      - ./html:/usr/share/nginx/html

$ mkdir -p html
$ cat > html/index.html << 'EOF'
<h2>Nextcloud is coming</h2>
EOF

$ docker compose up -d
$ docker compose exec nginx curl localhost

You should see <h2>Nextcloud is coming</h2>.

$ docker compose down

👉 Coming up: This isn't a full Nextcloud deployment yet, but you now have all the containers you need to get it running. Next post, we'll glue them all up and get it working. See you then.

📚 Want More? This guide covers the basics from Chapter 11: Using Docker Compose in my book, "Levelling Up with Docker". That's 14 chapters of practical, hands-on Docker guides.

> Note: The book has more content than this blog series. Some topics are only available in the book.

📚 Grab the book: "Levelling Up with Docker" on Amazon

Found this helpful? 🙌

LinkedIn: Share with your network
Twitter: Tweet about it
Questions? Drop a comment below or reach out on LinkedIn

Building a Blog Platform with Docker #2: Tailwind CSS

David Tio — Sun, 12 Apr 2026 00:16:36 +0000

Building a Blog Platform with Docker #2: Tailwind CSS

Quick one-liner: Upgrade your Flask app to Tailwind CSS via CDN — dark theme with teal branding, no build step required.

Why This Matters

Last time, you got a basic Flask app running with a separate CSS file. It worked — dark background, teal heading, centered layout.

But let's be honest — it's nothing like a blog yet. One centered heading. One paragraph. Nothing a reader would take seriously.

Today, we're making it look a lot more like a blog. We're adding Tailwind CSS.

Why Tailwind? You could write custom CSS. Or use Bootstrap. Or Bulma. But Tailwind is fast, modern, and easy to customise. Plus, it's what I'll use for the final blog.dtio.app, so you're learning the actual stack.

No build step. I'm not making you install Node.js, npm, and a whole build pipeline just for CSS. We're using Tailwind via CDN. It's not production-optimal, but for learning? Perfect.

By the end of this post, you'll have:

Tailwind CSS loaded via CDN
Google Fonts (DM Sans + Instrument Serif)
A teal navigation bar
A centered hero section
An editorial post list
A teal footer

Starting Point

You should have this from last time:

tiohub-blog/
├── app.py
├── static/
│   └── css/
│       └── style.css
└── templates/
    └── index.html

Your index.html currently links to static/css/style.css via a <link> tag in the <head>.

If you don't have this, go back and build Episode 1 first. This one builds on it.

Step 1: Add Tailwind CDN and Google Fonts

Open templates/index.html. You currently have something like this:

<!DOCTYPE html>
<html>
<head>
    <title>Welcome to David Tio's Blog</title>
    <link rel="stylesheet" href="{{ url_for('static', filename='css/style.css') }}">
</head>
<body>
    <h1>Welcome to David Tio's Blog</h1>
    <p>Building a blog platform with Docker.</p>
</body>
</html>

Add the Google Fonts and Tailwind CDN in the <head>:

<!DOCTYPE html>
<html lang="en">
<head>
    <title>David Tio's Blog</title>
    <link href="https://fonts.googleapis.com/css2?family=Instrument+Serif:ital@0;1&family=DM+Sans:wght@400;500;700&display=swap" rel="stylesheet">
    <script src="https://cdn.tailwindcss.com"></script>
</head>
<body>
    <h1>Welcome to David Tio's Blog</h1>
    <p>Building a blog platform with Docker.</p>
</body>
</html>

That's it. Tailwind is now loaded. We'll add the config file in Step 2.

CDN trade-off: It's bigger than a bundled build. But for a personal blog? Nobody's going to notice. And you save hours of build setup.

Step 2: Configure Tailwind

Tailwind's default colors and fonts are a good start, but we want our own brand colors and the fonts we loaded. This can be configured using JavaScript. Let's create a directory for it:

$ mkdir -p static/js

static/js/tailwind.config.js:

tailwind.config = {
    theme: {
        extend: {
            colors: {
                brand: {
                    500: '#14B8A6',  // teal accent
                    600: '#0F766E',  // primary teal
                    700: '#0D5F57',  // darker teal
                }
            },
            fontFamily: {
                sans: ['DM Sans', 'system-ui', 'sans-serif'],
                serif: ['Instrument Serif', 'Georgia', 'serif'],
            }
        }
    }
}

Load it in index.html right after the Tailwind CDN script:

<link href="https://fonts.googleapis.com/css2?family=Instrument+Serif:ital@0;1&family=DM+Sans:wght@400;500;700&display=swap" rel="stylesheet">
<script src="https://cdn.tailwindcss.com"></script>
<script src="{{ url_for('static', filename='js/tailwind.config.js') }}"></script>

Now you can use bg-brand-700, text-brand-500, font-serif, etc. in your classes.

Step 3: Build the Navigation Bar

Open templates/index.html. Add this right after the opening <body> tag:

<nav class="bg-brand-700 border-b border-brand-600">
    <div class="max-w-6xl mx-auto px-6 py-4 flex items-center justify-between">
        <a href="{{ url_for('index') }}" class="font-serif text-xl text-white">
            David Tio's Blog
        </a>
        <div class="flex items-center space-x-6">
            <a href="/" class="text-teal-100 hover:text-white font-medium text-sm transition duration-200">Home</a>
            <a href="#" class="text-teal-100 hover:text-white font-medium text-sm transition duration-200">Series</a>
            <a href="#" class="text-teal-100 hover:text-white font-medium text-sm transition duration-200">About</a>
        </div>
    </div>
</nav>

This gives you:

Darker teal navbar (brand-700) with a subtle border line underneath
Blog name on the left in Instrument Serif, linked back to your Flask index route via url_for
Three navigation links on the right with white hover transitions
max-w-6xl mx-auto centers the nav content at a comfortable width

Mobile note: This navbar isn't responsive yet. We'll fix that later. For now, it works on desktop.

Placeholder links: Series and About point to # for now. They're dead links until we build those pages in a future episode. Home links to your Flask index route, which is already live.

Step 4: Build the Hero and Post List

Now replace the entire <body> section with this:

<body class="bg-slate-950 text-gray-100 font-sans min-h-screen flex flex-col">
    <!-- Navbar from Step 3 -->

    <!-- Hero -->
    <div class="max-w-3xl mx-auto px-6 pt-20 pb-12 text-center">
        <span class="inline-block text-brand-500 text-xs font-semibold tracking-widest uppercase mb-5">Docker · Linux · Open Source</span>
        <h1 class="font-serif text-5xl text-white leading-tight mb-5">Practical guides for engineers.</h1>
        <p class="text-gray-400 text-lg leading-relaxed">Building with containers, Linux, and open source tools — one post at a time.</p>
    </div>

    <!-- Posts -->
    <main class="max-w-3xl mx-auto px-6 pb-20 flex-1 w-full">

        <div class="border-t border-slate-800 mb-10"></div>

        <h2 class="text-xs font-semibold text-gray-500 uppercase tracking-widest mb-8">Latest Posts</h2>

        <div class="flex flex-col">

            <article class="border-l-2 border-slate-800 hover:border-brand-500 pl-6 py-5 transition-all duration-300 group cursor-pointer">
                <p class="text-gray-600 text-xs mb-2">29 Mar 2026 &middot; Blog Platform</p>
                <h3 class="text-gray-100 font-semibold text-lg mb-2 group-hover:text-brand-500 transition-colors duration-200">
                    <a href="#">Building a Blog Platform #1: Flask Setup</a>
                </h3>
                <p class="text-gray-500 text-sm leading-relaxed">Get a basic Flask app running with separate CSS — no Docker yet, just Python and a stylesheet.</p>
            </article>

            <div class="border-t border-slate-800 ml-6"></div>

        </div>
    </main>

    <!-- Footer from Step 5 -->
</body>

What's happening here:

bg-slate-950 gives the whole page a dark slate background
min-h-screen flex flex-col makes the body stretch to full viewport height and stacks nav, hero, posts, and footer vertically
max-w-3xl mx-auto centers the content at a readable width — just like a real blog
The hero has a small teal label ("Docker · Linux · Open Source") and a large serif heading
The post card has a left border that turns teal when you hover over it — try it
The url_for in the navbar links back to your Flask index route, so nothing is hardcoded

Step 5: Add a Footer

Before the closing </body> tag, add:

<footer class="bg-brand-700 border-t border-brand-600">
    <div class="max-w-6xl mx-auto px-6 py-6 flex items-center justify-between">
        <p class="text-teal-100 text-sm">&copy; 2026 David Tio.</p>
        <div class="flex space-x-6">
            <a href="#" class="text-teal-100 hover:text-white text-sm transition-colors duration-200">LinkedIn</a>
            <a href="#" class="text-teal-100 hover:text-white text-sm transition-colors duration-200">Twitter</a>
            <a href="#" class="text-teal-100 hover:text-white text-sm transition-colors duration-200">GitHub</a>
        </div>
    </div>
</footer>

Matches the nav — teal background, copyright left, social links right.

Step 6: Clean Up Your CSS

Now that Tailwind is doing all the work, your old style.css is redundant. Remove the <link> tag from the <head> of index.html:

<!-- Delete this line -->
<link rel="stylesheet" href="{{ url_for('static', filename='css/style.css') }}">

Then delete the file itself:

$ rm static/css/style.css

Step 7: Test It

If you closed the terminal since Episode 1, reactivate the venv first:

$ source venv/bin/activate

Run your Flask app:

$ python app.py

Visit http://localhost:8000. You should see:

Teal navbar with your name in Instrument Serif
Dark background with a centered hero
Editorial post list with teal hover effects
Matching teal footer

It should look like an actual blog now.

What You've Built

You now have:

Tailwind CSS via CDN (no build step)
Google Fonts: DM Sans body, Instrument Serif for headings
Custom brand colors (teal-500 accent, teal-700 nav/footer)
Dark slate background (slate-950)
Teal nav and footer branding
Centered hero with serif heading
Editorial post list with teal left-border hover

Coming Up

Right now, your posts are hardcoded HTML. You want to write Markdown files and have them render automatically. Next time: Markdown support. You'll write .md files with frontmatter, and Flask will parse them into HTML.

No more HTML templates for every blog post. Just write Markdown and go.

Found this helpful? Share it with your network or drop a comment below.

Docker Networking Explained: Connect Your Containers (2026)

David Tio — Fri, 10 Apr 2026 23:56:09 +0000

🌐 Docker Networking Explained: Connect Your Containers (2026)

Quick one-liner: Connect your containers to each other and the outside world. Learn bridge networks, port mapping, DNS, and container-to-container communication.

🤔 Why This Matters

In the last post, you got Redis + RedisInsight working. Your data persisted across a version upgrade, your config was pre-loaded via bind mount, and your Redis data survived the container being deleted and recreated.

But remember what happened when we tried to connect RedisInsight to Redis?

# echo PING | nc dtredis86 6379
nc: bad address 'dtredis86'

Hostname didn't resolve. We had to fall back to docker inspect to find the Redis IP (172.17.0.2) and connect that way. That works for a quick test, but it's not how you want to run anything real:

🏗️ If you restart the container, the IP changes
📋 You'd need to manually update configs every time
🔒 No network isolation — anything can reach anything
🌐 No way to access containers from your browser

Today, we're fixing all of that. We'll cover:

Port mapping — exposing container ports to your browser
Custom bridge networks — containers that find each other by name
DNS resolution — no more docker inspect to find IPs
Network isolation — keeping your services segmented

By the end, you'll have RedisInsight talking to Redis by name, accessible from your browser, on a clean isolated network. The right way.

✅ Prerequisites

Docker installed (rootless mode recommended)
Ep 1-5 completed — you know volumes, environment variables, and bind mounts
5 minutes to wire up your first multi-container setup

🏗️ The Default Bridge Network

When you run a container without specifying a network, Docker puts it on the default bridge network:

$ docker network ls
NETWORK ID     NAME      DRIVER    SCOPE
a1b2c3d4e5f6   bridge    bridge    local
d4e5f6a1b2c3   host      host      local
e5f6a1b2c3d4   none      null      local

Containers on the default bridge can reach each other by IP address, but not by name. That's exactly what you saw with RedisInsight and Redis in the last post. Let's reproduce it with the same setup — the Redis + RedisInsight you ended Ep 5 with:

$ docker run -d --rm --name dtredis86 \
    -v redisdata:/data \
    -v ./redis.conf:/etc/redis/redis.conf \
    redis:8.6 redis-server /etc/redis/redis.conf

$ docker run -d --rm --name redisinsight \
    -v ./data/ri:/data \
    -e RI_PRE_SETUP_DATABASES_PATH=/data/config.json \
    -e RI_ACCEPT_TERMS_AND_CONDITIONS=true \
    redis/redisinsight

No -p flag — so you can't reach it from your browser, just like in Ep 5.

Try resolving dtredis86 from the RedisInsight container:

$ docker exec redisinsight sh -c "echo PING | nc dtredis86 6379"
nc: bad address 'dtredis86'

Hostname resolution doesn't work on the default bridge. You'd need to inspect the container to find its IP, then connect that way — exactly what you saw in Ep 5 when we had to fall back to 172.17.0.2.

This is fragile. If you restart the containers, the IPs change. Let's fix this properly.

🌐 Port Mapping: Expose Containers to the Host

In Ep 5, you ran RedisInsight without port mapping and couldn't reach it at http://localhost:5540. The container was alive inside, but your host had no way in.

Let's add port mapping to the same RedisInsight setup from Ep 5:

$ docker stop redisinsight

$ docker run -d --rm --name redisinsight \
    -p 8080:5540 \
    -v ./data/ri:/data \
    -e RI_PRE_SETUP_DATABASES_PATH=/data/config.json \
    -e RI_ACCEPT_TERMS_AND_CONDITIONS=true \
    redis/redisinsight

The ./data/ri directory should already have the correct chown from Ep 5. If not:

$ sudo chown -R 1001000:1001000 ./data/ri

Flag	What It Does
`-p 8080:5540`	Map host port `8080` → container port `5540` (RedisInsight)

Now open http://localhost:8080 — RedisInsight loads. 🎉

The format is always host_port:container_port:

$ docker run -d --rm --name dtredis2 -p 6380:6379 redis

Now here's a practical exercise: open RedisInsight at http://localhost:8080 and try adding dtredis2 as a new connection:

What you try	Result	Why
`redis://dtredis2:6379`	❌ DNS fails	Hostnames don't resolve on default bridge
`redis://127.0.0.1:6379`	❌ Connection refused	That's the RedisInsight container's own loopback
`redis://127.0.0.1:6380`	❌ Connection refused	Same reason — localhost inside a container

The only way to reach dtredis2 from RedisInsight is via your host's IP address. Get it with:

$ hostname -I
<your_host_ip>

Then in RedisInsight: redis://<your_host_ip>:6380 — it connects, but it's ugly. If your host IP changes, you're updating configs everywhere.

It works — but we're using a raw IP address that could change at any time.

Verify the port mapping:
$ docker port dtredis2
6379/tcp -> 0.0.0.0:6380

There has to be a better way. 👇

Rootless note: In rootless mode, you can't bind to ports below 1024. So -p 80:5540 won't work. Use -p 8080:5540 or higher. If you need port 80, put a rootful reverse proxy (nginx, caddy, traefik) in front.

Clean up before moving on:

$ docker stop dtredis86 redisinsight

🌉 Custom Bridge Networks: The Right Way

Create a custom bridge network. Containers on the same custom network can reach each other by name — Docker provides built-in DNS resolution.

$ docker network create dtapp

Run Redis and RedisInsight on this network:

$ docker run -d --rm --name dtredis --network dtapp redis
$ docker run -d --rm --name ri --network dtapp \
    -p 8080:5540 \
    -v ./data/ri:/data \
    -e RI_PRE_SETUP_DATABASES_PATH=/data/config.json \
    -e RI_ACCEPT_TERMS_AND_CONDITIONS=true \
    redis/redisinsight

First, verify the connection from the command line:

$ docker exec ri sh -c "echo PING | nc dtredis 6379"

It resolves. ✅ No IP inspection, no manual config. The name works automatically.

Now open http://localhost:8080 — RedisInsight loads, and you can add dtredis:6379 as a new connection. No IP addresses needed.

Connect an existing container to a network:

$ docker run -d --rm --name dtredis2 redis

This container is on the default bridge. Connect it to dtapp:

$ docker network connect dtapp dtredis2

Now dtredis2 is on both networks. Verify ri can reach it:

$ docker exec ri sh -c "echo PING | nc dtredis2 6379"
PING
+PONG

Redis responds by hostname. ✅

🧪 Exercise: CloudBeaver + PostgreSQL on a Custom Network

Let's wire up a real multi-container stack — PostgreSQL for the database, CloudBeaver as the web UI.

Part 1: Create the Network and Run PostgreSQL

$ docker network create dtstack
$ docker run -d --rm --name dtpg \
    --network dtstack \
    -e POSTGRES_PASSWORD=docker \
    -e POSTGRES_DB=testdb \
    -v pgdata:/var/lib/postgresql/data \
    --tmpfs /var/run/postgresql \
    postgres:17

Rootless note: PostgreSQL tries to chmod /var/run/postgresql for its PID file at startup. Rootless containers can't do that. The --tmpfs flag gives it a writable temp directory on that path without root.

Part 2: Run CloudBeaver on the Same Network

$ docker run -d --rm --name cloudbeaver \
    --network dtstack \
    -p 8978:8978 \
    -v cbdata:/opt/cloudbeaver/workspace \
    dbeaver/cloudbeaver:latest

Wait ~30 seconds for it to start, then open http://localhost:8978 in your browser.

It loads. 🎉 Now add a connection in the CloudBeaver UI:

Server: dtpg
Port: 5432
Username: postgres
Password: docker
Database: testdb

Part 4: Check the Network

$ docker network inspect dtstack

You'll see both containers listed under Containers:

"Containers": {
    "abc123...": {
        "Name": "dtpg",
        "IPv4Address": "172.18.0.2/16"
    },
    "def456...": {
        "Name": "cloudbeaver",
        "IPv4Address": "172.18.0.3/16"
    }
}

Two containers. One network. DNS works between them. Port mapping gives you browser access. This is how multi-container apps should run.

Part 5: Clean Up

$ docker stop dtpg cloudbeaver
$ docker volume rm pgdata cbdata
$ docker network rm dtstack

The Problem With What We Just Did

Look at what it took to wire up two containers:

$ docker network create dtstack
$ docker run -d --rm --name dtpg --network dtstack -e POSTGRES_PASSWORD=docker -e POSTGRES_DB=testdb -v pgdata:/var/lib/postgresql/data --tmpfs /var/run/postgresql postgres:17
$ docker run -d --rm --name cloudbeaver --network dtstack -p 8978:8978 -v cbdata:/opt/cloudbeaver/workspace dbeaver/cloudbeaver:latest

Three commands. That's not the problem.

The problem is:

The second command is a 150-character wall of flags, environment variables, and volume mounts
One typo in --tmpfs and PostgreSQL silently starts but fails to accept connections
Forget --network dtstack and the containers won't find each other
Tear it down and rebuild? Type it all again
What about when you have 5 containers? 10? Shared volumes? Secret files? Restart policies?

There's a better way.

📋 Network Comparison

Network Type	DNS Resolution	Isolation	Use Case
default bridge	❌ No (IP only)	Low	Quick testing
custom bridge	✅ Yes (by name)	Medium	Multi-container apps
host	N/A	None	Performance (container uses host network)
none	N/A	Total	Air-gapped containers

👉 Coming up: We'll replace every single command above with a clean YAML file. Docker Compose — define your entire multi-container stack and launch it with one command.

📚 Want More? This guide covers the basics from Chapter 5: Docker Networking in my book, "Levelling Up with Docker" — 14 chapters of practical, hands-on Docker guides.

📚 Grab the book: "Levelling Up with Docker" on Amazon

Found this helpful? 🙌

LinkedIn: Share with your network
Twitter: Tweet about it
Questions? Drop a comment below or reach out on LinkedIn

Podman on SLES 16: Installation, Storage, and First Rootless Container (2026 Guide)

David Tio — Mon, 06 Apr 2026 00:56:42 +0000

Podman on SLES 16: Installation, Storage, and First Rootless Container (2026 Guide)

Quick one-liner: Install Podman on SLES 16 from the installation DVD, set up shared multi-user storage on a dedicated disk, and run your first rootless container — no Docker required.

(This guide targets SLES 16. The concepts apply to SLES 15 as well, but I've only verified the steps on SLES 16.)

Why This Matters

Docker isn't the only container runtime. On SUSE Linux Enterprise Server, SLES ships Podman as the native container tool through its official Containers module — and it has genuine advantages over Docker.

The biggest one: rootless by default.

With Docker, the daemon runs as root. That means a container escape could give an attacker root access to your host. Podman runs containers under your regular user account — no root daemon, no single point of failure.

There's also no daemon at all. Podman is daemonless — each container runs as a direct child process. Simpler, more secure, easier to debug.

If you're in an enterprise environment running SLES, Podman is the natural fit. It's supported by SUSE, available on the installation DVD, and doesn't require third-party repositories. This guide gets you from a fresh SLES install to running your first container.

Prerequisites

SLES 16 (minimal or server installation)
DVD repository enabled (see Add a DVD as a Local Zypper Repository) — or an active SCC subscription
Two virtual disks (recommended): 40 GB for the OS, 20 GB for container storage
15-20 minutes

Why Two Disks?

Before we start — if you're setting this up on a VM, add a second virtual disk.

Container images accumulate fast. A few images later, your root partition fills up and everything breaks. Keeping container storage on a separate disk means:

Container data is isolated from the OS
You can resize or wipe container storage without touching the OS
Backups are simpler — back up the container disk separately

This is a production best practice worth building into your habits from day one.

Step 1: Mount the Second Disk

If you added a second disk, set it up before installing Podman.

Find the disk:

$ lsblk

On this VM the layout looks like:

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sr0     11:0    1 1024M  0 rom  
vda    254:0    0   40G  0 disk 
├─vda1 254:1    0    8M  0 part 
├─vda2 254:2    0   38G  0 part /var
│                               /usr/local
│                               /opt
│                               /home
│                               /srv
│                               /root
│                               /boot/grub2/i386-pc
│                               /boot/grub2/x86_64-efi
│                               /.snapshots
│                               /
└─vda3 254:3    0    2G  0 part [SWAP]
vdb    254:16   0   20G  0 disk

vda (40 GB) is the OS disk. vdb (20 GB) is the dedicated disk for container storage.

Format vdb with XFS (SLES default):

$ sudo mkfs.xfs /dev/vdb

Create the mount point:

$ sudo mkdir -p /var/lib/containers

Add to /etc/fstab for persistence:

$ echo '/dev/vdb /var/lib/containers xfs defaults 0 0' | sudo tee -a /etc/fstab

Mount everything from fstab and verify:

$ sudo mount -a
$ df -Th /var/lib/containers

Step 2: Install Podman

Podman ships on the SLES 16 installation DVD. Enable the DVD repository and install:

$ sudo zypper mr -e SLES
$ sudo zypper install -y podman fuse-overlayfs

Verify:

$ podman --version

podman version 5.4.2

Step 3: Set Up Shared Multi-User Storage

This is where most guides stop — they just say "install and go." But in a real environment, multiple people will run rootless containers. Each user's container images and layers are stored separately (rootless Podman stores everything under each user's home directory by default). If you don't plan for this, each user's ~/.local fills up their own home partition independently and unpredictably.

Here is how I like to set up Podman in an enterprise environment. Each user gets their own isolated space on a shared disk, and access is controlled through a group:

As root (or sudo):

Create the shared storage directory and the podman group:

$ sudo mkdir -p /var/lib/containers/storage
$ sudo groupadd podman
$ sudo chown root:podman /var/lib/containers/storage
$ sudo chmod 2775 /var/lib/containers/storage

The 2775 permission is important — the setgid bit means any subdirectory created inside /var/lib/containers/storage automatically inherits the podman group. That keeps things consistent as you add users.

Add users who should have container access:

$ sudo usermod -aG podman sysadmin

Why Subordinate UIDs Matter

In rootless mode, container processes run in their own user namespace. Their UIDs get remapped to different UIDs on your host. This is a Linux kernel feature (user_namespaces(7)) and works identically for both rootless Docker and rootless Podman. The mapping looks like this:

Inside container	On your host
UID 0 (root)	Your user UID (e.g. `1000`)
UID 1	`subuid_start`
UID N	`subuid_start + N - 1`

The subuid_start is defined in /etc/subuid:

$ grep sysadmin /etc/subuid
sysadmin:100000:65536

SLES assigns 100000 by default. This means a container process running as UID 1000 lands on your host as UID 100999 (100000 + 1000 - 1). If your bind-mounted directory is owned by you (1000), that container process cannot write to it.

I prefer explicit ranges so the math is clean and there's no guessing. First, remove any existing subordinate UID/GID entries, then set the new range:

$ sudo sed -i "/^sysadmin:/d" /etc/subuid
$ sudo sed -i "/^sysadmin:/d" /etc/subgid
$ sudo usermod --add-subuids 100001-165536 sysadmin
$ sudo usermod --add-subgids 100001-165536 sysadmin

This gives 65,536 subordinate UIDs and GIDs. Now the mapping is clean and predictable:

Inside container	On your host
0	1000 (sysadmin)
1	100001
1000	101000

Verify:

$ cat /etc/subuid
sysadmin:100001:65536

$ cat /etc/subgid
sysadmin:100001:65536

As each user:

Log out and back in so the group change takes effect. Verify:

$ groups

You should see podman in the list.

Create your personal storage directory:

$ mkdir -p /var/lib/containers/storage/sysadmin

Create Podman's per-user storage config:

$ mkdir -p ~/.config/containers
$ cat > ~/.config/containers/storage.conf << 'EOF'
[storage]
driver = "overlay"
graphroot = "/var/lib/containers/storage/sysadmin"

[storage.options.overlay]
mount_program = "/usr/bin/fuse-overlayfs"
EOF

This file tells rootless Podman to store your images, containers, and layers on the shared disk instead of filling up your home directory.

Verify:

$ podman info | grep graphRoot

You should see /var/lib/containers/storage/sysadmin.

Step 4: Run Your First Container

Now run a container as your regular user:

$ podman run quay.io/podman/hello:latest

You should see:

Embracing and extending the Podman community...

================================================================
                       Podman Podman Podman
================================================================

... (Podman hello output) ...

Have a great day!

Podman ran this rootless — no root daemon, no extra configuration.

Check the container ran successfully:

$ podman ps -a

CONTAINER ID  IMAGE                        COMMAND               CREATED        STATUS                     PORTS       NAMES
2671631a4e8a  quay.io/podman/hello:latest  /usr/local/bin/po...  26 seconds ago  Exited (0) 26 seconds ago              stoic_sammet

This is a good moment to clarify the difference between podman ps and podman ps -a:

Command	What it shows
`podman ps`	Only running containers
`podman ps -a`	All containers — running, stopped, or exited

If you run podman ps right now, it returns nothing — the hello container printed its message and exited immediately. It worked perfectly, it just isn't running anymore. podman ps -a shows the full history, including containers that completed and stopped.

Step 5: Verify Rootless Operation

This is the key difference from Docker. In rootless mode, there's no persistent background daemon waiting for commands. Check the status:

$ systemctl status podman

You'll see the podman.service exists but is inactive:

○ podman.service - Podman API Service
     Loaded: loaded (/usr/lib/systemd/system/podman.service; disabled; preset: disabled)
     Active: inactive (dead)
TriggeredBy: ○ podman.socket

This is normal — it's a socket-activated service. It starts only when needed (for example, when Podman Desktop or other tools connect to it) and shuts down when idle. Unlike Docker, there's no dockerd process sitting at PID 1 consuming resources all day.

Verify storage is on the shared disk:

$ df -Th /var/lib/containers/storage/sysadmin

You should see your second disk, not the root partition.

Podman vs Docker: Key Differences

Feature	Podman	Docker
Daemon	None (daemonless)	`dockerd` runs as root
Default user	Rootless	Root
CLI compatibility	Drop-in replacement (`alias docker=podman`)	—
systemd integration	Native (Quadlet)	Requires extra config
SLES support	On the installation DVD	Third-party repository
Security	No root daemon, SELinux-ready	Root daemon exposure

The CLI is fully compatible — most docker commands work with podman. You can set the alias:

$ alias docker=podman

Try It: Parse JSON Without Installing Anything

Instead of the usual hello-world, let's verify rootless Podman with something useful.

Create a sample JSON file:

$ cat > ~/sample.json << 'EOF'
{"name":"David","company":"Transcend Solutions","role":"DevOps Engineer","skills":["Docker","Kubernetes","Linux"],"location":"Singapore","experience_years":15}
EOF

Normally you'd need to install jq to parse and pretty-print this JSON. With Podman, the tool comes with the container:

$ cat ~/sample.json | podman run ghcr.io/jqlang/jq '.'

The image pulls:

Trying to pull ghcr.io/jqlang/jq:latest...
Getting image source signatures
Copying blob e27c450974af done   | 
Copying blob ee0085cc4ebc done   | 
Copying config 3bada1936a done   | 
Writing manifest to image destination

But the output is completely blank. No error, no JSON — nothing.

That's because podman run doesn't pass standard input into the container by default. The jq process started, received nothing, and exited silently. To pipe data in, you need the -i flag:

$ cat ~/sample.json | podman run -i ghcr.io/jqlang/jq '.'

Now the output — beautifully formatted JSON:

{
  "name": "David",
  "company": "Transcend Solutions",
  "role": "DevOps Engineer",
  "skills": [
    "Docker",
    "Kubernetes",
    "Linux"
  ],
  "location": "Singapore",
  "experience_years": 15
}

No installation. No sudo zypper install jq. No repository configuration. The jq binary lives inside the container, and you used it without touching your host system.

What's happening here:

Flag	Purpose
`-i`	Keep stdin open so `jq` can read the piped JSON
`'.'`	The jq filter — `.` means "print everything, formatted"

What's Next

You've got Podman installed with proper shared storage and running rootless containers on SLES 16.

Coming up: running your first real workload — pulling images, managing container lifecycles, and understanding the differences between podman run flags you'll use every day.

Author: David Tio
Tags: Podman, SLES 16, SUSE, Containers, Rootless, Linux, Enterprise, DevOps, Tutorial
Series: Levelling Podman
Word Count: ~1,500

Persistent VMs in Podman: Install Alpine to a qcow2 Disk Image

David Tio — Wed, 01 Apr 2026 03:14:22 +0000

Persistent VMs in Podman: Install Alpine to a Disk Image

Quick one-liner: Create a qcow2 disk image with qemu-img, install Alpine Linux into it, and boot from disk — so your VM survives container restarts.

Why This Matters

Post #2 proved that KVM hardware acceleration is fast. But there's a catch: every time the container stops, the VM state vanishes. The Alpine ISO is read-only — any changes you make inside the VM exist only in RAM. Stop the container and they're gone.

That's fine for a boot-speed demo, but it's not a real VM. A real VM has a disk that persists between runs. The disk lives on the host filesystem, the container is just the runtime, and the two are completely independent. Stop and restart the container as many times as you want — the disk doesn't care.

This post adds that layer. You'll create a qcow2 disk image, boot from ISO + disk to run the Alpine installer, then boot from disk alone to confirm it survived.

Prerequisites

qemu:base image from Post #1
Alpine ISO from Post #2 at ~/Downloads/alpine-standard-3.23.3-x86_64.iso
~/vm directory (you'll create it below)

Step 1: Create the VM Directory and Disk Image

First, create a dedicated directory for your VM disk images:

$ mkdir -p ~/vm

Then create the disk image:

$ podman run --rm \
    -v ~/vm:/vm:z \
    qemu:base \
    qemu-img create -f qcow2 /vm/alpine.qcow2 8G

You should see:

Formatting '/vm/alpine.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=8589934592 lazy_refcounts=off refcount_bits=16

What's qcow2? It stands for QEMU Copy-On-Write version 2. The key property is thin provisioning: the file on your host starts tiny (a few hundred KB) and only grows as the VM actually writes data. Specifying 8G sets the maximum size the VM sees, not the space it consumes on disk immediately.

Step 2: Boot from ISO + Disk to Install

Now boot with both the ISO and the disk attached. The -boot d flag tells QEMU to boot from the CD-ROM first:

$ podman run --rm -it \
    --device /dev/kvm \
    -v ~/vm:/vm:z \
    -v ~/Downloads:/iso:z \
    qemu:base \
    qemu-system-x86_64 \
        -enable-kvm -cpu host \
        -nographic \
        -m 512 \
        -cdrom /iso/alpine-standard-3.23.3-x86_64.iso \
        -drive file=/vm/alpine.qcow2,format=qcow2 \
        -boot d

Alpine will boot from the ISO into a live environment. Log in as root — no password required.

Step 3: Install Alpine

Once you're at the shell, run the Alpine installer:

# setup-alpine

Work through the prompts. Most defaults are fine. The ones that matter:

Hostname: anything, e.g. alpine
Network: eth0, DHCP
Proxy: none
Root password: set something you'll remember
Timezone: your choice
Mirror: pick the fastest (or just press Enter for the default)
SSH server: openssh or none — your call
Setup a user: enter a username — don't skip this; logging in as root is bad practice
Full name: optional, press Enter to skip
User password: set one
SSH key or URL: none
Disk: sda — this is your qcow2 image
How to use it: sys — full system install to disk
Erase above disk and continue: y

When the installer finishes, power off:

# poweroff

The container exits. The alpine.qcow2 file on your host now contains a complete Alpine installation.

Step 4: Boot from Disk Only

Drop the ISO flags entirely. The disk knows how to boot now:

$ podman run --rm -it \
    --device /dev/kvm \
    -v ~/vm:/vm:z \
    qemu:base \
    qemu-system-x86_64 \
        -enable-kvm -cpu host \
        -nographic \
        -m 512 \
        -drive file=/vm/alpine.qcow2,format=qcow2

Alpine boots from the installed disk. Log in with the username you created during setup. Now write a file to prove the disk persists:

$ echo "hello from install" > ~/persistence-test.txt
$ cat ~/persistence-test.txt
hello from install
$ su -
# poweroff

The container exits. Run the exact same boot command again:

$ podman run --rm -it \
    --device /dev/kvm \
    -v ~/vm:/vm:z \
    qemu:base \
    qemu-system-x86_64 \
        -enable-kvm -cpu host \
        -nographic \
        -m 512 \
        -drive file=/vm/alpine.qcow2,format=qcow2

$ cat ~/persistence-test.txt
hello from install

The file survived. The container was destroyed and recreated, but the disk image on your host never changed. That's persistence.

Step 5: Why This Persists Across Container Restarts

The container is ephemeral — --rm means Podman deletes it the moment QEMU exits. But the disk image at ~/vm/alpine.qcow2 lives on your host filesystem, completely outside the container lifecycle.

The bind mount (-v ~/vm:/vm:z) is just a path into the host. Writing to /vm/alpine.qcow2 inside the container is writing to ~/vm/alpine.qcow2 on the host. When the container is gone, the file remains.

New Flags at a Glance

Flag	Where	What It Does
`-drive file=/vm/alpine.qcow2,format=qcow2`	QEMU	Attaches the disk image as a block device (`sda` inside the VM)
`-boot d`	QEMU	Sets boot order to CD-ROM first; needed during install so Alpine boots from ISO, not the blank disk
`format=qcow2`	QEMU `-drive` option	Tells QEMU the image format explicitly; avoids format auto-detection warnings
`-v ~/vm:/vm:z`	Podman	Bind-mounts the host `~/vm` directory; the disk image lives here, not inside the container
`-v ~/Downloads:/iso:z`	Podman	Bind-mounts the ISO directory; only needed during the install step

What You've Built

✅ qcow2 disk image created on the host
✅ Alpine Linux installed to disk inside a KVM container
✅ VM boots from disk and survives container restarts
✅ Host filesystem as the persistence layer

What's Next?

That install took a few minutes of interactive prompts. Every time you want a new Alpine VM, you'd repeat it from scratch.

Post #4: We'll skip the installer entirely by using a cloud image — a pre-built disk image ready to boot in seconds.

This guide is Part 3 of the KVM Virtual Machines on Podman series.

Part 1: Build a KVM-Ready Container Image from Scratch
Part 2: KVM Acceleration in a Rootless Podman Container
Coming up in Part 4: Cloud Images — Skip the Installer, Boot in Seconds

Found this helpful?

LinkedIn: Share with your network
Twitter: Tweet about it
Questions? Drop a comment below or reach out on LinkedIn

Published: 6 Apr 2026
Author: David Tio
Tags: KVM, QEMU, Podman, Virtualization, Containers, Alpine Linux, qcow2, Linux, Tutorial
Series: KVM Virtual Machines on Podman
Word Count: ~750

SEO Metadata:

Title: Persistent VMs in Podman: Install Alpine to a qcow2 Disk Image (2026)
Meta Description: Create a qcow2 disk image with qemu-img, install Alpine Linux inside a rootless Podman container, and boot from disk so your VM survives container restarts.
Target Keywords: qcow2 podman vm, persistent vm podman, qemu-img create qcow2, alpine linux install qemu, podman kvm persistent disk, vm disk image container
Series: KVM Virtual Machines on Podman

KVM Acceleration in a Rootless Podman Container: Before and After

David Tio — Mon, 30 Mar 2026 12:53:58 +0000

KVM Acceleration in a Rootless Podman Container: Before and After

Quick one-liner: Pass /dev/kvm into your Podman container, boot Alpine Linux with -nographic, and time the difference between software emulation and hardware acceleration.

Why This Matters

In Post #1, we built a custom qemu:base container image with QEMU fully installed. I mentioned that if you tried to boot a VM without KVM it would be crawling slow. Let's test that theory.

Without KVM, QEMU runs in pure software emulation mode. Every single CPU instruction your VM executes gets translated and re-executed by QEMU on the host. Your modern multi-GHz processor spends most of its time pretending to be a slower, imaginary processor. An OS that boots in 10 seconds on bare metal can take 5–10 minutes in software emulation.

KVM changes everything. KVM (Kernel-based Virtual Machine) is a Linux kernel module that exposes your CPU's hardware virtualization extensions — Intel VT-x or AMD-V — to user-space software like QEMU. Instead of translating instructions, QEMU hands them directly to the CPU. The VM runs at near-native speed.

This post makes that difference measurable. You'll boot Alpine Linux twice — once without KVM, once with — and time both. The gap is dramatic.

Prerequisites

qemu:base image from Post #1
A host CPU with Intel VT-x or AMD-V (most CPUs made after 2010)
Virtualization enabled in your BIOS/UEFI
Alpine Linux 3.23.3 x86_64 ISO (~347 MB) downloaded to your machine

Step 1: Get the Alpine ISO

Alpine Linux is the perfect test ISO: it's tiny, boots fast, and drops you to a login prompt with minimal fanfare. That makes boot time easy to measure.

Download the standard x86_64 ISO:

$ wget https://dl-cdn.alpinelinux.org/alpine/v3.23/releases/x86_64/alpine-standard-3.23.3-x86_64.iso \
    -O ~/Downloads/alpine-standard-3.23.3-x86_64.iso

The download is ~347 MB. Once it's on disk, you'll mount ~/Downloads into the container as /vms.

Step 2: Boot WITHOUT KVM (baseline)

Let's establish the baseline. This is pure software emulation — no KVM, no hardware acceleration.

$ time podman run --rm -it \
    -v ~/Downloads:/vms:z \
    qemu:base \
    qemu-system-x86_64 \
        -nographic \
        -m 512 \
        -cdrom /vms/alpine-standard-3.23.3-x86_64.iso

Watch the output. QEMU will print boot messages, then Alpine's init system will work through its startup sequence. You'll eventually see:

localhost login:

When you see the login prompt, press Ctrl+A then X to exit QEMU. The time command will print how long it took.

On my machine this came in at ~22 seconds. Alpine is small enough that even software emulation is bearable. Write your number down — the comparison with KVM is still telling.

Step 3: Verify KVM is Available on Your Host

Before adding --device /dev/kvm, check that KVM is actually available:

$ ls -la /dev/kvm

You should see something like:

crw-rw----+ 1 root kvm 10, 232 Mar 30 09:00 /dev/kvm

If /dev/kvm doesn't exist, either:

Virtualization is disabled in your BIOS. Reboot, enter your UEFI settings, and look for "Intel Virtualization Technology", "VT-x", or "AMD-V". Enable it.
The KVM kernel module isn't loaded. Run sudo modprobe kvm_intel (or kvm_amd for AMD CPUs).

Also check that your user can access the device:

$ stat /dev/kvm

Rootless Podman passes device permissions through automatically, but your user needs read-write access to /dev/kvm on the host. If you're in the kvm group, you're set:

$ groups | grep kvm

If not: sudo usermod -aG kvm $USER, then log out and back in.

Step 4: Boot WITH KVM

Same command, two additions: --device /dev/kvm for Podman, and -enable-kvm -cpu host for QEMU.

$ time podman run --rm -it \
    --device /dev/kvm \
    -v ~/Downloads:/vms:z \
    qemu:base \
    qemu-system-x86_64 \
        -enable-kvm \
        -cpu host \
        -nographic \
        -m 512 \
        -cdrom /vms/alpine-standard-3.23.3-x86_64.iso

The difference is immediate. Boot messages scroll by quickly. Alpine's init sequence runs in seconds.

Press Ctrl+A then X to exit and check the time output. On my machine:

# Without KVM
real    0m21.868s

# With KVM
real    0m7.814s

3x faster — and that's on a lightweight OS that was already tolerable in software emulation. On a heavier OS the gap is far wider.

Step 5: What the Flags Do

Flag	Where	What It Does
`--device /dev/kvm`	Podman	Passes the KVM character device into the container namespace
`-enable-kvm`	QEMU	Tells QEMU to use the KVM kernel module instead of software emulation
`-cpu host`	QEMU	Exposes the host's actual CPU model and features to the VM (required for full KVM benefit)
`-nographic`	QEMU	Disables the graphical window — redirects all serial output to the terminal
`-m 512`	QEMU	Allocates 512 MB RAM to the VM
`-cdrom /vms/alpine-standard-3.23.3-x86_64.iso`	QEMU	Boots from the mounted ISO
`-v ~/Downloads:/vms:z`	Podman	Bind-mounts your Downloads directory; `:z` sets SELinux relabeling

Why -cpu host and not -cpu qemu64? The default QEMU CPU model (qemu64) is a minimal baseline that works everywhere but exposes no modern CPU extensions. With -cpu host, QEMU passes through all of your CPU's features — AVX, AES-NI, etc. — which is both faster and more realistic for testing.

Why does rootless Podman allow /dev/kvm? Podman uses the --device flag to grant access to specific devices without requiring --privileged. The container gets read-write access to /dev/kvm only, nothing else. This is much safer than running the whole container as root.

What You've Built

✅ KVM device passed into a rootless Podman container
✅ Alpine Linux booted inside the container with hardware acceleration
✅ Before/after timing comparison showing the real-world difference
✅ Hardware-accelerated VM running without root privileges

What's Next?

Right now, every time you stop the container, the VM state disappears. Alpine loses any changes you made. The ISO is read-only. The VM has no persistent disk.

Post #3: We'll create a persistent disk image with qemu-img, attach it to the VM, and install Alpine properly — so the VM survives container restarts.

This guide is Part 2 of the KVM Virtual Machines on Podman series.

Part 1: Build a KVM-Ready Container Image from Scratch
Coming up in Part 3: Persistent Disk Images — Keep Your VM Between Runs

Found this helpful?

LinkedIn: Share with your network
Twitter: Tweet about it
Questions? Drop a comment below or reach out on LinkedIn

Published: 30 Mar 2026
Author: David Tio
Tags: KVM, QEMU, Podman, Virtualization, Containers, Alpine Linux, Linux, Tutorial
Series: KVM Virtual Machines on Podman
Word Count: ~900

SEO Metadata:

Title: KVM Acceleration in a Rootless Podman Container: Before and After (2026)
Meta Description: Enable KVM hardware acceleration in a rootless Podman container. Boot Alpine Linux with and without KVM, time the difference, and understand every flag involved.
Target Keywords: kvm podman rootless, enable kvm container, --device /dev/kvm podman, qemu kvm acceleration, alpine linux qemu container, hardware virtualization podman
Series: KVM Virtual Machines on Podman

Building a Blog Platform with Docker #1: Flask Setup

David Tio — Mon, 30 Mar 2026 10:41:42 +0000

Building a Blog Platform with Docker #1: Flask Setup

Quick one-liner: Get a basic Flask app running with separate CSS — no Docker yet, just Python and a stylesheet.

Why This Matters

I'm building a new blog platform.

The reason is simple: I'm tired of writing HTML by hand. In 2026. For my tech blog. It's embarrassing.

I also want series grouping (so readers can actually navigate my Docker tutorials), and I want to own the platform instead of renting space on Blogger. Plus, I wrote Levelling Docker — might as well apply the same "learn by building" approach to my own infrastructure.

This is the first post in what will be an occasional series. I'll build features, write about them, and share the code. No fixed schedule. No promises about how many posts. We'll see where it goes.

Starting Simple

Today's goal: Get a Flask app running that says "Welcome to David Tio's Blog".

That's it. No Docker yet. No database. No Markdown. Just a basic Python web app.

Docker comes later — only when the app is more or less ready.

The Setup

For this post I'll be using terminal and vscodium. You can use any recent Linux distro and any text editor if you want to follow along.

Create a folder for the project:

$ mkdir tiohub-blog
$ cd tiohub-blog
$ mkdir templates

Set up a virtual environment (always use venv, trust me):

$ python -m venv venv
$ source venv/bin/activate

Now that venv is activated, I will install flask into the virtual environment.

$ pip install flask

Now create the Flask app, app.py:

from flask import Flask, render_template

app = Flask(__name__)

@app.route('/')
def index():
    return render_template('index.html')

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8000, debug=True)

And the template, templates/index.html:

<!DOCTYPE html>
<html>
<head>
    <title>Welcome to David Tio's Blog</title>
</head>
<body>
    <h1>Welcome to David Tio's Blog</h1>
    <p>Building a blog platform with Docker.</p>
</body>
</html>

Run it:

$ python app.py

Visit http://localhost:8000. You'll see... text. Black on white. Very 1993.

It works. It's also ugly. Let's add some styles.

Add a Stylesheet

I don't do inline CSS. Create a separate file from the start.

$ mkdir -p static/css

static/css/style.css:

body {
    background: #0f172a;
    color: #e5e7eb;
    font-family: system-ui, sans-serif;
    max-width: 800px;
    margin: 0 auto;
    padding: 2rem;
    line-height: 1.6;
}

h1 {
    color: #14b8a6;
    border-bottom: 3px solid #14b8a6;
    padding-bottom: 0.5rem;
}

p {
    margin: 1rem 0;
}

Update index.html to link it:

<!DOCTYPE html>
<html>
<head>
    <title>Welcome to David Tio's Blog</title>
    <link rel="stylesheet" href="{{ url_for('static', filename='css/style.css') }}">
</head>
<body>
    <h1>Welcome to David Tio's Blog</h1>
    <p>Building a blog platform with Docker.</p>
</body>
</html>

That url_for thing? Flask generates the correct URL for static files automatically. No hardcoded paths.

Refresh. Dark background, teal heading, centered layout. Much better.

A Few Things to Note

Why separate CSS files? You could inline the styles. For a single page, it's fine. But I've learned the hard way — inline CSS creeps. Next thing you know, your template is 200 lines and half of it is <style> tags.

Separate files mean:

Easier to find your styles
Multiple templates can share the same stylesheet
HTML stays focused on structure
Ready for Tailwind or a build step later

Why url_for? You could hardcode /static/css/style.css. But then if you change your static folder structure, you have to update every template. url_for handles that for you.

Why debug mode? The debug=True flag auto-reloads when you change code. It's great for development. Don't use it in production — we'll fix that when we deploy.

What's the Planned Stack?

For now: Flask + Python + a CSS file. That's it.

I'm thinking SQLite for the database (blogs don't need PostgreSQL). Tailwind CSS for styling eventually (via CDN, no build step). Traefik for routing when we add Docker. Markdown for writing posts.

But here's the thing: this might change. I might swap Traefik for something else. I might decide SQLite isn't enough. I'll figure it out as I build.

The beauty of starting simple is: you can pivot without losing weeks of work.

Coming Up

Next post will probably be Tailwind CSS. I want a proper navigation bar, a footer, maybe some nicer typography.

After that: Markdown support. I want to write .md files and have them render as HTML.

Then: Docker. I'll containerize the Flask app and show you why it's worth the effort.

No timeline on any of this. I'll post when I've built something worth sharing.

If you're following along and want to see something specific, drop a comment or reach out. This is a public build — your feedback might shape what I build next.

Found this helpful?

LinkedIn: Share with your network
Twitter: Tweet about it
Questions? Drop a comment below or reach out on LinkedIn

Published: 29 Mar 2026
Author: David Tio
Tags: Python, Flask, Docker, Blog Platform, Build Log
Word Count: ~800

SEO Metadata

Title: Building a Blog Platform with Docker #1: Flask Setup (2026)
Meta Description: Follow along as I build a blog platform from scratch. Episode 1: Flask setup with separate CSS. Build log with code examples.
Target Keywords: flask setup, python blog build log, docker blog series, flask css separate file, building blog platform 2026
Word Count: ~800

SLES 16: Add a DVD as a Local Zypper Repository (No Subscription Needed)

David Tio — Fri, 27 Mar 2026 23:49:27 +0000

💿 SLES 16: Add a DVD as a Local Zypper Repository (No Subscription Needed)

Quick one-liner: Mount the SLES 16 installation DVD (or ISO) as a local zypper repository so you can install packages without a subscription — perfect for air-gapped environments, home lab testing, or grabbing packages you skipped during installation.

🤔 Why This Matters

SLES out of the box is subscription-gated. Try to install anything with zypper on a fresh system and you'll hit this immediately:

Warning: There are no enabled repositories defined.
Use 'zypper addrepo' or 'zypper modifyrepo' commands to add or enable repositories.

This affects you in three common situations:

🔒 Air-gapped environments — Your network has no path to the SUSE Customer Center. There's no RMT server. zypper simply can't reach anything.

💸 No subscription — You're evaluating SLES in a home lab, or setting up a test box without a paid licence. The online repos are locked behind a registered system.

📦 Missed packages from installation — You kept the installer lean and now realise you need gcc, vim, rsync, or something else that was on the DVD all along. Why re-run the installer when the media is right there?

The DVD you used to install SLES 16 already contains hundreds of packages. Adding it as a local zypper repository unlocks all of them instantly — no internet, no subscription, no reinstall.

✅ Prerequisites

OS: SLES 16 installed and running
Media: SLES 16 Full installation DVD (physical) or ISO file
Access: sudo privileges
Time: ~5 minutes

🔍 Before You Start: Check for an Existing Repository

SLES 16 often creates a DVD repository automatically during installation — it's just disabled by default. Check if it's already there:

cat /etc/zypper/repos.d/SLES.repo

If the file exists, you'll see something like this:

[SLES]
name=SUSE Linux Enterprise Server 16.0
enabled=0
autorefresh=0
baseurl=dvd:/install
type=rpm-md
keeppackages=0

Enable it:

sudo zypper modifyrepo --enable SLES
# or the short form:
sudo zypper mr -e SLES

Then skip straight to Step 5: Install Packages below — you don't need to mount anything manually.

If the file doesn't exist, follow Steps 1–4 below to mount the DVD and add the repository manually.

🔧 Step 1: Mount the DVD

Physical DVD drive:

sudo mkdir -p /mnt/dvd
sudo mount /dev/sr0 /mnt/dvd

Confirm the drive device with lsblk if /dev/sr0 isn't right.

ISO file:

sudo mkdir -p /mnt/dvd
sudo mount -o loop /path/to/SLES-16.0-Full-x86_64.iso /mnt/dvd

Verify the mount:

ls /mnt/dvd

Expected output:

.signature  EFI  LiveOS  boot  install

The packages and repository metadata live inside the install/ subdirectory. You can confirm it's a valid zypper repository with:

ls /mnt/dvd/install/repodata

➕ Step 2: Add the Repository

sudo zypper ar /mnt/dvd SLES16-DVD

zypper discovers the repository metadata automatically — no need to point it at the install/ subdirectory, and no GPG trust prompt.

🔄 Step 3: Refresh the Repository

sudo zypper ref SLES16-DVD

Expected output:

Repository 'SLES16-DVD' is up to date.
All repositories have been refreshed.

📌 Step 4: Make the Mount Persistent (Optional)

The mount disappears after a reboot. For a permanent setup, add it to /etc/fstab.

For a physical DVD:

echo "/dev/sr0  /mnt/dvd  iso9660  ro,noauto  0 0" | sudo tee -a /etc/fstab

For an ISO file:

echo "/path/to/SLES-16.0-Full-x86_64.iso  /mnt/dvd  iso9660  ro,loop,noauto  0 0" | sudo tee -a /etc/fstab

The noauto flag means it won't try to mount at boot (which would fail if the DVD isn't in the drive). Mount it manually when you need it:

sudo mount /mnt/dvd

📥 Step 5: Install Packages

You're ready. Install anything available on the DVD the same way you normally would:

sudo zypper install -y <package-name>

For example:

sudo zypper install -y vim

Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following NEW package is going to be installed:
  vim

1 new package to install.
Overall download size: 1.7 MiB. Already cached: 0 B. After the operation, additional 5.3 MiB will be used.
Continue? [y/n/v/...? shows all options] (y): y

zypper reads directly from the mounted media — no internet, no subscription check.

💡 Not sure what's available? Search the repo before installing:

# If you enabled the default repository:
zypper search --repo SLES <keyword>

# If you added it manually:
zypper search --repo SLES16-DVD <keyword>

🗑️ Removing the Repository

When you no longer need it, clean up:

# If you added it manually:
sudo zypper rr SLES16-DVD
sudo umount /mnt/dvd

# If you enabled the default repository:
sudo zypper mr -d SLES

⚠️ What You Can and Can't Install

The DVD contains everything that shipped with SLES 16 at release — base packages, development tools, and common server software. That covers the vast majority of day-to-day needs.

What it won't have:

Limitation	Details
🔒 Security updates	DVD packages are release-day versions only. Updates require a subscription or a local mirror.
📦 Third-party packages	Anything outside the SLES base (e.g. Docker CE, custom RPMs) needs a separate repo.
🧩 PackageHub / Modules	These are subscription-only channels and aren't on the Full DVD.

For a fully up-to-date air-gapped environment, pair this with a local RMT (Repository Mirroring Tool) server that you sync once and distribute internally.

🚀 What's Next

Need Docker on this SLES system? Check out How to Install Docker Rootless on SLES 15/16

🙌 Found this useful? Share it with anyone setting up SLES in an air-gapped environment.

SEO Metadata:

Title: SLES 16: Add a DVD as a Local Zypper Repository (No Subscription Needed)
Meta Description: Mount the SLES 16 DVD or ISO as a local zypper repository to install packages without a subscription. Works in air-gapped environments. Step-by-step guide.
Target Keywords: sles 16 local repository, zypper add dvd repo, sles no subscription install packages, sles 16 airgap repository, zypper ar iso sles, sles offline package install
Word Count: ~750

Build a KVM-Ready Container Image from Scratch

David Tio — Wed, 25 Mar 2026 14:49:16 +0000

Build a KVM-Ready Container Image from Scratch

Quick one-liner: Learn how to build a custom Podman container image with KVM/QEMU installed — the first step to running hardware-accelerated virtual machines inside containers.

Why This Matters

You've probably heard that containers and virtual machines are different things. Containers share the host kernel. VMs have their own kernel. They're opposites, right?

Well, here's the thing: sometimes you need both.

Maybe you need to test software on a different architecture. Or run a legacy OS that won't work in a container. Or isolate something even more securely than containers provide.

That's where KVM and QEMU come in. QEMU is a free, open-source emulator that can run virtual machines. KVM (Kernel-based Virtual Machine) is the Linux kernel feature that gives QEMU direct access to your CPU's hardware virtualization extensions (Intel VT-x or AMD-V). And yes — you can run them inside a container.

But here's the catch: The official QEMU images are built for specific use cases. If you want full control over what's installed and how it's configured, you need to build your own.

This guide walks you through building a custom Podman container image with QEMU and KVM support installed from scratch. No black boxes. No mystery dependencies. Just you, a Containerfile, and a working KVM setup.

By the end, you'll have:

A custom Containerfile tailored for KVM/QEMU
A working Podman image with QEMU installed
Understanding of what each layer does
A foundation to build on in future posts (next: enable KVM acceleration!)

Prerequisites

Podman installed (rootless mode is the default — see your distro's Podman package)
5-10 minutes to build the image
Terminal access to your Podman host
Basic Containerfile knowledge (FROM, RUN, CMD instructions)

Step 1: Create Your Project Directory

First, let's set up a clean workspace.

$ mkdir -p ~/qemu-container
$ cd ~/qemu-container

You're going to build everything in this directory. When you're done, you can delete it or keep it for reference.

Step 2: Write the Containerfile

Create a file named Containerfile (no extension) in your project directory:

$ nano Containerfile

Here's what goes in it:

# QEMU Container Image — Base Setup
# Build: podman build -t qemu-base .
# Run:   podman run --rm -it qemu-base

FROM ubuntu:24.04

LABEL maintainer="Your Name <your.email@example.com>"
LABEL description="QEMU emulator in a Podman container"
LABEL version="1.0"

# Prevent interactive prompts during package installation
ENV DEBIAN_FRONTEND=noninteractive

# Update package lists and install QEMU
RUN apt-get update && \
    apt-get install -y --no-install-recommends \
        qemu-system-x86 \
        qemu-utils \
        qemu-system-common \
        libvirt-daemon-system \
        libvirt-clients \
        bridge-utils \
        virt-manager \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

# Set working directory for VM files
WORKDIR /vms

# Default command — show QEMU version
CMD ["qemu-system-x86_64", "--version"]

Let me break down what each section does:

Line	What It Does
`FROM ubuntu:24.04`	Start from Ubuntu 24.04 LTS — stable, well-documented, good QEMU support
`ENV DEBIAN_FRONTEND=noninteractive`	Prevents package installation from hanging on configuration prompts
`RUN apt-get update && apt-get install -y`	Updates package lists and installs QEMU packages
`--no-install-recommends`	Skips optional packages — keeps the image smaller
`qemu-system-x86`	The main QEMU emulator for x86_64 machines
`qemu-utils`	Utilities like `qemu-img` for managing disk images
`qemu-system-common`	Common files shared by QEMU system emulators
`libvirt-daemon-system`	Libvirt daemon for managing virtualization
`libvirt-clients`	Client tools like `virsh` to interact with libvirt
`bridge-utils`	Network bridge utilities for VM networking
`virt-manager`	Virtual Machine Manager GUI (optional, useful for testing)
`apt-get clean && rm -rf /var/lib/apt/lists/*`	Cleans up package cache — reduces image size
`WORKDIR /vms`	Sets default working directory for VM files
`CMD ["qemu-system-x86_64", "--version"]`	Shows QEMU version when container starts (useful for testing)

Why Ubuntu? You could use Alpine, Debian, or Fedora. But Ubuntu has the best documentation, largest community, and most stable QEMU packages. For a learning setup, it's the right choice.

Save the file and exit.

Step 3: Build the Image

Now build the image:

$ podman build -t qemu-base .

You should see output like:

STEP 1/10: FROM ubuntu:24.04
STEP 2/10: LABEL maintainer="Your Name <your.email@example.com>"
...
STEP 10/10: CMD ["qemu-system-x86_64", "--version"]
COMMIT qemu-base
--> a1b2c3d4e5f6
Successfully built qemu-base

The build downloads the base Ubuntu image, installs QEMU and all dependencies, then commits the result as qemu-base.

First build tip: The first time you build, it'll take a few minutes to download packages. Subsequent builds are faster because Podman caches layers.

Step 4: Test the Image

Let's verify QEMU is actually installed and working:

$ podman run --rm qemu-base

You should see QEMU's version information:

QEMU emulator version 8.2.2 (Debian 1:8.2.2+ds-0ubuntu1.13)
Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers

Success! QEMU is installed and working inside the container.

But wait — that's just the version check. Let's actually run QEMU interactively:

$ podman run --rm -it qemu-base /bin/bash

You're now inside the container. Try running QEMU directly:

root@container-id:/vms# qemu-system-x86_64 --version

Same version output. Good.

Now let's try something more interesting — boot a tiny test VM:

root@container-id:/vms# qemu-system-x86_64 -cpu help

This lists all CPU models QEMU can emulate. You should see a long list including qemu64, host, Nehalem, Haswell, and many more.

Exit the container:

root@container-id:/vms# exit

Step 5: Check Image Size

Let's see how big this image is:

$ podman images qemu-base

You should see something like:

REPOSITORY           TAG         IMAGE ID      CREATED        SIZE
localhost/qemu-base  latest      568a6950c2ea  5 minutes ago  439 MB

439 MB — pretty reasonable for a full QEMU setup with GUI tools.

Want it smaller? Remove virt-manager and libvirt packages if you only need command-line QEMU. That shaves off ~100 MB. But for learning, the full setup is worth it.

Step 6: Tag and Organize

Let's give this image a better tag for future use:

$ podman tag qemu-base qemu:base

Now you can refer to it as qemu:base instead of qemu-base.

List your images:

$ podman images qemu

You should see both tags pointing to the same image ID:

REPOSITORY   TAG       IMAGE ID       CREATED         SIZE
qemu         base      a1b2c3d4e5f6   3 minutes ago   1.2 GB
qemu-base    latest    a1b2c3d4e5f6   3 minutes ago   1.2 GB

What You've Built

You now have a working QEMU container image with:

✅ QEMU system emulator (x86_64)
✅ Disk image utilities (qemu-img)
✅ Libvirt management tools
✅ Network bridge support
✅ Clean, documented Containerfile

But here's the thing: Right now, this is just an image. You can run QEMU commands, but you can't actually boot a VM yet.

Why? Because you don't have a disk image to boot.

What's Next?

You've got QEMU installed in a container. But if you try to boot a VM right now, it'll be painfully slow — like, 10 minutes to boot an OS that normally boots in 30 seconds.

Why? Because you're using pure software emulation. Every CPU instruction is translated by QEMU instead of running directly on your hardware.

Next time: We'll enable KVM acceleration — Intel VT-x or AMD-V hardware virtualization — and speed up VM boot times by 10-20x.

But there's a catch: KVM requires special device access from inside the container. And that's where things get interesting with Podman.

Want More?

This guide is Part 1 of the KVM Virtual Machines on Podman series. Each post builds on the last, adding one capability at a time.

Coming up in Part 2: Enable KVM Acceleration: 10x Faster VMs in Rootless Podman

📚 Prefer the full book? Check out "Levelling Up with Docker" on Amazon for 14 chapters of practical Docker guides.

📖 Missed a post? Start from the beginning: Run Your First Docker Container

Found this helpful?

LinkedIn: Share with your network
Twitter: Tweet about it
Questions? Drop a comment below or reach out on LinkedIn

Published: 23 Mar 2026
Author: David Tio
Tags: KVM, QEMU, Podman, Virtualization, Containers, Linux, Tutorial
Series: KVM Virtual Machines on Podman
Word Count: ~800

SEO Metadata:

Title: Build a KVM-Ready Container Image from Scratch (2026 Guide)
Meta Description: Learn how to build a custom Podman container image with KVM/QEMU support. Step-by-step guide to creating a Containerfile, building the image, and preparing for hardware-accelerated virtualization.
Target Keywords: kvm podman container, build qemu image, podman build kvm, qemu-system-x86_64 container, rootless kvm, virtualization in containers, hardware acceleration podman
Series: KVM Virtual Machines on Podman

Docker Environment Management: Images, Logs, and Cleanup (2026 Guide)

David Tio — Mon, 23 Mar 2026 10:42:51 +0000

Docker Environment Management: Images, Logs, and Cleanup (2026 Guide)

Quick one-liner: Learn how to manage your Docker environment like a pro — list and remove images, view container logs, use environment variables, and reclaim disk space.

Why This Matters

After running a few containers, your Docker host starts accumulating stuff — images, stopped containers, unused volumes, build caches.

I learned this the hard way. A few months into using Docker, I ran df -h and discovered my home directory was 90% full. Docker had quietly consumed gigabytes of images, orphaned volumes, and build layers.

That's when I learned the prune commands.

This guide covers the essential skills for managing your Docker environment:

Listing and removing images
Viewing container logs
Using environment variables (critical for databases)
Setting restart policies
Cleaning up disk space safely

Prerequisites

Docker installed (rootless mode recommended)
Basic Docker familiarity (run, stop, rm commands)
5 minutes to work through the examples

Managing Images

Every time you run a container from an image you haven't used before, Docker downloads it and stores it locally. Over time, these images consume significant disk space.

List All Images

$ docker images

You'll see something like:

IMAGE                      ID             DISK USAGE   CONTENT SIZE
nginx:latest               dec7a90bd097        240MB         65.8MB
redis:latest               315270d16608        204MB         55.3MB
ghcr.io/jqlang/jq:latest   4f34c6d23f4b       3.33MB         1.03MB
hello-world:latest         85404b3c5395       25.9kB         9.52kB

The SIZE column shows the compressed size on disk. Just four images from following this series and you're already at ~450MB. Multiply that across months of pulling images and you can see why knowing how to manage them matters.

Remove an Image

To remove an image you no longer need:

$ docker rmi hello-world:latest

Note: If a container is still using the image (even a stopped one), Docker will refuse to remove it. Stop and remove the container first, or use the -f flag to force removal.

To remove all unused images at once, see the Cleaning Up Disk Space section below.

Viewing Container Logs

When a container fails to start or behaves unexpectedly, the first thing to check is its logs. Docker captures everything a container writes to standard output and standard error.

View Logs

$ docker logs dtnginx

You should see the nginx startup messages:

/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2026/03/23 10:08:54 [notice] 1#1: using the "epoll" event method
2026/03/23 10:08:54 [notice] 1#1: nginx/1.29.6
2026/03/23 10:08:54 [notice] 1#1: built by gcc 14.2.0 (Debian 14.2.0-19)
2026/03/23 10:08:54 [notice] 1#1: OS: Linux 6.8.0-100-generic
2026/03/23 10:08:54 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2026/03/23 10:08:54 [notice] 1#1: start worker processes
2026/03/23 10:08:54 [notice] 1#1: start worker process 29

The key line to look for is Configuration complete; ready for start up — that confirms nginx started successfully. Everything after that is the worker process startup.

Follow Logs in Real Time

To watch logs as they're written (like tail -f):

$ docker logs -f dtnginx

Press Ctrl+C to stop following.

Show Last N Lines

To see only the last 10 lines:

$ docker logs --tail 10 dtnginx

Combine flags for real-time tailing:

$ docker logs -f --tail 20 dtnginx

Environment Variables

Many Docker images are configured through environment variables rather than configuration files. This makes containers flexible — the same image can behave differently depending on the variables you pass at runtime.

Setting Environment Variables

Use the -e flag to set environment variables when running a container:

$ docker container run -d --name dtpostgres \
    -e POSTGRES_PASSWORD=docker \
    -e POSTGRES_DB=testdb \
    postgres

This starts PostgreSQL with:

Root password set to docker
A database called testdb automatically created

Important: Without POSTGRES_PASSWORD, the PostgreSQL container will refuse to start. It's a security requirement.

Verify Environment Variables

You can verify the variables inside a running container:

$ docker exec dtpostgres env

You should see:

POSTGRES_PASSWORD=docker
POSTGRES_DB=testdb
...

Connect and Use the Database

Once the container is running, connect using the PostgreSQL client inside the container:

$ docker exec -it dtpostgres psql -U postgres -d testdb

You're now inside the PostgreSQL shell. Create a table and insert some data:

CREATE TABLE users (
    id   SERIAL PRIMARY KEY,
    name VARCHAR(50)
);

INSERT INTO users (name) VALUES ('Alice');
INSERT INTO users (name) VALUES ('Bob');

SELECT * FROM users;

You should see:

 id | name
----+-------
  1 | Alice
  2 | Bob
(2 rows)

Exit the PostgreSQL shell:

\q

This confirms that environment variables aren't just startup flags — they configure a working database that you can immediately connect to and use.

Common Environment Variables

Image	Variable	Purpose
`postgres`	`POSTGRES_PASSWORD`	Required — database password
`postgres`	`POSTGRES_DB`	Optional — database to create on startup
`postgres`	`POSTGRES_USER`	Optional — custom username (default: postgres)
`mysql`	`MYSQL_ROOT_PASSWORD`	Required — root password
`redis`	—	No env vars required
`nginx`	—	No env vars required

Pro tip: Each image documents its supported environment variables on its Docker Hub page. Always check before running.

Cleanup

$ docker stop dtpostgres
$ docker rm dtpostgres

Restart Policies

By default, a container stays stopped if it crashes or if the Docker host reboots. Restart policies tell Docker to automatically restart containers.

Available Restart Policies

Policy	Behavior
`no`	Do not restart (default)
`on-failure`	Restart only if the container exits with a non-zero exit code
`always`	Always restart, including after host reboot
`unless-stopped`	Like `always`, but does not restart if you manually stopped the container

Run Container with Restart Policy

$ docker run -d --restart unless-stopped --name dtnginx nginx

If you reboot your Docker host, this container will start automatically. If you manually run docker stop dtnginx, it will stay stopped until you explicitly start it again.

Update Restart Policy of Existing Container

$ docker update --restart unless-stopped dtnginx

Cleanup

$ docker stop dtnginx
$ docker rm dtnginx

Cleaning Up Disk Space

After working with Docker for a while, your host will have accumulated:

Stopped containers
Unused images
Dangling build layers
Orphaned volumes

Docker provides prune commands to reclaim this space.

Check Disk Usage

See how much disk space Docker is using:

$ docker system df

You'll see something like:

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          5         2         1.2GB     800MB (66%)
Containers      3         1         50MB      40MB (80%)
Local Volumes   2         1         200MB     100MB (50%)
Build Cache     10        0         300MB     300MB (100%)

The RECLAIMABLE column shows how much space you can free up.

Remove Stopped Containers

$ docker container prune

Remove Unused Images

$ docker image prune -a

Clean Up Everything at Once

To clean up stopped containers, unused images, networks, and build cache:

$ docker system prune -a

Docker will ask for confirmation before proceeding. This is a safe way to reclaim disk space, but make sure you don't need any of the stopped containers or unused images before running it.

Exercise

This exercise demonstrates something important — and sets up exactly why you'll need Docker volumes in the next post.

Your Tasks

Start a MySQL container named dtmysql with MYSQL_ROOT_PASSWORD=docker and MYSQL_DATABASE=testdb
Verify the environment variables are set inside the running container
Connect to MySQL and create a users table, insert a row with the name Alice, then query it back
Stop and delete the container
Start a fresh dtmysql container with the same environment variables and try to query the users table again
Clean up

Try it yourself before reading the solution below.

Solution

1. Start MySQL:

$ docker run -d --name dtmysql \
    -e MYSQL_ROOT_PASSWORD=docker \
    -e MYSQL_DATABASE=testdb \
    mysql

2. Verify env vars:

$ docker exec dtmysql env | grep MYSQL

3. Connect and insert data:

$ docker exec -it dtmysql mysql -u root -pdocker testdb

Inside the MySQL shell:

CREATE TABLE users (name VARCHAR(50));
INSERT INTO users VALUES ('Alice');
SELECT * FROM users;

You should see:

+-------+
| name  |
+-------+
| Alice |
+-------+

exit

4. Stop and delete the container:

$ docker stop dtmysql
$ docker rm dtmysql

5. Start a fresh container and query:

$ docker run -d --name dtmysql \
    -e MYSQL_ROOT_PASSWORD=docker \
    -e MYSQL_DATABASE=testdb \
    mysql

Wait a few seconds for MySQL to initialise, then:

$ docker exec -it dtmysql mysql -u root -pdocker testdb -e "SELECT * FROM users;"

ERROR 1146 (42S02): Table 'testdb.users' doesn't exist

Alice is gone. The container was deleted, and everything inside it went with it.

This is the fundamental problem with containers: they're ephemeral by design. For stateless apps like nginx, that's fine. For databases, it's a disaster.

Coming up next: Docker volumes — the solution to exactly this problem.

6. Clean up:

$ docker stop dtmysql && docker rm dtmysql

What's Next

Now you can manage your Docker environment effectively:

Keep images organized — remove what you don't need
Debug with logs — find issues quickly
Configure with env vars — run databases and other configurable images
Auto-restart containers — survive reboots
Reclaim disk space — prune safely

Coming up: Docker persistent volumes — keep your data safe across container restarts and removals.

Want More?

This guide covers the basics from Chapter 4: Managing Docker Environment in my book, "Levelling Up with Docker" — 14 chapters of practical, hands-on Docker guides.

📚 Grab the book: "Levelling Up with Docker" on Amazon

Found this helpful?

LinkedIn: Share with your network
Twitter: Tweet about it
Questions? Drop a comment below or reach out on LinkedIn

Published: 23 Mar 2026
Author: David Tio
Word Count: ~1,100

SEO Metadata:

Title: Docker Environment Management: Images, Logs, and Cleanup (2026 Guide)
Meta Description: Learn how to manage your Docker environment — list and remove images, view container logs, use environment variables, and reclaim disk space. Includes a hands-on MySQL exercise that shows exactly why volumes matter.
Target Keywords: docker images command, docker logs, docker environment variables, docker system prune, docker image prune, docker cleanup, docker env flag, beginner docker tutorial 2026

Run Your First Docker Container (2026 Step-by-Step)

David Tio — Mon, 16 Mar 2026 01:54:00 +0000

Run Your First Docker Container (2026 Step-by-Step)

Quick one-liner: Learn how to run your first Docker container — from finding images on Docker Hub to accessing the container shell and cleaning up properly.

Why This Matters

Now that Docker is installed, it's time to run your first container.

If you're like most people starting with Docker, you might be tempted to just copy-paste commands without understanding what they do. I've been there. But here's the thing: knowing what each flag does means you'll understand what's happening when you run a container.

This guide walks you through running your first real container, step by step. No copy-paste without explanation. Every command broken down.

By the end, you'll know how to:

Find and pull images from Docker Hub
Run containers with the right flags
Access a running container's shell
Stop and clean up properly

Prerequisites

Docker installed (rootless mode recommended — see Ubuntu guide or SLES guide)
5 minutes to run your first container
Terminal access to your Docker host

Finding Images on Docker Hub

Docker Hub is the primary registry for Docker images. Think of it as an app store for containers.

You can browse at hub.docker.com or search from the command line:

$ docker search nginx

Look for images with the Official badge — these are maintained by the software's creators and are regularly updated with security patches.

My advice: If there's an official image, use it. It's more likely to be secure, up-to-date, and well-maintained.

If there's no official image, look for:

High download counts
Recent updates
Good star ratings

Each image page shows:

Available tags (versions) — for example, nginx:latest, nginx:1.25, nginx:alpine
Usage instructions and supported environment variables
Pull count and last update date

Note: When no tag is specified, Docker uses latest by default. For production, pin to a specific version like nginx:1.25 so your builds don't break when a new version drops.

Running Your First Container

Let's run nginx — the most popular web server.

$ docker container run -d --rm --name dtnginx nginx

Let me break down each flag:

Flag	What It Does
`-d`	Detach — runs in the background so your terminal stays free
`--rm`	Auto-remove — deletes the container when it stops (keeps things clean)
`--name dtnginx`	Name it — use "dtnginx" instead of a random ID like "a1b2c3d4e5f6"
`nginx`	The image — pulled from Docker Hub if not already present

The first time you run this, Docker downloads the image:

Unable to find image 'nginx:latest' locally
latest: Pulling from library/nginx
09f376ebb190: Pull complete
5529e0792248: Pull complete
Status: Downloaded newer image for nginx:latest

And... done. The container is now running in the background. You didn't see anything pop up, but trust me, it's there.

Checking Container Status

Let's verify it's actually running.

$ docker ps

You should see:

CONTAINER ID   IMAGE   COMMAND                  CREATED   STATUS         PORTS   NAMES
a1b2c3d4e5f6   nginx   "/docker-entrypoint..."   5 sec    Up 4 seconds   80/tcp   dtnginx

A few things to note:

CONTAINER ID — you can use this to manage the container. But since we gave it a name (dtnginx), just use that. It's way easier to remember.
PORTS — shows nginx is listening on port 80 inside the container. You can't access it from your host yet — we'll cover port forwarding in a later video.
STATUS — "Up 4 seconds" means it's running.

To see all containers (including stopped ones):

$ docker ps -a

Accessing the Container Shell

Here's something cool — you can open a shell inside a running container.

$ docker exec -it dtnginx /bin/bash

Let me explain the flags:

Flag	What It Does
`-i`	Keeps standard input open — so you can type commands
`-t`	Allocates a terminal — so you get a proper prompt

Together, -it is what you'll use 99% of the time.

Important: The best command to access a container depends on what's inside.

nginx, Ubuntu, Debian → /bin/bash works
Alpine-based images → Use /bin/sh instead (bash isn't installed)
Redis → Has /bin/bash and /bin/sh, but redis-cli is more useful for interacting with the database

Always check the image documentation on Docker Hub to see what's available.

You're now inside the container. Check the prompt — it probably says something like root@a1b2c3d4e5f6.

You're root inside this container. But remember, this is isolated from your host system.

Let's verify nginx is actually running. The official nginx image includes curl:

dtnginx# curl localhost

You should see the default nginx welcome page HTML:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...

Exit the container shell:

dtnginx# exit

And you're back on your host system.

Stopping and Cleaning Up

To stop the container:

$ docker stop dtnginx

Because we used --rm when we created it, the container is automatically removed after stopping.

Let's confirm:

$ docker ps -a

If you don't see dtnginx, that's good — it was automatically removed.

Note: If you had started a container without --rm, it would stick around in a stopped state. In that case, you'd need to clean it up manually:

$ docker rm dtnginx

Good habit to get into — clean up your stopped containers. If you have the containers from previous tutorials that are not removed and randomly named, you can remove them using the following command:

$ docker container rm container_id

Exercise

Try it yourself.

Part 1: nginx with Shell Access

Run an nginx container named dtnginx in detached mode without the --rm flag
Access the shell with docker exec -it dtnginx /bin/bash
Verify nginx is running by running curl localhost inside the container
Exit the container shell
Stop the container with docker stop dtnginx
Verify that it was not removed with docker ps -a
Remove the container with docker rm dtnginx

Part 2: Redis with redis-cli (No Shell Needed)

Not all containers require a shell to be useful. Redis is a great example — while it does have /bin/bash and /bin/sh available, the native redis-cli tool is far more useful for interacting with the database.

Run a Redis container named dtredis with the --rm flag:

   docker run -d --rm --name dtredis redis

Access Redis using redis-cli directly:

   docker exec -it dtredis redis-cli

Set and get a key:

   127.0.0.1:6379> SET mykey "Hello from Docker!"
   OK
   127.0.0.1:6379> GET mykey
   "Hello from Docker!"

Exit redis-cli:

   127.0.0.1:6379> exit

Stop the container:

   docker stop dtredis

Key takeaway: The command you use to access a container depends on what's inside. For shells, try /bin/bash first, then /bin/sh. For databases and specialized applications, use their native CLI tools (redis-cli, psql, mysql, etc.) — they're often more useful than a generic shell.

Coming up: Learn how to manage your Docker environment — listing images, viewing logs, using environment variables, and cleaning up disk space. Then we'll cover Docker volumes to keep your data safe across container restarts.

Want More?

This guide covers the basics from Chapter 3: Running Docker Images in my book, "Levelling Up with Docker" — 14 chapters of practical, hands-on Docker guides.

📚 Grab the book: "Levelling Up with Docker" on Amazon

Found this helpful?

LinkedIn: Share with your network
Twitter: Tweet about it
Questions? Drop a comment below or reach out on LinkedIn

Published: 17 Mar 2026
Author: David Tio
Tags: Docker, Beginners, Tutorial, Linux, DevOps, Container
Word Count: ~900

SEO Metadata:

Title: Run Your First Docker Container (2026 Step-by-Step)
Meta Description: Learn how to run your first Docker container — from finding images on Docker Hub to accessing the container shell and cleaning up properly. Step-by-step guide for beginners.
Target Keywords: docker run command, first docker container, docker exec, docker ps, docker stop, docker hub search, beginner docker tutorial 2026
Word Count: ~900