“云计算作业5”这类标题但凡经历过云平台课程实践的人一眼就能看懂它不是一道理论题而是一次完整的动手折腾。前几次作业可能还在教你怎么开通云主机、配置环境、写脚本到了“作业5”这个阶段通常就是要求你把前面学的东西串起来跑通一个尽量贴近真实业务的小系统。我见过不少同学在这一步栽跟头倒不是技术多难而是根本不知道“作业5”到底要交什么、按什么标准评。这篇内容就按最常见的一类作业——基于云主机部署Web应用并接入对象存储实现文件上传——来完整拆解从读题、选型到实操、排错和报告交付都会覆盖适合正在赶作业、或者第一次独立操作云平台的同学参考。1. 动手之前先把作业题读懂作业5的真实考点清单1.1 “作业5”到底想考你什么看标题只有“云计算作业5”几个字但课程作业编号背后往往藏着一条清晰的递进逻辑。第一、二次作业通常是熟悉界面、开通资源第三、四次可能涉及脚本、数据库或网络配置到了第五次基本就是综合实践。它不再只问你“什么是对象存储”而是要求你“把对象存储用起来”。所以这个阶段的核心考点就三个资源开通与配置能力、应用与云服务的整合能力、结果的可验证与可展示能力。很多同学拿到题目第一反应是追求“大而全”非要把高可用负载均衡、弹性伸缩、容器编排全部塞进去。这其实是误区。第五次作业的评分重点一般在“链路是否完整、过程是否有记录、结果是否可验证”而不是架构复杂度。我见过有人用三台云主机搭了集群结果报告里讲不清每个节点的作用最后分数反而不如一台机器跑通全链路、文档写得清晰的同学。先理解考点再分配精力这是做作业的第一原则。有个更实际的问题如果题目描述非常模糊只写了“完成云计算作业5”或者“实现一个云端应用”怎么办。这时候要主动限定范围。我常用的做法是把题目拆成“计算存储网络结果验证”四个维度如果题目没指定具体形态就选最简单但能覆盖这四个维度的方案——一台云主机、一个对象存储桶、一个带上传功能的小站点外加一份完整的验证记录。这个组合既能展示你对核心云服务的理解又不会把自己拖进过度设计的泥潭。1.2 需求澄清清单别把力气用错地方正式动手之前花半小时把需求彻底搞清楚能省后面一整天的返工。我建议你用一张自检清单来推进下面这几项基本是通用检查项作业的目标形态是什么要求交付一个公网可访问的URL还是仅要求本地可访问这决定你需不需要绑定域名、放通安全组规则。是否需要数据持久化如果应用有上传、注册这类功能文件和数据必须存到对象存储或云数据库里只放在云主机本地磁盘很可能不符合要求。是否需要高可用大多数第五次作业不强制做集群但如果题目明确写了“负载均衡”或“弹性伸缩”那就要另外规划。有没有预算限制学生账号通常有代金券或试用额度超出部分要自己承担。资源规格不是越大越好。报告要求是什么有些作业要提交代码有些只要报告加截图有些还要现场演示。把交付物清单列出来按它倒推工作项。我把这些检查项整理成过一个表格做任何一个云端实践作业都可以直接套用检查项默认假设如果题目不同怎么办目标形态公网可访问的Web站点本地返回受限公网IP存储方式对象存储存文件 云数据库或文件存配置题目要求自建数据库再调整资源数量1台云主机 1个对象存储桶需要高可用再增加节点预算上限尽可能使用代金券和免费额度做好账单监控交付物代码包 部署说明 演示截图/录像按课程要求增减提示做需求澄清不是“偷懒少做”而是把题目隐含的评价标准挖出来。宁可前半小时多问自己几个“题目到底要我证明什么”也不要做完才发现方向偏了。2. 方案选型怎么用最低成本搭出一套能演示的云应用2.1 计算资源与存储搭配一台主机加一个存储桶就够了方案选型是动手前最值得花时间的决策环节。大多数第五次作业需要的计算资源非常有限——你不是在生产环境支撑百万用户而是演示一个功能闭环。拿最常见场景来说一台1核2GB内存的云主机完全够用操作系统选Linux发行版通常是主流的CentOS或Ubuntu系列带宽按按量付费或者选择1Mbps左右的固定带宽就行。为什么不是2核4GB因为对于单机部署的小应用1核2GB跑Nginx加一个后端进程绰绰有余升配置只会拉高成本没有任何评分收益。但有一个地方不能省就是存储。作业里如果涉及文件上传功能文件必须落到对象存储里而不是直接写进云主机的系统盘。原因有两层第一层对象存储本来就是独立的云服务它在报告里是一个可以单独描述的组成部分能显著体现你对云服务的理解第二层云主机磁盘空间有限而且容量规划麻烦一旦实例被重置数据就丢了。对象存储的桶存储容量按量计算试用期里往往有几GB的免费额度对一个演示应用来说完全够用。选择对象存储服务时有几个细节要注意。首先是区域桶的区域必须和云主机所在区域一致或者至少网络延迟可以接受否则跨区域访问会产生额外流量费用和延迟。其次是桶的访问权限我建议全程使用“私有读写”加“临时签名URL”的方式不要图省事把桶设成公有读否则文件等于裸奔在公网上作业报告里这样写也很难看。最后是存储类型标准存储就够低频、归档这些是为冷数据设计的作业场景用不上还可能有最短存储时长限制。2.2 网络规划与安全组开放最小化端口网络配置是作业里最容易丢分、也最容易出bug的环节。云平台的安全组本质上就是一台虚拟防火墙它控制哪些端口能从外面访问你的实例。部署Web应用时最常见的错误是把安全组端口全部放通或者干脆选了“放通所有端口”模板结果不仅作业演示时暴露一堆无关端口还把安全分丢了。正确的做法是遵循最小权限原则按下面的列表放端口。22端口SSH登录用建议限定来源IP为你的校园网或家用宽带IP不要对全网段开放。80端口HTTP访问用放通来源为全网段因为老师、助教可能从任意网络访问你的演示地址。443端口如果配了HTTPS证书才需要放通作业演示通常用HTTP就够了可以不开。后端服务端口比如8080只允许在你本机或内网访问不要暴露到公网。演示时用80端口做反向代理转发。这些规则听着繁琐但实操起来就是控制台里几个点击。我自己的习惯是先把安全组配好再开通云主机因为实例创建时默认绑定的安全组如果太宽松后面还要回头改。另外Linux实例内部一般都自带防火墙比如firewalld或ufw安全组放通了不代表系统防火墙也放通了。查问题时记得两头都要看否则会因为“安全组明明开了80浏览器却打不开”而卡半天。3. 完整实操记录从开通云主机到跑通Web应用3.1 环境初始化新实例到手后先做这几件事新开通的云主机实际上是一张白纸很多人上来就装环境结果后面碰到各种奇怪的路径问题。我建议按照下面的顺序做环境准备每一步都有对应目的更新系统软件包。在Ubuntu上用apt update apt upgrade -y在CentOS上用yum update -y。这一步是为了避免安装软件时碰到过旧的依赖源。创建专用用户。别用root跑业务服务创建一个叫app的普通用户后面应用全用它来跑。这不是形式主义而是防止权限过大造成误操作。安装必要的运行环境。以最常见的Python Flask应用为例需要安装python3、pip3、nginx以及对象存储的官方SDK通常用pip安装。配置系统防火墙。把不需要的端口挡在门外只留22、80等必要端口。具体是ufw allow 22 ufw allow 80再ufw enable。设置主机名和时区。把主机名改成和作业相关的标识性名称比如cloud-assignment5时区设成国内时区便于记录日志时间。做完环境初始化最好在本地终端里敲一下history把操作记录导出保存或者直接用日志审计功能记录操作。作业报告需要过程记录时这一份操作历史就是最有说服力的素材。我记得有同学因为没存操作日志写报告时全靠回忆很多参数都记不清了最后只能重新做一遍补齐截图白白多花两小时。3.2 部署一个带上传功能的Web应用并接入对象存储选应用框架时我不建议用过于复杂的架构。一个简单的Flask应用就能讲清楚整个链路页面提供文件选择框提交后后端接收文件上传到对象存储返回文件的访问地址。这个功能虽然简单但完整覆盖了“Web服务对象存储结果展示”三个核心环节正好对应作业考点。下面是我实际测试过能跑通的Flask示例代码骨架你可以在本地写好后上传到云主机或者直接在云主机上用命令行创建。import os from flask import Flask, render_template, request from cloud_storage import CloudStorageClient app Flask(__name__) # 初始化对象存储客户端 # 这些配置建议从环境变量读取不要硬编码在代码里 endpoint os.environ.get(CLOUD_STORAGE_ENDPOINT) bucket os.environ.get(CLOUD_STORAGE_BUCKET) storage_client CloudStorageClient(endpoint, bucket) app.route(/, methods[GET]) def index(): return render_template(upload.html) app.route(/upload, methods[POST]) def upload(): file request.files.get(file) if not file: return 未选择文件, 400 # 上传到对象存储这里返回的 file_url 就是可访问的链接 file_url storage_client.upload(file.filename, file.read()) return f上传成功访问地址a href{file_url}{file_url}/a if __name__ __main__: app.run(host0.0.0.0, port8000)这里面的关键点在于CloudStorageClient的实现。不同的云平台SDK名称和调用方式不太一样但逻辑都差不多创建客户端时传入endpoint、访问密钥和桶名然后调用上传接口。我建议你用官方SDK因为SDK封装好了签名、重试这些细节比你自己写HTTP请求调用存储API要稳得多。密钥管理这里必须单独强调访问密钥是明文敏感信息不要写在代码里也不要提交到代码仓库。正确做法是设置成环境变量或者使用云平台的密钥管理功能报告中如果截到了密钥内容记得打码处理。部署应用时还有几个小细节。云主机上的安全组只放通了80端口而后端Flask运行在8000端口因此需要配置Nginx把80端口的请求反向代理到8000端口。反向代理配置核心就三行server { listen 80; server_name _; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; } }配置好后要记得nginx -t检查语法再systemctl reload nginx重载配置。这一步做完你访问云主机公网IP就能看到上传页面整个应用才算真正对外服务。3.3 功能验证与结果记录应用跑起来之后验证环节直接决定你的作业能得多少分。分三个层级来做本机验证、公网验证、内容验证。本机验证是在云主机上用curl -I http://localhost检查HTTP响应是否200公网验证是在你本地电脑浏览器访问http://云主机公网IP确认页面能打开内容验证是实际传一个文件上去确认文件出现在对象存储桶中并且能通过返回的链接访问。我特别建议把验证过程做成一份标准操作手册包含以下记录项验证时间点执行的操作命令观察到的返回结果截图或文本日志存档比如用curl测试时可以记录下类似HTTP/1.1 200 OK的字样并按时间顺序保存。压测环节如果你觉得有必要可以用ab -n 100 -c 10 http://IP/做一次简单并发测试记录吞吐量和响应时间。虽然不是强制要求但报告里放上压测结果能明显提升专业感。4. 踩坑现场最容易翻车的五个地方与修复方法4.1 外网访问不通安全组ACL、Windows防火墙还是实例防火墙“外网打不开页面”是最常见、也最让人头疼的问题。按照排查顺序逐步排查先确认实例有公网IP。有些云平台创建实例时如果没选“分配公网IP”实例就只有内网IP外网当然访问不到。再查云平台安全组是否放通80端口。在安全组规则列表里看入方向有没有允许TCP 80的来源。然后查实例系统防火墙状态。执行命令systemctl status ufw或systemctl status firewalld看防火墙有没有拦截。最后查Nginx是否在监听80端口。ss -lntp | grep :80一行命令就能看清端口状态。这四步走完90%的“打不开”都能定位。需要特别注意的是云平台安全组和实例防火墙是两级不同机制很多人只查其中一级结果来回折腾还查不出原因。4.2 文件上传失败存储桶命名、区域和签名问题上传文件报错是另一个高频翻车点。NoSuchBucket错误通常是因为存储桶名称不唯一或名字不符合规范云平台要求桶名全局唯一把桶名改成带特定前缀的标识再试一次。SignatureDoesNotMatch错误基本是密钥配错了或者签名算法和端点不匹配重新检查环境变量里密钥有没有多复制空格。AccessDenied错误多半是桶权限设成了“私有读写”但你却用公网地址直接访问去换成签名URL或临时凭证。我见过一个特容易忽略的点桶的区域和云主机的区域不一致导致SDK默认访问了错误区域的端点上传操作超时。所以创建桶的时候就要规划好区域保证计算和存储在同一个地域SDK配置里填的endpoint也要和桶所在区域严格一致。4.3 演示现场突然服务不可用资源欠费与进程崩溃作业演示最怕的是什么前面测试一切正常轮到给老师演示时页面打不开。原因通常是两类一类是云资源欠费被停机另一类是进程意外退出。第一类问题只能靠预算管理解决。很多云平台提供“费用预警”功能设置一个较低额度比如10元的告警超支立刻收到通知。另外作业完成后记得释放不再用的实例和弹性IP尤其要注意有些平台弹性IP单独计费即使实例关机也在产生费用。第二类问题要用守护进程来解决。Flask应用单独用python app.py跑的话SSH断开进程也可能被终止。推荐用systemd创建一个service文件把应用托管起来这样进程崩溃后会自动重启不会出现演示现场“服务挂了”的尴尬。配置内容大致如下[Unit] DescriptionCloud Assignment App Afternetwork.target [Service] Userapp WorkingDirectory/home/app/cloud-assignment5 EnvironmentFile/home/app/cloud-assignment5/.env ExecStart/usr/bin/python3 app.py Restartalways [Install] WantedBymulti-user.target配置好之后执行systemctl daemon-reload systemctl enable --now cloud-assignment5应用就变成后台托管服务了。4.4 报告里字段对不上记录缺失的补救办法等到写报告时才想起很多参数没记录是一件非常被动的事。但如果你真的已经漏了补救办法是有的。第一登录云平台控制台查看资源列表上面有每一个实例、存储桶的创建时间、规格、计费方式这些是系统审计记录可以直接作为报告素材。第二检查命令行历史记录在云主机上执行history可以找回之前敲过的命令虽然少了输出结果但至少能证明你做过这些操作。第三如果应用代码里打了日志比如loguru配置的输出文件查日志文件可以还原很多操作节点。这里我特别想强调代码里的日志规范。很多同学写Flask只有print一旦用systemd托管print内容会被吸收根本看不到。建议直接用Python的logging模块输出到文件每个请求记录时间、IP、操作类型和结果状态这样不仅报告素材有了排查问题也方便得多。5. 交付与汇报作业不只是“能跑”就行了5.1 报告结构用验收顺序反向搭建文档框架写报告是很多人的薄弱环节明明功能都实现了报告却写得像流水账。我总结了一个有效写法站在打分者的角度按照“你交了什么、拆成了几部分、怎么验证”来组织。报告里最重要的是三件事——整体架构说明、资源清单表、验证过程记录。资源清单表是报告里最有含金量的一张表它直接证明你对自己的云资源了如指掌。按这个模板来填就行资源类型资源名称规格/配置区域作用计费方式云主机assignment5-server1核2GB, Ubuntu 22.04华东区运行Nginx与Flask应用按量付费对象存储assignment5-bucket标准存储华东区存储用户上传的文件按量付费弹性IPassignment5-eip按带宽计费1Mbps华东区对外提供公网访问入口按量付费验证过程建议配截图但不要只放截图不解释。每张截图下面加两行文字一行写“做了什么操作”一行写“看到什么结果”。比如上传文件成功后截图对象存储控制台里出现了新文件下面标注说明“文件已成功上传至指定存储桶大小约xx KB”这样的记录比一堆截图拼在一起更清晰。5.2 演示时的节奏先讲链路再做实验最后留出问答缓冲如果作业需要现场演示演示节奏直接影响老师对作业的直观印象。我推荐的演示流程是三段式先对着架构图讲整体链路——“用户通过浏览器访问云主机云主机上的Nginx反向代理到Flask应用Flask上传文件到对象存储”再实操演示——“我现在上传一张测试图片上传成功后我们到存储桶里去确认”最后展示验证记录——“这份压测报告显示并发10个请求时平均响应xx毫秒无错误返回”。演示前务必做好三件事第一提前一天检查实例余额和服务状态万一实战前一晚欠费停机就只能眼睁睁看着演示失败第二备好恢复方案把systemd restart命令提前写在演示备忘录里万一页面打不开至少能快速重启服务再试一次第三把代码仓库或代码压缩包准备好有些老师看完演示会直接索要代码当场能给出完整代码会加很多印象分。还有一个容易被忽略的细节答辩环节老师通常问“为什么选这个方案”“有没有考虑过另一种实现”。所以做报告时提前准备两张对比表一张是“软件选型对比”比如Flask对比Node.js、Nginx对比Tomcat另一张是“服务方案对比”比如对象存储对比自建MinIO、单机对比负载均衡集群。这会让老师认为你是经过思考后做的决策而不只是在网上抄了一套配置。6. 写报告时的三个实用小技巧6.1 用表格代替大段文字云平台操作类作业的报告最忌讳的就是一整页“我点击了xxx然后又点击了xxx”的描述。老师看这种内容既累又抓不住重点。我的建议是操作步骤用编号列表参数配置用表格结果验证用截图加说明。比如安全组规则一张表就能说明白哪几个端口被放通、来源IP是什么、作用是什么远比十行文字更直观。6.2 保留关键操作日志作为附录报告主体控制在十页以内剩余的过程记录放进附录。怎么整理附录把终端操作历史导出后过滤掉无关命令按时间顺序做成年表标注重要操作节点。例如14:02 开通云主机实例 assignment5-server配置1核2GB14:18 完成系统更新创建app用户14:45 使用pip安装Flask与对象存储SDK15:20 配置Nginx反向代理15:30 首次上传文件成功记录返回URL这份年表就是最实打实的过程证明比任何文字描述都有说服力。6.3 提前模拟一整套演示场景我强烈建议在交作业之前把演示流程完整走三遍以上。流程可以固定在备忘录里打开演示系统首页、查看Nginx运行状态、查看对象存储桶中已有文件、上传一个新文件、展示返回链接、展示监控面板或账单页面。演练的意义在于你会发现很多第一次没注意到的问题比如上传文件有大小限制、页面加载速度太慢、浏览器缓存导致页面显示旧版等等。这些问题只要提前碰过一次演示时就不会手忙脚乱。说到这我个人的最大体会是做这类云计算实践作业考验的不是用了多高端的服务而是你有没有把每条链路都理清楚、每个环节都能说出理由。你选择了什么方案、是怎么实现的、遇到问题时怎么定位的这些过程的完整度往往比最终那个“能跑的网站”本身更能反映真实能力。如果你现在正准备动手建议先花一晚上把题目要求和验收标准彻底搞明白再开资源。等所有服务都跑通了把每一步记录整理成报告这份作业就算真正做扎实了。