Hands-on Lab·CompTIA Linux+
A Containerfile, an image, and what it runs as
Containers appear in 46 questions of the XK0-006 pool and Kubernetes in 4, so Domain 4's container content is images and how you run them. This guide writes a Containerfile, builds it, reads the layers it produced with their sizes, runs it twice to separate ENTRYPOINT from CMD, and generates a systemd unit for it without installing anything.
Automation and Scripting Guide 14 of 28 Intermediate
- OSUbuntu 26.04 LTS
- Kernel7.0.0-30-generic
- systemd259
- Containerspodman 5.7.0 (Ubuntu) / 5.8.2 (AlmaLinux)
- TimeAbout 24 min
- Mandatory access controlAppArmor on Ubuntu, SELinux enforcing on Alma
- Firewallufw / nftables 1.1.6 - firewalld / nftables 1.1.5
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| LPLUS-A01 | 192.168.0.73 | Ubuntu 26.04 LTS | Debian-family host - apt, ufw, netplan, AppArmor | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when packaging a script or a tool so it runs the same way everywhere. This matters because the two instructions that decide what a container runs - ENTRYPOINT and CMD - are routinely confused, and the difference decides whether an argument you pass replaces the command or is given to it.
- writing a Containerfile whose instructions each do one thing
- building it and reading
podman historyto see what every instruction cost - running the image with and without an argument, and watching the exit code change
- finding what
USERdecided, and how it maps on a rootless host - generating a systemd unit for a container rather than writing one
Before you start
- a-script-a-repo-and-a-container
-
A Containerfile, and what each instruction is for
-
Building it, and what the build produced
-
Running it, and the two ways to pass an argument
-
What the image actually is
-
A unit file for it, generated rather than written
-
Putting the machine back