Here are the 5 core concepts from the Day 4 video, fully formatted for your Obsidian setup with standard callouts, frontmatter, and Zettelkasten brackets!
---
tags: [docker, containers, devops, cka, dockerfile, cmd-vs-entrypoint]
aliases: [Day 4 Docker, CMD vs ENTRYPOINT]
---
# 🐳 Day 4: CMD vs ENTRYPOINT, Docker Commands & Custom Dockerfile
> [!summary] Video Overview
>
> This note extracts the 5 key concepts from the Day 4 CKA tutorial on Docker. It covers how to use custom `[[Dockerfile]]` names, understanding the `[[Build Context]]`, the classic interview question of **CMD vs. ENTRYPOINT**, how to combine them, and essential bulk cleanup commands.
>
> 🔗 **Source Video:** [Day 4: CMD vs ENTRYPOINT, Docker Commands & Custom Dockerfile | CKA Certification Course 2025](https://www.youtube.com/watch?v=34l1gRszQS4)
---
## 🏗️ Concept 1: Custom Dockerfile Names (`-f` flag)
You aren't forced to name your file exactly `Dockerfile`. You can have multiple files for different environments (e.g., `Dockerfile.dev`, `Dockerfile.prod`) [00:01:58].
To build an image using a custom-named file, use the `-f` (file) flag to explicitly tell the Docker daemon where to look [00:03:51].
> [!example] Command Example
>
> `docker build -f Dockerfile.dev -t my-app:dev .`
---
## 📦 Concept 2: The Build Context (The `.` in Docker Build)
When you run `docker build -t image_name .`, the `.` at the end doesn't just mean "look in this directory." It specifies the **[[Build Context]]** [00:04:42].
- **What it is:** The build context is everything (files, folders) sent to the Docker Daemon to build the image.
- **Best Practice:** Keep the build context as small as possible. *Do not* run builds in directories with large, unnecessary files (like random `.md` files or giant `.git` folders), because Docker copies *everything* in that folder before building [00:05:37].
---
## ⚔️ Concept 3: CMD vs. ENTRYPOINT
This is a classic Docker interview question. While both run commands when a container starts, their behavior differs when you pass arguments during `docker run` [00:14:40]:
- **[[CMD]] (Default & Replaceable):** Provides a *default* command. If you run `docker run image_name <new_command>`, the new command **completely overrides** the CMD instruction [00:08:15].
- **[[ENTRYPOINT]] (Strict & Appends):** Defines the primary executable. If you pass arguments at runtime, they do NOT override the Entrypoint; they **append** to it [00:11:20]. *(To force an override of an Entrypoint, you must use the `--entrypoint` flag)*.
---
## 🤝 Concept 4: Combining CMD and ENTRYPOINT
The most robust way to write a Dockerfile is to use *both* instructions together.
By combining them, you make `ENTRYPOINT` the strict executable, and `CMD` the default (but easily changeable) arguments [00:16:39].
> [!example] Example Configuration
>
> ```dockerfile
> ENTRYPOINT ["ping", "-c", "4"]
> CMD ["google.com"]
> ```
> - **Result:** If you run `docker run my-image`, it pings `google.com`.
> - If you run `docker run my-image amazon.com`, it easily overrides the CMD and pings `amazon.com` instead [00:18:05].
---
## 🧹 Concept 5: Bulk Deletion & Pruning
Over time, stopped containers and dangling images eat up host storage. You can quickly clean them up using these operational commands [00:24:30]:
- **`docker container prune`**: Safely deletes *all* stopped containers at once (prompts for confirmation) [00:24:44].
- **`docker rm -f $(docker ps -aq)`**: A powerful bash combo to **force delete** every single container on the system, running or stopped (`-q` returns just the IDs) [00:25:49].
- **`docker rmi -f $(docker images -q)`**: Force deletes all local images [00:26:46].
> [!warning] Danger Zone
>
> Be extremely careful with the `-f $(docker ps -aq)` commands in production, as they will indiscriminately wipe all workloads on the host!