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