这是「把自己部署到互联网上」系列的第 22 篇。
上一篇讨论了 Nginx 的部署方式：系统安装，还是放进 Docker 容器。
我的结论是:
如果只是单项目、传统部署，系统 Nginx很好；如果像我这样准备在一台服务器上跑多个 Docker 项目，并希望统一入口、减少公网端口暴露、提升迁移清晰度，容器化 Nginx更适合。
比如博客一个 Nginx，官网一个 Nginx，作品站一个 Nginx，后台服务一个 Nginx。每个项目都自带入口，看起来独立，也符合“项目自包含”的直觉。
我一开始也考虑过这个方案，之前也确实这么干过，一个应用配套一个 Nginx, 但最后没有这么做。
单看一个...
这是「把自己部署到互联网上」系列的第 21 篇。
上一篇讲了 Docker 和 Docker Compose 的分工。Docker 负责单个服务的打包、运行和隔离，Compose 负责一组服务的启动、连接和管理。到这里，我的博客部署方向已经明确：
项目尽量用 Docker 管理，多服务用 Compose 编排，数据库不直接暴露公网，外部入口集中在 80 和 443。
那么问题就来了：
这是个很好的...
这是「把自己部署到互联网上」系列的第 20 篇。
前两篇我围绕部署方案做了选择：生产环境到底该用 Conda 还是 Docker，以及为什么最终放弃 Conda 部署。到这里，方向已经确定：这台服务器后面会以 Docker 作为主要部署方式。
但在真正写 Dockerfile、compose.yml、启动容器之前，需要先把两个概念讲清楚：Docker 和 Docker Compose 到底分别解决什么问题？
很多教程会写：安装 Docker，写 Compose 文件，然后执行：
docker compose up -d
照着做可能能跑起来，但如果不理解它们的分工，后面排查问题会很困难...
这是「把自己部署到互联网上」系列的第 19 篇。
上一篇，我把 Conda 和 Docker 放在个人博客生产部署场景里做了一次对比。结论不是 Conda 不好，也不是 Docker 永远更高级，而是：如果只是本地开发、数据分析、短期实验，Conda 很舒服；但如果是长期运行、多服务组合、多项目共存，并且后续要迁移和维护的个人博客，Docker 更适合我的目标。
这一篇不再泛泛对比，而是从自己的过程出发，复盘为什么我最终放弃了 Conda 部署。
一开始，我确实想用 Conda。长期写 Python 的人，很容易把 Conda 当成自然选择。本地开发时，它管理 Python 版本和依赖很...
这是「把自己部署到互联网上」系列的第 18 篇。
前面一段时间，我花了几篇文章处理服务器安全：普通用户、root 登录、SSH、安全组、防火墙、数据库端口、扫描日志和基础安全清单。安全边界处理完后，终于要进入部署阶段。
但在真正部署博客之前，遇到了一个实际选择：生产环境到底该用 Conda 还是 Docker？
这个问题和我的项目直接相关。个人博客会涉及 Python 环境、依赖安装、数据库、服务启动、后续迁移和长期维护。如果只是本地开发，Conda 很方便；但如果要放到长期运行的云服务器上，还要考虑 Nginx、HTTPS、多项目共存、数据库和未来个人官网，选择就不只是“哪个工具熟”这...
这是「把自己部署到互联网上」系列的第 17 篇。
从第 11 篇到第 16 篇，我一直在写服务器安全。这几篇没有部署成功截图，没有博客页面上线，也没有复杂架构图，讲的都是普通用户、root 登录、SSH、安全组、防火墙、数据库端口、服务器扫描、fail2ban、日志和健康检查。
这些内容不算新颖，但写完这一段后，我更确定了一件事：对一台准备长期暴露在公网的服务器来说，部署项目之前，必须先把基础安全边界建好。
这篇是服务器安全阶段的复盘，不包含太多操作，只是把前面几篇串起来，看看我为什么从“赶紧部署博客”，变成了“先把服务器边界理清楚”。
第 10 篇之前，我主要解决的是动机问题：为...
这是「把自己部署到互联网上」系列的第 16 篇。
前几篇围绕服务器安全展开：不要急着部署项目，不要长期用 root 登录，分清安全组和防火墙，不要随便开放数据库端口，也记录了服务器4小时被扫 500 多次后的判断。到这里，需要把这些内容收束成一份清单。
这不是企业级安全方案，也不是完整加固手册。它只是我给个人服务器设定的最低安全标准：在部署博客、Nginx、Docker、数据库和 HTTPS 之前，先把基础风险过一遍。
为什么需要清单？因为感觉是个小项目，心理上容易跳过基础安全。
买完服务器想马上部署，装完 Docker 想马上跑项目，域名解析好了想马上访问页面。
...这是「把自己部署到互联网上」系列的第 15 篇。
前几篇一直在写服务器安全：不要急着部署项目，不要长期用 root 登录，分清安全组和防火墙，也不要随便开放数据库端口。这些看起来感觉有点水文章的嫌疑:dog:
直到我真的去看服务器日志，看到陌生 IP、异常请求和登录尝试，才有了更直接的感受：公网服务器不是等你部署项目的安静机器。只要它有公网 IP，就已经进入了一个会被扫描、探测和尝试访问的环境。
在看日志之前，我也有过一种侥幸：我这只是个人博客，没有访问量，也没有什么值钱业务，肯定没人专门盯上。我们平时说安全、后门等，一想到就是大公司、核心业务、支付接口和用户数据。个人项目听起...
这是「把自己部署到互联网上」系列的第 14 篇。
上一篇讲了防火墙和安全组的区别。安全组控制云平台入口流量，防火墙控制服务器系统层面的访问。理解这两层之后，端口就不能再凭感觉乱放行。
这一篇继续讲端口，重点是一个很容易踩的坑：为什么不要随便开放数据库端口？
部署个人博客时，必须要有数据库。可能是 MySQL，也可能是 PostgreSQL、Redis，或者项目自带的数据库服务。当本地工具连不上数据库时，很多人的第一反应是：是不是端口没开？于是去安全组里放行 3306、5432、6379，再改防火墙，甚至把数据库监听地址改成 0.0.0.0。工具能连上了，看起来问题解决了，但风险也被一起打...
这是「把自己部署到互联网上」系列的第 13 篇。
上一篇，我处理了服务器安全里的第一件事：不要一直用 root 登录服务器。
我创建了普通用户，给它配置 sudo 权限，并且提醒自己：在确认普通用户能正常 SSH 登录之前，不要急着禁用 root。
用户权限处理完之后，下一步就要面对另一个很容易混淆的问题：
这个问题我以前也没有真正分清楚。
很多教程会说：开放 80 端口，开放 443 端口，检查防火墙，检查安全组。
但如果第一次自己搭服务器，就很容易困惑：
安全组不是防火墙吗？
我在云平台放行了端口，为什么服务器里还要配防火墙？
我服务器防火墙放行了端口...