简介这是一份《云计算技术与应用基础》课程教案适合高校云计算相关专业师生、刚入门的从业者及培训讲师备课自学使用。整份资料围绕云计算概述、分类、基础架构与标准化等核心模块编排重点讲解了公有云、私有云与混合云的适用场景引入阿里云助力“爱线下”服务器运维等案例并对比云计算与SOA、分布式计算的差异帮助读者系统建立从概念到应用的完整认知。压缩包共1个PDF文件大小约2.11MB内容涵盖教案头、教学目标、任务案例、教学步骤与作业设计结构清晰方便按章节查阅。目前已有273人学习下载适合作为课堂教学参考或考前复习材料。通过研读这份教案读者可以快速梳理云计算产业链与标准化体系掌握云存储分类及系统结构等知识点为后续深入学习或实际项目实践打下扎实基础。1. 云计算技术与应用基础卡住你的往往是这三块机制“云计算技术与应用基础”这种课程教案内容通常不深但真按它去操作云主机时很多人卡在同一个地方IaaS、PaaS、SaaS 的定义能背一进控制台却不知道实例规格怎么选、对象存储和云硬盘该用哪个、安全组从哪里配起。这套知识真正有用的部分是把计算、存储、网络这三块基础构件块在真实环境里各自跑通再往上面叠容器和运维手段。适合刚接手云资源的开发或运维读也适合准备内部培训的人当提纲。下文不按教案顺序复述概念按一个工程师搭建云实验环境时会执行的顺序走一遍。2. 云基础设施机制计算、存储、网络三块构件怎么选云基础设施机制是云环境的基础构件块最常见的分类只有三种计算、存储、网络。架构书里把它们叫机制控制台里它们就是实例规格、云盘类型和 VPC 配置。这三块选错后面所有应用层方案都会跟着返工。华为云、AWS 这类国内外平台在命名上有差异底层逻辑几乎一致学会一套就能迁移到另一套。2.1 计算机制vCPU、超分与规格选型的判断方法虚拟化层把物理 CPU 核心切成 vCPU 呈现给云主机这里的关键变量是超分比。共享型实例允许超分多个租户竞争同一批物理核独享型实例绑定固定物理核性能更可控但价格更高裸金属服务器则完全去掉虚拟化层把整台物理机交给你。基础教案通常只列价格差异实际选型要看负载是否对延迟敏感。规格类型超分情况适合负载选型注意点共享型超分核间竞争Web 前端、测试、批量计算峰值 CPU 不可控不适合数据库独享型不超分绑定物理核数据库、中间件、交易系统价格约为共享型两倍弹性受限裸金属无虚拟化层特殊驱动、高性能计算恢复和管理成本高拿到一台云主机后怎么确认自己买到的是什么类型在实例内执行lscpu | grep -E Model name|^CPU\(s\)|Thread|Core|Socket virt-what 2/dev/null || echo no virt-whatlscpu输出里的CPU(s)是虚拟机看到的逻辑核数Thread(s) per core、Core(s) per socket和Socket(s)的乘积应该等于它。如果逻辑核数与购买规格明显不符说明平台做了绑核或超分。virt-what能识别底层虚拟化类型输出kvm表示标准虚拟机输出空值则可能是容器或裸金属。选型原则很简单数据库和消息队列一律独享型测试环境用共享型特殊硬件需求才上裸金属。2.2 存储机制对象、块、文件三类接口的适用边界很多人在存储上栽跟头是因为把三种接口当性能差异选实际它们解决的是不同访问语义的问题。块存储云硬盘挂载到实例后要自己格式化行为最接近本地磁盘适合数据库数据盘文件存储以 NFS/CIFS 暴露多个节点可以同时挂载适合大数据集群的共享目录对象存储走 HTTP 协议不用装驱动适合海量小文件、备份归档和静态网站。存储类型访问方式典型场景生命周期块存储挂载并格式化数据库、日志盘随实例或独立文件存储NFS/CIFS 挂载多节点共享、HDFS 临时目录独立对象存储HTTP API备份、静态资源、镜像仓库独立默认多副本本地没有云环境时用 MinIO 模拟对象存储流程可以完全复用mc alias set lab http://127.0.0.1:9000 minioadmin minioadmin mc mb lab/course-backup mc cp ./project.tar.gz lab/course-backup/ mc ls lab/course-backup/alias set是让客户端记住端点地址和密钥后面所有命令都通过这个别名访问mb创建桶bucketcp上传文件ls确认写入结果。对象存储的坑在清理环节教案很少提生命周期规则实际生产里备份堆了三个月账单会比数据本身贵记得为桶配置过期转冷或自动删除策略。2.3 网络机制VPC、子网、安全组的隔离顺序云网络隔离分三层VPC 隔离二层广播域子网规划 IP 网段和路由安全组做有状态的白名单过滤。建一台云主机的正常顺序是先建 VPC再划子网然后配安全组最后绑定弹性 IP。常见错误是只建 VPC 不配安全组或者为了图省事把 22 端口对0.0.0.0/0放开生产上一旦被扫到就是爆破入口。用 OpenStack 命令模拟这套流程各平台控制台的操作顺序完全相同openstack network create --share net-demo openstack subnet create --network net-demo \ --subnet-range 192.168.50.0/24 --gateway 192.168.50.1 \ subnet-demo openstack security group create sg-demo openstack security group rule create --proto tcp --dst-port 22:22 \ --remote-ip 0.0.0.0/0 sg-demo--share让其他项目也能使用这个网络--subnet-range决定实例的内网 IP 池--remote-ip 0.0.0.0/0表示允许所有来源访问 22 端口实验环境可以这样写生产环境应改为运维跳板机的具体 IP。安全组是有状态的允许入站 22 时回程流量自动放行但如果你在入站规则里只放行 ICMP出站又没有匹配规则就会出现 ping 得通但 SSH 连不上的怪问题。这一层做完云主机才算有了基础的三层连通性负载均衡和 NAT 网关都构建在它之上。3. 从 hello docker 到容器上云镜像怎么构建才不返工3.1 容器在云基础设施机制里的位置虚拟机虚拟的是硬件容器虚拟的是操作系统内核的调用接口多个容器共享宿主机内核但彼此拥有独立的文件系统和进程空间。正因如此Docker 成为云计算基础课的标准起点它把依赖打包进镜像解决了“在我机器上能跑”的问题。不少在线实训平台的头歌任务里都有 hello docker开场就是一条docker run hello-world但课程停在那里就废了。真正要掌握的是镜像分层、端口暴露、数据持久化以及怎么控制镜像体积。3.2 最小 Dockerfile五个指令的语义边界一个可运行的最小服务Dockerfile 只需要覆盖五个指令FROM ubuntu:22.04 RUN apt-get update apt-get install -y --no-install-recommends curl ca-certificates COPY app.sh /app.sh RUN chmod x /app.sh EXPOSE 80 ENTRYPOINT [/app.sh]对应的app.sh#!/bin/bash echo cloud lab ready tail -f /dev/nullFROM指定基础镜像它是所有层的祖先RUN在构建期执行每一条会生成一个新的镜像层所以安装包时要加上--no-install-recommends避免塞入无关依赖COPY把本地文件放进镜像EXPOSE只是声明容器内服务监听 80不实际打开端口ENTRYPOINT是容器启动后的主进程。关键区别在RUN和ENTRYPOINT前者在构建时执行后者在运行时执行。主进程一旦退出容器就结束所以示例脚本最后用tail -f挂住进程。构建并运行docker build -t lab/hello-docker:v1 . docker run --rm -p 8080:80 lab/hello-docker:v1 curl -s http://127.0.0.1:8080/-t给镜像打标签--rm让容器退出后自动删除-p 8080:80把宿主机 8080 端口映射到容器 80 端口。curl返回cloud lab ready说明整个链路通了。3.3 端口、数据卷与重启策略docker run 参数速查部署一个稍复杂的服务时参数组合得合理后面运维能省一半事。参数作用使用建议-p 8080:80端口映射公网访问用高端口内部服务只绑内网 IP-v /opt/data:/app/data挂载数据卷让容器无状态日志和数据落在宿主机--restartunless-stopped异常退出自动重启生产环境必须配置--name lab-app容器命名便于docker ps识别--networkhost共享宿主机网络栈性能好但端口冲突要自己管一个完整的启动命令docker run -d --name course-lab \ -p 8080:80 \ -v /opt/data:/app/data \ --restartunless-stopped \ lab/hello-docker:v1-d后台运行-v把宿主机/opt/data挂载到容器/app/data容器删了数据还在。Docker 默认的 bridge 网络会给容器分配独立 IP容器之间通过网桥通信用--networkhost时容器直接使用宿主机 IP适合对延迟敏感或需要固定端口的场景。3.4 镜像瘦身多阶段构建和 .dockerignore基础课上很少有人讲镜像体积但生产环境里上 GB 的镜像拖慢发布漏洞扫描也更慢。多阶段构建是标准解法FROM golang:1.22 AS builder WORKDIR /src COPY main.go . RUN CGO_ENABLED0 go build -o /app FROM alpine:3.20 COPY --frombuilder /app /app ENTRYPOINT [/app]第一阶段用完整的 Go 工具链编译出静态二进制第二阶段只拷贝产物基础镜像从 1GB 级别降到几十 MB。配合.dockerignore排除无用文件.git node_modules *.log这样docker build的上下文体积也小构建速度会明显提升。4. 云计算运维的量化起点云覆盖度计算与告警阈值4.1 云覆盖度计算先算存活率再算覆盖率运维接手一套云环境最先要回答的问题不是“告警怎么配”而是“该管的资源都纳管了吗”。这里有两个容易混淆的指标。存活率是所有采集 target 中up为 1 的比例用 PromQL 一句查出来100 * sum(up{job~node-exporter|blackbox-exporter}) / count(up{job~node-exporter|blackbox-exporter})up是 Prometheus 主动探活指标1 表示抓取成功0 表示失败sum累加存活数量count统计总 target 数两者相除就是存活率。低于 90% 时先别急着加告警把失联的 exporter 找出来恢复再谈阈值。存活率只代表“已经纳管的部分是好的”真正的云覆盖度计算要拿监控 target 和云资源清单做差集。脚本思路如下示例用 AWS CLI其他云平台命令结构一致CLOUD_INSTANCES$(aws ec2 describe-instances \ --query Reservations[].Instances[].InstanceId --output text \ | tr \t \n | sort) MONITORED$(curl -s http://localhost:9090/api/v1/targets \ | jq -r .data.activeTargets[].labels.instance \ | sed s/:[0-9]*$// | sort -u) comm -23 (echo $CLOUD_INSTANCES) (echo $MONITORED)第一行取出云上全部实例 ID第二行从 Prometheus API 拿当前活跃 target 的地址去掉端口第三行用comm -23输出只存在于第一个集合的行也就是完全没纳入监控的实例。实际环境里实例 ID 和 IP 不是一回事需要先做一轮映射但求差集的思路是通用的。覆盖度低于 95% 的云环境告警规则配得再精细都是盲人摸象。4.2 四条基础告警规则与阈值参考监控覆盖度达标后基础告警从存活、CPU、内存、磁盘四条起步。指标告警条件持续时间级别节点存活up 01mcriticalCPU 使用率大于 90%5mwarning内存可用量低于 200MB5mcritical磁盘使用率大于 85%15mwarningPrometheus 规则配置示例groups: - name: cloud-basic.rules rules: - alert: NodeDown expr: up 0 for: 1m labels: severity: critical annotations: summary: {{ $labels.instance }} 探活失败 - alert: DiskUsageHigh expr: (1 - node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100 85 for: 15m labels: severity: warningexpr是触发条件表达式for表示条件持续多久才告警用来抑制瞬时抖动labels.severity决定告警级别annotations.summary里可以用模板变量把具体实例带出来。磁盘使用率阈值不建议设成 90%要留出日志临时写入的空间85% 是大多数团队都能接受的平衡点。4.3 云厂商 CLI 的成本对账与释放策略告警管住了稳定性成本管住了账单。云覆盖度同样适用于资产清理很多账号里躺着几个月没人碰的实例按月扣费。用云厂商 CLI 快速盘点aws ec2 describe-instances \ --query Reservations[].Instances[].[InstanceId,State.Name,InstanceType] \ --output table aws ce get-cost-and-usage \ --time-period Start2024-01-01,End2024-01-31 \ --granularity MONTHLY --metrics UnblendedCost第一条命令列出所有实例及其状态和规格第二条命令拉取当月成本。对账的重点是找出运行中但 CPU 使用率长期低于 5% 的实例先打快照再释放实例快照保留 7 天确认无碍后删除。给这类实例单独配一条低利用率告警能防止同样的问题在下个月卷土重来。5. 把 Hadoop 搭建实验搬到云上最小集群的验证方法5.1 实验环境规划与免密登录课程教案里 Hadoop 搭建如果只给配置文件不给验证步骤作业交上去也学不深。我的建议是直接用三台 2 核 4G 的共享型云主机系统选 Ubuntu 22.04全部放进同一 VPC 子网用主机名 node1、node2、node3 互相解析。Hadoop 集群的启动依赖 SSH 免密登录提前配好能省掉大半排错时间ssh-keygen -t ed25519 -N -f ~/.ssh/id_ed25519 for host in node1 node2 node3; do ssh-copy-id $host done-N 表示生成空口令密钥-f指定密钥路径ssh-copy-id把公钥分发到各节点的authorized_keys。验证是否成功用ssh node1 hostname如果无需密码直接返回主机名说明免密可用。5.2 Hadoop 配置与启动验证最小集群只改两个文件。core-site.xml指定默认文件系统地址configuration property namefs.defaultFS/name valuehdfs://node1:9000/value /property /configurationhdfs-site.xml设置副本数和元数据路径configuration property namedfs.replication/name value2/value /property property namedfs.namenode.name.dir/name value/data/hadoop/name/value /property property namedfs.datanode.data.dir/name value/data/hadoop/data/value /property /configuration启动顺序固定首次启动先格式化 NameNodehdfs namenode -format -force start-dfs.sh jps curl -I http://node1:9870/格式化只能执行一次重复格式化会清空 NameNode 的元数据start-dfs.sh会按 NameNode、DataNode、SecondaryNameNode 的顺序拉起进程jps用来确认各节点上的 Java 进程是否存活最后用curl -I探活 Namenode Web UI返回 200 状态码说明集群的 RPC 和 HTTP 服务都已就绪。看到那个 200再跑一个 wordcount 示例验证数据读写整套云实验环境才算真正闭环之后记得把实验数据和配置打包传到对象存储留档下次重建环境时直接拉下来复用。本文还有配套的精品资源点击获取