“云计算作业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(host="0.0.0.0", port=8000)这里面的关键点在于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] Description=Cloud Assignment App After=network.target [Service] User=app WorkingDirectory=/home/app/cloud-assignment5 EnvironmentFile=/home/app/cloud-assignment5/.env ExecStart=/usr/bin/python3 app.py Restart=always [Install] WantedBy=multi-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-server | 1核2GB, Ubuntu 22.04 | 华东区 | 运行Nginx与Flask应用 | 按量付费 |
| 对象存储 | assignment5-bucket | 标准存储 | 华东区 | 存储用户上传的文件 | 按量付费 |
| 弹性IP | assignment5-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核2GB
- 14:18 完成系统更新，创建app用户
- 14:45 使用pip安装Flask与对象存储SDK
- 15:20 配置Nginx反向代理
- 15:30 首次上传文件成功，记录返回URL
这份年表就是最实打实的过程证明，比任何文字描述都有说服力。
6.3 提前模拟一整套演示场景
我强烈建议在交作业之前，把演示流程完整走三遍以上。流程可以固定在备忘录里：打开演示系统首页、查看Nginx运行状态、查看对象存储桶中已有文件、上传一个新文件、展示返回链接、展示监控面板或账单页面。演练的意义在于你会发现很多第一次没注意到的问题，比如上传文件有大小限制、页面加载速度太慢、浏览器缓存导致页面显示旧版等等。这些问题只要提前碰过一次，演示时就不会手忙脚乱。
说到这，我个人的最大体会是：做这类云计算实践作业，考验的不是用了多高端的服务，而是你有没有把每条链路都理清楚、每个环节都能说出理由。你选择了什么方案、是怎么实现的、遇到问题时怎么定位的，这些过程的完整度，往往比最终那个“能跑的网站”本身更能反映真实能力。如果你现在正准备动手，建议先花一晚上把题目要求和验收标准彻底搞明白，再开资源。等所有服务都跑通了，把每一步记录整理成报告，这份作业就算真正做扎实了。
