Deploy and recover a containerized service

Coming soon. This course is planned; lessons and labs are not available yet. No release date has been announced.

Package and run one Linux service on a container host, verify readiness and preserve its data through a controlled rollback.

Intermediate ยท Single-host container operations

Before you begin

Be able to operate a Linux service, inspect logs and requests, and make a controlled configuration change. Container concepts are introduced here.

The planned project

The planned project asks you to deploy a containerized service, verify a real client request and recover from a bad release without losing its persistent state.

Course scope

One container host and one service; Kubernetes and multi-cluster orchestration are separate subjects.

Planned course outline

3 planned chapters and 6 lesson outlines.

  1. Understand the host boundary

    See what the container isolates and what remains a host responsibility.

    1. Planned lesson: Inspect namespaces and resource groups

      Planned task: Compare a service process inside and outside a container, including its limits.

      Changed case to investigate: A process is isolated by namespace but still exhausts a shared resource; identify the missing bound.

    2. Planned lesson: Map mounts and persistent state

      Planned task: Locate image files, writable state and the mounted service data.

      Changed case to investigate: A new container starts with an empty directory; find the missing mount before retrying writes.

  2. Package and release

    Make the runtime definition reproducible and gate the change on useful behavior.

    1. Planned lesson: Build an immutable service image

      Planned task: Pin an image and supply configuration separately, then compare two launches.

      Changed case to investigate: A secret or environment value differs on the second launch; trace the behavior without rebuilding the image.

    2. Planned lesson: Check readiness before routing clients

      Planned task: Use a representative request and dependency check to decide whether a release can serve traffic.

      Changed case to investigate: The container process is running while the data dependency is down; hold the release.

  3. Recover without losing state

    Use signals, logs and a rollback decision while respecting persistent data.

    1. Planned lesson: Observe stop and failure behavior

      Planned task: Inspect signals, logs and exit status during a controlled failure and restart.

      Changed case to investigate: A forced stop interrupts an in-flight request; distinguish process recovery from completed client work.

    2. Planned lesson: Roll back a bad release

      Planned task: Restore the prior image and verify client behavior, volume contents and schema compatibility.

      Changed case to investigate: The newer release changed stored data; explain why an image-only rollback is unsafe.

See available courses