跪拜 Guibai
← Back to the summary

Docker Isn't a Lightweight VM — It's a Shipping Container for Your Entire Runtime

1. What problem does Docker solve?

During software development, you often encounter this problem:

"It runs on my machine, why doesn't it run on yours?"

Take a Vue2 project for example:

Your machine:

Node.js 14
npm 6
Vue2
webpack 4

The project runs fine:

npm run dev

Open:

localhost:8080

You can see the page.

But after a colleague pulls the code and runs:

npm install
npm run dev

It throws errors:

Node version mismatch
webpack dependency error
npm install failed

Why?

Because even though the code is the same, the environment running the code is different.

2. An application is more than just code

Many beginners think:

Project = Source code

For example:

my-project

├── src
├── package.json
└── README.md

In reality, getting a project to actually run requires many additional conditions:

Application

+
Runtime environment

+
Dependencies

+
Configuration

For example, a Node project:

Node project

├── Source code
│
├── Node.js
│
├── npm
│
├── Third-party dependencies
│
└── Environment variables

Code is only one part.

If the runtime environment is missing, the code cannot work.

3. Problems with traditional solutions

In the past, deploying a project usually required manually configuring the server.

For example:

Developer:

Machine A

Node 14
Redis
MySQL
npm

Test server:

Server B

Node 16
Different Redis version
Different MySQL configuration

Production server:

Server C

Node 18
Different OS
Different dependencies

Every time you switch machines, you need to reconfigure the environment.

So a question arises:

Can we package everything the program needs to run together?

This is the problem Docker aims to solve.

4. Docker's core idea

Docker's core philosophy:

Package the application and the environment it needs to run together.

In other words:

Before:

Server

├── Node
├── npm
├── Project code
└── Configuration

Now:

Docker

┌─────────────────┐
│  Application     │
│                 │
│  Node environment│
│                 │
│  npm dependencies│
│                 │
│  Configuration   │
└─────────────────┘

This whole unit is a Docker Image.

5. What is an Image?

An Image can be understood as:

A template for an application's runtime environment.

For example:

A Docker Image for a Node project:

node-app-image

Contains:

├── Node.js
├── npm
├── Project code
├── node_modules
└── Configuration files

This Image can be copied.

For instance:

Development environment:

node-app-image

Test server:

node-app-image

Production server:

node-app-image

Everyone runs the same environment.

Therefore:

Development environment = Test environment = Production environment

This eliminates a huge number of environment-related problems.

6. What is a Container?

An Image is a template.

But a template cannot run directly.

It's like:

Program installer

Cannot be used directly

Needs to be installed before running

In Docker:

Image

↓

Create

↓

Container

A Container is the actually running application instance.

For example:

A Node Image:

node-image

Start it:

docker run node-image

Docker creates:

Container

Running inside:

Node service

This Container is the program that is actually working.

The relationship between Image and Container

A simple way to understand it:

Image

Similar to:

Class

Template


Container

Similar to:

Object

Running instance

One Image can create multiple Containers.

For example:

Node Image


        ↓

 ┌────────────┐
 │ Container1 │
 └────────────┘


        ↓

 ┌────────────┐
 │ Container2 │
 └────────────┘

The same application can start multiple instances.

7. What is the difference between Docker and a virtual machine?

Many people encountering Docker for the first time think:

Isn't Docker just a lightweight virtual machine?

The two are indeed similar:

Both provide isolated runtime environments.

But the implementation is different.

Virtual Machine

A virtual machine simulates a complete computer:

Server

└── Virtual Machine

    ├── Operating System
    │
    ├── System libraries
    │
    └── Application

For example:

The server is Linux.

Inside the virtual machine, you install:

Windows

Then run the program.

Disadvantages:

Docker

Docker does not need a complete operating system.

It shares the host kernel:

Server

├── Docker

│
├── Container A
│   └── Node application
│
├── Container B
│   └── MySQL
│
└── Container C
    └── Redis

Advantages:

8. Docker's place in a real project

A modern web project is usually not a single program.

For example:

An e-commerce site:

User

↓

Frontend

React/Vue

↓

Backend

Node/Java

↓

Database

MySQL

↓

Cache

Redis

These services might run in different environments.

Docker can manage them separately:

Docker

├── React Container

├── Node Container

├── MySQL Container

└── Redis Container

Each service has its own runtime environment.

9. A simple example: Dockerizing a Vue2 project

Suppose your Vue2 project:

vue-project

├── src
├── package.json
└── webpack.config.js

Previously, to run it:

npm install

npm run dev

Dependencies:

Node
npm
webpack
Vue

After Docker:

Create an Image:

vue-image

Contains:

Node
npm
Vue dependencies
Project code

Run:

docker run vue-image

You get:

vue-container

Running inside:

npm run dev

Result:

No matter which computer:

As long as Docker is installed:

docker run vue-image

The project can run.

10. Dockerfile: Telling Docker how to create the environment

How does Docker know:

The answer is:

Dockerfile.

For example:

FROM node:14

WORKDIR /app

COPY . .

RUN npm install

CMD ["npm","run","dev"]

Meaning:

Select the Node environment:

FROM node:14

Enter the working directory:

WORKDIR /app

Copy the project:

COPY . .

Install dependencies:

RUN npm install

Start the project:

CMD ["npm","run","dev"]

Docker creates the Image based on this file.

Process:

Dockerfile

↓

docker build

↓

Image

↓

docker run

↓

Container

11. The three most core concepts of Docker

To learn Docker, you only need to grasp three things first:

Image

Image.

Responsible for:

Describing the application's runtime environment.

Container

Container.

Responsible for:

Actually running the application.

Dockerfile

Build rules.

Responsible for:

Telling Docker how to create the Image.

Relationship:

Dockerfile

      ↓

    Image

      ↓

  Container

12. Summary

The core problem Docker solves:

Delivering the application together with its runtime environment.

Before:

Code

+

Manual environment configuration

Easily leads to:

It runs on your machine

It doesn't run on my machine

Docker:

Application

+

Runtime environment

+

Dependencies

↓

Image

↓

Container

Gives the application a consistent runtime environment.

The next article will enter the actual deployment process:

"Deploying Web Services with Docker: From Node to Nginx Reverse Proxy"

Key points to understand: