第1章 开源项目部署基础认知与前置准备
1.1 开源项目部署的常见场景与模式选型
我自己第一次接触开源项目部署，是给自己搭一个图床。那会儿想得特别简单，装个软件、跑起来、能用就行。真上手了才发现，同一个项目在不同场景下部署方式差得远。个人自用，扔在一台最低配的云服务器上、单机跑一个进程就够了。公司内部使用的工具，要考虑多人访问、权限划分、数据备份。对外提供服务的电商或者SaaS类项目，流量、可用性、安全这些都得提前想清楚。场景决定了后面所有的技术选择，这一点我踩过不少坑才明白。
模式选型上，我大致分成几种路子。单机部署适合验证和小规模使用，成本低，维护简单，缺点是扛不住流量也扛不住故障。主从或者多节点部署能解决可用性问题，代价是复杂度上来了，你得处理数据同步、会话共享、负载均衡。还有一种是我最近比较偏爱的托管式思路，把数据库、对象存储、缓存这些交给云服务商，自己只管应用层。这种模式适合小团队，人手有限的时候能把精力放在业务上。
我一般会问自己几个问题再决定模式。这个项目是给谁用的、预计多少人访问、数据丢了能不能接受、预算大概多少。答案清楚之后，选型基本就定了。别一上来就追求高可用架构，很多项目根本用不上，白花钱还增加维护负担。我自己就干过这种事，给一个日活几十的内部工具上了集群，后来运维起来头都大了。
1.2 项目评估：许可证、依赖、资源与社区活跃度
选项目这件事，我现在的习惯是先翻许可证。MIT、Apache 2.0 这类比较宽松，商用、修改、二次分发都相对自由。GPL 系列要注意，如果你的项目要闭源分发，可能会被传染。我见过有人把 GPL 项目直接嵌进商业产品里，后来被要求开源，整个团队焦头烂额。许可证不是技术问题，是法律和商业问题，值得花半小时认真读一遍。
依赖情况也得看。一个项目如果依赖了几十个陈年老包，里面还夹着好几个已经不维护的库，部署的时候编译报错能让你怀疑人生。我的做法是看它的 lock 文件、看依赖更新的频率，顺便在 issues 里搜一下安装失败相关的帖子。资源消耗同样重要，官方文档里一般会写最低配置，我通常会在这个基础上再留出一倍余量，尤其是内存，开源项目跑着跑着内存涨上去是常有的事。
社区活跃度这块，我主要看三样东西。最近三个月的提交频率、issue 的响应速度、还有文档的完整程度。一个半年没更新、issue 里全是“同问”没人回的项目，用起来风险很大。文档写得好不好也很能说明问题，愿意认真写文档的维护者，通常对项目也更上心。我吃过文档残缺的亏，一个部署参数找了半天，最后在某个 issue 的评论里才看到答案。
1.3 服务器、域名、网络与安全组基础配置
服务器我一般从云厂商的轻量应用服务器起步，配置按项目来。个人项目 2 核 2G 够用，稍微正经一点的应用我会上 2 核 4G 或者 4 核 8G。系统镜像我偏爱 Ubuntu LTS 或者 Debian，社区资料多，遇到问题好搜。买机器的时候注意地域，国内业务选国内节点，需要备案的记得提前走流程，别等部署完了才发现域名解析不了。
域名这块，注册完先做实名认证，国内节点还要备案。解析记录我习惯先加一条 A 记录指向服务器公网 IP，等测试通了再考虑加 CDN 或者负载均衡。DNS 生效有时候要等几分钟到几十分钟，别急着反复改。我见过有人解析没生效就以为配错了，来回折腾半天。
网络和安全组是最容易被忽略的部分。云厂商默认的安全组策略一般只开少数端口，我自己部署时至少会放行 22、80、443。22 端口我强烈建议改掉默认端口，再配上密钥登录，密码登录直接关掉。80 和 443 按需开放。数据库端口千万不要对公网开放，这是血泪教训，我有个朋友的测试库就是这么被挖矿程序盯上的。内网能通的走内网，安全组规则能收紧就收紧。
1.4 部署方案对比：源码部署、包管理部署与容器化部署
源码部署是我最早用的方式，clone 下来、装依赖、编译、启动。好处是透明，每一层你都能看到，出了问题也容易定位。坏处是环境差异太折磨人，本地能跑服务器上跑不起来，十个里有八个是依赖版本或者系统库的问题。我现在只在需要深度定制、或者项目没有现成镜像的时候才走这条路。
包管理部署适合那些进了 apt、yum 或者 npm 仓库的项目。一条命令装完，升级也方便。缺点是版本往往滞后，你想要新特性可能得等。另外包管理器装的东西散落在系统各个目录里，卸载的时候不一定干净，多版本共存也麻烦。我一般用它来装一些基础组件，应用本身还是倾向于更可控的方式。
容器化部署这几年成了我的默认选择。Docker 把运行环境和依赖打包在一起，本地跑通基本就等于服务器上跑通，环境一致性这块省了太多事。镜像版本可以固定，回滚也简单，换个 tag 重启就行。学习曲线确实有，网络、存储、编排这些概念得花时间消化。对于刚起步的项目，我建议先源码部署跑通一遍，理解项目结构之后再上容器，这样出问题不至于两眼一抹黑。
第2章 开源项目部署教程：从源码到上线
2.1 获取源码与版本选择策略
我拿到一个开源项目，第一件事不是急着 clone 到服务器上，而是先在本机把代码拉下来看一眼。GitHub 上点 Code 按钮，复制那个 https 地址，或者用 SSH 方式都行。我一般会 fork 一份到自己账号下面，这样后面做个性化改动或者提 PR 都方便。clone 的时候顺手看看仓库的 release 页面，有没有打包好的压缩包，有些项目 release 里附了编译好的产物，省得自己折腾构建。
版本选择上我吃过贪新的亏。之前有个项目 master 分支天天更新，我直接拉最新代码部署，结果第二天起来服务挂了，查了半天是上游一个没测试充分的提交。现在我默认选最新的 release tag，stable 版本经过维护者测试，踩坑概率低很多。如果 release 更新太慢、你又需要某个修复，再考虑切到某个具体的 commit。生产环境我从来不直接用 master，这是底线。
分支和 tag 的管理也值得说一下。clone 下来之后我会 git checkout 到选定的 tag 上，别停在默认分支。有些项目主分支和 release 分支差别很大，构建脚本、配置模板都可能不一样。我习惯在服务器上建一个 /opt/项目名 目录专门放代码，后续升级直接 git fetch 加切换 tag，比重新下载压缩包干净。代码目录的权限也注意一下，别用 root 直接跑，后面会专门说运行用户的事。
2.2 运行环境与依赖安装配置
依赖安装是最容易出问题的环节，我踩的坑一半以上都在这里。动手之前先看项目根目录有没有 .nvmrc、.python-version、go.mod、composer.json 这类文件，它们直接告诉你项目要什么版本的运行时。Node.js 项目我一般用 nvm 装对应版本，Python 用 pyenv 或者系统的 venv，别用系统自带的旧版本硬跑，版本不对报错信息能把你带偏。
系统层面缺的库也得提前补齐。编译类的依赖比如 gcc、make、python3-dev、libssl-dev 这些，Ubuntu 和 Debian 上一行 apt 就能装。我习惯先把项目 README 里的 Prerequisites 部分读一遍，按它列的清单打勾。有些项目文档写得简略，编译报错说找不到某个头文件，你就去搜那个头文件属于哪个包，apt-file search 这个命令挺管用。真的，别硬猜。
包管理器这块我有个小习惯，能用 lock 文件就用 lock 文件。npm 用 npm ci 而不是 npm install，pip 用 pip install -r requirements.txt 并且尽量固定版本，PHP 的 composer 也用 lock。lock 文件保证了依赖树跟作者测试时一致，少了很多“我这里能跑你那里不能跑”的扯皮。装依赖的时候网络慢可以换国内镜像源，npm、pip、composer 都支持，配置一下能省不少等待时间。
2.3 配置文件、数据库与第三方服务接入
开源项目一般都会提供一个 .env.example 或者 config.example.yml，复制一份改名成正式配置，这一步别跳过。配置里的数据库连接、缓存地址、密钥这些，按你的实际环境填。密钥类的东西我强烈建议用随机生成的长字符串，别图省事写个 123456，后面被扫到哭都来不及。生成命令随手就有，openssl rand -hex 32 敲一下的事。
数据库接入分两种情况。项目自带 SQLite 的，基本零配置，适合小规模和个人项目。用 MySQL 或者 PostgreSQL 的，先在服务器上把数据库服务装好，建库建用户，把连接信息填进配置文件。建库的时候字符集记得选 utf8mb4，不然 emoji 存进去会出乱码。数据库用户权限给到具体那个库就行，别直接上 root，最小权限原则能挡掉不少意外。
第三方服务接入这块看项目支持哪些。邮件发送要配 SMTP，对象存储要填 AccessKey 和 Bucket，支付、短信、地图这些也都有对应的配置项。我的做法是先只配核心功能必需的，把服务跑起来，其余的一个个加、一个个测。有一次我把所有第三方配置一股脑填完再启动，结果一个短信服务商密钥填错，整个启动流程卡住，排查了半天才定位到是哪个配置的问题。配置项多的时候，改一项重启一次验证一次，看着笨，实际最快。
2.4 构建、启动、反向代理与HTTPS配置
构建这步因项目而异。前端项目一般 npm run build 出静态文件，后端 Java 的 mvn package 打个 jar，Go 的 go build 出一个二进制，PHP 和 Python 很多项目不需要构建直接跑。构建的时候留意输出目录，产物一般在 dist、build、target 这类文件夹里，后面反向代理要指过去。构建失败先看报错最后几行，环境问题居多，内存不够也是常见原因，小机器上编译大项目记得加 swap。
启动方式我推荐用 systemd 托管，别直接在终端里 npm start 然后关掉 SSH 就断。写一个 service 文件，指定运行用户、工作目录、启动命令和环境变量文件，systemctl enable 加 start 就完事。日志走 journald 或者重定向到文件，方便后面排查。项目官方如果提供了 Docker 方式，那是另一条路，第 3 章会细讲。源码部署这条线上，systemd 是我用得最顺手的进程管理方案。
反向代理我这几年基本只用 Nginx。配置文件里一个 server 块，proxy_pass 指到本地应用端口，静态资源让 Nginx 直接 serve，动态请求转发给后端。WebSocket 的项目记得加 Upgrade 和 Connection 头。HTTPS 用 Let's Encrypt 的 certbot，一条命令签发证书，再配个自动续期。我习惯把 80 端口的请求全部 301 到 443，安全组里 80 和 443 都开着，但应用只监听 127.0.0.1，外面碰不到。这样结构清晰，后面加域名、加缓存都好弄。
2.5 部署验证与常见问题排查
部署完别急着交付，先自己从头到尾走一遍。浏览器打开域名看首页能不能正常加载，登录、注册、核心业务操作都点一遍。接口层面可以用 curl 测一下健康检查端点，很多项目带 /health 或者 /api/status 之类的路径。数据库连接、缓存读写、邮件发送这些依赖项也要单独验证，别等用户反馈了才发现某个功能是坏的。我有个清单，每次部署按着过一遍，花不了十分钟，省心很多。
常见问题我归类了一下。502 一般是后端没起来或者端口不对，先 systemctl status 看进程状态，再看应用日志。504 是超时，可能是后端处理慢或者 Nginx 的 timeout 设太短。静态资源 404 多半是 Nginx 的 root 路径配错了，或者构建产物目录不对。白屏但接口正常，八成是前端路由或者资源路径的问题，打开浏览器控制台看报错最直接。这些问题看着多，处理几次就有肌肉记忆了。
日志是我排查问题的主要抓手。应用日志、Nginx 的 access 和 error 日志、系统日志，三个地方对着看。我习惯部署完先 tail -f 盯着日志，一边操作一边观察有没有异常输出。频率高的错误比如权限不足、文件找不到、连接被拒，日志里都会写得很清楚。遇到实在摸不着头脑的问题，把关键错误信息拿去搜，GitHub issues 里大概率有人遇到过。部署这件事，经验都是踩坑踩出来的，多部署几次就顺了。
第3章 开源项目Docker部署实战
3.1 Docker部署优势与适用边界
说实话，我刚开始接触Docker那会儿是有点抵触的。源码部署我能控制每一个细节，出了问题也知道去哪儿翻日志。后来项目越接越多，每换一台服务器就要重新装一遍运行时、配一遍依赖，烦得不行。有次帮朋友部署一个Python项目，他服务器是CentOS 7，系统自带的Python版本太老，我硬是折腾了一下午才把环境凑齐。那次之后我就开始认真用Docker了，一个镜像打出来，换到哪台机器上跑起来都一样，这种一致性是我最看重的东西。
Docker最大的好处在我看来就三条：环境隔离、部署可重复、资源占用比虚拟机小。同一台服务器上跑三四个不同项目，各自依赖不同版本的Node、Python、PHP，互不干扰。部署的时候一条docker run或者docker compose up -d就起来了。但我也得说清楚边界在哪。Docker不是银弹，小项目、单体应用、对性能极其敏感的场景，源码部署或者直接跑二进制可能更合适。我之前给一个客户部署轻量级Wiki，就一个进程，直接用systemd托管，简单直接，上Docker反而多了一层管理成本。
还有个常见误区是把Docker当虚拟机用。容器里跑systemd、塞一堆服务、把容器当服务器养，这路子不对。容器的设计哲学是一个容器一个进程，无状态、可替换。我在项目里遵循的原则是：数据部分用卷分离出去，容器本身随时可以删掉重建。这样升级、回滚都特别干脆，docker rm再docker run就行了。你要是把数据写在容器内部，重建的时候哭都来不及，这个后面讲数据卷的时候还会细说。
另外说一下适用边界。需要直接访问硬件、对内核参数有特殊要求、或者有GPU直通需求的项目，Docker能跑但配置起来比较绕。我去年部署过一个视频转码项目，需要调用GPU，从装nvidia-docker到调试驱动兼容性，花的时间比部署项目本身还多。这种场景你得权衡，是能用就行还是非得容器化。我的建议是先用源码部署把项目跑通，确认业务逻辑没问题了，再考虑用Docker重新打包，别一上来就从头Docker化，容易卡在环境问题上怀疑人生。
3.2 Dockerfile编写与镜像构建优化
写Dockerfile这件事，我一开始是照着网上的模板抄的，后来被镜像体积吓到了。一个简单的Node项目，镜像打出来1.2个G，拉取的时候慢得要命。后来我学了多阶段构建，把构建阶段和运行阶段分开，最终镜像降到一百多兆，部署速度直接上了一个台阶。多阶段构建的思路很简单：第一阶段装依赖、编译、打包，第二阶段只拷贝产物和运行必需的东西，编译工具链统统不要。
基础镜像的选择也有讲究。很多人习惯用ubuntu或者centos做底，实际上大部分项目用alpine或者官方提供的slim版本就够了。alpine体积小，几十兆，但要注意它用的是musl libc，有些依赖glibc的二进制包跑不起来。我遇到过Python的某个C扩展在alpine上编译失败，换成python:3.11-slim就好了。选镜像这事别追求极致小，够用、稳定排第一位。官方镜像一般比第三方镜像靠谱，安全更新也跟得上。
写Dockerfile的几个习惯我分享一下。COPY的时候把package.json和锁文件先拷进去，装完依赖再拷源代码，这样源代码变了依赖层缓存还能用，构建快很多。RUN命令尽量合并，减少层数，但别为了合并而合并，可读性也要顾。apt-get install后面记得加rm -rf /var/lib/apt/lists/*清缓存。环境变量用ENV声明，别写在RUN里。还有那个.dockerignore文件，很多人不写，结果node_modules、.git目录全打进镜像里，体积大还慢。我现在的项目模板里一定有.dockerignore，node_modules、.git、dist这些列上。
构建速度优化还有个关键点是构建缓存。本地构建很爽，服务器上构建如果每次都从头来，等得人心焦。我一般的做法是在CI环境或者本地构建好镜像，推送到镜像仓库，服务器只负责拉取和运行。这样服务器上不用装编译工具，也不用等构建。如果确实要在服务器上构建，用BuildKit，开启缓存挂载，RUN --mount=type=cache这个语法能把包管理器的缓存保留下来，第二次构建能快不少。我测试过一个Go项目，开启缓存后构建时间从三分多钟降到四十秒。
3.3 Docker Compose多服务编排与环境变量管理
单容器项目用docker run就够了，但稍微正经一点的项目都是多服务的：一个Web应用、一个数据库、可能还有缓存、队列、定时任务。这时候Compose就派上用场了。我第一个Compose文件写得乱七八糟，所有配置都写死，换个环境就改一次文件。后来学乖了，docker-compose.yml里只放结构，变量全抽到.env文件里，环境相关的配置一个文件搞定。
Compose文件的写法我有个套路。services下面每个服务定义image或者build、ports、volumes、environment、depends_on。端口映射我现在只映射必要的那一个，数据库端口坚决不往外暴露，Compose内部网络里服务之间用服务名通信就够了。depends_on要配合健康检查用，depends_on只保证启动顺序，不保证服务就绪，我踩过这个坑，应用起来连数据库连不上，因为数据库容器还在初始化。加上healthcheck和condition: service_healthy就稳了。
环境变量管理这件事值得单独说。密码、密钥这类东西绝对不能写在Compose文件里提交到Git。我现在的做法是.env文件放服务器上，权限设成600，Compose启动时自动读取。environment字段引用.env里的变量，${DB_PASSWORD}这种语法。更敏感的环境我会用Docker secrets，虽然Compose对swarm模式的secrets支持更完整，普通模式下也能通过挂载文件的方式实现。别嫌麻烦，密钥泄露的代价比这点配置成本大太多了。
多环境管理我用docker-compose.override.yml这个机制。基础配置放docker-compose.yml，开发环境的额外配置放override文件，Compose默认会合并这两个文件。生产环境用-f参数指定生产配置文件。这样一套代码，开发、测试、生产三套配置各管各的，互不干扰。有时候项目多了，我会给每个项目建单独的目录，目录名就是项目名，里面放docker-compose.yml、.env、data目录，一眼就能看清结构。启动脚本也放在目录里，./start.sh一敲就起来，换台机器把目录拷过去就能用。
3.4 数据卷、网络、持久化与备份策略
数据卷这块我交过学费。刚开始用Docker的时候不知道数据要持久化，数据库跑在容器里，有次升级镜像直接docker rm把容器删了，数据跟着没了。那次之后我认真研究了卷的用法。现在我的原则很明确：所有需要持久化的数据，一律挂载到宿主机目录或者命名卷，容器内部不留重要数据。数据库的数据目录、应用的上传文件、配置文件，全部分离出去。
挂载方式有两种，bind mount和named volume。bind mount直接挂宿主机路径，比如/opt/项目名/data:/app/data，好处是备份方便，直接拷宿主机目录就行。named volume由Docker管理，跨平台一致性更好，但备份稍微绕一点。我一般数据库用named volume，因为性能好而且Docker管理生命周期省心；上传文件这类需要经常备份的用bind mount，直接rsync到备份服务器就完事。权限问题要注意，容器里的运行用户UID跟宿主机用户对不上会导致写不进去，chown一下宿主机目录，或者启动时指定用户。
网络这块说简单也简单。Compose默认创建一个bridge网络，服务之间用服务名就能互相访问。我习惯给每个项目建独立的网络，不同项目的容器完全隔离，避免误连。需要对外暴露的服务映射端口到宿主机，其余服务不映射，通过内部网络访问。有个细节是容器重启后IP会变，所以应用配置里连数据库千万别写IP，写服务名，比如mysql、redis，Docker的DNS会帮你解析。
备份策略我目前是一套组合拳。数据库每天定时mysqldump或者pg_dump，导出的SQL文件压缩后传对象存储，保留最近三十天。上传文件目录用rsync每小时同步到备份服务器，保留七天。配置文件直接纳管到Git私有仓库，改了就有记录。所有这些备份我每个月至少恢复一次到测试环境验证，不验证的备份等于没有备份。有次数据库备份文件损坏，我恢复的时候才发现，还好只丢了一天数据。从那以后备份验证就成了我清单里的固定项，再忙也不跳过。
3.5 私有镜像仓库、多架构镜像与部署发布
项目多了之后镜像管理就成了问题。一开始我在服务器上本地构建，后来发现多台服务器都要用同一个镜像，总不能每台都构建一遍。这时候私有镜像仓库就很有必要了。我用过Harbor和Registry，小规模用官方Registry就够，带Web界面和权限管理的选Harbor。现在云厂商基本都提供容器镜像服务，免费额度够个人项目用，省得自己维护。
镜像的命名和版本管理我摸索出一套习惯。镜像标签不用latest，用Git commit的短哈希或者版本号，比如myapp:a3f5c21、myapp:v1.2.0。latest谁都说不清是哪个版本，回滚的时候抓瞎。每次构建推送到仓库，服务器上docker pull指定标签再重启。部署脚本里我把版本号作为参数传进去，./deploy.sh v1.2.0，干净利落。镜像仓库里保留最近十个版本，老版本定期清理，不然磁盘会满。
多架构镜像这块我踩过坑。开发机是M1芯片的Mac，服务器是x86_64，本地构建的镜像推上去服务器跑不了。后来用了docker buildx，一套命令构建amd64和arm64两个架构的镜像，打成一个manifest推送到仓库，拉取的时候Docker自动选对应架构。命令也不复杂，docker buildx build --platform linux/amd64,linux/arm64 -t 镜像:标签 --push .，前提是配置好builder。这个对混合架构的团队特别有用，不用再为架构问题折腾。
部署发布流程我现在尽量做到一键化。服务器上放一个deploy.sh脚本，做的事情就是docker compose pull、docker compose up -d、docker image prune -f。配合GitHub Actions或者GitLab CI，代码推送到main分支自动构建、推送镜像、触发部署。回滚也简单，./deploy.sh 旧版本号就回去了。我有个项目用Watchtower做自动更新，镜像仓库有新版本就自动拉取重启，省心但风险也大，只适合不关键的个人项目。生产环境我还是手动控制发布节奏，发布前看日志、做健康检查，确认没问题再切流量，这事急不得。
第4章 部署后运维、安全与持续优化
4.1 日志、监控与告警体系搭建
项目上线那天我一般不会庆祝，真正的麻烦从那一刻才开始。半夜两点电话响起来说站点打不开，你连哪台机器出了问题都不知道，那种感觉太糟糕了。所以我现在的习惯是，部署完成后的第一件事不是去写新功能，而是把日志和监控先支起来。没有观测手段的系统就像闭着眼睛开车，早晚出事。
日志这块我一开始的做法特别朴素，docker logs看输出，看完就完事。后来问题多了发现不行，日志一多刷屏，找一条错误跟大海捞针一样。现在我的标准配置是每个项目都加上日志驱动或者日志采集容器。简单的场景用Docker自带的json-file驱动配个轮转，max-size=10m、max-file=3，防止日志把磁盘吃满。稍微认真的项目我会上一套Loki或者ELK，所有容器日志统一收集，按服务、按时间检索。我给一个电商项目配Loki的时候，客户反馈订单提交失败，我从日志里十秒钟定位到是某个第三方支付回调的超时错误，没这工具得排查一晚上。
监控和告警我分了三个层次。机器层面用Node Exporter加Prometheus，盯CPU、内存、磁盘、网络，磁盘快满的时候提前告警，别等写不进去才反应。应用层面加健康检查接口，黑盒探针定时请求，返回非200就报警。业务层面最关键，比如注册量突然掉到零、支付成功率跌破阈值，这些指标只有业务自己知道。我吃过只监控机器不监控业务的亏，服务器一切正常，但数据库连接池耗尽，应用半死不活，机器指标愣是没反映出来。告警渠道我用Telegram机器人或者钉钉webhook，消息简短直接，带上服务名和错误摘要，别整一堆没用的，半夜被吵醒的时候越简洁越好。
4.2 权限控制、密钥管理与漏洞修复
安全这块我以前有点侥幸心理，觉得小项目没人盯上。后来一个朋友的博客被人扫到弱密码，数据库被拖走，还收到了勒索邮件。这事给我敲了警钟，安全不是等出事了才补的东西，平时就得当回事。我现在的原则是能少开一个口就少开一个，能少给一分权限就少给一分。
服务器登录我早就关掉了密码认证，只留SSH密钥，而且禁用root直接登录，用普通用户加sudo。Docker权限也一样，容器默认以非root用户跑，USER指令在Dockerfile里写明。数据库的连接账号按项目分，一个项目一个账号，权限只给需要的库和表，别图省事全用root。我见过不少教程直接root/123456跑数据库，跑在公网上简直是给扫描器送人头。端口暴露也要克制，Compose内部网络通信就行，非要对外暴露的走反向代理加认证。
密钥管理我上过当。早期图方便，密码直接写在启动命令里，docker run -e DB_PASS=xxx，用ps一看全暴露。后来改成.env文件，权限600，只有部署用户能读。更敏感的东西比如API私钥、证书，我放到服务器的加密目录，启动时挂载进容器。再讲究一点可以用Vault或者云厂商的密钥管理服务，自动轮换密钥。漏洞修复我的做法是订阅所用基础镜像的安全通告，定期在测试环境更新镜像重建容器，跑一遍回归测试再上生产。有个项目用的某个npm包爆了高危漏洞，我当天就把依赖升级了，升级前先在测试环境验证兼容性，没把握的包就找替代，安全债拖不得。
4.3 备份恢复、版本升级与回滚机制
备份这事前面提过一嘴，这一节我想再细说一下，因为它跟升级、回滚是绑在一起的。我的升级流程现在固定成三步：备份、升级、验证。升级前先跑一次全量备份，数据库加文件目录，确认备份文件大小正常、能解压、能导入测试库。这一步花不了十分钟，省下的可能是几天几夜的抢救时间。
版本升级我尽量做小步走。一次升一个版本，别从1.2直接跳到2.0，中间要跨过的变更点太多，出了问题根本不知道是哪个改动引起的。升级窗口选在低峰期，提前发通知，升级完先看日志有没有ERROR，再跑一遍核心功能的冒烟测试。我有个项目因为跳过了一个中间版本，数据库迁移脚本有先后依赖，直接升级的时候迁移失败，回滚回去又发现新版本写过的数据不兼容老表结构，折腾了大半天才手工修复。
回滚机制我说一下我现在的做法。镜像版本用唯一的tag，上一版镜像永远保留在仓库里，回滚就是docker compose切回旧tag重启。数据库的回滚麻烦一些，我不做自动回滚，因为迁移脚本一般没有逆向操作。所以涉及表结构变更的升级，我会先在一个只读副本上做预演，确认迁移脚本能跑通、能回退。应用层回滚加上数据层备份，这两条腿都站稳了，升级才敢放手做。
4.4 CI/CD自动化部署与配置管理
手工部署多了迟早出错，少敲一个参数、忘了拉最新镜像、环境变量改错一个字母，都是真实发生过的翻车现场。我推动自动化部署的原因特别实际，就是不想再在深夜重复那些枯燥的步骤。CI/CD听着高大上，落到个人项目上其实可以很轻。
我目前最常见的组合是GitHub Actions或者Gitee的流水线。代码推送到指定分支，自动跑测试、构建镜像、打tag、推仓库，再通过SSH到服务器执行部署脚本。流水线里加几个门禁，测试不通过不许合并，镜像构建失败不发通知。这个过程中我特别注意一点，流水线的凭据用仓库的Secrets存储，别把密码写在YAML里。服务器上的部署账号也只给最小权限，能拉镜像、能重启容器就行。
配置管理这块我走过弯路。一开始每台服务器的配置靠手改，改了一台忘了另一台，时间一长谁跟谁都不一样。现在我尽量让配置代码化，所有环境变量、nginx配置、启动脚本放在Git仓库里，用Ansible或者简单的同步脚本推送到服务器。配置文件改了就走提交记录，谁改的、为什么改，一目了然。环境之间的差异用变量区分，开发、测试、生产用同一套模板，减少“在我机器上是好的”这类问题。
4.5 性能调优、成本控制与扩展实践
性能调优我信奉一条：先量后调。没有指标就优化，等于瞎猜。我的习惯是先压测，找到瓶颈在哪再动手。压测工具用wrk或者k6，模拟真实用户请求，看响应时间、吞吐量和错误率。有一次客户抱怨页面慢，我第一反应是加服务器，后来一测发现瓶颈在数据库慢查询，一个缺索引的查询拖垮了整个接口，加索引之后响应时间从八百毫秒降到三十毫秒，服务器一台没加。这种案例太多了，千万别凭感觉做性能决策。
服务器资源这块我比较抠。个人项目和小团队项目，一开始没必要上高配机器。我现在的默认方案是一台中等配置的云主机，Docker跑所有服务，数据库加适量内存，应用容器限制CPU和内存上限，防止一个服务把整机拖死。docker stats定期看一眼，哪个容器常年资源利用率低于百分之十，就把它合并或者降配。磁盘定期清理无用镜像和日志，能省不少钱。云厂商的优惠券和预留实例我也会关注，一年能省出一台机器的钱。
扩展实践我遵循先纵向后横向。流量涨了先看看是不是能通过缓存、队列、加内存来顶住，这些成本最低。真到了单机顶不住的时候，再考虑横向扩展。横向扩展的前提是应用无状态，会话数据存Redis，文件存对象存储，容器随便加。我做过一个活动的临时扩容，用云厂商的弹性伸缩组，活动期间从两台扩到十台，活动结束自动缩回去，成本控制得很漂亮。扩展这件事别过度设计，够用就好，架构复杂度本身也是成本。
