What Is a Docker Image?
Before node server.js can run on another machine, where do the files it expects come from?
Starting that process does not create them. Typing the command does not put Node on disk. It does not create server.js. It does not install the dependencies that file imports, or the libraries underneath. For node server.js to work, those pieces already have to be present in the filesystem the process can see.
That matters once isolation enters the picture. Namespaces can change what filesystem a process sees. They do not populate that filesystem.
The obvious answer is: prepare the machine yourself.
Install Node. Copy the application files over. Install the dependencies. Put the rest of the filesystem environment in place so node server.js can start. That works. Engineers have been doing versions of this for a long time.
The trouble shows up when you need the same environment on another machine. Now you have to prepare that machine too. Install the right version of Node. Copy the same application files. Install the same dependencies.
And then another machine needs it. You prepare that one too.
Manual setup works. The problem is having to recreate the same filesystem environment reliably every time.
What if we prepared that filesystem environment once?
Not “set up this machine,” then set up the next one the same way. Prepare the files once, package them as an artifact, and take that prepared artifact to another machine instead of reconstructing the environment by hand every time.
What goes in that package is the filesystem content we deliberately include for the application. Node. The application files. Dependencies. Libraries. The pieces we chose to put there so node server.js has something real to see when it starts.
That artifact is called an image.
An image is not a running process. It does not become the container. It is the prepared filesystem environment used when creating the container. When the container starts, the application process runs with that filesystem environment available to it, and with boundaries around it.
The image stays an artifact. The process is what runs.
So instead of rebuilding the application's filesystem environment by hand on every machine, we can reuse a prepared artifact that provides that starting filesystem environment.
Which leaves a practical question. If an image is that prepared filesystem package, how do we create it in a reliable way?