这篇记录的是我这学期云计算基础课程的第一个大作业的完整过程。作业要求本身不算难在云平台上创建一台云服务器自己动手把基本环境配好部署一个能通过公网访问的页面最后提交一份报告加演示截图。但说实话如果只是对着课堂PPT照葫芦画瓢大概率会卡在安全组或者公网IP这种不起眼的地方。我从资源申请到最终验收完整走了一遍中间踩了几个挺典型的坑这里把整个过程从头到尾捋清楚包括每个环节的取舍逻辑和排错思路给接下来也要做类似作业的同学当一个参考。1. 作业要求拆解看似简单却暗藏三个考核点老师当时给的需求用一段话就能说完使用云计算平台创建一台云主机配置运行环境部署一个简单的Web页面能够通过公网访问并提交操作报告。很多同学听完觉得这是最水的一个作业无非是点几下鼠标的事情。但实际上这种描述越简短里面藏着的隐性要求越多。我后来反复琢磨这个作业至少包含了三个明确的考核点并不只是能访问那么简单。第一个考核点是云资源的交付方式。你需要说明白这台云主机是怎么来的是按需购买的包年包月还是抢占式实例镜像选择的是公共镜像还是自定义镜像规格为什么选2核4G而不是1核2G这些在报告里都要有据可查。老师不会听你说我随便选了一个而是看你有没有理解云资源的基本逻辑计算、存储、网络是解耦的你可以按需组合。第二个考核点是网络可达性的完整链路。页面能被访问并不是配好Web服务器就可以。从公网到你的云主机中间要经过安全组过滤、虚拟交换机转发、弹性公网IP映射任何一个环节断了都访问不了。所以这题考的不是你装Nginx多熟练而是你是否能弄清楚80端口到底是怎么从外网穿到操作系统进程上的。第三个考核点是可复现性。作业报告不是让你贴几张截图就完事而是要让人看着你的文档能一步步复现出一个一模一样的实例。你用了什么镜像、改了哪些配置、执行了哪些命令、开放了哪些端口必须完整记录。这也是为什么我后面写了一份类似操作清单的东西每一步都经过重新验证避免编出实际上跑不通的步骤。搞清楚这三点之后我这个作业的目标就清晰了不追求花哨不搞复杂的负载均衡或域名绑定就跑通一条最朴素的从云平台控制台到浏览器页面的路径但把路径上的每个节点都讲透。2. 资源申请与选型从选镜像到定规格的取舍逻辑这个作业里最容易被忽略的就是选型环节。很多人只会盯着价格或者默认推荐但实际上规格和镜像的选择直接决定了后续配置的效率。我当时在云平台控制台上大概对比了十分钟最后定了这样一套参数配置项我的选择选择理由计费模式按量付费作业周期只有几天用完即释放成本可控地域华东区域离我最近延迟低拉取软件源速度快实例规格2核4G跑Nginx加编译工具绰绰有余又不浪费镜像Ubuntu 22.04 LTS生命周期长、社区资料多、包管理方便系统盘40GB高效云盘只装系统和Web服务不需要大容量公网带宽按使用流量计费峰值5Mbps测试流量很小按带宽计费反而更贵安全组新建只放行22和80端口最小权限原则后续再按需调整这里重点说下镜像为什么选Ubuntu而非CentOS。虽然课堂演示用的是CentOS但我在作业里特意选了Ubuntu原因很实际第一Ubuntu 22.04的apt源在国内访问速度通常比CentOS的yum源稳定第二Nginx和Python相关的包在Ubuntu下版本比较新不太会遇到源里版本太老导致的兼容问题第三遇到报错时Ubuntu系的问题在社区里翻答案的成功率更高。对新手来说用一套自己更容易查资料的系统本身就是降低风险的做法。规格这块我原本也想选1核2G的最便宜实例但后来考虑到要在上面装编译工具链还可能跑Node.js或者Python的Web服务1核在处理并发请求时响应会比较慢排查问题和演示时体验不好。2核4G在这个作业场景下是个甜点配置不至于烧钱又能保证流畅操作。关于地域选择很多人会忽略掉软件源距离这个隐藏因素。我一开始选了华北的某个可用区结果执行apt update时速度只有几十KB每秒后来换成华东的实例同样的源速度能到几MB每秒。地域不只是影响你连上SSH的延迟还会影响云主机访问外网软件源的速度。如果你的作业要装大量依赖这个选择会直接决定你的心情。所以我建议地域尽量选离自己物理位置近的同时也要考虑目标用户群体所在位置学生作业没那么多讲究就近原则基本不会出错。下单之后还有个容易漏的细节绑定弹性公网IP。有些云平台默认会分配一个公网IP但有些只分配私网IP需要你单独申请EIP并绑定到实例上。这个操作如果是第一次做很容易在控制台里东翻西找。我的建议是下单前看清楚网络配置的选项确保系统提示待绑定弹性公网IP是0个否则后面可能因为没绑IP而完全无法从外部访问。3. 安全组与网络配置真正卡住大多数人的隐藏门槛如果这个作业有八十%的人第一次没能顺利通过公网访问到页面那问题几乎都出在安全组上。安全组你可以粗浅理解成云主机外层的门禁系统它作用在虚拟网卡层面在操作系统根本看不到请求之前就已经决定放行还是丢弃了。所以哪怕你在实例里把防火墙关了、Nginx监听0.0.0.0:80只要安全组没放行80端口外部就是访问不了。我当时创建实例时顺手建了一个默认安全组只放行了22端口用于SSH。装好Nginx后我直接在浏览器里输入公网IP刷新了半天都是无法访问此网站。排查的第一步是在本地ping公网IP发现能ping通。这里注意能ping通只能说明网络链路是通的因为ICMP协议通常是被放行的但并不代表80端口就通了。第二步我在本地用telnet IP 80测试结果连接被拒绝。到了这一步基本可以锁定问题出在安全组而不是Nginx因为如果Nginx没启动通常是connect refused如果是安全组拦截通常表现为超时timeout。我用telnet能看到refused其实说明请求已经穿过了安全组到达了系统层但我之后发现实际上我测试时看到的是timeout这让我重新回到了安全组配置页面。不同云平台的界面术语略有差异有的叫安全组规则有的叫防火墙核心操作都是添加入方向规则。我最终添加了两条规则协议TCP端口22来源0.0.0.0/0SSH管理用协议TCP端口80来源0.0.0.0/0HTTP访问用保存后立刻刷新浏览器页面就出来了。这个从timeout到突然出页面的瞬间确实能把安全组的概念刻进脑子里。这里要特别提醒一个新手常犯的错误不要把来源IP范围缩小到一个过于具体的IP段也不要用0.0.0.0/0以外的写法乱试。有些同学听说要限制来源IP就在安全组里填了/24这种结果自己出门换个Wi-Fi就访问不了了。作业场景下直接用0.0.0.0/0是最稳妥的毕竟你的实例上只有测试页面没什么敏感数据。等你日后上生产环境再来谈最小化授权也不迟。另外操作系统内部的iptables/firewalld也要注意。云平台的安全组是外层门禁系统自带的防火墙是内层门禁两层都要放行。Ubuntu默认没有安装防火墙通常不影响但如果你用CentOS或者自己开了firewalld记得执行systemctl stop firewalld或者把80端口加入zone。我当时为了保险在Ubuntu里执行了ufw allow 80/tcp双重保障避免因为系统内核拒绝而在报告里说不清。安全组还有一个特性是状态性只要出方向是放行的那么从内部发起的连接对应的入方向返回流量会自动放行。这并不是所有网络设备都这样我在排查时一度怀疑是不是出方向规则也要设置后来查了文档才确认云平台的安全组默认是状态性的。这点在写报告时可以作为一个加分项体现出你对网络原理的理解而不是只会配几条规则。4. 环境部署与页面上线从SSH到公网访问的完整走查当网络层面的问题解决后剩下的就是常规操作了。但即便是常规操作我也用作业的标准把每一步重新过了一遍确保不是照着一个模糊的记忆敲命令而是真正知道每条命令在干嘛。第一步是SSH连接。我用的是Windows的PowerShell自带OpenSSH客户端命令很简单ssh root公网IP需要注意的是这个作业的Ubuntu镜像默认登录用户可能是root也可能是ubuntu不同镜像商的习惯不一样。连接后第一件事是修改root密码或者设置密钥登录。由于作业要求快速复现我直接用了密码登录同时设置了复杂度还行的密码。如果你想把报告里的级别拉高一点可以顺手生成一套SSH密钥对把公钥放到~/.ssh/authorized_keys之后禁用密码登录。这一步能明显体现你对安全配置的理解而且后续连接也方便不用每次输密码。第二步是更新系统和安装Nginx。Ubuntu下的操作顺序一般是apt update apt upgrade -y apt install -y nginx其中apt upgrade不是必须但建议做一下。我在实际环境中曾经因为没升级系统而装着老版本的OpenSSL库导致后面某些HTTPS相关的测试失败。虽然作业不需要HTTPS但保持系统最新能避免很多诡异的坑。Nginx装完后可以通过systemctl status nginx确认服务状态是activerunning也可以用curl -I http://localhost在本机测试一下返回200就说明服务起来了。第三步是替换默认页面。默认的Nginx欢迎页其实是可以直接拿来交作业的但我觉得那样没什么区分度。我写了一个简单的HTML页面内容就是陈述这个作业的信息包括作业名称、实例规格、操作系统版本、完成的日期。用echo重定向或者nano编辑都可以核心是让页面内容体现出这台实例的基本信息方便截图验证。我当时的写法是echo htmlbodyh1云计算作业一/h1pUbuntu 22.04 Nginx/p/body/html /var/www/html/index.html这里有个细节要确认你写入的文件路径确实是Nginx的站点根目录。有些镜像的Debian/Ubuntu根目录是/var/www/html但如果你是lnmp一键包或者其他自定义镜像路径可能是/home/wwwroot之类的。我是在VNC里查了/etc/nginx/sites-enabled/default的配置文件才确认的而不是凭经验直接写。这个习惯对新手来说很重要——每台主机可能有不同预设看到配置再动手能少走弯路。第四步是验证公网访问。我在浏览器里输入http://公网IP页面正常渲染。此时我在另一台设备上手机流量也测试了一遍排除本地DNS缓存或者浏览器代理之类的本地干扰。如果这一步通了说明从公网到安全组到Nginx再到文件系统的完整链路都是通的。第五步是记录和备份。为了交作业我把实例上的配置文件、页面文件和操作命令都打包下载了一份cp /etc/nginx/sites-enabled/default ./nginx_default_backup.conf tar czf cloud_homework1_backup.tar.gz /var/www/html /etc/nginx之后如果实例被误删也可以用这份备份恢复。这其实也是云上架构里的一个重要习惯任何有状态的东西都至少有一份额外备份。对于作业来说你至少能保证数据不丢报告内容不空。整个过程最耗时的其实是确认每一步都是当前环境实际验证过的而不是我自以为是的命令。像curl -I localhost、telnet、systemctl这些命令都是我当时顺手执行的验证动作。在写报告时我把每一步的输入与输出都记录了下来甚至包括一条失败的安全组规则和修复过程这反而让报告内容更加丰富也让老师看到你真的在做而不是在走马观花。5. 验收清单与常见坑写给下周要交作业的你如果你明天就要交这个作业这里我直接把最后验收时需要确认的事项列出来。我按照自己的经验整理了一个清单每一项对应一个可能让你扣分的细节可以跟着过一遍公网IP是否固定且绑定成功打开控制台看实例详情确认公网IP地址不为空不要用弹性公网IP过期后自动释放的临时IP否则下次重启就访问不了。安全组是否放行80/443在控制台的安全组规则里检查入方向是否有TCP:80来源为0.0.0.0/0的规则。如果用的是国内云厂商还要注意是否有端口范围写法差异有些控制台写成80/80而非单独80。Web服务是否设置了开机自启执行systemctl enable nginx确保重启实例后服务依然可用。作业验收时老师可能会让你重启实例再试访问这一步没做就直接暴露。页面内容是否不是默认页如果你连欢迎页都没改那整个作业明显没有深入。哪怕改一行字也说明你自己动手操作过。系统时间是否正确云主机默认配置了NTP但如果你改了时区最好用date命令确认一下。报告里的时间戳乱了挺影响观感的。清理无用进程与临时文件把调试时的telnet、wget、临时压缩包清理一下展示一个整洁的系统环境。老师通过SSH登进来看一眼这部分的印象分比你想象中高。截图要包含公网IP和实例ID浏览器截图上不要只显示IP最好把控制台的实例ID、公网IP和Web页面放在同一张截图里证明这个页面确实是那台实例提供的。除了这些我还想讲讲作业过程中比较典型的三个坑这三类问题我至少帮三个同学排查过出镜率特别高。第一个坑是用localhost测试通过就以为公网没问题。很多人在SSH里执行curl http://localhost返回正常然后直接交作业结果外部访问完全不通。原因就是没检查安全组或者根本没绑定公网IP。localhost测试只证明Nginx进程在跑证明不了网络路径。正确做法是必须从另一台设备或至少从实例外部的浏览器访问公网IP来验证。第二个坑是修改Nginx配置时把默认站点文件改坏了。有人为了让页面路径更短直接改/etc/nginx/sites-enabled/default里的listen端口结果忘记加default_server参数重启Nginx后配置测试失败页面直接502。我的建议是新手不要自己去改默认配置就放在系统默认的80端口上页面移到根目录即可。你交作业的目的是展示能跑起来而不是展示我会改配置还改出bug。第三个坑是以为释放实例就万事大吉。作业结束后要用控制台释放或退订实例避免持续扣费。但释放前记得把需要的数据备份到本地因为一旦释放云盘上的所有数据都会被清除不可恢复。如果不确定以后还要不要用可以选择关机而不是释放——关机状态下很多云平台不收计算费用但云盘和公网IP可能还有少量费用。我建议直接做镜像或快照之后关机把成本降到最低的同时保留恢复能力。做完上述检查后我重新从零开始用另一个账号把整个流程完整复跑了一遍确保报告里的每个步骤都能原样重现。这一步特别花时间但确实值得。因为只有当你把一个流程完完整整走通两遍以上才算真正掌握而不是依赖于当时控制台界面上的某次运气。对我而言这个作业虽然叫作业1但它逼着我理解了云主机的本质是计算、存储和网络三者按需组合也第一次真正体会到能ping通不代表能访问这些网络细节的份量。以后再做更复杂的云上项目这些基础就是地基里的一块砖。
