The Blueprint Document

Look, if you've ever dealt with this in production, you know exactly what the problem is. So far, you have only used pre-built Images from Docker Hub. But what happens when you write your own custom Node.js application? How do you package it into a Docker Image? You write a 'Dockerfile'. A Dockerfile is a simple, plain-text script that contains a sequential list of instructions. The Docker Engine reads this file from top to bottom, executing each command step-by-step to physically construct your immutable Image. This isn't just academic theory—understanding the *why* behind this is what separates junior devs from senior engineers. When you deploy to a cluster, this is the mechanic that prevents catastrophic failure.

Look, if you've ever dealt with this in production, you know exactly what the problem is. Every single Dockerfile in the world MUST begin with the FROM instruction. Why? Because you rarely build an operating system from scratch. FROM defines the 'Base Image' you are starting with. If you type FROM node:18, you are telling Docker: 'Go to Docker Hub, download the official Node v18 image (which already includes Linux and Node.js), and use that as the foundation for my new custom image.' This isn't just academic theory—understanding the *why* behind this is what separates junior devs from senior engineers. When you deploy to a cluster, this is the mechanic that prevents catastrophic failure.

Look, if you've ever dealt with this in production, you know exactly what the problem is. The Base Image doesn't have your code yet. You must move your source code from your laptop into the Image. First, use WORKDIR /app to create a dedicated directory inside the container and CD into it. Then, use the COPY instruction. The syntax is COPY <host-path> <container-path>. So, COPY . . means: 'Copy everything in my current laptop directory into the current container directory (/app).' This isn't just academic theory—understanding the *why* behind this is what separates junior devs from senior engineers. When you deploy to a cluster, this is the mechanic that prevents catastrophic failure.

The Blueprint Document. So far, you have only used pre-built Images from Docker Hub. But what happens when you write your own custom Node.js application? How do you package it into a Docker Image? You write a 'Dockerfile'. A Dockerfile is a simple, plain-text script that contains a sequential list of instructions. The Docker Engine reads this file from top to bottom, executing each command step-by-step to physically construct your immutable Image.

FROM: The Foundation. Every single Dockerfile in the world MUST begin with the FROM instruction. Why? Because you rarely build an operating system from scratch. FROM defines the 'Base Image' you are starting with. If you type FROM node:18, you are telling Docker: 'Go to Docker Hub, download the official Node v18 image (which already includes Linux and Node.js), and use that as the foundation for my new custom image.'

Why must every Dockerfile begin with a FROM instruction?

• →Because it specifies the 'Base Image' (like a pre-configured Linux OS with Node installed) that your custom code will be built on top of.
• →Because it authenticates you to Docker Hub.

COPY & WORKDIR. The Base Image doesn't have your code yet. You must move your source code from your laptop into the Image. First, use WORKDIR /app to create a dedicated directory inside the container and CD into it. Then, use the COPY instruction. The syntax is COPY <host-path> <container-path>. So, COPY . . means: 'Copy everything in my current laptop directory into the current container directory (/app).'

RUN: Executing Commands. Your code is copied over, but it probably needs dependencies. In a Node.js project, you need to run npm install. The RUN instruction allows you to execute any standard terminal command *during the image building process*. If you write RUN npm install, Docker will execute that command inside the Image, download the packages, and permanently save the resulting node_modules folder directly into the Image.

CMD: The Default Action. The Image is fully built. It has an OS, the source code, and dependencies. But what should it actually *do* when someone runs it? The CMD instruction defines the default command that executes when the Container starts. Unlike RUN (which happens during build time), CMD happens at runtime. If you write CMD ["node", "server.js"], you are telling Docker: 'When someone spins up a container from this image, start the server.'

What is the critical difference between the RUN instruction and the CMD instruction in a Dockerfile?

• →RUN executes commands during the Image creation (Build Time). CMD defines the default command that executes when the Container actually starts (Runtime).
• →RUN is for Linux servers. CMD is for Windows servers.

Syntax Mastered. You have decoded the syntax of the Dockerfile. You understand how FROM provides the foundation, WORKDIR and COPY handle the file system, RUN executes build-time configuration, and CMD dictates runtime behavior. However, simply writing these instructions in order is not enough. In the next lesson, we will uncover how Docker builds Images using 'Layers', and why the order of these instructions drastically affects performance.