这是「把自己部署到互联网上」系列的第 25 篇。

从第 18 篇到第 24 篇，我一直在处理一个问题：

个人博客到底应该怎么部署？

这个问题看起来只是技术选型，但会直接影响后续维护。如果部署架构一开始就很散，后面新增项目、修改配置、迁移服务器、排查故障，都会消耗大量精力。所以这一阶段我没有急着把博客跑起来，而是先把部署方式理清楚。

这几篇大致走过三步：

• 先在 Conda 和 Docker 之间做选择
• 再复盘为什么放弃 Conda 部署，转向 Docker
• 最后确定用全局 Nginx 统一管理多个项目入口

到现在，我的基本方案可以概括为一句话：

Docker 管项目运行，Docker ...

这是「把自己部署到互联网上」系列的第 21 篇。

上一篇讲了 Docker 和 Docker Compose 的分工。Docker 负责单个服务的打包、运行和隔离，Compose 负责一组服务的启动、连接和管理。到这里，我的博客部署方向已经明确：

项目尽量用 Docker 管理，多服务用 Compose 编排，数据库不直接暴露公网，外部入口集中在 80 和 443。

那么问题就来了：

• Nginx 到底装在系统里，还是放进 Docker 容器？
• 如果每一个项目都起一个NGINX 容器，起多了对服务器有什么影响?

Nginx 到底装在系统里，还是放进 Docker 容器

这是个很好的...

这是「把自己部署到互联网上」系列的第 20 篇。

前两篇我围绕部署方案做了选择：生产环境到底该用 Conda 还是 Docker，以及为什么最终放弃 Conda 部署。到这里，方向已经确定：这台服务器后面会以 Docker 作为主要部署方式。

但在真正写 Dockerfile、compose.yml、启动容器之前，需要先把两个概念讲清楚：Docker 和 Docker Compose 到底分别解决什么问题？

很多教程会写：安装 Docker，写 Compose 文件，然后执行：

docker compose up -d

照着做可能能跑起来，但如果不理解它们的分工，后面排查问题会很困难...

这是「把自己部署到互联网上」系列的第 18 篇。

前面一段时间，我花了几篇文章处理服务器安全：普通用户、root 登录、SSH、安全组、防火墙、数据库端口、扫描日志和基础安全清单。安全边界处理完后，终于要进入部署阶段。

但在真正部署博客之前，遇到了一个实际选择：生产环境到底该用 Conda 还是 Docker？

这个问题和我的项目直接相关。个人博客会涉及 Python 环境、依赖安装、数据库、服务启动、后续迁移和长期维护。如果只是本地开发，Conda 很方便；但如果要放到长期运行的云服务器上，还要考虑 Nginx、HTTPS、多项目共存、数据库和未来个人官网，选择就不只是“哪个工具熟”这...