为什么用 Docker
个人网站从静态页到动态博客，部署方式一直在变。早期我在服务器上装 Nginx、PHP、MySQL，每换一次环境就要重新折腾一遍依赖。后来改用 Docker，最大的感受是“搬家的成本变低了”：本地跑起来是什么样，服务器上大概率就是什么样。你不用再担心系统版本不一致、软件库冲突这些事。
如果你只是放一个静态页面，其实没必要用 Docker。但当你开始加评论、统计、搜索，或者想在同一台服务器上同时跑多个站点，Docker 的隔离和复用价值就体现出来了。
写一个最小的 Dockerfile
以常见的个人博客为例，假设你的站点是基于 Nginx 的静态站。项目根目录里只需要一个文件：
“`dockerfile
FROM nginx:alpine
COPY ./public /usr/share/nginx/html
“`
`public` 是打包后的静态文件目录。如果你用的是 Hugo 或 VuePress，构建之前先跑各自的生成命令，把输出目录指向 `public`。之后构建镜像：
“`bash
docker build -t my-blog .
“`
这条命令会把当前目录下的 `public` 内容打包进镜像。启动容器：
“`bash
docker run -d -p 8080:80 –name my-blog-container my-blog
“`
此时在浏览器访问 `http://服务器IP:8080`，就能看到你的网站了。`-d` 表示后台运行，`-p` 把容器内的 80 端口映射到服务器的 8080。
第一次成功跑起来后，你可以试着把端口改成 80（如果没被占用），或者用 `-v` 挂载本地目录，实现本地改代码、容器即时生效。这对开发调试很有用。
用 Docker Compose 管理依赖
如果你的网站有后端，比如用 Node.js 写的 API，再加一个数据库，单个容器就不够用了。建议改用 Docker Compose。在项目根目录创建一个 `docker-compose.yml`：
“`yaml
services:
web:
build: .
ports:
- "8080:80"
depends_on:
- api
api:
build: ./api
environment:
- DB_HOST=db
db:
image: postgres:16-alpine
volumes:
- db_data:/var/lib/postgresql/data
“`
`depends_on` 会保证 api 在 db 之后启动，但不保证 api 启动完了 db 一定可用，所以程序里还是要写重试逻辑。数据通过卷保存在宿主机上，容器删了也不会丢。
用 Compose 启动所有服务：
“`bash
docker compose up -d
“`
之后无论是换服务器还是部署到另一台机器，只要把项目代码和 `docker-compose.yml` 拿过去，执行同样的命令就行。这种“声明式”的感觉，比手工配环境踏实很多。
更新与回滚
网站上线后，更新是常态。Docker 的流程很简单：
“`bash
docker compose build
docker compose up -d
“`
如果升级后发现有问题，想回滚到上一个版本，最稳妥的做法是在每次构建镜像时打上标签，比如 `my-blog:v1.0.1`。然后把 `docker-compose.yml` 里的镜像名改成上一个标签，重新启动即可。不要每次都用 `latest`，否则回滚的时候你记不清“上一个”到底是哪个。
如果服务器上存了很多旧镜像，记得定期清理：
“`bash
docker image prune -a
“`
它会删掉没有被容器使用的镜像，释放磁盘空间。
自动部署的小建议
手动敲命令虽然不麻烦，但做多了还是容易出错。我后来加了最简单的自动化：用 Git 的 post-receive 钩子，在服务器端收到推送后自动拉取代码并执行 `docker compose up -d –build`。这属于最原始但很有效的做法。
更复杂的 CI/CD（比如 GitHub Actions）当然也能用，但对个人网站来说，一套钩子或一个定时任务完全够用。关键是不要让“自动化”本身变成负担。先手动部署跑通，再考虑自动化的边界。
最后一点经验
我用 Docker 部署个人网站之后，最明显的变化不是速度，而是心态。以前为了一个 Nginx 配置查半天，现在出了问题，直接删掉容器重新起一个，几分钟就能恢复。这种“基础设施可丢弃”的思路，放到个人项目上特别管用。网站内容才是核心，部署方式应该尽量退到后台，让你感觉不到它的存在。