DEV Community: David Tio

Customizing Docker Images: Write Your First Dockerfile (2026)

David Tio — Mon, 25 May 2026 10:04:18 +0000

Quick one-liner: Pre-built images are convenient until they break. A Dockerfile turns your app into a portable, reproducible artifact you can fix, rebuild, and own.

🤔 Why This Matters

In episode 10, we fixed the startup race. Ghost now waits for MySQL to be genuinely ready before starting. The stack is stable.

But after docker compose down --volumes, you rebuild from scratch: new theme, default config, all manual setup repeated. The image pulled from Docker Hub does not remember your changes.

That is not a Ghost problem. That is what it looks like when you do not own the image.

A Dockerfile is how you own it. You start from a base, install what you need, bake in configuration, and define exactly what runs when the container starts. The result is an artifact that rebuilds cleanly and consistently every time.

This episode covers the fundamentals: FROM, WORKDIR, COPY, RUN, EXPOSE, and CMD. The example is a Flask app — small enough to understand, realistic enough to matter.

✅ Prerequisites

Ep 1-10 completed. You are comfortable with Compose files, multi-service stacks, and health checks.

🗂 Project Structure

Create a working directory for this episode:

$ mkdir -p ~/noteboard
$ cd ~/noteboard

You will create three files:

noteboard/
├── app.py
├── requirements.txt
└── Dockerfile

✍️ The App

Create a minimal Flask app:

$ vi app.py

from flask import Flask

app = Flask(__name__)

@app.route("/")
def index():
    return "<h1>Noteboard</h1><p>Hello.</p>"

Create the requirements file — just Flask for now:

$ vi requirements.txt

flask==3.1.3

🐳 First Dockerfile: Flask Dev Server

Write your first Dockerfile:

$ vi Dockerfile

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY app.py .
EXPOSE 5000
CMD ["flask", "run", "--host=0.0.0.0"]

Here is what each instruction does:

Instruction	What It Does
`FROM python:3.12-slim`	Start from the official Python 3.12 slim image — smaller footprint, versioned base
`WORKDIR /app`	Set the working directory inside the container. All following instructions run here
`COPY requirements.txt .`	Copy the requirements file from your host into `/app`
`RUN pip install ...`	Install dependencies at build time. This layer is cached until `requirements.txt` changes
`COPY app.py .`	Copy the app source code
`EXPOSE 5000`	Document that this container listens on port 5000
`CMD [...]`	The command that runs when the container starts

EXPOSE does not publish the port. It is documentation — a signal to whoever runs the image that port 5000 is where the app listens. You still need -p at runtime.

Build and run:

$ docker build -t noteboard .
$ docker run -d -p 5000:5000 --name noteboard noteboard

Test it:

$ curl http://localhost:5000

<h1>Noteboard</h1><p>Hello.</p>

It works. Now check the logs:

$ docker logs noteboard

 * Debug mode: off
WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on all addresses (0.0.0.0)
 * Running on http://127.0.0.1:5000
 * Running on http://172.17.0.2:5000

That warning is not a style note. Flask's built-in server is single-threaded. It handles one request at a time. Under concurrent load it queues and drops connections. It is not designed to serve real traffic.

Stop the container before moving on:

$ docker stop noteboard && docker rm noteboard

🔧 Fix It: Switch to Gunicorn

Gunicorn is a production-grade WSGI server. It runs multiple worker processes, handles concurrent requests, and does not print warnings about being unsuitable for deployment.

Add it to requirements.txt:

$ vi requirements.txt

flask==3.1.3
gunicorn==22.0.0

Update the CMD in your Dockerfile:

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY app.py .
EXPOSE 5000
CMD ["gunicorn", "--bind", "0.0.0.0:5000", "app:app"]

Rebuild and run:

$ docker build -t noteboard .
$ docker run -d -p 5000:5000 --name noteboard noteboard
$ docker logs noteboard

[2026-05-25 08:00:00 +0000] [1] [INFO] Starting gunicorn 22.0.0
[2026-05-25 08:00:00 +0000] [1] [INFO] Listening at: http://0.0.0.0:5000 (1)
[2026-05-25 08:00:00 +0000] [7] [INFO] Booting worker with pid: 7

No warning. One line change in the Dockerfile — that is what owning the image gives you.

One thing to notice about the ordering: requirements.txt is copied and installed before app.py. This is deliberate. Docker caches each layer. When you change app.py, Docker reuses the cached pip install layer and only rebuilds from COPY app.py onward. Reverse the order and every code change triggers a full reinstall.

🔨 Verify the Build

$ docker images noteboard

IMAGE              ID             DISK USAGE   CONTENT SIZE
noteboard:latest   a1b2c3d4e5f6        196MB         48.6MB

$ curl http://localhost:5000

<h1>Noteboard</h1><p>Hello.</p>

🔁 The Rebuild Workflow

Edit app.py to change the response:

@app.route("/")
def index():
    return "<h1>Noteboard</h1><p>Version 2.</p>"

Stop the running container, rebuild, and redeploy:

$ docker stop noteboard && docker rm noteboard
$ docker build -t noteboard .
$ docker run -d -p 5000:5000 --name noteboard noteboard
$ curl http://localhost:5000

On the second build, Docker reuses the cached install layer:

 => CACHED [4/5] RUN pip install --no-cache-dir -r requirements.txt
 => [5/5] COPY app.py .

Only the changed layers rebuild. This is why layer ordering matters.

🏷️ Tagging Your Builds

Every image you have built so far has been tagged latest. That is the default when you do not specify one. But latest is just a label — it has no special meaning. It does not mean newest, it does not update automatically. It is whatever you last tagged with it.

As your app evolves, version tags give you something latest cannot: the ability to know exactly what is running and to go back to a previous version if something breaks.

Tag your current build as 0.1:

$ docker build -t noteboard:0.1 .

Now edit app.py to mark the next release:

@app.route("/")
def index():
    return "<h1>Noteboard</h1><p>Version 1.0 — stable.</p>"

Build it as 1.0:

$ docker build -t noteboard:1.0 .

List both:

$ docker images noteboard

IMAGE              ID             DISK USAGE   CONTENT SIZE
noteboard:1.0      b2f3a4c5d6e7        196MB         48.6MB
noteboard:0.1      a1b2c3d4e5f6        196MB         48.6MB

Both images exist on your host. You can run either by name:

$ docker run -d -p 5000:5000 --name noteboard noteboard:1.0
$ curl http://localhost:5000

<h1>Noteboard</h1><p>Version 1.0 — stable.</p>

If 1.0 breaks something, switching back is one flag change:

$ docker stop noteboard && docker rm noteboard
$ docker run -d -p 5000:5000 --name noteboard noteboard:0.1

Stop the container before moving on:

$ docker stop noteboard && docker rm noteboard

✏️ Renaming an Image

Docker does not have a rename command. You rename an image by tagging it with the new name and removing the old tag.

Say you want to rename noteboard to myapp:

$ docker tag noteboard:1.0 myapp:1.0
$ docker rmi noteboard:1.0

docker tag creates a new name pointing at the same image layers — nothing is copied or rebuilt. docker rmi removes the old name. The underlying image data stays on disk as long as at least one tag points to it.

You can also use this to promote a tested version to latest:

$ docker tag noteboard:1.0 noteboard:latest

Now noteboard:latest and noteboard:1.0 both point to the same image. Pulling or running noteboard without a tag will use it.

🗄️ Baking Init Scripts into Database Images

The Flask example showed how to control what your app runs. Official database images go further — they provide a hook specifically for initialization.

Both MariaDB and Postgres run any .sql or .sh files placed in /docker-entrypoint-initdb.d/ on first startup. Drop your schema there and the database initializes itself. No manual connection, no migration script, no extra setup step.

Create a working directory:

$ mkdir -p ~/mariadb-custom
$ cd ~/mariadb-custom

Create the SQL file:

$ vi init.sql

CREATE TABLE notes (
    id INT AUTO_INCREMENT PRIMARY KEY,
    content TEXT NOT NULL,
    created_at TIMESTAMP DEFAULT NOW()
);

Write the Dockerfile:

$ vi Dockerfile

FROM mariadb:11
COPY init.sql /docker-entrypoint-initdb.d/

Build and run:

$ docker build -t mariadb-custom .
$ docker run -d \
    -e MARIADB_ROOT_PASSWORD=docker \
    -e MARIADB_DATABASE=appdb \
    --name mariadb-custom \
    mariadb-custom

Wait a few seconds for initialization, then verify the table was created:

$ docker exec -it mariadb-custom mariadb -uroot -pdocker appdb -e "SHOW TABLES;"

+------------------+
| Tables_in_appdb  |
+------------------+
| notes            |
+------------------+

Cleanup:

$ docker stop mariadb-custom && docker rm mariadb-custom

The table exists because the init script ran at first startup. Tear it down and bring it back up — the schema is part of the image, not a step you repeat.

🧪 Exercise 1: Auto-Initialize a Postgres Schema

Postgres supports the same /docker-entrypoint-initdb.d/ hook as MariaDB. Apply the same pattern using a Postgres image.

Create the project folder:

$ mkdir -p ~/pgcustom
$ cd ~/pgcustom

Create the SQL file:

$ vi init.sql

CREATE TABLE notes (
    id SERIAL PRIMARY KEY,
    content TEXT NOT NULL,
    created_at TIMESTAMP DEFAULT NOW()
);

Write the Dockerfile:

$ vi Dockerfile

FROM postgres:16
COPY init.sql /docker-entrypoint-initdb.d/

Build and run:

$ docker build -t pgcustom .
$ docker run -d \
    -e POSTGRES_PASSWORD=docker \
    -e POSTGRES_DB=appdb \
    --name pgcustom \
    pgcustom

Wait a few seconds, then verify the table was created:

$ docker exec -it pgcustom psql -U postgres -d appdb -c "\dt"

        List of relations
 Schema | Name  | Type  |  Owner
--------+-------+-------+----------
 public | notes | table | postgres

Cleanup:

$ docker stop pgcustom && docker rm pgcustom

The schema was created at first startup — no manual psql session, no migration script, just a COPY instruction in the Dockerfile.

🧪 Exercise 2: Bake a Custom Theme into a Ghost Image

In episode 10, you ran Ghost with health checks. But after docker compose down --volumes, Ghost starts fresh — database wiped, any configuration you applied through the UI gone.

In this exercise, you will modify Ghost's default theme directly in the image. The change is visible the moment Ghost starts — no admin registration, no theme activation, no re-uploading after teardown.

Ghost ships with a theme called source that is active by default. Its templates live at /var/lib/ghost/current/content/themes/source/. Replacing default.hbs in your Dockerfile replaces it in the image layer — Ghost loads your version on every startup.

Create a fresh project folder:

$ mkdir -p ~/ghost-custom
$ cd ~/ghost-custom

Create config.production.json:

$ vi config.production.json

{
  "url": "http://localhost:2368",
  "server": {
    "host": "::",
    "port": 2368
  },
  "database": {
    "client": "mysql",
    "connection": {
      "host": "db",
      "user": "ghost",
      "password": "ghostpass",
      "database": "ghost",
      "port": 3306
    }
  },
  "mail": {
    "transport": "SMTP",
    "options": {
      "host": "mail",
      "port": 1025
    }
  }
}

Extract the original default.hbs from the Ghost image:

$ docker run --rm ghost:5-alpine \
    cat /var/lib/ghost/current/content/themes/source/default.hbs > default.hbs

Edit it to add a banner. Find the <div class="gh-viewport"> line and add the banner immediately after it:

$ vi default.hbs

 <div class="gh-viewport">
+
+    <div style="background:#0f766e;color:white;text-align:center;padding:0.75rem;font-size:0.9rem;font-family:sans-serif;">
+        Running on a custom Ghost image — theme baked in at build time.
+    </div>
+
     {{> "components/navigation" navigationLayout=@custom.navigation_layout}}

Write the Dockerfile:

$ vi Dockerfile

FROM ghost:5-alpine
COPY config.production.json /var/lib/ghost/config.production.json
COPY default.hbs /var/lib/ghost/current/content/themes/source/default.hbs

Build the image:

$ docker build -t ghost-custom .

Create the Compose file:

$ vi docker-compose.yml

services:
  db:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD: rootpass
      MYSQL_DATABASE: ghost
      MYSQL_USER: ghost
      MYSQL_PASSWORD: ghostpass
    healthcheck:
      test: ["CMD-SHELL", "mysqladmin ping -h localhost -ughost -pghostpass --silent"]
      interval: 5s
      timeout: 3s
      retries: 12
      start_period: 10s

  mail:
    image: axllent/mailpit:latest
    ports:
      - "8025:8025"

  app:
    image: ghost-custom
    ports:
      - "2368:2368"
    depends_on:
      db:
        condition: service_healthy
      mail:
        condition: service_started

Bring it up:

$ docker compose up -d

Visit http://localhost:2368. The teal banner appears at the top.
Now tear it down and bring it back:

$ docker compose down --volumes
$ docker compose up -d

Visit http://localhost:2368 again. The banner is still there.

The database was wiped. The theme modification was not — it is part of the image.

🏁 What You Built

What	Why It Matters
`FROM python:3.12-slim`	Starts from a clean, versioned base instead of inheriting unknown state
`WORKDIR`	Sets a predictable working directory — no scattered files across the container filesystem
Layer ordering	`requirements.txt` before `app.py` — expensive installs are cached; only changed code rebuilds
Gunicorn instead of dev server	Removes the dev server warning and makes the app production-capable
`/docker-entrypoint-initdb.d/` hook	Schema baked into database images — first startup initializes without manual intervention, works on both MariaDB and Postgres
Version tags (`0.1`, `1.0`)	Each build is addressable — you know what is running and can roll back without rebuilding
Modified source theme baked into Ghost image	Change is visible immediately at startup — no registration, no theme activation, survives `down --volumes`

Coming up: You built two images this episode. Both work. Neither is reachable without a port number in the URL. How many of your users are typing :2368? Next episode, we fix that.

Building a Blog Platform with Docker #5: Add a Dockerfile + Deploy to Clouderized

David Tio — Sun, 24 May 2026 15:14:21 +0000

🐳 Building a Blog Platform with Docker #5: Add a Dockerfile + Deploy to Clouderized

Quick one-liner: Write a Dockerfile, build an image, and deploy to Clouderized with one git push so your Flask blog goes live with automatic HTTPS and zero server babysitting.

🔧 Before We Start: URL Control for Blogger Migration

Before touching Docker, there's one fix from Episode 4 worth making now.

Right now our platform builds URLs from the filename: hey-markdown.md becomes /2026/04/hey-markdown.html. That works for new posts, but not for migrated Blogger URLs:

Blogger URL	Filename-based URL
`/2026/03/docker-rootless-on-ubuntu-2026-guide.html`	`/2026/03/docker-rootless-ubuntu.html`

We add canonical_url to frontmatter and use it for two things:

The actual URL this platform serves the post at — so migrated posts keep their Blogger paths
<link rel="canonical"> — tells Google this page is the same content as the old Blogger URL

Update content/posts/hey-markdown.md:

---
title: "Hey Markdown"
date: 2026-04-25
description: "The first post written in Markdown — no more writing HTML by hand."
tags: [meta, blog]
canonical_url: "https://blog.dtio.app/2026/04/old-markdown.html"
---

The mismatch is intentional: filename and served path can differ.

Add a URL Helper to `app.py`

Open app.py. Add this import at the top:

from urllib.parse import urlparse

Then add a get_post_path() function below parse_post():

def get_post_path(meta):
    """Determine the URL path for a post from its canonical_url."""
    if meta.get('canonical_url'):
        return urlparse(meta['canonical_url']).path
    # Fallback: auto-generate from date + slug
    slug = meta.get('slug', 'unknown')
    date = meta.get('date', '')
    if hasattr(date, 'year'):
        return f'/{date.year}/{date.month:02d}/{slug}.html'
    return f'/{slug}.html'

This helper extracts the URL path from canonical_url, with a date+slug fallback.

Update `get_all_posts()`

In the existing get_all_posts() function, add the path field:

def get_all_posts():
    posts = []
    posts_dir = 'content/posts'
    for filename in os.listdir(posts_dir):
        if not filename.endswith('.md'):
            continue
        filepath = os.path.join(posts_dir, filename)
        post = parse_post(filepath)
        post['slug'] = filename[:-3]
        post['path'] = get_post_path(post)
        posts.append(post)
    posts.sort(key=lambda p: p.get('date', ''), reverse=True)
    return posts

Each post now has a path field — the exact URL it should be served at.

Update the Route

Find the existing route in app.py:

@app.route('/<int:year>/<int:month>/<slug>')
def post(year, month, slug):
    filepath = f'content/posts/{slug}.md'
    if not os.path.exists(filepath):
        abort(404)
    post = parse_post(filepath)
    return render_template('post.html', post=post)

Replace it with this dynamic lookup:

@app.route('/<int:year>/<int:month>/<path:slug>.html')
def post(year, month, slug):
    target_path = f'/{year}/{month:02d}/{slug}.html'
    all_posts = get_all_posts()
    matching_post = next((p for p in all_posts if p['path'] == target_path), None)

    if not matching_post:
        abort(404)

    post_data = parse_post(f'content/posts/{matching_post["slug"]}.md')
    post_data['path'] = matching_post['path']
    return render_template('post.html', post=post_data)

This route matches .html URLs, finds the matching post['path'], and loads the correct markdown file.

Update the Homepage Links

In templates/index.html, replace the manually constructed URL with the post's path:

<a href="{{ post.path }}">{{ post.title }}</a>

And for the "Read more" link:

<a href="{{ post.path }}" class="text-teal-400 text-sm hover:text-teal-300 font-medium transition-colors duration-200">
    Read more →
</a>

Add the Canonical Link Tag

In templates/post.html, add the canonical link tag inside <head>, after the meta description:

<meta name="description" content="{{ post.description }}">
{% if post.canonical_url %}
<link rel="canonical" href="{{ post.canonical_url }}">
{% endif %}

The {% if %} guard keeps the tag optional for posts without canonical_url.

Updated Frontmatter Schema

This is now the full frontmatter schema going forward:

Field	Used for
`title`	`<title>` tag, `<h1>` on post page, post list
`date`	URL generation, sorting, display
`description`	`<meta name="description">`, excerpt on homepage
`tags`	Tag pills on post page, eventually tag pages in Ep12
`canonical_url`	Homepage links + `<link rel="canonical">` for Blogger migration (optional)

When migrating posts, set canonical_url to match the original Blogger URL.

✅ Step 1: Verify Everything Works Locally

Before touching Docker, make sure the platform still runs correctly after the URL changes.

Activate your venv and run the app:

$ source venv/bin/activate
$ python app.py

Visit http://localhost:8000 and check:

Homepage — posts listed, links point to the correct paths
Post page — renders correctly, <link rel="canonical"> is present in the HTML source (view source and search for canonical)
Tag pills — display correctly on post pages

Once everything works locally, we're ready to containerise it.

📦 Step 2: Add a .dockerignore

Before writing the Dockerfile, tell Docker what to leave out of the image. Create .dockerignore in the project root:

venv/
__pycache__/
*.pyc
.git/
.gitignore

This keeps the image lean and avoids shipping local environment files.

📄 Step 3: Write the Dockerfile

Create Dockerfile in the project root:

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 8000

CMD ["python", "app.py"]

Why this order matters:

copy requirements.txt first so dependency install can be cached
copy app code after that so normal code edits rebuild quickly

🔨 Step 4: Build the Image

Make sure you're in the project root (where the Dockerfile is):

$ docker build -t tioblog .

When it finishes, verify the image exists:

$ docker images tioblog
IMAGE            ID             DISK USAGE   CONTENT SIZE   EXTRA
tioblog:latest   05dbc52b9852        231MB         55.6MB

🚀 Step 5: Run It

$ docker run -p 8000:8000 tioblog

Visit http://localhost:8000. The blog loads — same as before, but now running inside a container.

📝 Step 6: Add .gitignore

Before pushing to Clouderized, make sure you're not committing things that don't belong in the repo. Create .gitignore in the project root:

venv/
__pycache__/
*.pyc
.env

This keeps your virtual environment, cache files, and any local config out of version control.

🌐 Step 7: Deploy to Clouderized

Clouderized is the deployment target in this series because it is optimized for simple container app shipping: push to Git, auto-build, auto-deploy, HTTPS on by default.

For this blog, deployment is:

$ git init
$ git add .
$ git commit -m "Initial commit for tioblog"
$ git branch -M main
$ git remote add origin https://git.clouderized.com/davidtio/tioblog.git
$ git push -u origin main

https://git.clouderized.com/davidtio/tioblog.git uses davidtio as the Clouderized username and tioblog as the project name.
For your app, use:

https://git.clouderized.com/<username>/<project>.git

After a minute or two, your blog is live at:

https://davidtio-tioblog.clouderized.com

Same Dockerfile, now running publicly with HTTPS.

Add Your Custom Domain

Clouderized also supports custom domains. For this blog, production runs at blog.dtio.app.

Go to https://dash.clouderized.com
Open the tioblog app card
Click Domains
Add your custom domain (for example blog.dtio.app)
Copy the cfargotunnel target shown by Clouderized
Create a CNAME record for your domain and point it to the cfargotunnel target

After DNS propagates, your app is served on your own domain while Clouderized continues handling routing and HTTPS.

Why this matters for small creator platforms:

you keep one deployment unit (your Docker image)
you avoid hand-maintained reverse proxy and certificate setup
you can ship content and app changes with the same Git workflow

🧪 Step 8: Verify It's Live

Open your browser and check the live URL:

https://davidtio-tioblog.clouderized.com

Confirm the homepage loads, posts are listed, and a .html post URL works:

https://davidtio-tioblog.clouderized.com/2026/04/hey-markdown.html

This matches Blogger-style URLs for smoother migration.

Also verify HTTPS is active and the cert is valid. On Clouderized this is automatic, so you can focus on content and product work instead of infra chores.

✅ What You've Built

tiohub-blog/
├── Dockerfile         ← new
├── .dockerignore      ← new
├── app.py             (get_post_path, post['path'] in get_all_posts, route adds post['path'])
├── requirements.txt
├── static/
│   └── js/
│       ├── tailwind.config.js
│       └── code-blocks.js
├── templates/
│   ├── index.html     (links use {{ post.path }} instead of manual URLs)
│   └── post.html      (<link rel="canonical"> added)
└── content/
    └── posts/
        ├── hey-markdown.md  (canonical_url added to frontmatter)
        └── second-post.md

What changed:

canonical_url and post.path now drive stable post URLs
dynamic route resolves URL path to the right markdown file
homepage links use {{ post.path }}
optional canonical tag added to post.html
Dockerfile, .dockerignore, and .gitignore added
app runs in container with docker build + docker run
deployment pushed to Clouderized for public HTTPS hosting
custom domain can be mapped in Domains with DNS pointed to the provided cfargotunnel target
deployment flow is Git-native, which keeps publish operations repeatable for future series posts

🚀 Coming Up

One problem: every time you edit a post, you have to rebuild the image to see the change. That defeats the purpose of a content-driven blog.

Next episode: bind mounts. We'll mount the content/ folder from your machine directly into the container — edit a post, refresh the page, see the change instantly. No rebuild needed.

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

SEO Metadata

Title: Building a Blog Platform with Docker #5: Add a Dockerfile + Deploy to Clouderized
Meta Description: Write a Dockerfile for your Flask blog, build the image, and deploy it to clouderized.com — push to git.clouderized.com/davidtio/tioblog, auto-build, auto-route, and auto-HTTPS at davidtio-tioblog.clouderized.com.

Desktop Access for KVM on Podman: VNC First, SPICE Next

David Tio — Wed, 20 May 2026 15:08:59 +0000

Desktop Access for KVM on Podman: VNC First, SPICE Next

Quick one-liner: Your VM works over SSH, but some tasks need a real desktop. In this post, we add a QEMU VNC console first, then show the same VM through SPICE and remote-viewer.

🤔 Why This Matters

In Post #5, we made the VM reachable over SSH. In Post #6, we fixed the tiny SLES cloud image so it finally had room to install real packages.

That gives us a working server-style VM — but it's still terminal-only.

That's fine for many tasks, until you need:

GUI installers
visual tools
browser-based checks inside the guest
desktop workflows for testing

This post is the step from "I can SSH into it" to "I can actually see and operate the desktop."

The important distinction is that we're not starting with a guest-native remote desktop service yet. We first want a VM access path that proves the display layer works, even before SLES-specific RDP configuration enters the picture.

🏗️ What We Are Building

We're not rebuilding everything from scratch. We keep the same resized VM disk from Post #6, the same SSH management path from Post #5, and add desktop access in two layers:

QEMU VNC console
- VM console path
- useful when the guest stops at GRUB, installer screens, first boot, or recovery
- does not depend on a working guest-native remote desktop service
GNOME inside the guest
- full desktop environment
- visible through the VM console
- Firefox and Cockpit for a useful first desktop/admin workflow
- prepares the VM for guest-native remote desktop in the next post
SPICE from QEMU
- alternate VM console path
- works with remote-viewer

VNC is first because QEMU can expose the VM console directly. Once GNOME is installed, the same console shows the graphical desktop.

SPICE is the alternate path we add next so the same VM can be opened with remote-viewer too.

✅ Prerequisites

Posts #1 to #6 completed
Existing VM disk in ~/vm
qemu:base image available
Podman network mynet available
Host port 5900 free
SLES 16 full ISO available in ~/vm for non-subscribed installs
The /data disk from Post #6 available as ~/vm/extra-disk.qcow2

Examples below assume:

VM disk: ~/vm/SLES-16.0-Minimal-VM.x86_64-Cloud-GM.qcow2
SLES ISO: ~/vm/SLES-16.0-Full-x86_64-GM.install.iso
Data disk: ~/vm/extra-disk.qcow2
Guest user: sysadmin

If you are using another distro image, keep the same flow and swap only the package commands for that distro.

🖥️ Step 1: Boot the VM with a QEMU VNC Console

First, boot the VM with the QEMU VNC console exposed on host port 5900.

The QEMU console matters before the guest desktop is ready. If the VM stops at GRUB or needs boot interaction, SSH will not help yet. You need to see the VM console first.

One important carry-over from Post #6: we continue with the same VM state, including the /data disk.

If extra-disk.qcow2 is missing but /etc/fstab still expects it, the VM may sit at a boot wait for a missing UUID and SSH will never become usable.

cd ~/vm
# Download your SLES 16 full ISO manually from SUSE Customer Center if needed.
podman network exists mynet || podman network create mynet

podman run --rm -it \
  --name kvm-gui \
  --network=mynet \
  --device /dev/kvm \
  -p 2222:22 \
  -p 5900:5900 \
  -v ~/vm:/vm:z \
  qemu:base \
  qemu-system-x86_64 \
    -enable-kvm -cpu host \
    -m 2048 \
    -drive file=/vm/SLES-16.0-Minimal-VM.x86_64-Cloud-GM.qcow2,format=qcow2,if=virtio \
    -drive file=/vm/extra-disk.qcow2,format=qcow2,if=virtio \
    -drive file=/vm/SLES-16.0-Full-x86_64-GM.install.iso,media=cdrom,readonly=on \
    -boot order=c \
    -netdev user,id=net0,hostfwd=tcp::22-:22 \
    -device virtio-net-pci,netdev=net0 \
    -vga virtio \
    -display vnc=0.0.0.0:0

After you run this, the terminal may look quiet — that's expected. QEMU isn't opening a local GTK window or printing the graphical boot console to your shell. The VM console is being served over VNC on 5900.

Quick notes:

-p 5900:5900 exposes the QEMU VM console to your host
keep -p 2222:22 for SSH control
ISO is attached as a virtual CD-ROM so the guest can mount it as /dev/sr0
extra-disk.qcow2 keeps the /data mount from Post #6 available during boot
-boot order=c keeps the resized cloud disk as the boot target even with the ISO attached
-vga virtio gives the guest a proper virtual display adapter for the graphical desktop
-display vnc=0.0.0.0:0 exposes QEMU's console on port 5900

Now connect a VNC client to the QEMU console right away:

localhost:5900

Use this console to watch boot progress and confirm the VM gets past GRUB and reaches the guest OS. After the guest is up, SSH should work again:

ssh -p 2222 sysadmin@localhost

🎨 Step 2: Install GNOME 48

Once the VM is up, SSH in if you're not already using the QEMU console:

ssh -p 2222 sysadmin@localhost

We'll install GNOME, the default desktop environment on SLES 16.

There are two practical install paths:

subscribed system: install directly from online repos
non-subscribed system: mount the SLES 16 ISO and use it as a local repo

Option A: Subscribed SLES (online repos)

sudo zypper refresh
sudo zypper patterns | grep -i gnome
sudo zypper in -t pattern gnome
sudo zypper install -y MozillaFirefox cockpit
sudo systemctl start cockpit.socket
sudo systemctl enable cockpit.socket

Option B: Non-Subscribed SLES (ISO repo)

Mount the attached SLES 16 ISO inside the guest and register it as a local repository:

sudo mkdir -p /mnt/sles16-iso
lsblk
sudo mount /dev/sr0 /mnt/sles16-iso
sudo zypper ar -f file:///mnt/sles16-iso sles16-iso
sudo zypper refresh
sudo zypper patterns | grep -i gnome
sudo zypper in -t pattern gnome
sudo zypper install -y MozillaFirefox cockpit
sudo systemctl start cockpit.socket
sudo systemctl enable cockpit.socket

Firefox gives the desktop something useful to open immediately.
Cockpit gives you a browser-based admin interface at:

https://localhost:9090

From inside the VM desktop, open Firefox and browse to that address.
Cockpit also gives you a decent terminal, so you don't need to add a separate desktop terminal package for this lab.

Set graphical mode as the default boot target:

sudo systemctl set-default graphical.target

Then reboot so SLES starts into the graphical target:

sudo reboot

🔌 Step 3: Connect to the Desktop Console

From your host, keep your VNC client connected to the QEMU console:

localhost:5900

After the reboot, the same QEMU VNC console should show the SLES graphical login screen. This is still not guest-native RDP — it's the VM console showing the guest desktop.

⚡ Step 4: Where SPICE Fits

QEMU VNC proves the VM console and desktop path work. SPICE is the alternate client path — same VM, different protocol.

Use the same VM, but switch the display side of the QEMU command to SPICE:

podman run --rm -it \
  --name kvm-spice \
  --network=mynet \
  --device /dev/kvm \
  -p 2222:22 \
  -p 5930:5930 \
  -v ~/vm:/vm:z \
  qemu:base \
  qemu-system-x86_64 \
    -enable-kvm -cpu host \
    -m 2048 \
    -drive file=/vm/SLES-16.0-Minimal-VM.x86_64-Cloud-GM.qcow2,format=qcow2,if=virtio \
    -drive file=/vm/extra-disk.qcow2,format=qcow2,if=virtio \
    -drive file=/vm/SLES-16.0-Full-x86_64-GM.install.iso,media=cdrom,readonly=on \
    -boot order=c \
    -netdev user,id=net0,hostfwd=tcp::22-:22 \
    -device virtio-net-pci,netdev=net0 \
    -spice port=5930,addr=0.0.0.0,disable-ticketing=on \
    -device virtio-vga \
    -device virtio-keyboard-pci \
    -device virtio-mouse-pci

Then connect with:

remote-viewer spice://localhost:5930

At this point, you have two access paths:

SSH: command-line management on 2222
QEMU VNC console or SPICE console: boot, recovery, and desktop console

💡 Why Not Start with RDP?

SLES 16 has a GNOME Remote Desktop path that uses RDP. That's probably the more familiar protocol for many users, and it's worth covering.

But it's also a guest OS feature. You configure it inside SLES with GNOME, GDM, TLS credentials, and grdctl — that's a different layer from the VM console.

VNC is the generic first step because it works across guest operating systems. SPICE is another QEMU/KVM console protocol and a valid alternate client path.

So the order is deliberate:

QEMU VNC proves generic console and desktop visibility.
SPICE gives you another way to open the same console from remote-viewer.
GNOME Remote Desktop over RDP becomes the SLES-native day-to-day access path once the guest is healthy.

🎉 Wrap Up

At this point, your KVM-on-Podman VM is not only reachable and resized — it's also visible. VNC gives you the generic desktop baseline, and SPICE is an alternate console path for remote-viewer.

In the next post, we'll switch from console access to guest-native access and use the SLES 16 path: GNOME Remote Desktop over RDP.

Docker Compose: depends_on and Health Checks That Actually Protect Startup (2026)

David Tio — Mon, 11 May 2026 07:00:41 +0000

Quick one-liner: restart: unless-stopped brings containers back, but it cannot make startup safe. This episode fixes startup races with healthcheck and depends_on: condition: service_healthy.

🤔 Why This Matters

In episode 9, we hit a painful failure pattern.

The app started before Postgres was actually ready. Migration failed once, then the app kept restarting into a broken state. docker compose ps looked fine, users still saw failures.

That is the key difference between these two ideas:

Restart policy answers: what to do after a container exits.
Health check answers: is this service actually ready to serve traffic.

If you want reliable startup, you need both concepts. In this post we focus on readiness.

✅ Prerequisites

Ep 1-9 completed. You are comfortable with Compose files, multi-service stacks, and restart policies.

🧨 The Startup Race

Create and use a dedicated project folder so container names stay predictable in this post:

$ mkdir -p ~/appstack
$ cd ~/appstack

Use this minimal stack:

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_DB: app
      POSTGRES_USER: app
      POSTGRES_PASSWORD: app

  app:
    image: gitea.dtio.app/davidtio/noteboard:latest
    ports:
      - "5000:5000"
    volumes:
      - appstate:/app/state
    restart: unless-stopped

volumes:
  appstate:

Bring it up:

$ docker compose up

Typical early logs:

app-1  | First run, setting up...
app-1  | Migration failed: connection to server at "db" (...) Connection refused
app-1  | Already installed, skipping migrations
app-1  | Serving on :5000

Now check the app:

$ curl -i http://localhost:5000

A very common result here is:

curl: (52) Empty reply from server

This is the exact failure pattern we care about in this episode. The container is up, but the app is not actually ready.

❌ Why Plain `depends_on` Is Not Enough

A common fix attempt is:

app:
  depends_on:
    - db

This only guarantees start order, not readiness.

Compose starts db first, but Postgres still needs time to initialize and accept queries. Your app can still race and fail.

✅ Add a Real Database Health Check

Update the db service with pg_isready:

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_DB: app
      POSTGRES_USER: app
      POSTGRES_PASSWORD: app
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app -d app"]
      interval: 5s
      timeout: 3s
      retries: 12
      start_period: 10s

What this means:

test: command used to check readiness
interval: how often to check
timeout: max time for one check
retries: failures before unhealthy
start_period: grace period during startup

Check status:

$ docker compose ps

You should see db move from starting to healthy.

✅ Gate App Startup on Health, Not Order

Now update app:

services:
  app:
    image: gitea.dtio.app/davidtio/noteboard:latest
    ports:
      - "5000:5000"
    volumes:
      - appstate:/app/state
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy

This is the important part of the configuration. This configuration will ensure that app will not start until Compose marks db healthy.

After updating the Compose file, always remove containers and volumes first:

$ docker compose down --volumes
$ docker compose up -d
$ docker compose ps

Then test:

$ curl -i http://localhost:5000

Now you should get a valid HTTP response instead of empty reply or transaction errors.

📦 Full Compose File (Fixed)

The full compose file will be as follow:

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_DB: app
      POSTGRES_USER: app
      POSTGRES_PASSWORD: app
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app -d app"]
      interval: 5s
      timeout: 3s
      retries: 12
      start_period: 10s

  app:
    image: gitea.dtio.app/davidtio/noteboard:latest
    ports:
      - "5000:5000"
    volumes:
      - appstate:/app/state
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy

volumes:
  appstate:

🔍 What To Watch During Startup

Useful commands while testing:

$ docker compose ps
$ docker compose logs -f db app
$ docker inspect --format json appstack-db-1 | jq '.[]|.State.Health'

You are looking for this sequence:

db container starts.
health check runs and turns healthy.
app starts only after db is healthy.

⚠ Important Caveat

depends_on: condition: service_healthy controls startup order and readiness at startup time.

It does not restart dependent services automatically later if db becomes unhealthy at runtime.

You still need app-level retry logic, graceful error handling, and observability for runtime incidents.

🧪 Exercise: Start Ghost, Sign Up, and Switch to Journal

In this exercise, you will:

start Ghost with MySQL
apply startup-readiness fix with healthcheck + depends_on
sign up in Ghost Admin with any email (captured by Mailpit)
switch to the built-in Journal theme

Exercise Walkthrough

Start with this Compose file (plain depends_on first):

services:
  db:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD: rootpass
      MYSQL_DATABASE: ghost
      MYSQL_USER: ghost
      MYSQL_PASSWORD: ghostpass

  mail:
    image: axllent/mailpit:latest
    ports:
      - "8025:8025"

  app:
    image: ghost:5-alpine
    ports:
      - "2368:2368"
    environment:
      database__client: mysql
      database__connection__host: db
      database__connection__user: ghost
      database__connection__password: ghostpass
      database__connection__database: ghost
      database__connection__port: "3306"
      mail__transport: SMTP
      mail__options__host: mail
      mail__options__port: "1025"
    depends_on:
      - db
      - mail

First run:

$ docker compose up -d

Check behavior:

$ docker compose logs --no-color db app | tail -n 80
$ curl -I http://localhost:2368

On this first run, you should see this failure:

curl: (7) Failed to connect to localhost port 2368 after 0 ms: Couldn't connect to server

Typical broken-state signal:

Ghost starts, then fails database connection
MySQL is still initializing
app goes offline even though containers were started

Real output example (trimmed):

app-1  | [INFO] Ghost server started in 0.228s
app-1  | [ERROR] connect ECONNREFUSED 172.20.0.2:3306
app-1  | Error: connect ECONNREFUSED 172.20.0.2:3306
app-1  | [WARN] Ghost is shutting down
db-1   | [Entrypoint]: Initializing database files
db-1   | [Entrypoint]: Creating database ghost
db-1   | [Entrypoint]: MySQL init process done. Ready for start up.
db-1   | mysqld: ready for connections. ... port: 3306

Apply startup-readiness fix:

db:
  healthcheck:
    test: ["CMD-SHELL", "mysqladmin ping -h localhost -ughost -pghostpass --silent"]
    interval: 5s
    timeout: 3s
    retries: 12
    start_period: 10s

depends_on:
  db:
    condition: service_healthy
  mail:
    condition: service_started

After updating the Compose file, reset fully (including volumes), then run:

$ docker compose down --volumes
$ docker compose up -d
$ docker compose ps
$ curl -I http://localhost:2368

Open Ghost and Mailpit:

Ghost site: http://localhost:2368
Ghost Admin: http://localhost:2368/ghost
Mailpit inbox: http://localhost:8025

Create your Ghost admin user with any email address.

The email does not need to be real for this lab. Ghost email goes to Mailpit, so use the inbox at http://localhost:8025 for any verification link.

In Ghost Admin, switch to the built-in Journal theme:

Settings -> Design -> Change theme -> Journal -> Activate

Exercise complete.

Ghost is now running cleanly, Mailpit is handling local signup flow, and the Journal theme is live.

Most importantly, you removed the startup race by gating app startup on real database readiness.

Next episode, we level this up: a simpler, cleaner, more repeatable Ghost deployment you can rebuild with confidence.

🏁 What You Built

Feature	What It Does
`mysql` health check	Confirms the DB is truly ready, not only started
`depends_on` with `service_healthy`	Delays Ghost startup until MySQL readiness is real
Mailpit in local stack	Captures signup/verification emails without external SMTP
reset-and-rerun workflow	Reproduces and validates the startup race fix cleanly

Coming up: Startup is stable now. Next, we simplify the Ghost deployment so setup is faster, cleaner, and easier to repeat.

Building a Blog Platform with Docker #4: Dynamic Routes and a Real Post List

David Tio — Sun, 10 May 2026 07:02:51 +0000

🗂️ Building a Blog Platform with Docker #4: Dynamic Routes and a Real Post List

Quick one-liner: Replace the hardcoded route and static post list with a dynamic scanner that finds every .md file in your content folder — drop a file in, it appears on the homepage.

🤔 Why This Matters

After Episode 3 you can render a Markdown post. One post. At a hardcoded URL.

That's proof the plumbing works — but it's not a blog platform. To have a real blog, two things need to change:

The homepage should list all posts, sorted by date, pulled from actual files — not copied in by hand
The routes should be dynamic — any post at any date and slug should just work, without adding a new @app.route every time

While we're at it, there's a third thing worth doing now: SEO. The moment you have multiple real posts and real URLs, Google can find them. A <meta name="description"> tag is the minimum you need. And since we already have a description field in the post frontmatter (we're adding it today), it costs nothing to wire it up.

By the end of this episode, you'll be able to drop any .md file into content/posts/, refresh the homepage, and see it listed. No code changes required.

🏁 Starting Point

From Episode 3, your structure looks like this:

tiohub-blog/
├── app.py
├── requirements.txt
├── static/
│   └── js/
│       ├── code-blocks.js
│       └── tailwind.config.js
├── templates/
│   ├── index.html
│   └── post.html
└── content/
    └── posts/
        └── hey-markdown.md

If you're missing anything, go back to Episode 3 first.

✏️ Step 1: Update the Frontmatter Schema

We're adding one field to the frontmatter: description. It does two things at once — it becomes the <meta name="description"> tag for SEO, and it becomes the excerpt blurb on the homepage post list.

Update content/posts/hey-markdown.md. Find the existing frontmatter:

---
title: "Hey Markdown"
date: 2026-04-25
tags: [meta, blog]
---

Add the description field between date and tags:

---
title: "Hey Markdown"
date: 2026-04-25
description: "The first post written in Markdown — no more writing HTML by hand."
tags: [meta, blog]
---

This is the full frontmatter schema going forward. Every post should have all four fields:

Field	Used for
`title`	`<title>` tag, `<h1>` on post page, post list
`date`	URL generation, sorting, display
`description`	`<meta name="description">`, excerpt on homepage
`tags`	Tag pills on post page, eventually tag pages in Ep12

🔍 Step 2: Add the Post Scanner

Open app.py. Add a get_all_posts() function below parse_post():

def get_all_posts():
    posts = []
    posts_dir = 'content/posts'
    for filename in os.listdir(posts_dir):
        if not filename.endswith('.md'):
            continue
        filepath = os.path.join(posts_dir, filename)
        post = parse_post(filepath)
        post['slug'] = filename[:-3]
        posts.append(post)
    posts.sort(key=lambda p: p.get('date', ''), reverse=True)
    return posts

What this does:

Lists every .md file in content/posts/
Parses each one with the existing parse_post() function
Adds a slug field (the filename without .md) — this is what goes in the URL
Sorts all posts by date, newest first
Returns the full list

🔗 Step 3: Replace the Hardcoded Route with a Dynamic One

Remove the hardcoded hey_markdown_post() route entirely. Replace it with this:

@app.route('/<int:year>/<int:month>/<slug>')
def post(year, month, slug):
    filepath = f'content/posts/{slug}.md'
    if not os.path.exists(filepath):
        abort(404)
    post = parse_post(filepath)
    return render_template('post.html', post=post)

At the top of app.py, find the existing Flask import:

from flask import Flask, render_template

Add abort to it:

from flask import Flask, render_template, abort

How the URL is constructed: The date in the frontmatter has a year and month attribute once parsed by PyYAML (it parses 2026-04-25 as a Python date object). We'll use those in the next step to build the correct link from the homepage. The route parameters year and month aren't used to look up the file — the slug is enough, since slugs are unique. They're there to keep the URL format consistent with the Blogger pattern we established in Episode 3.

🏠 Step 4: Update the Homepage

Update the index route in app.py. Find the existing route:

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

Replace it with:

@app.route('/')
def index():
    posts = get_all_posts()
    return render_template('index.html', posts=posts)

Replace the hardcoded post list in templates/index.html:

Find the hardcoded <article> block inside <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>

Replace it with this loop:

{% for post in posts %}
<article class="border-b border-slate-800 pb-10 last:border-0 last:pb-0">
    <div class="flex items-center gap-3 mb-3">
        <time class="text-gray-500 text-sm">{{ post.date }}</time>
        {% for tag in post.tags %}
        <span class="text-xs bg-teal-900/50 text-teal-300 px-2 py-0.5 rounded-full">{{ tag }}</span>
        {% endfor %}
    </div>
    <h2 class="font-serif text-2xl text-white mb-3 leading-snug">
        <a href="/{{ post.date.year }}/{{ '%02d' | format(post.date.month) }}/{{ post.slug }}"
           class="hover:text-teal-400 transition-colors duration-200">
            {{ post.title }}
        </a>
    </h2>
    <p class="text-gray-400 leading-relaxed mb-4">{{ post.description }}</p>
    <a href="/{{ post.date.year }}/{{ '%02d' | format(post.date.month) }}/{{ post.slug }}"
       class="text-teal-400 text-sm hover:text-teal-300 font-medium transition-colors duration-200">
        Read more →
    </a>
</article>
{% endfor %}

Each post in the list now shows:

The date and tag pills in a row
The post title as a link
The description as the excerpt
A "Read more →" link

The URL is built from the date and slug: /2026/04/hey-markdown. No hardcoding anywhere.

🔎 Step 5: Add Meta Description to the Post Page

Open templates/post.html. In the <head> section, add the meta description tag after <title>:

<title>{{ post.title }}</title>
<meta name="description" content="{{ post.description }}">

That's it. When Google indexes the page, it reads this tag and uses it as the snippet under the link in search results. The content comes directly from the description field in your frontmatter — the same text you already wrote for the homepage excerpt.

🏷️ Step 6: Add Tag Pills to the Post Page

Open templates/post.html. Inside <main>, find the date and title block:

<p class="text-gray-500 text-sm mb-4">{{ post.date }}</p>
<h1 class="font-serif text-4xl text-white leading-tight mb-8">{{ post.title }}</h1>

Replace it with this — same date and title, with the tag pills inserted between them:

<p class="text-gray-500 text-sm mb-3">{{ post.date }}</p>
<div class="flex flex-wrap gap-2 mb-6">
    {% for tag in post.tags %}
    <span class="text-xs bg-teal-900/50 text-teal-300 px-2.5 py-1 rounded-full">{{ tag }}</span>
    {% endfor %}
</div>
<h1 class="font-serif text-4xl text-white leading-tight mb-8">{{ post.title }}</h1>

Tags are non-clickable for now — they're labels, not links. They become proper links with their own pages in Episode 12, once the platform has enough posts and structure to make tag filtering useful.

🧪 Step 7: Test It

Add a second post so you can verify the list actually works. Create content/posts/second-post.md:

---
title: "Second Post"
date: 2026-04-26
description: "Proving the scanner works — this post appeared without touching app.py."
tags: [test]
---

Dropped this file into `content/posts/`. Restarted Flask. It appeared.

No new routes. No hardcoded HTML. Just a file.

Run the app:

$ python app.py

Check:

Homepage — both posts listed, newest first, with excerpts and tags
/2026/04/hey-markdown — first post renders correctly
/2026/04/second-post — second post renders correctly
View source on either post — confirm <meta name="description"> is present in <head>
Drop another .md file into content/posts/ and refresh — it should appear immediately

✅ What You've Built

Your file structure now:

tiohub-blog/
├── app.py
├── requirements.txt
├── static/
│   └── js/
│       ├── tailwind.config.js
│       └── code-blocks.js
├── templates/
│   ├── index.html
│   └── post.html
└── content/
    └── posts/
        ├── hey-markdown.md
        └── second-post.md

What changed:

✅ get_all_posts() — scans the posts folder and returns all posts sorted by date
✅ Dynamic /<int:year>/<int:month>/<slug> route — works for any post, no code changes needed
✅ Homepage driven by real files — no more hardcoded HTML
✅ description field wired up as SEO meta tag and homepage excerpt
✅ Tag pills on post pages

🚀 Coming Up

Next episode: Docker. The app runs fine locally, but "works on my machine" isn't a deployment strategy. We'll write a Dockerfile, build an image, and run the blog in a container — the same way it'll run in production.

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

SEO Metadata

Title: Building a Blog Platform with Docker #4: Dynamic Routes and a Real Post List
Meta Description: Replace hardcoded Flask routes with a dynamic post scanner. Every .md file in your content folder becomes a post automatically — plus SEO meta description and tag pills.
Word Count: ~1,100

Resize a Tiny SLES 16 Cloud Image with qemu:base on Ubuntu 26.04

David Tio — Wed, 06 May 2026 01:01:03 +0000

Resize a Tiny SLES 16 Cloud Image with qemu:base on Ubuntu 26.04

Quick one-liner: The SLES 16 minimal cloud image boots fast, but it left me with about 3 MB free. That is not enough room to do real work, so we resize it on our brand new qemu:base.

🤔 Why This Matters

In Post #4, SLES gave us the most interesting cloud-image result: fast boot, enterprise Linux, and almost no free space.

The VM works. It boots quickly. Cloud-init configures the user. In Post #5, we made it reachable over the network.

Then you log in and see this:

sysadmin@kvmpodman:~> df -Th
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/vda3      xfs       742M  739M  3.0M 100% /

About 3 megabytes free. I had barely done anything with this VM yet.

That is painful by today's standard. Installing one package can fill that up. A normal zypper update is already too much. The VM is technically running, but there is no breathing room.

Ubuntu cloud images are usually generous enough to be usable without resizing. SLES 16 minimal is not, and that makes it the perfect example for learning how cloud image resizing actually works.

To resize it properly, our qemu:base toolbox needs the right disk utility. qemu-img handles the virtual disk size from outside the guest.

Ubuntu 26.04 LTS just dropped, so this is a good chance to see how it holds up as the new base for our QEMU toolbox. We will rebuild qemu:base on Ubuntu 26.04, keep qemu-img available there, then use that container to fix the SLES disk.

In this post we will:

Rebuild qemu:base on Ubuntu 26.04.
Use the refreshed toolbox to grow the SLES qcow2 file.
Expand the root partition inside the VM.
Grow the filesystem.
Verify that the VM finally has room to work.

📋 Prerequisites

Podman
~/vm directory with cloud images
A SLES cloud image in ~/vm, already seeded with cloud-init from Post #4
SSH access to the VM from Post #5

The examples use this file:

~/vm/SLES-16.0-Minimal-VM.x86_64-Cloud-GM.qcow2

If your image has a different name, swap the path in the commands below. If this is a fresh SLES cloud image, boot it once with the cloud-init-sles.iso from Post #4 before following this post. The resize steps assume the VM already has the sysadmin user and SSH access configured.

🧰 Step 1: Rebuild qemu:base on Ubuntu 26.04

Our earlier qemu:base image was only meant to get QEMU running. For this episode, we will refresh it on Ubuntu 26.04 and include the disk tools we need:

FROM ubuntu:26.04

ENV DEBIAN_FRONTEND=noninteractive

RUN apt-get update && \
    apt-get install -y --no-install-recommends \
        qemu-system-x86 \
        qemu-utils \
        iproute2 \
        bash \
        ca-certificates \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

COPY run-vm.sh /run-vm.sh
RUN chmod +x /run-vm.sh

WORKDIR /vms
CMD ["/bin/bash"]

Build it:

$ cd ~/vm
$ podman build -t qemu:base .

Check the tools:

$ podman run --rm qemu:base qemu-img --version

The Ubuntu version here is about the toolbox. It does not mean the guest VM is Ubuntu. We are using an Ubuntu-based container to manage and boot a SLES cloud image.

📊 Step 2: Check the Problem

Create the same Podman network we used in Post #5:

$ podman network create mynet

Then boot the already-seeded SLES VM with SSH forwarding:

$ podman run --rm -it \
    --name sles-resize \
    --network=mynet \
    --device /dev/kvm \
    -p 2222:22 \
    -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 \
        -netdev user,id=net0,hostfwd=tcp::22-:22 \
        -device virtio-net-pci,netdev=net0

In another terminal, SSH into the VM through the forwarded host port:

$ ssh -p 2222 sysadmin@localhost

Once you are in, check the root filesystem:

sysadmin@kvmpodman:~> df -Th /
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/vda3      xfs       742M  739M  3.0M 100% /

Also check the block devices:

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

The disk is small, and the root partition is smaller. We need to grow both.

Shut the VM down cleanly before touching the disk image:

sysadmin@kvmpodman:~> sudo poweroff

🔧 Step 3: Back Up the Image

Before resizing any disk image, make a copy:

$ cp ~/vm/SLES-16.0-Minimal-VM.x86_64-Cloud-GM.qcow2 \
     ~/vm/SLES-16.0-Minimal-VM.x86_64-Cloud-GM.qcow2.bak

This is cheap insurance. If you mistype a partition number later, you can go back.

🔧 Step 4: Grow the qcow2 File

Use qemu-img resize from the qemu:base container. This grows the virtual disk container, but it does not grow the partition or filesystem inside it yet.

$ podman run --rm \
    -v ~/vm:/vm:z \
    qemu:base \
    qemu-img info /vm/SLES-16.0-Minimal-VM.x86_64-Cloud-GM.qcow2
image: /vm/SLES-16.0-Minimal-VM.x86_64-Cloud-GM.qcow2
file format: qcow2
virtual size: 1.29 GiB (1385168896 bytes)
disk size: 339 MiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
    extended l2: false
Child node '/file':
    filename: /vm/SLES-16.0-Minimal-VM.x86_64-Cloud-GM.qcow2
    protocol type: file
    file length: 339 MiB (355467264 bytes)
    disk size: 339 MiB

The guest sees a 1.29 GiB virtual disk, but the qcow2 file only uses 339 MiB on the host. That is normal. qcow2 can be compressed and thin-provisioned, so host disk usage and guest-visible disk size are not the same thing.

Add 10 GB:

$ podman run --rm \
    -v ~/vm:/vm:z \
    qemu:base \
    qemu-img resize /vm/SLES-16.0-Minimal-VM.x86_64-Cloud-GM.qcow2 +10G
Image resized.

Check it:

$ podman run --rm \
    -v ~/vm:/vm:z \
    qemu:base \
    qemu-img info /vm/SLES-16.0-Minimal-VM.x86_64-Cloud-GM.qcow2
image: /vm/SLES-16.0-Minimal-VM.x86_64-Cloud-GM.qcow2
file format: qcow2
virtual size: 11.3 GiB (12122587136 bytes)
disk size: 339 MiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
    extended l2: false
Child node '/file':
    filename: /vm/SLES-16.0-Minimal-VM.x86_64-Cloud-GM.qcow2
    protocol type: file
    file length: 339 MiB (355467776 bytes)
    disk size: 339 MiB

The virtual size is now bigger, but the host disk usage is still 339 MiB. That is the thin-provisioning part of qcow2: the guest can see the larger disk immediately, but the host file grows only as data is written.

🔧 Step 5: Verify the Guest Expanded

Boot the VM again with the same SSH forwarding:

$ podman run --rm -it \
    --name sles-resize \
    --network=mynet \
    --device /dev/kvm \
    -p 2222:22 \
    -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 \
        -netdev user,id=net0,hostfwd=tcp::22-:22 \
        -device virtio-net-pci,netdev=net0

Then reconnect over SSH:

$ ssh -p 2222 sysadmin@localhost

Inside the VM, check both the block devices and the mounted filesystem:

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

sysadmin@kvmpodman:~> df -Th /
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/vda3      xfs    11G  948M  9.8G   9% /

That is the clean success case:

lsblk shows the disk at 11.3G.
lsblk shows the root partition at 10.8G.
df -Th / shows the mounted XFS filesystem at 11G with almost 10G available.

In this SLES 16 cloud image, cloud-init grew the root partition and filesystem automatically on boot after the qcow2 virtual size changed. The important number is not Used. The image was already effectively full before resizing. The win is Avail: from about 3M to 9.8G.

From about 3 MB free to almost 10 GB available. That is enough room to update the system, install tools, and use the VM like a real machine.

🔧 If the Guest Does Not Auto-Grow

Most cloud images include grow tools because cloud platforms resize disks all the time. If your image does not auto-grow, check which layer is still small.

If lsblk still shows /dev/vda3 at 806M, grow partition 3 manually:

sysadmin@kvmpodman:~> sudo growpart /dev/vda 3

If df -Th / still shows the old 742M filesystem, grow it manually. For XFS, grow the mounted filesystem by mount point:

sysadmin@kvmpodman:~> sudo xfs_growfs /

For ext4, use the block device instead:

sysadmin@kvmpodman:~$ sudo resize2fs /dev/vda3

Then check again:

sysadmin@kvmpodman:~> lsblk
sysadmin@kvmpodman:~> df -Th /

If growpart is missing and the root filesystem is already this full, the safer option is to go back to your backup image or add a second disk instead of fighting package installation inside the cramped guest.

🔧 Add a Second Disk Instead

Sometimes you do not want to resize the root filesystem. A separate data disk is simpler and safer for databases, logs, or application data.

Power off the VM first:

sysadmin@kvmpodman:~> sudo poweroff

Create a new qcow2 disk:

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

Attach it when starting the VM:

$ podman run --rm -it \
    --name sles-resize \
    --network=mynet \
    --device /dev/kvm \
    -p 2222:22 \
    -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 \
        -drive file=/vm/extra-disk.qcow2,format=qcow2,if=virtio \
        -netdev user,id=net0,hostfwd=tcp::22-:22 \
        -device virtio-net-pci,netdev=net0

Reconnect over SSH:

$ ssh -p 2222 sysadmin@localhost

Inside the VM, format it and create the mount point:

sysadmin@kvmpodman:~> sudo mkfs.xfs /dev/vdb
sysadmin@kvmpodman:~> sudo mkdir /data

Make it persistent by UUID instead of /dev/vdb. Device names can change if you attach disks in a different order later.

sysadmin@kvmpodman:~> sudo blkid /dev/vdb
/dev/vdb: UUID="11111111-2222-3333-4444-555555555555" BLOCK_SIZE="512" TYPE="xfs"

sysadmin@kvmpodman:~> sudo sh -c 'echo "UUID=11111111-2222-3333-4444-555555555555 /data xfs defaults 0 0" >> /etc/fstab'

Mount everything from /etc/fstab, then verify /data:

sysadmin@kvmpodman:~> sudo mount -a
sysadmin@kvmpodman:~> df -Th /data
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/vdb       xfs    20G  424M   20G   3% /data

Use this when you need more storage but do not need the root filesystem itself to be bigger.

🧹 Cleanup

If you created a backup and no longer need it:

$ rm ~/vm/SLES-16.0-Minimal-VM.x86_64-Cloud-GM.qcow2.bak

If you created the extra disk and want to remove it, clean it up from inside the VM first:

sysadmin@kvmpodman:~> sudo umount /data
sysadmin@kvmpodman:~> sudo sed -i '\| /data xfs |d' /etc/fstab
sysadmin@kvmpodman:~> sudo poweroff

Then remove the disk image from the host:

$ rm ~/vm/extra-disk.qcow2

✅ What You've Built

✅ Rebuilt qemu:base on Ubuntu 26.04
✅ Resized a qcow2 cloud image with qemu-img
✅ Verified cloud-init expanded the root partition automatically
✅ Verified the XFS root filesystem grew automatically
✅ Used a second disk as an alternative

🔜 What's Next?

The VM now has room to breathe. We rebuilt the toolbox, expanded the SLES cloud image, and confirmed the guest can actually use the space.

There is still more to explore with KVM on Podman.

See you in the next episode.

Found this helpful?

LinkedIn: Share with your network
Questions? Drop a comment below

Docker Compose: Scale Out and Stay Resilient (2026)

David Tio — Mon, 27 Apr 2026 08:54:02 +0000

Quick one-liner: Scale worker containers with one command and add restart policies so crashed services recover on their own. Then hit the one problem restart policies can't solve.

🤔 Why This Matters

In the last post, you put nginx in front of a Python web app. One backend, one load balancer, and it works fine.

Then traffic picks up and that single backend starts choking. You need another one. So you add a second container to your compose file, update nginx.conf to include it, and restart everything. It works. Traffic grows and you add a third. You edit the compose file, add another upstream entry in nginx.conf, and restart. Same drill.

Here's where things get interesting. One of those backends crashes. Maybe a memory leak, maybe a bad request triggers a segfault. It goes down, but nginx doesn't know about it. It keeps routing requests to the dead container and users start seeing errors.

We'll work through both of these problems in this post.

✅ Prerequisites

Ep 1-8 completed. You know Compose basics like multi-service files, .env files, shared networks, and the up/ps/logs/down workflow.

📦 Scaling Web Apps Behind nginx

Back in the last post, you built a load balancer with nginx in front of a Python web app. If you still have that loadbalance directory, great. If not, grab the files from the exercise at the end of post 08. You need app.py, nginx.conf, and docker-compose.yml.

Here's where we left off:

services:
  nginx:
    image: nginx:latest
    ports:
      - "8080:80"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf

  web:
    image: python:slim
    command: python /app/app.py
    volumes:
      - ./app.py:/app/app.py
    working_dir: /app

One backend. nginx in front. nginx.conf has one upstream entry: server web:5000;.

Now traffic picks up. One backend isn't enough. You need a second one.

The obvious approach: copy the web service, rename the original to web1, add a web2, and update nginx.conf.

Update docker-compose.yml:

services:
  nginx:
    image: nginx:latest
    ports:
      - "8080:80"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf

  web1:
    image: python:slim
    command: python /app/app.py
    volumes:
      - ./app.py:/app/app.py
    working_dir: /app

  web2:
    image: python:slim
    command: python /app/app.py
    volumes:
      - ./app.py:/app/app.py
    working_dir: /app

Update nginx.conf:

upstream backend {
    server web1:5000;
    server web2:5000;
}

server {
    listen 80;
    keepalive_timeout 0;

    location = /favicon.ico {
        return 204;
    }

    location / {
        proxy_pass http://backend;
    }
}

keepalive_timeout 0 disables HTTP keep-alive. The favicon.ico block returns an empty response directly from nginx — without it, every browser page load fires two requests (/ and /favicon.ico) and they interleave on the round-robin, so your page refresh always lands on the same backend. Without it, browsers reuse the same connection and you always hit the same backend. With it, each request gets a fresh connection and nginx round-robins properly.

Two services. Two upstream entries. Tear down the old stack and start fresh:

$ docker compose down --remove-orphans
$ docker compose up -d

--remove-orphans removes any containers that are no longer defined in your compose file. Without it, the old web container stays behind and blocks network cleanup.

[+] up 3/3
 ✔ Container loadbalance-nginx-1   Created
 ✔ Container loadbalance-web1-1    Created
 ✔ Container loadbalance-web2-1    Created

Open http://localhost:8080 and refresh. The hostname changes between requests. nginx is round-robining between web1 and web2.

Check the containers:

$ docker compose ps -a

NAME                       IMAGE         COMMAND   STATUS
loadbalance-nginx-1        nginx:latest  "nginx…"  Up 5 min
loadbalance-web1-1         python:slim   "python…" Up 5 min
loadbalance-web2-1         python:slim   "python…" Up 5 min

Three containers. nginx distributes requests between two backends. It works.

Now let's break one:

$ sudo kill -9 $(docker inspect --format '{{.State.Pid}}' loadbalance-web2-1)

This kills the container process at the OS level, outside Docker's control. Docker sees it as a crash. Let's watch what happens.

Check:

$ docker compose ps -a

NAME                       IMAGE         COMMAND   STATUS
loadbalance-nginx-1        nginx:latest  "nginx…"  Up 6 min
loadbalance-web1-1         python:slim   "python…" Up 6 min
loadbalance-web2-1         python:slim   "python…" Exited (137) 10s ago

web2 exited with code 137. The kernel killed the process with SIGKILL. Not a clean exit. Just dead.

Two containers left running. nginx and web1.

Open http://localhost:8080 and refresh. The page still loads. nginx tries to send a request to web2, gets a connection refused, and falls back to web1. You might see one slow refresh, then everything works.

This is the real-world pattern: containers die. Crashes. Memory leaks. Bad requests. nginx keeps serving traffic with whatever backends are alive. But we had to bring web2 back manually. Nobody was watching. Nobody got paged. It just stayed dead until someone noticed the output from docker compose ps -a.

That's the second problem we'll fix in this post. But look at the compose file first. web1 and web2 are identical. Same image, same command, same volumes. The only difference is the name. And nginx.conf lists each one by name. Want a third instance? Add web3 to the compose file. Add server web3:5000; to nginx.conf. Want ten? Edit ten lines.

There's a better way.

Replace web1 and web2 with a single web service. Add depends_on so nginx doesn't start before web exists:

services:
  nginx:
    image: nginx:latest
    ports:
      - "8080:80"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
    depends_on:
      - web

  web:
    image: python:slim
    command: python /app/app.py
    volumes:
      - ./app.py:/app/app.py
    working_dir: /app

Update nginx.conf to reference just web:

upstream backend {
    server web:5000;
}

server {
    listen 80;
    keepalive_timeout 0;

    location = /favicon.ico {
        return 204;
    }

    location / {
        proxy_pass http://backend;
    }
}

When nginx loads this config, it resolves web through Docker DNS and builds its upstream pool from what it sees at that moment. depends_on helps startup order, but it does not guarantee nginx picks up every replica on first boot. If nginx starts too early, reload it after the stack is up.

One service name. No hardcoded numbers.

Tear down the old stack and start fresh with two instances:

$ docker compose down --remove-orphans
$ docker compose up -d --scale web=2
$ docker compose exec nginx nginx -s reload

[+] up 3/3
 ✔ Container loadbalance-nginx-1   Created
 ✔ Container loadbalance-web-1     Created
 ✔ Container loadbalance-web-2     Created

Open http://localhost:8080 and refresh. The hostname should alternate between the two containers on every request.

Now kill one:

$ sudo kill -9 $(docker inspect --format '{{.State.Pid}}' loadbalance-web-2)

$ docker compose ps -a

NAME                       IMAGE         COMMAND   STATUS
loadbalance-nginx-1        nginx:latest  "nginx…"  Up 2 min
loadbalance-web-1          python:slim   "python…" Up 2 min
loadbalance-web-2          python:slim   "python…" Exited (137) 3s ago

web-2 is dead. Keep refreshing — the page still loads. nginx detected the failure and routes everything to web-1.

Now bring it back. You don't need to know which container died or restart it by name. Just tell compose how many you want:

$ docker compose up -d --scale web=2

[+] up 2/2
 ✔ Container loadbalance-web-1     Running
 ✔ Container loadbalance-web-2     Started

web-2 is back. Round-robin resumes. With the manual web1/web2 approach you'd have had to run docker compose up web2 and know the exact name. With --scale you just declare the count.

Scale to five with the same command:

$ docker compose up -d --scale web=5

[+] up 5/5
 ✔ Container loadbalance-nginx-1   Running
 ✔ Container loadbalance-web-1     Running
 ✔ Container loadbalance-web-2     Running
 ✔ Container loadbalance-web-3     Started
 ✔ Container loadbalance-web-4     Started
 ✔ Container loadbalance-web-5     Started

No nginx config changes. But nginx resolved web at startup when only two containers existed — it doesn't know about the three new ones yet. Reload nginx to pick them up:

$ docker compose exec nginx nginx -s reload

Now all five are in the pool. That's the power of --scale — the config stays the same, you just change the count and reload.

But there's a gap in this recovery story. Bringing web-2 back required you to notice it was dead and run the command yourself. Nobody was watching.

Tear it down:

$ docker compose down

🔄 Restart Policies

web-2 stayed dead until you ran the command. What if you didn't notice for an hour?

Back in post 04 we covered restart policies — one flag that tells Docker to bring a container back whenever it exits. The same thing works in Compose. One line, and you never have to babysit a crashed container again.

Add restart: unless-stopped to the web service:

services:
  nginx:
    image: nginx:latest
    ports:
      - "8080:80"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf

  web:
    image: python:slim
    command: python /app/app.py
    volumes:
      - ./app.py:/app/app.py
    working_dir: /app
    restart: unless-stopped

Start with two again:

$ docker compose up -d --scale web=2

Now kill web-2:

$ sudo kill -9 $(docker inspect --format '{{.State.Pid}}' loadbalance-web-2)

Check:

$ docker compose ps

NAME                  IMAGE          SERVICE  STATUS
loadbalance-nginx-1   nginx:latest   nginx    Up 2 minutes
loadbalance-web-1     python:slim    web      Up 2 minutes
loadbalance-web-2     python:slim    web      Up 1 second

Already back. web-2 restarted so fast it barely registered as dead. You didn't touch anything — Docker saw the process die and brought it straight back up.

unless-stopped restarts on crashes and host reboots, but stays down when you run docker compose stop intentionally.

🧪 Exercise 1: Scale Your Worker Stack from Episode 8

Done with the loadbalance stack. Tear it down:

$ docker compose down

In episode 8 you built a producer/worker/redis stack. One worker, pulling jobs from a queue. Submit enough jobs and the queue grows faster than the worker drains it. One worker isn't enough.

Grab your prodwork directory from episode 8. Your starting point:

prodwork/
├── producer.py
├── worker.py
└── docker-compose.yml

Your job:

Add restart: unless-stopped to the worker service. The producer and redis services stay as-is.
Scale to three workers:

   $ docker compose up -d --scale worker=3

Check docker compose ps. You should have one redis, one producer, and three workers.

Watch the logs, then submit jobs:

   $ docker compose logs -f

With the log stream open, go to http://localhost:5000 and submit a few jobs. You'll see different workers picking them up in real time. The queue drains faster with three workers pulling from it.

Kill one worker mid-queue:

   $ sudo kill -9 $(docker inspect --format '{{.State.Pid}}' prodwork-worker-2)

Keep watching the logs. worker-2 drops out, the other two keep draining. Once worker-2 restarts, it rejoins and starts pulling jobs again — all visible in the log stream.

Test that manual stop is respected. Stop the stack:

   $ docker compose stop

All containers exit and stay stopped. Start it back up and the workers are ready again. No jobs were processed in the meantime, but nothing was lost either. Redis persisted the queue.

The key thing to notice: you never changed worker.py. Multiple workers connect to the same Redis queue and brpop handles the coordination. Each job goes to exactly one worker.

🧪 Exercise 2: The App That Dies on Boot

Your worker stack is resilient. But it only works because Redis starts fast and unless-stopped keeps retrying until it connects. Now try the same pattern with an app that connects to Postgres. Postgres takes longer to initialise, and this time the app has a flaw that makes restart policies actively dangerous.

Create a new directory:

$ mkdir -p appstack && cd appstack

We'll use noteboard. It's a simple note board app. POST a name and message, GET shows all notes. On first start it runs a migration to create the schema.

docker-compose.yml:

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_DB: app
      POSTGRES_USER: app
      POSTGRES_PASSWORD: app

  app:
    image: gitea.dtio.app/davidtio/noteboard:latest
    ports:
      - "5000:5000"
    volumes:
      - appstate:/app/state
    restart: unless-stopped

volumes:
  appstate:

Start it and watch the logs:

$ docker compose up

app-1  | First run, setting up...
app-1  | Migration failed: connection to server at "db" (172.20.0.2), port 5432 failed: Connection refused
app-1  |
app-1  | Already installed, skipping migrations
app-1  | Database not ready: connection to server at "db" (172.20.0.2), port 5432 failed: Connection refused
app-1  |
app-1  | Already installed, skipping migrations
app-1  | Serving on :5000
app-1  | Exception occurred during processing of request from ('172.20.0.1', 41410)
app-1  | psycopg2.errors.InFailedSqlTransaction: current transaction is aborted,
app-1  | commands ignored until end of transaction block

Open http://localhost:5000. The browser returns nothing — no error page, just an empty response.

On the very first boot, the app wrote the state file and tried to run the migration — but Postgres wasn't ready. The migration failed mid-transaction, leaving the connection in a broken state. The app exited. unless-stopped brought it back. Every restart after that saw the state file and skipped the migration entirely. Postgres eventually came up, the app reached Serving on :5000, and started accepting requests. But the notes table was never created, and psycopg2 refuses to run any query on a connection with a prior failed transaction. Every request crashes the handler silently.

$ docker compose ps

NAME             IMAGE                                      STATUS
appstack-db-1    postgres:16                                Up 2 min
appstack-app-1   gitea.dtio.app/davidtio/noteboard:latest   Up 2 min

Both containers up. Nothing in docker compose ps tells you anything is wrong.

Tear down and clear the volume:

$ docker compose down --volumes

The damage was done in the first few seconds. The state file was written, the migration never ran, and every restart since then has skipped it without question. Restart policies didn't cause this — they just kept the broken app alive long enough that you might not notice until a user reports it.

Restart policies can't solve this. They only decide what happens after a container exits. What you actually need is a way to tell Docker: don't start the app until the database is ready to accept connections.

That's the next post.

🏁 What You've Built

Feature	What It Does
`--scale web=5`	Spins up five web containers behind one nginx. No config changes needed.
`--scale worker=3`	Spins up three workers pulling from the same Redis queue. Each job goes to exactly one worker.
Compose DNS + nginx reload	Docker can resolve a service name to multiple scaled instances. Reload nginx after scaling or late starts to refresh the upstream pool.
`restart: unless-stopped`	Auto-restarts crashed containers without manual intervention. See post 04 for the full policy breakdown.

👉 Coming up: The noteboard died on boot because Postgres wasn't ready, and restart policies made it worse. There has to be a better way to bring a stack up. That's what we tackle next.

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 #3: Markdown Rendering

David Tio — Sun, 26 Apr 2026 08:59:28 +0000

Building a Blog Platform with Docker #3: Markdown Rendering

Quick one-liner: Stop writing HTML for your posts. Parse .md files with YAML frontmatter and render them in Flask.

Why This Matters

Last time you built a blog that looks like a blog. Teal nav, dark background, editorial post list. Nice.

But the post in that list? It's hardcoded HTML. Every time you want a new post, you have to edit a template. That's not a blog platform, that's a website.

A real blog platform lets you write a file, drop it in a folder, and have it appear. That's what Markdown gives you.

Why Markdown?

You write in plain text: no <p> tags, no &, no forgetting to close a <div>
It's readable as-is, even before rendering
Every major writing tool supports it
Easy to version control in git

By the end of this post, you'll be able to drop a .md file into a folder and have Flask render it as a proper HTML page.

Starting Point

You should have this from last time:

tiohub-blog/
├── app.py
├── static/
│   └── js/
│       └── tailwind.config.js
└── templates/
    └── index.html

If you don't have this, go back to Episode 2 first.

Step 1: Install the Packages

You need two libraries:

Markdown: converts Markdown syntax to HTML
PyYAML: parses the YAML frontmatter at the top of each post

Make sure your venv is active first:

$ source venv/bin/activate

Install both:

$ pip install Markdown PyYAML

Save them to requirements.txt:

$ pip freeze > requirements.txt

Why pip freeze? It saves every installed package with its exact version. Anyone cloning your repo can run pip install -r requirements.txt and get the exact same environment. We'll need this when we add Docker later.

Step 2: Create Your First Post

Create the content folder:

$ mkdir -p content/posts

Create content/posts/hey-markdown.md:

---
title: "Hey Markdown"
date: 2026-04-25
tags: [meta, blog]
---

This is my first post written in Markdown.

No more HTML by hand. No more forgetting to close a `<div>`. Just write, save, done.

Here's what Markdown looks like in practice:

- **Bold** with double asterisks
- *Italic* with single asterisks
- `Code` with backticks

And a code block:

\```

bash
$ source venv/bin/activate
# apt update
\

```

python
print("First Markdown post, and it actually works")
\


That's it. Clean to write, clean to read.

The section between the --- markers at the top is called frontmatter. It's YAML, a simple key-value format. The title, date, and tags fields are metadata about the post. The Markdown content starts after the second ---.

Step 3: Write the Parse Function

Open app.py. Add the imports at the top:

import yaml
import markdown

Now add a parse_post() function below the imports:

def parse_post(filepath):
    with open(filepath, 'r') as f:
        content = f.read()

    if content.startswith('---'):
        parts = content.split('---', 2)
        meta = yaml.safe_load(parts[1])
        body = parts[2].strip()
    else:
        meta = {}
        body = content

    meta['content'] = markdown.markdown(
        body,
        extensions=['fenced_code', 'tables']
    )
    return meta

What this does:

Reads the .md file
Checks if it starts with --- (frontmatter present)
Splits on --- to separate the YAML from the Markdown
Parses the YAML into a Python dict (meta)
Converts the Markdown body to HTML and stores it as meta['content']
Returns the whole thing: metadata and rendered HTML together

Why fenced_code and tables? The base markdown library is minimal. The fenced_code extension enables code blocks with triple backticks. The tables extension adds table support. Both are included with the library, no extra install needed.

Step 4: Add a Route

Add a new route to app.py:

@app.route('/2026/04/hey-markdown')
def hey_markdown_post():
    post = parse_post('content/posts/hey-markdown.md')
    return render_template('post.html', post=post)

Why this URL format? This matches Blogger's URL pattern: /<year>/<month>/<slug>. My current blog is on Blogger, and I'm planning to migrate it to this platform. If the URLs match from the start, existing posts won't need 301 redirects when I move them over.

In Episode 4, this becomes a dynamic route, /<int:year>/<int:month>/<slug>, that looks up any post by its date and slug. For now, we're hardcoding it to prove the parsing works.

Your full app.py should now look like this:

import yaml
import markdown
from flask import Flask, render_template

app = Flask(__name__)

def parse_post(filepath):
    with open(filepath, 'r') as f:
        content = f.read()

    if content.startswith('---'):
        parts = content.split('---', 2)
        meta = yaml.safe_load(parts[1])
        body = parts[2].strip()
    else:
        meta = {}
        body = content

    meta['content'] = markdown.markdown(
        body,
        extensions=['fenced_code', 'tables']
    )
    return meta

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

@app.route('/2026/04/hey-markdown')
def hey_markdown_post():
    post = parse_post('content/posts/hey-markdown.md')
    return render_template('post.html', post=post)

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

Step 5: Create the Post Template

Create templates/post.html:

<!DOCTYPE html>
<html lang="en">
<head>
    <title>{{ post.title }}</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?plugins=typography"></script>
    <script src="{{ url_for('static', filename='js/tailwind.config.js') }}"></script>
</head>
<body class="bg-slate-950 text-gray-100 font-sans min-h-screen flex flex-col">

    <!-- Navbar -->
    <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>

    <!-- Post -->
    <main class="max-w-3xl mx-auto px-6 py-16 flex-1 w-full">

        <p class="text-gray-500 text-sm mb-4">{{ post.date }}</p>
        <h1 class="font-serif text-4xl text-white leading-tight mb-8">{{ post.title }}</h1>

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

        <div class="prose prose-invert max-w-none
                    prose-headings:font-serif prose-headings:text-white
                    prose-p:text-gray-300 prose-p:leading-relaxed
                    prose-a:text-brand-500 prose-a:no-underline hover:prose-a:underline
                    prose-code:text-brand-500 prose-code:bg-slate-800 prose-code:px-1 prose-code:rounded
                    prose-pre:p-0 prose-pre:bg-transparent prose-pre:border-0
                    prose-strong:text-white
                    prose-li:text-gray-300">
            {{ post.content | safe }}
        </div>

    </main>

    <!-- Footer -->
    <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>

</body>
</html>

A few things to note:

{{ post.content | safe }}: The | safe filter tells Flask's template engine not to escape the HTML. Without it, you'd see raw <p> and <h2> tags on the page instead of rendered HTML. This is safe here because you control the content, it's your own Markdown files, not user input.

prose classes: These are Tailwind Typography utility classes that style HTML content you don't control directly. Without them, the rendered Markdown (<h1>, <p>, <ul>, etc.) would inherit no styles at all from Tailwind, because Tailwind resets all browser defaults by design. The prose classes restore readable typography for body content.

prose-pre:p-0 prose-pre:bg-transparent prose-pre:border-0: These override the default <pre> styling that prose applies. In the next step we'll add a JavaScript file that wraps each code block in a styled container with a language label and a Copy button. Those wrapper elements provide the background, padding, and border, so we strip the defaults here to avoid double-styling. If you're not planning to add the code-block wrapper yet, you can swap these for prose-pre:bg-slate-800 prose-pre:border prose-pre:border-slate-700 for now.

Wait, do I need to install anything for prose? No package install is needed for this tutorial because the Tailwind Play CDN can enable first-party plugins through the script URL. The ?plugins=typography part is what makes the prose classes available.

Step 6: Format the Date

Right now, {{ post.date }} outputs exactly what's in your YAML: 2026-04-25.

I generally use YYYY-MM-DD in my coding files. It's great for sorting and it keeps everything in chronological order. But it doesn't read like a blog post date. Let's format it into something easier for readers.

Open app.py. Add the datetime import at the top:

from datetime import datetime

Now add a format_date() function below parse_post():

def format_date(date_value):
    """Convert YYYY-MM-DD to '01 January 2026' format."""
    if isinstance(date_value, str):
        date_value = datetime.strptime(date_value, '%Y-%m-%d').date()
    return date_value.strftime('%d %B %Y')

What this does:

Accepts either a string ("2026-04-25") or a date object (PyYAML sometimes parses dates automatically)
Converts string input to a proper date object
Returns it formatted as 25 April 2026

Now update app.py to apply the formatting when returning the post:

@app.route('/2026/04/hey-markdown')
def hey_markdown_post():
    post = parse_post('content/posts/hey-markdown.md')
    post['date'] = format_date(post.get('date', ''))
    return render_template('post.html', post=post)

The date in your template will now read 25 April 2026 instead of 2026-04-25.

Step 7: Better Code Blocks

At this point the page works. Markdown renders, the layout matches the rest of the site. But the code blocks are plain, just a dark box with no label and no way to copy the content.

Since we're building a platform for technical content, this matters. Readers want to copy commands and snippets without selecting text manually.

We'll fix this with a small JavaScript file. Create it in static/js/.

Create static/js/code-blocks.js:

document.querySelectorAll('pre').forEach(function(pre) {
    var code = pre.querySelector('code');
    var lang = '';
    if (code && code.className) {
        var match = code.className.match(/language-([\w-]+)/);
        if (match) lang = match[1];
    }

    function copyText() {
        var text = code.innerText;
        var shellLanguages = ['bash', 'sh', 'shell', 'zsh', 'console'];

        if (shellLanguages.indexOf(lang) !== -1) {
            return text
                .split('\n')
                .map(function(line) {
                    return line.replace(/^\s*[$#]\s+/, '');
                })
                .join('\n')
                .trimEnd();
        }

        return text;
    }

    var wrapper = document.createElement('div');
    wrapper.className = 'rounded-lg border border-slate-700 overflow-hidden my-6';

    var header = document.createElement('div');
    header.className = 'flex items-center justify-between bg-slate-800 px-4 py-2 border-b border-slate-700';

    var label = document.createElement('span');
    label.className = 'text-xs text-gray-400 font-mono';
    label.innerText = lang || 'code';

    var btn = document.createElement('button');
    btn.innerText = 'Copy';
    btn.className = 'text-xs text-gray-400 hover:text-white bg-slate-700 hover:bg-slate-600 px-2 py-1 rounded transition-colors duration-200';

    btn.addEventListener('click', function() {
        navigator.clipboard.writeText(copyText()).then(function() {
            btn.innerText = 'Copied!';
            setTimeout(function() { btn.innerText = 'Copy'; }, 2000);
        });
    });

    header.appendChild(label);
    header.appendChild(btn);

    pre.className = 'bg-slate-900 p-4 overflow-x-auto m-0 text-sm';

    pre.parentNode.insertBefore(wrapper, pre);
    wrapper.appendChild(header);
    wrapper.appendChild(pre);
});

What this does:

Finds every <pre> block on the page after it loads
Reads the language from the class="language-python" attribute added by the fenced_code extension
Wraps the block in a styled container with a header bar showing the language label and a Copy button
Uses navigator.clipboard.writeText() to copy the code text
Strips leading $ and # prompts from shell snippets before copying, so readers can paste commands directly
Changes the button to "Copied!" for 2 seconds as feedback

Now update post.html with two changes. First, override the prose-pre defaults so they don't conflict with the custom wrapper the script builds:

prose-pre:p-0 prose-pre:bg-transparent prose-pre:border-0

Second, add the script tag just before </body>:

    <script src="{{ url_for('static', filename='js/code-blocks.js') }}"></script>

</body>

The script tag goes at the bottom, after the page content has loaded, so that querySelectorAll('pre') finds the rendered blocks.

Your prose-pre classes from Step 5 already have this covered, so you don't need to change anything in the <div class="prose ..."> block.

Step 8: Test It

Run the app:

$ python app.py

Visit http://localhost:8000/2026/04/hey-markdown.

It should look like this:

Try the Copy button on the bash block. It should leave out the $ and # prompts, so the copied text is ready to paste into your terminal.

The homepage at http://localhost:8000 still shows the hardcoded post list from Episode 2. That's fine for now, we'll wire everything together in Episode 4.

What You've Built

Your file structure is now:

tiohub-blog/
├── app.py
├── requirements.txt
├── static/
│   └── js/
│       ├── tailwind.config.js
│       └── code-blocks.js
├── templates/
│   ├── index.html
│   └── post.html
└── content/
    └── posts/
        └── hey-markdown.md

You've added:
✅ Markdown and PyYAML installed and saved to requirements.txt
✅ parse_post(): reads a .md file, splits frontmatter from content, returns both
✅ format_date(): converts 2026-04-25 to 25 April 2026 for display
✅ /<year>/<month>/<slug> URL format matching Blogger's pattern
✅ post.html template with matching nav, footer, and Tailwind Typography styles
✅ Code blocks styled as boxes with a language label and one-click copy button

Coming Up

Next time: multiple posts. We'll scan the content/posts/ folder for all .md files, sort them by date, and list them on the homepage. We'll also make the route dynamic, /<int:year>/<int:month>/<slug>, so any post can be reached by its date and filename.

The hardcoded post in index.html goes away. The hardcoded route in app.py goes away too.

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

SEO Metadata

Title: Building a Blog Platform with Docker #3: Markdown Rendering (2026)
Meta Description: Stop writing HTML for every blog post. Parse Markdown files with YAML frontmatter in Flask using the Markdown and PyYAML libraries.
Target Keywords: flask markdown rendering, pyyaml frontmatter flask, python markdown blog, flask blog markdown tutorial 2026
Word Count: ~1,100

KVM on Podman Networking

David Tio — Thu, 23 Apr 2026 01:16:24 +0000

KVM on Podman Networking

Quick one-liner: Two networking modes for KVM in Podman — container-native (private) and bridge (full network). Each serves different use cases.

🤔 Why This Matters

Your VMs need to talk to something — containers, the host, or the outside world. But networking isn't one-size-fits-all.

Container-native is simple, private, and requires no host setup. Your VM lives inside the container's network namespace.

Bridge networking gives you full VM behavior — visible to host, other VMs, and the network. But it needs bridge, dnsmasq, and TAP devices on the host.

This post shows both approaches.

🐳 Section 1: Container-Native Networking

The VM lives inside the container's network namespace. It's private — only visible to containers on your Podman network.

When to Use This

Databases that shouldn't be exposed
Testing environments
Quick experiments without host setup

The Architecture

Prerequisites

qemu:base image from Post #1
~/vm directory with cloud images

Step 1: Create a Podman Network

podman network create mynet

Step 2: Run the VM with Slirp

Run the VM with slirp networking and port forwarding:

podman run --rm -it \
    --name qemu-container \
    --network=mynet \
    -p 2222:22 \
    -p 6379:6379 \
    --device /dev/kvm \
    -v ~/vm:/vm:z \
    qemu:base \
    qemu-system-x86_64 \
        -enable-kvm -cpu host \
        -m 1024 \
        -drive file=/vm/noble-server-cloudimg-amd64.img,format=qcow2,if=virtio \
        -netdev user,id=net0,hostfwd=tcp::22-:22,hostfwd=tcp::6379-:6379 \
        -device virtio-net-pci,netdev=net0 \
        -nographic

The key flags:

mynet — Podman network (10.89.0.0/24)
-p 2222:22 -p 6379:6379 — expose to host
hostfwd=tcp::22-:22 — forward VM port 22 to container (all interfaces)
hostfwd=tcp::6379-:6379 — forward VM port 6379 to container (all interfaces)
-netdev user — slirp user-mode networking

The VM boots and gets an IP from slirp's internal DHCP (usually 10.0.2.15).

🐧 Step 3: Install Redis in the VM

Wait for boot and cloud-init (~20 seconds). Login at the console and install Redis:

sudo apt-get update
sudo apt-get install -y redis-server
sudo sed -i 's/bind 127.0.0.1/bind 0.0.0.0/' /etc/redis/redis.conf
sudo sed -i 's/protected-mode yes/protected-mode no/' /etc/redis/redis.conf
sudo systemctl enable --now redis-server

🧪 Step 4: Test — Host to VM

From your host, test the Redis connection:

redis-cli localhost 6379

Or SSH to the VM:

ssh -p 2222 sysadmin@localhost

🧪 Step 5: Test — Container to VM

From a new terminal, test with an app-container:

podman run --rm -it \
    --network=mynet \
    docker.io/redis:latest \
    redis-cli -h qemu-container ping

Note: Podman DNS resolves qemu-container to 10.89.0.2 — no need to remember IPs.

🌉 Section 2: Bridge Networking

The VM acts like it's on a real network. It's visible to the host, other VMs, and the network.

When to Use This

VMs that need full network access
Hosting services accessible from the network
Multi-VM environments

The Architecture

Prerequisites

qemu:base image from Post #1
~/vm directory with cloud images
Root access on your host

Step 1: Host Setup

Create the bridge and TAPs on your host:

sudo ip link add kvmbr0 type bridge
sudo ip addr add 192.168.100.1/24 dev kvmbr0
sudo ip link set kvmbr0 up

Configure dnsmasq:

sudo tee /etc/dnsmasq.d/kvmbr0.conf << 'EOF'
interface=kvmbr0
bind-interfaces
dhcp-range=192.168.100.200,192.168.100.250,12h
dhcp-option=3,192.168.100.1
dhcp-option=6,8.8.8.8
EOF

sudo systemctl restart dnsmasq

Enable IP forwarding:

sudo tee /etc/sysctl.d/99-kvmbr0.conf << 'EOF'
net.ipv4.ip_forward=1
EOF

sudo sysctl --system

Create TAP devices:

sudo ip tuntap add tap0 mode tap
sudo ip link set tap0 master kvmbr0
sudo ip link set tap0 up

Step 2: Build the QEMU Image

mkdir -p ~/kvmnet
cd ~/kvmnet

cat > run-vm.sh << 'EOF'
#!/bin/bash
DISK=$1
CPUS=${2:-2}
MEMORY=${3:-1024}
TAP=${4:-tap0}

qemu-system-x86_64 \
    -enable-kvm -cpu host \
    -m $MEMORY -smp $CPUS -nographic \
    -drive file=$DISK,format=qcow2,if=virtio \
    -netdev tap,id=net0,ifname=$TAP,script=no,downscript=no \
    -device virtio-net-pci,netdev=net0
EOF

chmod +x run-vm.sh

Containerfile:

FROM alpine:latest

RUN apk add --no-cache \
        qemu-system-x86_64 \
        qemu-img \
        iproute2 \
        bash

COPY run-vm.sh /run-vm.sh
RUN chmod +x /run-vm.sh

WORKDIR /vms
CMD ["/bin/bash"]

Build:

podman build -t qemu:base .

Step 3: Run a VM

podman run --rm -it \
    --name vm1 \
    --network=host \
    --device /dev/kvm \
    --device /dev/net/tun:/dev/net/tun \
    -v ~/vm:/vm:z \
    qemu:base \
    /run-vm.sh /vm/noble-server-cloudimg-amd64.img

Wait for the VM to boot and cloud-init (~20 seconds). Check the IP in the VM console:

ip addr show ens3

Note this IP — you'll use it for the tests below.

🧪 Step 4: Test — Host to VM

From your host:

redis-cli <your-vm-ip>

🧪 Step 6: Test — Container to VM

Launch an app-container:

podman run --rm -it \
    --name app-container \
    --network=container:vm1 \
    docker.io/redis:latest \
    redis-cli -h <your-vm-ip> ping

Comparison

Aspect	Container-Native	Bridge
Host setup	None	Bridge, dnsmasq, TAPs
VM visible to host	Via -p ports	Yes
Container-to-VM	Via Podman DNS	Via IP
VM network	Private (slirp)	Real (bridge)
Use case	Private/testing	Full networking

🧹 Cleanup

Container-Native

podman rm -f qemu-container
podman network rm mynet

Bridge

podman rm -f vm1 app-container

sudo ip link delete tap0
sudo ip link delete kvmbr0
sudo rm /etc/dnsmasq.d/kvmbr0.conf
sudo systemctl restart dnsmasq

What You've Built

✅ Container-native networking with slirp
✅ Port forwarding (hostfwd) from VM to container
✅ Podman DNS for container-to-VM communication
✅ Host access via -p ports
✅ Bridge networking with host bridge
✅ TAP devices for VM networking
✅ Container-to-VM via shared network
✅ Host-to-VM via bridge

What's Next?

Your VMs and containers can now talk to each other. I am actually not sure what's next but this is definitely not the end .

Found this helpful?

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

Docker Compose Explained: Multi-Container Stacks (2026)

David Tio — Mon, 20 Apr 2026 01:05:42 +0000

Quick one-liner: Connect CloudBeaver and PostgreSQL in one compose file. Then scale up to a full four-service Nextcloud stack with shared networks.

🤔 Why This Matters

In the last post, you created two compose projects: PostgreSQL in one directory, CloudBeaver in another. Each has its own compose file, its own network, its own lifecycle. They can't talk to each other.

That's the problem this post solves. We'll put them in one file, on one network, and CloudBeaver can finally reach PostgreSQL. No custom network commands. No --network flags. Just one docker compose up -d.

Once you've got two services talking, we'll scale up to four. Here's the full Nextcloud stack with MariaDB, Redis, PHP-FPM, and nginx all in one file.

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

CloudBeaver + PostgreSQL connected in one compose file
A four-service Nextcloud stack on a shared network

✅ Prerequisites

Ep 1-7 completed. You know Compose basics like single service per file, .env files, and the up/ps/logs/down workflow.

📦 The Problem: Two Compose Files, Two Networks

Last time you ended up with PostgreSQL in one directory and CloudBeaver in another:

~/
├── dtstack-pg/
│   ├── docker-compose.yml
│   └── .env
└── dtstack-cb/
    ├── docker-compose.yml
    └── ...

Each project gets its own network. PostgreSQL is on dtstack-pg_default, CloudBeaver is on dtstack-cb_default. They can't reach each other. You can't connect CloudBeaver to the database.

That's what multi-service compose fixes. One file, one network, both services talking.

🔧 Step 1: CloudBeaver + PostgreSQL in One File

Create a single directory for your stack:

$ mkdir -p cloudstack && cd cloudstack

Create docker-compose.yml:

services:
  postgres:
    container_name: dtstack-pg
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: ${PG_PASSWORD}
      POSTGRES_DB: ${PG_DATABASE}
    volumes:
      - pgdata:/var/lib/postgresql/data
    networks:
      - dtstack

  cloudbeaver:
    container_name: dtstack-cb
    image: dbeaver/cloudbeaver:latest
    ports:
      - "8978:8978"
    volumes:
      - cbdata:/opt/cloudbeaver/workspace
    networks:
      - dtstack

volumes:
  pgdata:
  cbdata:

networks:
  dtstack:
    driver: bridge

Two services. One networks: block. Both on the same dtstack network.

Create .env:

$ cat > .env << EOF
PG_PASSWORD=docker
PG_DATABASE=testdb
EOF

Two things to notice:

No ports on PostgreSQL. CloudBeaver reaches it on the internal network, so there's no need to expose port 5432 to the host. Only CloudBeaver needs a port mapping since it's the one you access from your browser.
Each service lists networks: - dtstack. This explicitly connects them to the shared bridge network. Compose would create a default network and connect them automatically, but declaring it explicitly makes the intent clear.

🚀 Start the Stack

$ docker compose up -d

[+] up 32/32
 ✔ Image postgres:17                Pulled
 ✔ Image dbeaver/cloudbeaver:latest Pulled
 ✔ Network cloudstack_dtstack       Created
 ✔ Volume cloudstack_pgdata         Created
 ✔ Volume cloudstack_cbdata         Created
 ✔ Container dtstack-cb             Started
 ✔ Container dtstack-pg             Started

One command. Seven things done (two images pulled, network, two volumes, two containers). Everything connected.

Verify both services are running:

$ docker compose ps
NAME         IMAGE                        COMMAND                  SERVICE      CREATED      STATUS      PORTS
dtstack-cb   dbeaver/cloudbeaver:latest   "./launch-product.sh"    cloudbeaver  5 min ago    Up 5 min    0.0.0.0:8978->8978/tcp
dtstack-pg   postgres:17                  "docker-entrypoint.s…"   postgres     5 min ago    Up 5 min    5432/tcp

Only CloudBeaver has a port mapping. PostgreSQL is on the dtstack network but invisible to the host. That's exactly what we want.

🔍 Verify Connectivity

Open http://localhost:8978 in your browser. CloudBeaver loads.

Now add PostgreSQL as a connection in CloudBeaver:

Host: postgres (the service name, not an IP address)
Port: 5432
Database: testdb (from your .env)
Username: postgres
Password: docker (from your .env)

Connect. It works. CloudBeaver reaches PostgreSQL by service name. No IP addresses. No docker network connect. It just works.

🔍 Inspect the Network

See what Compose created:

$ docker network inspect cloudstack_dtstack

Look at the Containers section. Both services are listed with their IP addresses:

"Containers": {
    "abc123...": {
        "Name": "dtstack-pg",
        "IPv4Address": "172.19.0.2/16"
    },
    "def456...": {
        "Name": "dtstack-cb",
        "IPv4Address": "172.19.0.3/16"
    }
}

Two containers. One network. Use the service name (postgres, cloudbeaver) when connecting services to each other — not the container name.

🛑 Tear It Down

$ docker compose down

[+] down 3/3
 ✔ Container dtstack-cb       Removed
 ✔ Container dtstack-pg       Removed
 ✔ Network cloudstack_dtstack Removed

Two containers gone. Network gone. Volumes survive.

Volumes are preserved by default. Check:

$ docker volume ls | grep cloudstack

local  cloudstack_pgdata
local  cloudstack_cbdata

Start the stack again and your database is still there:

$ docker compose up -d

To remove everything including volumes:

$ docker compose down --volumes

[+] down 5/5
 ✔ Container dtstack-pg       Removed
 ✔ Container dtstack-cb       Removed
 ✔ Volume cloudstack_cbdata   Removed
 ✔ Volume cloudstack_pgdata   Removed
 ✔ Network cloudstack_dtstack Removed

📦 Step 2: Scale Up to a Four-Service Nextcloud Stack

Now let's go bigger. Four services in one file, all talking to each other.

Create a single directory for your Nextcloud stack:

$ mkdir -p nextcloud && cd nextcloud

Create docker-compose.yml:

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

  redis:
    container_name: nc-redis
    image: redis:8.6
    volumes:
      - redisdata:/data
    networks:
      - nextcloud

  php:
    container_name: nc-php
    image: nextcloud:fpm
    volumes:
      - ./html:/var/www/html
    networks:
      - nextcloud

  nginx:
    container_name: nc-nginx
    image: nginx:latest
    ports:
      - "8080:80"
    volumes:
      - ./html:/var/www/html
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
    networks:
      - nextcloud

volumes:
  dbdata:
  redisdata:

networks:
  nextcloud:
    driver: bridge

Four services. One networks: block. All of them on the same nextcloud network.

Create .env:

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

Create nginx.conf:

server {
    listen 80;
    server_name localhost;

    root /var/www/html;
    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass php:9000;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

Three things to notice:

Volumes are shared. dbdata and redisdata are defined once at the bottom and used by the services that need them.
PHP-FPM and nginx both mount ./html. Both services mount the same host directory at the same container path: /var/www/html. When Nextcloud writes an uploaded file to /var/www/html/data/user1/photo.jpg inside the PHP-FPM container, nginx can immediately serve it from the same path. No copying, no syncing, just one shared directory.
Nginx needs a config to talk to PHP-FPM. The nginx.conf file tells nginx: when you see a .php request, don't serve the raw file. Forward it to the php service on port 9000 via FastCGI. Without this, your browser would download index.php instead of running it.

🚀 Start the Nextcloud Stack

$ docker compose up -d

[+] up 19/19
 ✔ Image nextcloud:fpm         Pulled
 ✔ Image nginx:latest          Pulled
 ✔ Image mariadb:11            Pulled
 ✔ Image redis:8.6             Pulled
 ✔ Network nextcloud_nextcloud Created
 ✔ Volume nextcloud_dbdata     Created
 ✔ Volume nextcloud_redisdata  Created
 ✔ Container nc-nginx          Started
 ✔ Container nc-db             Started
 ✔ Container nc-redis          Started
 ✔ Container nc-php            Started

One command. Eleven things done (four images pulled, network, two volumes, four containers). Everything connected.

Verify all services are running:

$ docker compose ps
NAME         IMAGE            COMMAND                  SERVICE   CREATED      STATUS      PORTS
nc-db        mariadb:11       "docker-entrypoint.s…"   db        5 min ago    Up 5 min    3306/tcp
nc-redis     redis:8.6        "docker-entrypoint.s…"   redis     5 min ago    Up 5 min    6379/tcp
nc-php       nextcloud:fpm    "docker-entrypoint.s…"   php       5 min ago    Up 5 min    9000/tcp
nc-nginx     nginx:latest     "/docker-entrypoint.…"   nginx     5 min ago    Up 5 min    0.0.0.0:8080->80/tcp

Only nc-nginx has a port mapping. The other three services are on the nextcloud network but invisible to the host. That's exactly what we want.

🖥️ Use Nextcloud

Open http://localhost:8080. The Nextcloud setup page loads.

Create an admin account, then fill in the database section:

Database type: MariaDB
Database user: nextcloud
Database password: nextcloud
Database name: nextcloud
Database host: nc-db

Hit Finish setup. Nextcloud initializes, connects to MariaDB, and drops you into the dashboard.

Upload a file. Create a folder. It works. All four services are talking to each other through that single compose file.

Check the html/ directory on the host. The nextcloud:fpm image populated it on first start:

$ ls html/

You'll see Nextcloud's file structure like index.php, core/, apps/, config/, and more. Nginx is serving from this same directory, so your static files and PHP requests all come from the same source.

🛑 Tear Down the Nextcloud Stack

To stop and remove containers, volumes, and the network:

$ docker compose down --volumes

--volumes removes named volumes (dbdata, redisdata) but not bind-mounted directories. The html/ directory on your host stays untouched. Remove it manually if you want a clean slate:

$ rm -rf html/

Start again and you'll get a fresh Nextcloud setup.

🧪 Exercise 1: Producer, Queue, and Worker

In a real production system, you often have long-running tasks that shouldn't block a web request. The solution is a job queue: the web server adds a job, a separate worker picks it up and processes it.

Create a directory and save these two scripts:

producer.py (adds jobs to Redis):

from http.server import HTTPServer, BaseHTTPRequestHandler
import urllib.parse, redis

r = redis.Redis(host='redis', port=6379, decode_responses=True)

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        count = r.llen('jobs')
        self.send_response(200)
        self.send_header("Content-Type", "text/html")
        self.end_headers()
        self.wfile.write(f"<h2>Job Queue</h2><p>{count} jobs in queue</p><form method='post'><input name='job' placeholder='Enter job name'><button>Submit</button></form>".encode())

    def do_POST(self):
        length = int(self.headers.get("Content-Length", 0))
        job = urllib.parse.parse_qs(self.rfile.read(length).decode())["job"][0]
        r.lpush('jobs', job)
        self.send_response(302)
        self.send_header("Location", "/")
        self.end_headers()

    def log_message(self, format, *args):
        pass

HTTPServer(("0.0.0.0", 5000), Handler).serve_forever()

worker.py (processes jobs from Redis):

import redis, time, random

r = redis.Redis(host='redis', port=6379, decode_responses=True)

print("Worker ready. Waiting for jobs...")
while True:
    job = r.brpop('jobs', timeout=0)
    if job:
        _, task = job
        print(f"Processing {task}...")
        time.sleep(random.randint(30, 60))
        print(f"Completed {task}")

Your job: Write the compose file to connect all three services.

Hints:

Three services: redis, producer, worker
All three need to be on the same network
Use python:slim for both producer and worker
Mount producer.py and worker.py into their respective containers
Producer needs port 5000 exposed
Worker uses brpop which blocks until a job is available

📦 Exercise 1 Solution

Create a directory and save all three files inside it:

$ mkdir -p prodwork && cd prodwork

docker-compose.yml:

services:
  redis:
    image: redis:latest

  producer:
    image: python:slim
    command: sh -c "pip install redis && python -u /app/producer.py"
    ports:
      - "5000:5000"
    volumes:
      - ./producer.py:/app/producer.py
    working_dir: /app

  worker:
    image: python:slim
    command: sh -c "pip install redis && python -u /app/worker.py"
    volumes:
      - ./worker.py:/app/worker.py
    working_dir: /app

The -u flag forces unbuffered output. Without it, Python buffers print() when there's no terminal, and you won't see worker logs in real time.

No networks: block in the compose file. Compose creates a default network named prodwork_default and connects all three services automatically. You can verify:

$ docker network ls | grep prodwork
80e4fc2182b5   prodwork_default   bridge    local

Then start:

$ docker compose up -d

Watch the worker and start submitting jobs:

$ docker compose logs -f worker
worker  | Worker ready. Waiting for jobs...

Open http://localhost:5000 in your browser, submit a job, and every 30-60 seconds you'll see the worker process it:

worker  | Processing "Generate monthly report"...
worker  | Completed Generate monthly report

The web server never blocked. The job queue handled the delay.

🧪 Exercise 2: Build a Load Balanced App

Here's a Python app that shows its hostname and a random background color. We'll put nginx in front of it. Writing the compose file is your job.

app.py (stdlib, no external dependencies):

from http.server import HTTPServer, BaseHTTPRequestHandler
import socket, random, time

colors = [
    "#e74c3c", "#c0392b", "#8e44ad", "#2c3e50", "#2980b9",
    "#16a085", "#27ae60", "#d35400", "#f39c12", "#2d3436",
]
color = random.choice(colors)
requests = 0
started = time.time()

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        global requests
        if self.path == "/favicon.ico":
            self.send_response(204)
            self.end_headers()
            return
        requests += 1
        self.send_response(200)
        self.send_header("Content-Type", "text/html")
        self.end_headers()
        hostname = socket.gethostname()
        ip = socket.gethostbyname(hostname)
        uptime = int(time.time() - started)
        html = f"""<html><body style="background:{color};font-family:monospace;text-align:center;padding-top:10%">
        <h1 style="font-size:4em;color:white">{hostname}</h1>
        <p style="font-size:1.8em;color:white">{ip}</p>
        <p style="font-size:1.4em;color:white">Requests: {requests} | Uptime: {uptime}s</p>
        </body></html>"""
        self.wfile.write(html.encode())

    def log_message(self, format, *args):
        pass

HTTPServer(("0.0.0.0", 5000), Handler).serve_forever()

nginx.conf (load balance across upstream instances):

upstream backend {
    server web:5000;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend;
    }
}

Hints for the compose file:

Two services: nginx and web (python:slim)
Nginx needs port 8080 mapped to 80
Nginx mounts nginx.conf
Web mounts app.py, runs on port 5000 internally (no host port needed)
Both on the same network (or just let Compose create the default)

📦 Exercise 2 Solution

Create a directory and save all three files inside it (docker-compose.yml, app.py, nginx.conf):

$ mkdir -p loadbalance && cd loadbalance

docker-compose.yml:

services:
  nginx:
    image: nginx:latest
    ports:
      - "8080:80"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf

  web:
    image: python:slim
    command: python /app/app.py
    volumes:
      - ./app.py:/app/app.py
    working_dir: /app

$ docker compose up -d

Open http://localhost:8080. You'll see a random color with the container hostname. Refresh. Same result for now.

Next post we'll put this under pressure.

🏁 What You've Built

Feature	What It Does
One file, two services	CloudBeaver + PostgreSQL on the same network
One file, four services	MariaDB, Redis, PHP-FPM, nginx, all in one place
Shared volume mounts	PHP-FPM and nginx mount `./html` at the same `/var/www/html` path
Nginx + FastCGI	`nginx.conf` proxies PHP requests to PHP-FPM on port 9000
No unnecessary ports	Only the web-facing service is exposed, database and cache stay internal
`.env` for secrets	Passwords live in a file, not in YAML
Redis job queue	Producer, worker, and queue. Three services, one compose file
Load balanced app	nginx + Python web service, ready for scaling

👉 Coming up: You've got services talking to each other. But what happens when the worker crashes, or the queue suddenly has a hundred jobs? How do you build a stack that holds up?

Found this helpful? 🙌

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

Run Your First Podman Container: Images, Lifecycle, and Flags (2026)

David Tio — Sun, 19 Apr 2026 05:30:43 +0000

🐳 Run Your First Podman Container: Images, Lifecycle, and Flags (2026)

Quick one-liner: Pull images, run containers, manage their lifecycle, and understand the flags that make Podman different from Docker.

🤔 Why This Matters

In Ep 1, you installed Podman, set up shared storage, and verified rootless operation. Now it's time to actually do something with it.

This post walks you through:

Finding and pulling images from container registries
Running your first container with the right flags
Managing container lifecycles (start, stop, restart, remove)
The key differences between podman run and docker run

By the end, you'll be comfortable managing containers with Podman. You'll also understand why podman run is a drop-in replacement for docker run.

✅ Prerequisites

Podman installed, rootless on SLES 16 (see Ep 1)
Shared storage configured (multi-user UID/GID setup)
5 minutes to run your first workload

🔍 Finding Images

Podman uses container registries to pull images. On SLES, the default registry is registry.suse.com. It's SUSE's own registry with images built and maintained for SLES:

$ podman search nginx
NAME                                                                              DESCRIPTION
registry.suse.com/caasp/v4/nginx-ingress-controller                               
registry.suse.com/caasp/v4.5/ingress-nginx-controller                             
registry.suse.com/caasp/v5/ingress-nginx-controller                               
registry.suse.com/cap/nginx-buildpack                                             
registry.suse.com/cap/stratos-metrics-nginx                                       
registry.suse.com/cap/suse-nginx-buildpack                                        
registry.suse.com/rancher/library-nginx                                           
registry.suse.com/suse/nginx

Start here. If the image you need is in the SUSE registry, use it. It's tested on SLES, receives security updates, and works seamlessly with your system.

But the SUSE registry doesn't have everything. If you can't find an image there, fall back to Docker Hub (docker.io) or Quay (quay.io), which is where most of the world's container images live. To search Docker Hub, prefix with the registry name:

$ podman search docker.io/library/nginx
NAME                                              DESCRIPTION
docker.io/library/nginx                           Official build of Nginx.
docker.io/nginx/nginx-ingress                     NGINX and NGINX Plus Ingress Controllers...
docker.io/nginx/nginx-prometheus-exporter         NGINX Prometheus Exporter for NGINX...
docker.io/nginx/unit                              This repository is retired, use the Docker...
docker.io/nginx/nginx-ingress-operator            NGINX Ingress Operator for NGINX and NGINX...
docker.io/bitnami/nginx                           Bitnami Secure Image for nginx

Look for the official images (from docker.io/library/). They're maintained by the software's creators and receive regular security updates.

🐳 Running Your First Container

Let's run nginx from the SUSE registry:

$ podman run -d --rm --name dtnginx suse/nginx

Let me break down each flag:

Flag	What It Does
`-d`	Detach: runs the container in the background so you get your terminal back
`--rm`	Auto-remove: automatically deletes the container once it stops
`--name dtnginx`	Name it `dtnginx` instead of a random ID
`suse/nginx`	The image to run. Podman on SLES searches `registry.suse.com` by default, so the short name works

If this is the first time running this image, Podman downloads it:

Resolving "suse/nginx" using unqualified-search registries (/etc/containers/registries.conf)
Trying to pull registry.suse.com/suse/nginx:latest...
Getting image source signatures
Checking if image destination supports signatures
Copying blob 5a22de652f81 done   |
Copying blob 36e296237f0c done   |
Copying config 885ea61474 done   |
Writing manifest to image destination
Storing signatures

📊 Checking Container Status

Verify it's running:

$ podman ps
CONTAINER ID  IMAGE                                COMMAND               CREATED        STATUS         PORTS       NAMES
431e72ff8902  registry.suse.com/suse/nginx:latest  nginx -g daemon o...  10 seconds ago Up 10 seconds  80/tcp      dtnginx

Note: podman ps and docker ps produce identical output. If you've used Docker, the commands feel the same.

To see all containers (including stopped ones):

$ podman ps -a
CONTAINER ID  IMAGE                                COMMAND               CREATED         STATUS                     PORTS       NAMES
431e72ff8902  registry.suse.com/suse/nginx:latest  nginx -g daemon o...  2 minutes ago   Up 2 minutes               80/tcp      dtnginx
2ea01225897d  quay.io/podman/hello:latest          /usr/local/bin/po...  3 minutes ago   Exited (0) 3 minutes ago               hopeful_heyrovsky

dtnginx is still running in the background. The hello container from Ep1 is sitting in "Exited" state. Because it was run without --rm, it stayed around after it finished.

💡 Tip: forgot to name your container? Podman assigns random names like hopeful_heyrovsky or agitated_villani. You can rename it anytime:
$ podman rename hopeful_heyrovsky dthello
Now podman ps -a shows dthello instead. Much easier to manage.

To clean up stopped containers, use podman rm:

$ podman rm dthello
dthello
$ podman ps -a
CONTAINER ID  IMAGE  COMMAND  CREATED  STATUS  PORTS  NAMES

💻 Accessing the Container Shell

Open a shell inside the running container:

$ podman exec -it dtnginx /bin/bash

Flag	What It Does
`-i`	Keeps stdin open
`-t`	Allocates a pseudo-terminal

You're now inside the container. Check the nginx default page:

bash-5.2# curl localhost
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the container with the nginx web server is 
successfully installed and working.</p>
</body>
</html>

Exit the shell:

bash-5.2# exit

🛑 Stopping and Cleaning Up

Stop the container:

$ podman stop dtnginx

Since we used --rm, it's automatically removed. Confirm:

$ podman ps -a
CONTAINER ID  IMAGE  COMMAND  CREATED  STATUS  PORTS  NAMES

No sign of dtnginx. The --rm flag took care of it.

If you forgot --rm, the container stays around in "Exited" state. Clean it up:

$ podman rm dtnginx

Or remove all stopped containers at once:

$ podman container prune

⚙️ Environment Variables

Many container images are configured through environment variables instead of editing config files. This is how you run databases, web apps, and services without ever touching a config file inside the container.

Use the -e flag to pass variables at runtime. Let's run MariaDB:

$ podman run -d --rm --name dtmariadb \
    -e MARIADB_ROOT_PASSWORD=podman \
    -e MARIADB_DATABASE=testdb \
    suse/mariadb

This starts MariaDB with the root password set to podman and automatically creates a database called testdb. Without MARIADB_ROOT_PASSWORD, the container refuses to start.

You can verify the variables inside a running container:

$ podman exec dtmariadb env | grep MARIADB
MARIADB_ROOT_PASSWORD=podman
MARIADB_DATABASE=testdb

To connect to the database from inside the container:

$ podman exec -it dtmariadb mariadb -u root -ppodman -e "SHOW DATABASES;"
Database
information_schema
mysql
performance_schema
testdb

Each image documents its supported environment variables on its Docker Hub page. Scroll down to the "Environment Variables" section and you'll find everything you need. Things like POSTGRES_PASSWORD, MYSQL_ROOT_PASSWORD, REDIS_PASSWORD, and dozens more. That's always the first place I check before running a new database image.

Stop the container when done:

$ podman stop dtmariadb

🔄 Key Differences: Podman vs Docker

You'll notice the commands are nearly identical. But here's what's different under the hood:

Feature	Docker	Podman
Daemon	Required (`dockerd`)	No daemon needed. Containers run as direct child processes
Rootless	Requires extra setup	Rootless by default, no extra setup needed
Systemd integration	Manual	Native support via `podman generate systemd`
Pod support	Via Compose	Native support via `podman pod create`
Fork/exec model	Single daemon manages all	Each container is independent

In practice: alias docker=podman works for 95% of daily commands.

🏋️ Exercise

Part 1: Run Redis and Store Data

Redis isn't in the SUSE registry (the available image is 8 years old), so we fall back to Docker Hub:

$ podman run -d --rm --name dtredis docker.io/library/redis
$ podman exec -it dtredis redis-cli

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

Part 2: Run PostgreSQL and Add Data

$ podman run -d --rm --name dtpg \
    -e POSTGRES_PASSWORD=podman \
    -e POSTGRES_DB=testdb \
    suse/postgres

Wait ~10 seconds for PostgreSQL to initialize, then create a table and insert some data:

$ podman exec -it dtpg psql -U postgres -d testdb

testdb=# CREATE TABLE users (name VARCHAR(50), email VARCHAR(50));
CREATE TABLE
testdb=# INSERT INTO users VALUES ('Alice', 'alice@example.com');
INSERT 0 1
testdb=# SELECT * FROM users;
 name  |       email        
-------+--------------------
 Alice | alice@example.com
(1 row)
testdb=# \q

Alice is in the database. Everything looks good.

Part 3: Remove Both and Lose Everything

$ podman stop dtredis dtpg
$ podman ps -a
CONTAINER ID  IMAGE  COMMAND  CREATED  STATUS  PORTS  NAMES

Both are gone (thanks to --rm). Now start fresh containers:

$ podman run -d --rm --name dtredis docker.io/library/redis
$ podman exec -it dtredis redis-cli

127.0.0.1:6379> GET mykey
(nil)

Redis data is gone. Now check PostgreSQL:

$ podman run -d --rm --name dtpg \
    -e POSTGRES_PASSWORD=podman \
    -e POSTGRES_DB=testdb \
    suse/postgres
$ podman exec -it dtpg psql -U postgres -d testdb -c "SELECT * FROM users;"
ERROR:  relation "users" does not exist

Alice is gone. The table is gone. The database is a fresh empty shell.

Containers are ephemeral by design. When they go, everything inside them goes with them.

Next chapter: we rescue Alice. Persistent storage that survives container death.

👉 Coming up: You've got nginx running and MariaDB configured. But here's a problem. Stop the container, remove it, start a new one, and your data is gone. The database you just created? Disappeared.

Next time: we fix that. Persistent storage that survives container death. Your data lives on even when containers come and go.

Found this helpful? 🙌

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

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

DEV Community: David Tio

Customizing Docker Images: Write Your First Dockerfile (2026)

🤔 Why This Matters

✅ Prerequisites

🗂 Project Structure

✍️ The App

🐳 First Dockerfile: Flask Dev Server

🔧 Fix It: Switch to Gunicorn

🔨 Verify the Build

🔁 The Rebuild Workflow

🏷️ Tagging Your Builds

✏️ Renaming an Image

🗄️ Baking Init Scripts into Database Images

🧪 Exercise 1: Auto-Initialize a Postgres Schema

🧪 Exercise 2: Bake a Custom Theme into a Ghost Image

🏁 What You Built

Building a Blog Platform with Docker #5: Add a Dockerfile + Deploy to Clouderized

🐳 Building a Blog Platform with Docker #5: Add a Dockerfile + Deploy to Clouderized

🔧 Before We Start: URL Control for Blogger Migration

Add a URL Helper to app.py

Update get_all_posts()

Update the Route

Update the Homepage Links

Add the Canonical Link Tag

Updated Frontmatter Schema

✅ Step 1: Verify Everything Works Locally

📦 Step 2: Add a .dockerignore

📄 Step 3: Write the Dockerfile

🔨 Step 4: Build the Image

🚀 Step 5: Run It

📝 Step 6: Add .gitignore

🌐 Step 7: Deploy to Clouderized

Add Your Custom Domain

🧪 Step 8: Verify It's Live

✅ What You've Built

🚀 Coming Up

SEO Metadata

Desktop Access for KVM on Podman: VNC First, SPICE Next

Desktop Access for KVM on Podman: VNC First, SPICE Next

🤔 Why This Matters

🏗️ What We Are Building

✅ Prerequisites

🖥️ Step 1: Boot the VM with a QEMU VNC Console

🎨 Step 2: Install GNOME 48

Option A: Subscribed SLES (online repos)

Option B: Non-Subscribed SLES (ISO repo)

🔌 Step 3: Connect to the Desktop Console

⚡ Step 4: Where SPICE Fits

💡 Why Not Start with RDP?

🎉 Wrap Up

Docker Compose: depends_on and Health Checks That Actually Protect Startup (2026)

🤔 Why This Matters

✅ Prerequisites

🧨 The Startup Race

❌ Why Plain depends_on Is Not Enough

✅ Add a Real Database Health Check

✅ Gate App Startup on Health, Not Order

📦 Full Compose File (Fixed)

🔍 What To Watch During Startup

⚠ Important Caveat

🧪 Exercise: Start Ghost, Sign Up, and Switch to Journal

Exercise Walkthrough

🏁 What You Built

Building a Blog Platform with Docker #4: Dynamic Routes and a Real Post List

🗂️ Building a Blog Platform with Docker #4: Dynamic Routes and a Real Post List

🤔 Why This Matters

🏁 Starting Point

✏️ Step 1: Update the Frontmatter Schema

🔍 Step 2: Add the Post Scanner

🔗 Step 3: Replace the Hardcoded Route with a Dynamic One

🏠 Step 4: Update the Homepage

🔎 Step 5: Add Meta Description to the Post Page

🏷️ Step 6: Add Tag Pills to the Post Page

🧪 Step 7: Test It

✅ What You've Built

🚀 Coming Up

SEO Metadata

Resize a Tiny SLES 16 Cloud Image with qemu:base on Ubuntu 26.04

Resize a Tiny SLES 16 Cloud Image with qemu:base on Ubuntu 26.04

🤔 Why This Matters

Add a URL Helper to `app.py`

Update `get_all_posts()`

❌ Why Plain `depends_on` Is Not Enough