1. 折腾部署的时候我先被本机环境磨掉了耐心今年上半年我的主要学习内容就是部署系统。从最简单的docker run hello-world到 GitLab 社区版、Zabbix 监控平台、再到 AI 模型的本地部署实验一路走下来最大的感受不是部署难而是被环境反复打断。最初所有实验都在自己的笔记本上做一台 8GB 内存的 Windows 和一台虚拟机每次换个实验都要花半天时间清理、卸载、恢复环境。后来我换成云服务器做主要练习环境才真正体会到什么叫把时间花在学习本身而不是花在伺候环境上。这篇记录的目的是给那些同样在学部署的朋友一条可以抄的路径怎么选云服务器、新机器到手先做什么、我用同一台机器跑过的几次典型部署、以及踩下来最值得说的几个坑。如果你是刚接触 Linux、Docker或者正准备用云服务器学部署这篇文章应该能帮你省掉一部分学费。1.1 本机部署不是完全不行只是代价太高先说实话我并不是一开始就用云服务器的。最初本地跑个 Docker 容器、装个 MySQL完全没问题。但学习部署系统不是说装一个服务就结束了你要反复做以下几件事同时启动多服务一个实际点的项目往往包含 Nginx、Redis、应用容器、数据库4个容器一开8GB 笔记本内存直接见底风扇起飞鼠标都开始飘。反复重装系统部署过程中最容易把系统搞乱。改坏一个依赖、删错了配置文件、把网络调没了这些事几乎每做几天就来一次。想要回滚本地虚拟机是做快照了但虚拟机文件几十个 GB而且快照本身会拖慢整个虚拟磁盘物理机就更是只能靠重装系统后一切重来。想给别人演示本机部署的服务只能在自己电脑上看给同学演示还得搞内网穿透穿透工具不稳定还好配置上又有各种认证要求远不如一个公网 IP 来得直接。这些事单独看都不致命但叠加在一起学习效率就被拉低了。尤其是部署这件事很多知识只有在反复重复装好、弄坏、重装的过程中才能记住本机环境恰恰不允许你频繁地弄坏再重来。1.2 云服务器解决的不只是性能问题更是心态问题用云服务器之后最明显的变化是我终于敢乱动了。服务器在传统印象里是生产环境的东西应该小心翼翼。但学习用的云服务器恰恰相反它最适合什么都不怕地折腾原因有几个快照是后悔药。动手改配置之前拍个快照改坏了直接回滚整个过程几秒钟不用重装。重置系统成本极低。系统彻底搞挂了也没关系控制台里点一下重置回到干净状态。按需购买。学习时期先用按量计费做实验的时候开做完关机成本可控。自带公网 IP 和多台内网互通。公网 IP 用于访问演示内网互通则让你有条件做多机集群实验这是本机环境最难模拟的部分。所以对我这种以学会如何部署为目标的人来说云服务器真正带来的不是更高的配置而是更低的重来成本。换句话说它把试错变成了一件可以顺手就做的事。2. 选服务器不是越贵越好学生党验证过的选型路径选型这件事我一开始也走了弯路看了一堆云服务器推荐最后发现学习部署系统的核心诉求其实不复杂能折腾、便宜、有公网 IP、配置比本机略高就行。按这个标准筛下来结论很明确优先考虑各家的轻量应用服务器而不是一上来就买标准云服务器。2.1 先薅免费试用把流程跑通再决定花钱我建议所有新手第一台服务器都从免费试用开始。像阿里云、腾讯云、华为云这些主流厂商都有面向新用户的免费试用入口通常是一个月到三个月不等的轻量服务器或者等额的代金券。学习部署基础一个月的时间其实够跑完 Docker、GitLab、Zabbix 这类基础实验了。用免费试用的过程中要注意三个细节。第一看清试用的是什么配置很多免费云服务器给的是低配置小带宽跑纯命令行、装 Docker 还好跑 AI 大模型基本没戏。第二到期时间要设个提醒试用机器到期以后要么续费要么赶紧把数据导出不然里面存的实验配置说没就没。第三试用机器更适合用来验证这个部署流程对不对而不是长期跑服务等你确定自己会持续练习了再付费也不迟。我自己的路径就是先用一台免费试用机器把 Docker 和 Linux 常用操作跑熟确定还要继续深入学习数据库和监控部署之后才掏钱买了正式的轻量服务器。2.2 轻量应用服务器和标准云服务器学习阶段选哪个买服务器之前我查了不少资料发现很多人分不清轻量应用服务器和云服务器到底有什么区别。简单说轻量应用服务器是面向个人网站、应用部署推出的套餐化产品CPU、内存、带宽在购买时已经打包好还自带应用镜像标准云服务器比如阿里云的 ECS、腾讯云的 CVM则是更底层的云主机配置完全自己拼网络、安全组这些概念也更接近生产环境。我用一张表把核心差异列出来对比项轻量应用服务器标准云服务器配置方式固定套餐带宽已含自定义 CPU/内存/带宽上手难度低有镜像市场中需自己配置网络安全组/网络简化版概念偏少VPC、安全组分得很细价格相对便宜计费项多容易超支适用场景学习部署、个人项目生产环境、多节点架构结论很明白如果你只是想学习部署流程、跑通一个服务、做个人项目轻量应用服务器是最合适的省下那些绕不开又暂时用不到的 VPC 概念把精力集中在服务本身的部署逻辑上。但如果你接下来要学多节点集群、自定义网络拓扑、生产级架构最好还是用标准云服务器因为很多部署细节在轻量应用服务器上是看不到的。2.3 按照部署目标选配置别一上来就 8 核 16G配置怎么选取决于你接下来要跑什么类型的部署。我根据自己这一年多折腾下来的经验给一个保守但实用的参考部署目标建议配置说明入门 Linux 和 Docker2 核 2G 40G跑简单容器足够装桌面环境则建议 4GDocker 部署中等应用GitLab 等4 核 8G 80GGitLab 实际跑起来内存占用超预期4G 会频繁 OOM监控系统Zabbix 数据库2 核 4G 起步单机实验够但要数据库前端一起跑建议 4G 以上AI 模型本地部署小模型/Ollama 量化4 核 8G 至 8 核 16G7B 量化模型需要 8G 左右内存低于这个跑不动三节点数据库集群3 台 2 核 4G单机性能不用高但机器数量要够这里我想多说一句很多人看部署教程的时候会照着教程里的生产环境配置去买服务器结果花钱买了一台高配机器平时的实验根本用不满。学习阶段的正确思路是先用最低配置跑通流程发现瓶颈了再升级。云服务器的好处就在于配置可以随时变不需要一步到位。3. 新服务器到手别急着部署先花 20 分钟做完环境初始化拿到一台崭新服务器之后我犯过的最大错误就是直接开始翻教程照着命令一顿装然后把系统弄得乱七八糟最后只能重置。后来我养成了一个习惯任何一台新服务器到手先花 20 分钟左右做环境初始化之后再折腾部署出问题的概率会低很多。下面这几个步骤是我每次都会做的。3.1 系统镜像Ubuntu 22.04 LTS 是目前的基准选择新服务器第一个选择就是系统镜像。我现在的默认选择是 Ubuntu 22.04 LTS。原因不复杂国内外的部署教程、社区问答、官方文档绝大多数都基于 Ubuntu 或 Debian 系来写遇到问题搜索时的参考资料最多。CentOS 虽然过去很流行但官方已经停止维护不少老教程里的命令在新环境里已经不好用了。24.04 LTS 现在已经发布理论上也可以选但我的建议是如果你的教程主要还在 apt 和 systemd 这套体系里先选 22.04 可能是最稳妥的因为踩坑资料最全。可能有人会问Ubuntu 和 Debian 选哪个我的看法是学习阶段抓一个就行Ubuntu 的云镜像在各家平台都是标准选项国内源更新也方便。选一个生态资料最丰富的系统远比选一个看起来更专业的系统重要。系统装完之后第一步做了什么我一般是先执行一遍apt update apt upgrade把基础软件包更新到最新再装curl、wget、git、vim这些常用工具。这时候不要急着装 Docker先把系统的网络、源、SSH 这些都确认正常了再说。3.2 SSH 密钥登录和安全组是两道必须跨过的门槛很多部署教程默认你已经能顺利 SSH 登录服务器但恰恰这一步新手容易卡住。我的做法是这样的在本地机器上生成密钥对。推荐用ed25519算法命令是ssh-keygen -t ed25519 -C deploy-server生成的公钥在~/.ssh/id_ed25519.pub。把公钥内容追加到服务器上的~/.ssh/authorized_keys文件里。如果服务器已经开了密码登录直接复制粘贴过去就行。用密钥登录成功后再修改/etc/ssh/sshd_config把PasswordAuthentication设为no重启 sshd。这样服务器就不再接受纯密码登录安全度上升一个档次。比 SSH 登录更容易踩的坑是安全组。云厂商的安全组相当于服务器外面的一道虚拟防火墙默认情况下很多端口根本没有放行。你在这台服务器上启动了某个服务看起来很努力了但是从公网怎么都访问不了第一反应往往是在系统里查防火墙、查服务状态折腾半天最后发现只是云控制台的安全组入方向规则里没加对应端口。所以我的习惯是在初始化阶段就统一想好这台机器要开放哪些端口22SSH、80HTTP、443HTTPS然后按需临时添加其他端口。安全组改完才是真正意义上的服务对外可用。3.3 数据盘、Swap 和 Docker 日志三件小事避免后面炸盘新服务器不给数据盘挂载和 Swap 设置留点心思后期部署大概率会碰壁。我遇到过好几次内存不足直接 OOM或者 Docker 镜像把系统盘占满的情况后来把下面三件事做齐了才很少再因为资源问题卡住。第一如果服务器有额外的数据盘先确认它有没有自动挂载。轻量服务器有些套餐默认系统盘就挺小Docker 镜像、容器日志、数据库文件很快就会把它塞满。我的做法是把数据盘挂载到/data然后把 Docker 的数据目录改到/data/docker或者直接把数据盘挂到/var/lib/docker下一劳永逸。具体怎么改 Docker 目录可以搜官方文档基本思路是修改/etc/docker/daemon.json里的>sudo fallocate -l 4G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile再把它写进/etc/fstab重启后也能自动启用。这里要说明一下Swap 是内存不足时的兜底方案不是让程序变快的方案。跑数据库、大模型这类吃内存的任务还是要靠真实内存Swap 的作用是避免进程直接被系统杀掉给你从容处理的机会。第三Docker 的日志不能不管。容器的标准输出日志会一直写在宿主机上如果一个容器每天产生几百 MB 日志一周下来几十 G 就没了。我会在/etc/docker/daemon.json里加一段配置{ log-driver: json-file, log-opts: { max-size: 10m, max-file: 3 } }配置完后重启 Docker新的容器就会限制日志大小。这三件事做起来都不复杂但部署环境的稳定度会好很多。4. 同一台服务器上我跑通的三类典型部署环境初始化完成后就可以进入正题了。我用这台云服务器跑过的最有代表性的三类部署分别是 GitLab 社区版的 Docker 部署、Zabbix 监控平台部署、以及 AI 模型的本地部署实验。这几个例子刚好覆盖了最常见的几种部署需求一个重应用、一个典型 C/S 架构、一个资源敏感型应用。把它们完整走一遍部署相关的核心技能基本就都会碰到了。4.1 用 Docker 部署 GitLab 社区版启动慢和内存是两堂必修课GitLab 是我在云服务器上第一次认真做的部署实验。当时参考的是 GitLab 官方提供的 Docker 镜像方式用 Docker Compose 管理数据目录单独挂载。部署文件大致长这样services: gitlab: image: gitlab/gitlab-ce:latest container_name: gitlab restart: always hostname: gitlab.example.com ports: - 8080:80 - 8443:443 volumes: - /data/gitlab/config:/etc/gitlab - /data/gitlab/logs:/var/log/gitlab - /data/gitlab/data:/var/opt/gitlab挂载数据卷这一点很重要容器本身是可以随意删除重建的但数据目录留在宿主机的数据盘上将来升级或者迁移都方便。我第一次部署的时候就吃过亏只挂载了配置目录数据留在容器内部后来想升级镜像时发现数据不好迁移。GitLab 部署最典型的一个坑是启动慢。第一次启动时容器内部要做大量初始化工作可能要等两到三分钟浏览器里才能看到页面。很多新手在这段时间里就以为部署失败了反复重启容器反而把初始化过程搞乱。我当时的做法是先看容器日志docker logs -f gitlab确认日志有没有持续输出只要日志在走耐心等就行。另一个坑是内存。GitLab 对内存的要求比想象中高2G 内存的服务器跑起来大概率直接 502 或者频繁 OOM。我后来把服务器升到 4G才顺畅了许多。如果你手头只有 2G可以用GITLAB_OMNIBUS_CONFIG环境变量关掉一些用不上的组件比如prometheus_monitoring[enable] false能省下不少内存。GitLab 社区版功能本身够用部署它最大的收获不只是在浏览器里看到一个登录页而是理解了一个重服务的部署往往不只是装一个包还要关心资源、数据目录和启动时序。4.2 用 Zabbix 学监控部署从单机到 server-agent 结构学完 GitLab 这样偏单体应用的部署之后我接着试了 Zabbix。Zabbix 是开源监控系统部署结构比 GitLab 复杂不少因为它天然是一个分布式架构Zabbix Server 负责收集和存储数据Zabbix Web 提供界面Zabbix Agent 安装在每一台需要被监控的机器上。理解了这个关系部署 Zabbix 才能真正顺畅。我在云服务器上用的是 Docker Compose 方式整个 Zabbix Server 加 Web 前端和 PostgreSQL 数据库放在一台机器上然后另外开了一台机器装 Agent。Agent 默认监听在 10050 端口Server 监听 10051 端口。这里有个细节很多教程会让你在系统防火墙里放行这两个端口但你同样要去云控制台的安全组里加规则。我当时测试 Agent 注册不上排查了半天才发现是安全组只放行了 Web 界面端口把 10050/10051 漏了。Zabbix 的部署过程让我学到的核心概念是被监控对象如何主动和监控服务器建立联系。Agent 装好之后不是 Server 去扫描它而是 Agent 主动向 Server 汇报。所以配置 Agent 时要填 Server 的 IP还要确保服务器之间网络通畅。这个模型在真实的监控、日志采集场景里非常常见把 Zabbix 跑通一次后面再看其他 agent-server 架构的部署基本都能举一反三。4.3 在云服务器上跑 AI 模型本地部署从 Ollama 到量化模型最近大模型本地部署非常热我也在云服务器上做了实验。严格来说大模型部署在云服务器上的成本并不低因为推理很吃内存和算力普通 CPU 机器只能跑小参数量模型或者量化版。我的实验从 Ollama 开始它是一个把模型加载、推理接口大大简化的工具非常适合学习模型部署整个流程。我当时在一台 4 核 8G 的机器上部署了qwen2.5:7b的量化版本结果内存不够推理速度很慢几乎不可用。后来换成 3B 左右的模型马上顺畅了许多。这个经历给我的深刻教训是资源敏感型的部署一定要先搞清楚你部署的东西实际需要多少资源而不是只看教程里写的安装完就能用。为什么 Ollama 这类工具会降低部署门槛因为它把模型下载、加载、API 服务启动都封装好了你不需要先搞懂 PyTorch、CUDA、模型权重格式这些底层东西。对于学习部署的人来说先用它跑通模型如何变成一个可通过 API 访问的服务理解模型文件、端口、推理参数之间的关系比一开始就深挖底层更有效。另外想提一点很多人在学部署时会纠结要不要买带 GPU 的服务器。我的建议是如果你目标是学习部署流程本身CPU 机器完全够用只是要跑小模型如果你目标是把大模型真正用起来那 GPU 服务器才是正解但这又是另一笔预算了。顺便说个身边同学的例子他在 RK3588 开发板上部署 YOLOv8要处理交叉编译和板端环境和云服务器上pip install加启动服务的体验完全不一样。不是说板子不好而是不同环境的学习重心不同。对初学者来说云服务器这种低摩擦的环境更适合先把部署逻辑学明白。4.4 一次想顺带完成的多节点部署实验实践过程中还有一个我一直想完成的内容是三节点数据库部署。传统的 MySQL 主从复制至少两台服务器分布式数据库要看更多节点这在本机虚拟环境里也可以做但性能和网络模拟总差点意思。云服务器的好处是再开两台最低配机器就能组成一个真正的内网集群跨机器的部署、配置、故障转移这些知识点是可以实打实练到的。这部分我没有像前三次一样在一台服务器上完成因为至少需要 3 台机器。个人建议是先用免费试用名额多开几台低配机器按官方文档把它们配成一个小集群重点理解节点间通信、配置同步和探活机制。多节点部署是部署系统里和生产环境最接近的场景值得在掌握单机部署之后再花时间学。5. 部署这一路踩过的坑比教程里写的多得多最后想专门讲讲教训因为很多教程都只会写正确做法不太会写那些让新手折腾到半夜的坑。我把自己踩过且印象最深的几类问题整理出来希望能帮你少走点弯路。5.1 端口不通先查安全组再查系统防火墙这个坑我在前面已经反复强调过但值得单独列出来。不管是 SSH 登录、Web 界面还是自定义端口公网访问不通时排错顺序应该是服务进程是否在监听、系统防火墙是否放行、云厂商安全组是否放行、本地网络是否正常。实际情况里很多人第一步就去重启服务、改防火墙浪费大量时间。我现在只要遇到服务明明起来了但外面访问不了第一件事就是打开云控制台看安全组规则。5.2 教程抄一半是最浪费时间的错误部署文档最怕的就是抄一半。比如教程开头说基于 CentOS 7你用的是 Ubuntu教程让你直接下载二进制包你又之前已经装了 Docker 版某条命令在新版本里已经废弃你还照着老文档执行。每一条单独看都不是大事但混在一起就会产生各种诡异问题。我的经验是先选定一个主教程优先官方文档或者更新日期很新的教程完整跑通一遍再拿其他博客文章作为补充参考。如果发现两个教程的命令有冲突先理解冲突点再决定用哪个。盲目地多线抄作业最后往往就是环境被改得面目全非。5.3 Docker 日志和悬空镜像让磁盘悄悄见底云服务器系统盘一般只有 40G 到 80GDocker 用久了之后日志文件和悬空镜像会悄悄把磁盘占满。我印象最深的一次是某台服务器跑了一个持续输出日志的容器一周没用结果磁盘直接满了服务全部异常。从那之后我做了三件事限制容器日志大小前面提到过、定期清理悬空镜像、把 Docker 数据目录挂到大容量数据盘上。docker system prune -af这条命令能清理未使用的镜像、容器、网络和构建缓存适合在对服务影响小的时候执行。不过注意它会把你本地的无用资源一并清理生产环境要慎用。5.4 按量计费虽然灵活但别忘了关机学习阶段我用得最多的是按量计费因为可以用完就关很省钱。但问题是服务器关机和释放是两个概念关机状态下只是不产生计算费用但磁盘、公网 IP 这些资源可能还在计费。另外如果连着好几周忘记关机费用也会积少成多。我的做法是设置云厂商的账单提醒规定自己每次实验结束立刻关机如果短时间不再用干脆释放实例加备份快照避免产生存储费用。5.5 云服务器的适用边界要心里有数最后想提醒一句云服务器是很好的学习工具但它的用途边界是明确的。不同云厂商对服务器用途都有严格规定学习部署时只做合规、正当范围内的实验。不要动那些不该动的心思轻则账户被封重则给自己带来麻烦。像我上面说的这些部署场景——GitLab、Zabbix、AI 模型、数据库集群——范围内的东西已经足够学很长时间了根本不需要打擦边球。说了这么多最后分享一个小经验。我现在每次给新服务器做初始化都会顺手把过程记成一份清单包括系统版本、安装过的命令、改过的配置文件、放行的端口、遇到过的问题。因为部署这件事从来不是一次性的过一两个月再重装系统或者换一台新服务器照着这份清单重跑一遍会发现当初踩过的坑已经全部变成流程。这也是我为什么从一开始觉得云服务器麻烦到后来反而离不开它的原因——它把反复折腾的成本压到最低让我能把更多精力放在理解系统本身怎么运行上。如果你也在学部署希望这篇记录能让你少走弯路。