跳到主要内容
返回项目档案
工作已完成

生产服务器治理与内网 Gitea 远程办公

把一台阿里云 ECS 从「能用」做成「可接手」:脚本化的账号体系与安全基线、一条命令带自动回滚的发布,以及零公网端口的内网 Gitea 远程访问

角色
服务器与账号体系管理员(单人)
量级
1 台 ECS · 7 个管理脚本 · 10 篇运维手册
时间
2026年10月 — 至今
Alibaba Cloud ECSAlibaba Cloud Linux 3SSH / ED25519sudo 分组systemdMySQLRedisNginxTailscaleHeadscaleGiteaShell

做了什么

  • 账号体系:入职开号与离职回收全走脚本 —— 建号、装带加固前缀的公钥、随机 sudo 口令、建库账号、写台账,手工 useradd 视为违规
  • 安全基线:SSH 关密码登录、只允许 sysops 组、root 仅密钥;MySQL / Redis 只绑回环,端口暴露每日自检,安全组不放行 3306 / 6379
  • 发布与回滚:deploy-backend 备份 → 替换 → 重启 → 探活 → 失败自动回滚;前端 tar 备份后解包校验,回滚同样一条命令
  • 远程办公:内网 Gitea 经 Tailscale tailnet 访问,零公网端口;再自建 Headscale 去掉官方账号与 3 人上限,用 subnet router 直连内网网段
  • 可交接:管理员手册 + 9 篇同事手册(申请账号 → 自检 → 部署 → 改库 → 报错速查),新人按文档即可上手,不必等管理员在线

问题:服务器能用,但接手不了

接手时的状态很常见:几个人有 root、账号是口头加的、发版靠一句「你重启一下」、出了事去翻群聊。 这类系统不是不能用,而是不可交接——所有关键知识都挂在具体的人身上,一旦换人,风险立刻显性化。

所以目标不是「再装几个服务」,而是把三件事写成制度:谁能进、能做什么、出事怎么救。

账号体系:把开通与回收变成脚本

账号是权限的源头,也是最容易被手工操作绕过的地方。这里的原则是:只有脚本能开号,手工 useradd 一律视为事故。

阶段 动作 产物
开通 收公钥 → 建系统账号并入 sysops → 装带加固前缀的公钥 → 生成随机 sudo 口令 → 建库账号 → 写台账 一条可交付的开号结果 + 台账一行
使用 家目录 700/700/600;公钥带 no-agent-forwarding 等前缀;sudo 需密码 权限最小、可追溯
回收 撤公钥、锁账号、删库账号、查孤儿文件与配置引用、核对云侧 RAM 与操作审计 回收清单,逐项确认

台账(accounts.tsv,640 root:sysops)只记账号与公钥指纹,不记任何密码——密码走密码管理器或一次性链接,不在 IM 里明文发。 「谁在什么时候、用什么身份、执行了什么」,由 sudo 审计日志回答,而不是靠回忆。

安全基线:默认不暴露

安全不是一个开关,而是一组默认值。这台机器上的默认值是「关掉一切不必要的入口」:

  • SSH:禁密码登录、禁键盘交互、最多 3 次尝试、只允许 sysops 组与 root,root 仅密钥。
  • 数据库:MySQL 只绑 127.0.0.1,root 走 socket;Redis 只绑回环。安全组不放行 3306 / 33060 / 6379。
  • 自检:db-exposure-check 每日校验端口暴露与绑定地址,user-audit 每周输出账号 / 公钥 / 口令年龄 / sshd 生效配置快照。
  • 云侧:RAM 子账号只给只读与会话管理,不给 RunCommand、快照与重置密码;ActionTrail 保留审计。

基线快照(sshd 配置、sudoers、账号与公钥指纹、监听端口)在改动前先备份,出问题可以整体回退——改之前先想好怎么退。

发布与回滚:一条命令,失败自己退回去

发布是最容易出事的环节,所以它被压成一条命令,并且自带退路:

deploy-backend <jar>   备份 → 替换 → 重启 → 探活 → 失败自动回滚
deploy-frontend <dist> tar 备份 → 清空解包 → 校验 index.html

配套的规则同样明确:低峰发布;含 SQL 变更先备份再发;发布后检查服务状态、近两分钟日志无 ERROR、关键页面抽查;磁盘留出余量(备份只留最近两三份)。 回滚不需要现场想命令——上一个版本就在 *.bak-* 里,用同一条脚本回滚即可。

远程办公:内网 Gitea,零公网端口

内网 Gitea 原本只能在公司网段访问,同事在家就没法推代码。传统解法是开公网端口或架 VPN,但这两种都在扩大攻击面。

第一版 · Tailscale:把 Gitea 服务器与同事的电脑放进同一个加密 tailnet,用虚拟 IP 访问。 不开公网端口、不做端口映射、不装 VPN 设备;访问权限按设备授权,tailscale ping 能直接定位是直连还是走中继。

第二版 · 自建 Headscale:官方 Tailscale 依赖第三方账号,且有 3 用户上限,对团队是硬约束。 于是自建 Headscale 作为控制服务器——它只负责协调(注册、下发地址、交换公钥、下发 ACL),业务流量仍是节点间点对点直连,打不通才走 DERP 中继。 Gitea 服务器作为 subnet router 宣告内网网段,同事在家可以直接用原来的内网地址访问,客户端配置几乎不用改。

取舍写在前面:自建换来可控与不限人数,代价是要自己维护控制服务器、证书与升级。

文档即交付

这套东西真正的交付物不是一台配好的机器,而是十篇能照着做的文档:

  • 《管理员手册》:账号基线、开通与回收、数据库管理、发布与回滚、审计巡检、应急处置、云侧管控、已知坑。
  • 《同事手册》9 篇:申请账号 → 自检与配置 → 信息速查 → 服务器规则 → 常用命令 → 部署代码 → 数据库操作 → 报错速查 → 找管理员。

写法上刻意「去个人化」:命令按「在哪台机器执行」标注,值一律用占位符,每步写清「预期看到什么」。 文档里的每条结论都来自实测——比如「普通同事账号读不到 root 服务的 journal,真实日志在应用目录」,就是排障时撞出来的。

结果

  • 新同事从「等管理员在线」变成「照文档自助」:申请、自检、部署、连库、排错都有路径。
  • 发布从「凭记忆操作」变成「一条命令 + 自动回滚」,失败不再需要现场决策。
  • 远程办公从「开端口 / 架 VPN」变成「设备进 tailnet 才能访问」,公网暴露面为零。
  • 账号从「谁都能加」变成「只有脚本能加」,离职回收有清单、有审计、可核对。