把这座观测站搬上云：一次 ASP.NET 部署手记

网站写完，只是把它送到别人面前的第一步。

这篇不是一份严肃的运维手册，只是把「遥远未来的故事」从本地 dotnet run 搬上一台云服务器的过程，记成一份可以复用的清单。

一、先让它在本地跑起来

发布之前，先确认三件事：

1. dotnet build 没有意外。
2. 首页、文章页、后台登录都能正常打开。
3. 数据目录和上传目录不在发布目录里面。

最后一点很重要。应用目录会在每次部署时被覆盖，如果文章和图片也存在里面，一次更新就会把过去一起删掉。

所以我把持久化目录拆了出来：

Blog__DataDir=/root/distant-future-data
Blog__UploadDir=/root/distant-future-data/uploads

二、发布产物

ASP.NET 的发布命令并不复杂：

dotnet publish -c Release -o ./publish

把 publish 目录打包、上传，再由启动脚本解压到固定的应用目录。

启动脚本需要做四件事：

• 解压新的代码；
• 确认 .NET 运行时存在；
• 用 nohup 在后台启动；
• 把 PID 与日志写到固定位置。

unzip -o app.zip -d /root/distant-future
cd /root/distant-future
nohup dotnet DistantFuture.dll --urls http://0.0.0.0:8080 \
  >> /root/app.log 2>&1 &
echo $! > /root/app.pid

三、上线之后才看见的问题

第一件事：端口。

应用监听 8080，但安全组没有放行，浏览器只会给你一个安静的「无法访问」。记得同时检查进程、端口和安全组。

第二件事：路径。

在 Windows 上写的是 D:\...，到了 Linux 就变成 /root/...。所有写死的路径都要重新检查，尤其是图片与 JSON 数据文件。

第三件事：日志。

不要只看部署平台返回的绿色对勾。真正的答案在 /root/app.log 里。应用有没有开始监听、有没有抛异常，那里写得比任何状态面板都清楚。

四、把「上线」当成一次写作

部署不是开发结束后的杂务，它更像给文章按下发布键：你终于要面对真实的读者、真实的网络，以及真实的错误。

但也正是从那一刻起，它不再只是你电脑里的一个项目。

它有了地址，有了夜晚的访客，也有了一点点继续生长下去的可能。

如果你也在把自己的第一个网站搬上云，愿你的日志里只有：

Now listening on: http://0.0.0.0:8080
Application started. Press Ctrl+C to shut down.