分类
这是「把自己部署到互联网上」系列的第 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。
那么问题就来了：
这是个很好的...
这是「把自己部署到互联网上」系列的第 22 篇。
上一篇讨论了 Nginx 的部署方式：系统安装，还是放进 Docker 容器。
我的结论是:
如果只是单项目、传统部署，系统 Nginx很好；如果像我这样准备在一台服务器上跑多个 Docker 项目，并希望统一入口、减少公网端口暴露、提升迁移清晰度，容器化 Nginx更适合。
比如博客一个 Nginx，官网一个 Nginx，作品站一个 Nginx，后台服务一个 Nginx。每个项目都自带入口，看起来独立，也符合“项目自包含”的直觉。
我一开始也考虑过这个方案，之前也确实这么干过，一个应用配套一个 Nginx, 但最后没有这么做。
单看一个...
这是「把自己部署到互联网上」系列的第 23 篇。
前两篇连续讨论了 Nginx：第 21 篇讲 Nginx 应该装在系统里，还是放进 Docker 容器；第 22 篇讲为什么我没有给每个项目都起一个 Nginx 容器。到这里，思路已经明确。
我的个人服务器后面不只跑博客，还可能跑个人官网、作品站、小工具和实验项目。如果每个项目都各自暴露端口、处理 HTTPS、维护 Nginx 配置，后面会越来越难管理。
所以我的最终方案是：全局 Nginx 统一管理多个项目的公网入口。
这篇不是最终配置文件，而是后续部署博客和官网时遵循的整体架构。下一篇再进入公共网络、配置文件和启动检查。
这是「把自己部署到互联网上」系列的第 24 篇。
上一篇我确定了 Nginx 方案：
Nginx 统一管理多个项目的公网入口Docker Compose 管理应用、数据库和数据卷这一篇开始落到操作层面。目标是先把全局 Nginx 容器跑起来，确认它具备接入多个项目的基础能力：能占用 80 和 443，配置文件在宿主机可维护，加入公共 Docker 网络，日志能查看，配置能检查，也能安全 reload。
开始前，-服务器已经...
这是「把自己部署到互联网上」系列的第 25 篇。
从第 18 篇到第 24 篇，我一直在处理一个问题：
个人博客到底应该怎么部署？
这个问题看起来只是技术选型，但会直接影响后续维护。如果部署架构一开始就很散，后面新增项目、修改配置、迁移服务器、排查故障，都会消耗大量精力。所以这一阶段我没有急着把博客跑起来，而是先把部署方式理清楚。
这几篇大致走过三步：
到现在，我的基本方案可以概括为一句话：
Docker 管项目运行，Docker ...
这是「把自己部署到互联网上」系列的第 26 篇。
上一篇复盘了部署架构：
Docker Compose 管项目内部服务Nginx 容器 管公网入口到这里，服务器安全和部署架构都有了基本方案。
但个人博客还不能算真正准备好上线，因为还差一个关键环节：HTTPS。
从技术上说，HTTP也能访问网站。
输入域名，浏览器能打开页面，文章能看，接口能请求，似乎已经够了。
问题是，如果这个网站准备长期公开访问，尤其以后还会承载博客、官网、作品站和后台管理，HTTPS 就不该被当成...
这是「把自己部署到互联网上」系列的第 27 篇。
上一篇讲了为什么个人网站需要 HTTPS。
它不仅仅只是地址栏里的小锁，还关系到访问安全、浏览器提示、后台登录、现代 Web 能力、搜索和分享体验。
对一个准备长期运行的博客来说，网站不能只做到“能访问”，还要能通过可信连接访问。
这一篇进入实际操作：SSL 证书怎么申请、下载，并部署到 Nginx。
我这里会以阿里云为例(域名在阿里买的)，在哪个平台购买不重要，不同平台页面布局多少会有一些差异。
更重要的是理解流程：申请证书，完成域名验证，下载证书，放到服务器，配置 Nginx，检查配置，重载服务，最后验证 HTTPS 是否正...