Introduction
Containers package a process with its filesystem view and runtime settings. A container engine such as Docker can build images, run containers from those images, attach storage, show logs, execute commands inside a running container, and remove containers when they are no longer needed.
In this lab, you will use the Docker engine already available in the LabEx instance. To avoid public image pulls, the lab builds a small practice image from a cached local base image. You will inspect the engine, build an image, run a named container with a bind mount, inspect logs and generated files, execute a command inside the container, and clean up the running container.
Inspect the Container Engine
In this step, you will confirm that Docker is available and inspect the local images. A container workflow starts with knowing which engine you are using and which images are already present. This lab avoids public pulls by using a cached base image.
Move into the project directory.
cd /home/labex/project
Check the Docker version.
docker --version
List local images.
docker image ls
You should see gcr.io/k8s-minikube/kicbase:v0.0.37, which the lab uses as the local build base.
Review and Build a Local Image
In this step, you will inspect the prepared Dockerfile and build a local image. An image is a reusable filesystem and metadata template. A container is a running instance created from an image.
View the Dockerfile. The ENTRYPOINT line is important because the cached base image has its own default entrypoint. This lab sets a new entrypoint so the container starts the practice script directly.
cat Dockerfile
Build the image and tag it as lfcs-container-demo:1.0. The -t option assigns a name and tag, and the final . tells Docker to use the current directory as the build context.
docker build -t lfcs-container-demo:1.0 .
Check the image after the build succeeds.
docker image ls lfcs-container-demo:1.0
Run a Named Container
In this step, you will run the image as a detached container. Detached means the container runs in the background. The container is named lfcs-demo, and a bind mount connects /home/labex/project/container-data on the host to /data inside the container.
Run the container.
docker run -d --name lfcs-demo -v /home/labex/project/container-data:/data lfcs-container-demo:1.0
Show the container ID.
docker ps -q --filter name=lfcs-demo
List running containers and find lfcs-demo.
docker ps --filter name=lfcs-demo
Inspect Logs and Execute a Command
In this step, you will inspect the running container. Logs show what the containerized process prints. A bind mount lets you verify that the container wrote data back to the host. docker exec runs a command inside the running container.
Give the container a moment to write logs.
sleep 3
Read recent container logs.
docker logs --tail 5 lfcs-demo
Check the file written through the bind mount.
tail -n 5 container-data/container-output.log
Run a command inside the container to confirm the mounted data is visible from inside.
docker exec lfcs-demo sh -c 'test -f /data/container-output.log && echo container-data-visible'
Stop and Remove the Container
In this step, you will clean up the running container. Stopping a container ends its process. Removing a stopped container deletes the container object, but it does not remove the image you built.
Stop the container.
docker stop lfcs-demo
Remove the stopped container.
docker rm lfcs-demo
Check cleanup. docker ps -a lists all containers, including stopped ones. After removal, lfcs-demo should not appear.
docker ps -a --filter name=lfcs-demo
Summary
You practiced a complete basic Docker workflow: inspect the engine, use a cached local base image, build a tagged image, run a named detached container with a bind mount, inspect logs, execute a command inside the container, and stop and remove the container. These are the core container operations to understand before deeper engine configuration or orchestration topics.
