公有云服务架构与运维（基于阿里云）（微课版）教案汇 12自动伸缩(ESS)实战 - 22综合练习：企业级云架构方案设计

教师备课纸教师备课纸课题自动伸缩(ESS)实战课型理实一体授课班级授课时数2教学目标1.知识目标：•理解弹性伸缩（ESS）的核心价值：根据业务负载自动调整计算资源。•掌握ESS的核心组件：伸缩组、伸缩配置、伸缩规则（动态/定时）。2.抭能目标：•能创建一个ESS伸缩组，并关联包含应用环境的启动模板。•能配置基于CPU使用率的动态伸缩规则，实现自动扩缩容。•能通过模拟高负载，验证ECS实例的自动增加与释放过程。3.素质目标：•树立“自动化运维”理念，认同通过策略而非人工干预来应对业务波动。•强化“成本优化”意识，理解弹性伸缩是应对流量洪峰、避免资源浪费的有效手段。教学重点•ESS伸缩组的创建与伸缩配置（关联启动模板）。•基于云监控指标（CPU）的动态伸缩规则配置。教学难点•理解伸缩组、伸缩配置、伸缩规则三者之间的逻辑关系。•理解“冷却时间”的作用，避免因指标抖动导致频繁的扩缩容操作。学情分析学生对“自动扩容”概念感到新奇，但对监控指标、阈值设定等抽象概念理解较慢；容易混淆“告警”和“自动伸缩”是两个独立但可联动的功能。教学需用生活化类比（如恒温空调）并进行直观的压力测试演示。教学效果•学生成功创建了名为WebApp-AutoScaling的伸缩组，并关联了包含LNMP环境的启动模板。•学生配置了动态伸缩规则：当CPU平均值>70%持续5分钟时，增加1台ECS；当CPU平均值<30%持续10分钟时，减少1台ECS。•学生通过在ECS上运行stress-ng命令制造CPU压力，观察到新ECS实例被自动创建。教后记通过现场演示stress-ng--cpu2命令制造CPU压力，让学生亲眼看到新ECS实例被自动创建，极大地增强了教学的直观性和说服力；“智能空调”的类比非常成功。主要不足是部分学生在创建启动模板时，未将应用代码固化，导致新扩容的机器是“空”的。下次课需在实训步骤中强调此关键点。一、情境导入与任务驱动（10分钟）痛点回顾：我们的博客平时很安静，但万一明天一篇爆款文章带来10倍流量，单台ECS会立刻被压垮。如果提前多开几台，平时又白白浪费钱。引出ESS：弹性伸缩ESS（ElasticScalingService）就像一个“智能空调”，当业务“热”（CPU高）时自动加机器，当业务“冷”（CPU低）时自动减机器，完美平衡性能与成本！明确任务：今天我们将为博客装上这个“智能空调”，让它能从容应对流量的潮起潮落。二、核心概念精讲（20分钟）ESS工作原理：伸缩组：管理一组具有相同应用的ECS实例的逻辑集合。定义了最小/最大实例数。伸缩配置：定义新加入伸缩组的ECS实例的规格、镜像、安全组等（通常关联一个启动模板）。伸缩规则：定义“何时”以及“如何”扩缩容（如：+1台，-1台）。触发任务：动态任务：由云监控报警触发（如CPU过高）。定时任务：在预设时间点执行（如每天上午9点扩容）。冷却时间：一次伸缩活动完成后，一段时间内不再执行新的伸缩活动，防止抖动。关键前提：必须有一个包含完整应用环境（如LNMP+WordPress）的启动模板。三、技能实训（50分钟）任务：为博客配置“智能空调”准备启动模板（10分钟）：确认：确保已有一个包含LNMP环境的ECS实例。创建模板：从该ECS创建一个启动模板，命名为LNMP-Base-Template。创建伸缩组与配置（20分钟）：创建伸缩组：名称：WebApp-AutoScaling地域/VPC：与现有资源一致。最小实例数：1最大实例数：3关联启动模板：选择刚创建的LNMP-Base-Template。配置动态伸缩规则（20分钟）：创建“扩容”规则：规则名称：Scale-Out-CPU-High调整方式：增加1台创建“缩容”规则：规则名称：Scale-In-CPU-Low调整方式：减少1台创建报警任务：扩容任务：监控项CPU使用率，阈值平均值>=70%，连续周期5。缩容任务：监控项CPU使用率，阈值平均值<=30%，连续周期10。关联规则：分别关联到上面创建的扩容和缩容规则。四、总结评价与拓展延伸（10分钟）成果验收：检查学生伸缩组是否创建成功，启动模板是否关联正确。抽查学生的动态伸缩规则和报警任务配置是否准确。提问：为什么缩容的连续周期（10分钟）要比扩容（5分钟）长？知识梳理：伸缩组=容器：规定了实例数量的上下限。伸缩配置=蓝图：定义了新实例长什么样。伸缩规则=指令：告诉系统是加还是减。报警任务=触发器：根据监控数据决定何时执行指令。作业布置：思考题：我们目前的伸缩策略只基于CPU。如果应用是I/O密集型（如数据库），应该监控哪个指标来触发伸缩？预习任务：阅读教材关于容器服务ACK的内容，思考微服务架构下的弹性伸缩是如何实现的。课题容器服务ACK初探与集群搭建课型理实一体授课班级授课时数2教学目标1.知识目标：•了解Docker容器和Kubernetes（K8s）的核心概念及其价值。•掌握阿里云ACK托管版集群的基本架构（Master/Worker节点）。2.技能目标：•能在阿里云控制台创建一个托管版ACK集群。•能为集群配置包含ECS实例的节点池。•能在本地计算机安装并配置kubectl工具，成功连接到ACK集群。3.素质目标：•初步建立云原生技术认知，理解容器化是现代应用部署的趋势。•培养对新兴技术的好奇心和探索精神。教学重点•托管版ACK集群的创建流程与关键参数。•节点池的配置（实例规格、数量、操作系统）。•kubectl工具的安装与集群连接验证。教学难点•理解KubernetesMaster节点（控制平面）与Worker节点（工作负载）的职责分离。•在本地环境中正确配置kubeconfig文件以连接远程集群。学情分析学生首次接触容器和K8s概念，普遍感到抽象和陌生。对“集群”、“节点池”等术语缺乏直观感受。教学需避免深入技术细节，聚焦于“是什么”和“怎么用”，并通过图形化界面操作降低入门门槛。教学效果•学生成功创建了一个名为my-first-ack-cluster的托管版ACK集群。•学生为集群配置了一个包含2台ecs.g7.large实例的节点池。•学生在本地（或通过CloudShell）成功安装kubectl，并执行kubectlgetnodes命令查看到集群中的节点列表。教后记作为云原生的入门课，学生表现出强烈的好奇心。通过创建真实集群并看到kubectlgetnodes的输出，有效建立了对K8s的初步感性认识。主要挑战在于本地kubectl环境配置，部分学生遇到权限或路径问题。下次可主推使用CloudShell，确保所有学生都能顺利完成连接验证。一、情境导入与任务驱动（10分钟）应用部署演进：从物理机→虚拟机（ECS）→容器（Docker）。容器像“标准化的集装箱”，让应用打包、分发、运行更高效、更一致。引出K8s与ACK：当有成百上千个容器需要管理时，就需要一个“船长”——Kubernetes（K8s）。阿里云ACK（AlibabaCloudContainerServiceforKubernetes）就是托管版的K8s服务，省去了自己搭建和维护K8s集群的复杂性。明确任务：今天我们将迈出云原生的第一步——亲手创建我们的第一个ACK集群！二、核心概念精讲（20分钟）Docker与K8s速览：Docker：将应用及其依赖打包成一个轻量、可移植的镜像，运行时成为容器。Kubernetes(K8s)：一个开源的容器编排平台，用于自动化容器的部署、扩缩容和管理。ACK托管版架构：Master节点（控制平面）：由阿里云全托管，负责集群的全局管理和调度（如APIServer,etcd,Scheduler）。用户无需关心。Worker节点（工作节点）：用户购买的ECS实例，实际运行容器化应用。我们通过节点池来管理这些ECS。核心优势：免运维：Master节点完全托管，开箱即用。无缝集成：与VPC、SLB、NAS等阿里云产品深度集成。三、技能实训（50分钟）任务：创建我的第一个ACK集群创建ACK集群（25分钟）：进入ACK控制台→“集群”→“创建集群”。选择模板：标准托管集群。关键配置：集群名称：my-first-ack-cluster地域/可用区：与之前VPC一致（如华东1）。VPC：选择已有的My-Enterprise-VPC。公网访问：勾选“使用EIP暴露APIServer”（便于本地连接）。其他选项：保持默认。配置节点池（15分钟）：在集群创建向导中，进入“节点池配置”。创建节点池：实例规格：ecs.g7.large(2核8G)系统盘：ESSD云盘40GB数量：2操作系统：AlibabaCloudLinux3.2104登录方式：设置SSH密钥或密码。连接集群（10分钟）：获取凭证：集群创建完成后，在详情页点击“连接信息”→“公网接入”→“KubeConfig”，复制内容。配置kubectl：方法一（推荐）：使用阿里云CloudShell（控制台右上角），它已预装kubectl，直接粘贴KubeConfig即可。方法二（本地）：在本地电脑安装kubectl，并将KubeConfig内容保存到~/.kube/config文件。验证连接：kubectlgetnodes#应看到两个Worker节点的状态为Ready四、总结评价与拓展延伸（10分钟）成果验收：检查学生ACK集群是否创建成功。验证学生能否通过kubectlgetnodes命令看到Ready状态的节点。知识梳理：ACK=托管的K8s：Master免运维，专注业务。节点池=Worker集群：运行容器的计算资源池。kubectl=集群遥控器：管理集群的命令行工具。作业布置：思考题：为什么ACK要将Master节点和Worker节点分开？这样做有什么好处？预习任务：阅读教材关于Pod和Deployment的内容，思考如何将一个简单的Nginx应用部署到我们刚创建的ACK集群中。课题容器应用部署与服务暴露课型理实一体授课班级授课时数2教学目标1.知识目标：•理解Kubernetes核心对象Deployment、Service、Ingress的作用及相互关系。•掌握容器镜像仓库（ACR）的基本概念。2.技能目标：•能将WordPress应用镜像推送到阿里云容器镜像服务（ACR）。•能在ACK集群中通过YAML文件创建Deployment和Service来部署WordPress。•能配置Ingress规则，将应用通过自定义域名（或测试域名）对外提供HTTP访问。3.素质目标：•培养声明式API的运维思维，理解通过YAML文件定义应用状态。•强化对云原生应用网络模型的理解。教学重点•在ACK中通过Deployment部署WordPress应用。•配置Ingress实现应用的外部HTTP访问。教学难点•理解Service（ClusterIP）与Ingress的层级关系：Ingress将外部流量路由到Service，Service再负载均衡到Pod。•编写和理解基本的Deployment、Service、Ingress的YAML配置文件。学情分析学生已成功创建ACK集群，但对K8s的核心对象（Pod,Deployment等）和YAML配置方式非常陌生，容易产生畏难情绪。教学需提供完整的、经过验证的YAML模板，并解释关键字段，避免学生陷入语法细节。教学效果•学生成功将wordpress:latest镜像推送至自己的ACR实例。•学生在ACK集群中成功创建了WordPress的Deployment和关联的Service。•学生配置了Ingress规则，并能通过Ingress的公网IP地址访问到WordPress初始化页面。教后记一、情境导入与任务驱动（10分钟）回顾与提问：我们有了ACK集群（船），也有了容器镜像（货物），如何把货物装上船并让外面的人能访问到？引出核心对象：Deployment：负责“装货”和“管货”，确保指定数量的Pod（集装箱）始终在运行。Service：集群内部的“服务发现与负载均衡”，为一组Pod提供稳定的内部访问入口。Ingress：集群的“统一入口网关”，负责将外部HTTP/HTTPS流量路由到内部的Service。明确任务：今天我们将把WordPress这个“货物”部署到我们的“船”（ACK）上，并通过“Ingress大门”让全世界都能访问它！二、核心概念精讲（20分钟）K8s对象关系图：[用户]↓(HTTP请求)[IngressController]←(Ingress规则:host/path->Service)↓[Service(ClusterIP)]←(Selector匹配Pod标签)↓(负载均衡)[Pod-1][Pod-2]...(由Deployment管理)关键组件详解：Deployment：声明应用的期望状态（如：3个副本）。K8s会自动创建和管理Pod，并在Pod故障时进行自愈。Service：为动态变化的Pod提供一个不变的虚拟IP（ClusterIP）和DNS名称，供集群内部其他服务调用。Ingress：一个API对象，定义了如何将外部流量路由到集群内的Service。需要一个IngressController（如NginxIngress）来实现。三、技能实训（50分钟）任务：在ACK上部署可公网访问的WordPress准备镜像（15分钟）：创建ACR实例：进入容器镜像服务ACR控制台，创建一个个人版实例。推送镜像（使用CloudShell）：#登录ACRdockerlogin--username=<your-uid><acr-instance>.#拉取官方镜像dockerpullwordpress:latest#重命名镜像dockertagwordpress:latest<acr-instance>./<namespace>/wordpress:latest#推送dockerpush<acr-instance>./<namespace>/wordpress:latest部署WordPress（20分钟）：准备YAML：教师提供wordpress-deployment.yaml和wordpress-service.yaml模板。Deployment：指定从ACR拉取的镜像，设置副本数为1。Service：类型为ClusterIP，暴露端口80。应用YAML：kubectlapply-fwordpress-deployment.yamlkubectlapply-fwordpress-service.yamlkubectlgetpods,svc#验证Pod和Service状态配置Ingress（15分钟）：安装IngressController（若未预装）：通过ACK控制台“组件管理”一键安装nginx-ingress-controller。准备IngressYAML：教师提供wordpress-ingress.yaml模板。host字段可留空（使用通配符）或填写一个测试域名。backend指向刚创建的wordpress-service。应用并验证：kubectlapply-fwordpress-ingress.yamlkubectlgetingress#获取Ingress的EXTERNAL-IP#在浏览器中访问http://<EXTERNAL-IP>，应看到WordPress初始化页面四、总结评价与拓展延伸（10分钟）成果验收：检查学生ACR中是否存在WordPress镜像。验证学生能否通过kubectlgetpods看到Running状态的WordPressPod。最终验证：学生能否通过Ingress的公网IP访问到WordPress。知识梳理：Deployment管应用实例。Service提供内部稳定访问。Ingress打开外部访问大门。作业布置：思考题：目前我们的WordPress数据是存储在Pod内的，如果Pod被删除，数据会丢失。如何利用之前学过的NAS或云盘，为WordPress提供持久化存储？预习任务：阅读教材关于Helm包管理器的内容，思考如何简化WordPress这种复杂应用的部署流程。课题容器弹性伸缩与微服务治理课型理实一体授课班级授课时数2教学目标1.知识目标：•了解Kubernetes弹性伸缩机制：HPA（基于CPU/内存）和VPA（垂直伸缩）。•理解服务发现是微服务架构通信的基础。2.技能目标：•能为已部署的Deployment配置HPA（水平Pod自动伸缩）策略。•能使用压测工具模拟高负载，验证Pod的自动扩容与缩容效果。•能为Ingress配置基于路径（Path）的流量转发规则，实现多服务路由。3.素质目标：•深化对云原生应用“自愈”与“弹性”特性的理解。•初步建立微服务架构下流量管理的意识。教学重点•HPA策略的创建与配置（基于CPU指标）。•使用压测工具验证HPA的自动扩缩容效果。教学难点•理解HPA的工作原理及其对应用无状态性的要求。•编写和应用包含多路径规则的IngressYAML文件。学情分析学生已掌握基本的容器部署，但对“弹性”和“微服务治理”等进阶概念较为陌生。压测环节可能因工具不熟而受阻。教学需提供简单易用的压测命令，并强调应用必须是无状态的才能使用HPA。教学效果•学生成功为WordPressDeployment配置了HPA策略（CPU>50%时扩容）。•学生通过hey或ab工具对应用进行压测，观察到Pod数量从1个自动增加到3个。•学生配置了Ingress规则，能将/blog路径的请求转发到WordPress服务。教后记通过实时压测观察Pod数量动态变化，给学生留下了深刻印象，有效诠释了“弹性”的价值。主要问题是部分学生未在Deployment中预先设置CPUrequests，导致HPA无法工作。下次实训前需增加一个检查清单，确保所有前置条件都已满足。一、情境导入与任务驱动（10分钟）场景设问：我们的容器化WordPress很酷，但如果突然有大量用户访问，单个Pod会不会被压垮？能否像ECS一样自动加机器？引出容器弹性：Kubernetes提供了更细粒度的弹性能力——HPA（HorizontalPodAutoscaler），它能根据CPU、内存等指标，自动增减Pod的数量！明确任务：今天我们将让我们的WordPress应用具备“自我调节”的能力，并学习如何用Ingress管理更复杂的流量。二、核心概念精讲（20分钟）弹性伸缩机制：HPA(水平Pod伸缩)：最常用。通过增加或减少Pod副本数来应对负载变化。要求应用是无状态的。VPA(垂直Pod伸缩)：较少用。通过调整单个Pod的CPU/内存请求量来应对负载，通常需要重启Pod。微服务治理基础-服务发现：在K8s中，每个Service都有一个固定的DNS名称（如wordpress-service.default.svc.cluster.local）。其他服务只需通过这个名称即可访问，无需关心后端Pod的具体IP，实现了解耦。Ingress高级路由：除了基于域名的路由，Ingress还支持基于URL路径的路由（Path-basedRouting），例如：/blog→WordPressS/api→APIService三、技能实训（50分钟）任务：让我的应用学会“自我调节”配置HPA（20分钟）：前提：确保WordPressDeployment中的Pod已设置resources.requests.cpu（如100m）。创建HPA（使用命令行）：kubectlautoscaledeploymentwordpress-deployment\--cpu-percent=50\--min=1\--max=3#或通过YAML文件定义更复杂的指标查看HPA状态：kubectlgethpa压测与验证（15分钟）：安装压测工具（在CloudShell或一台ECS上）：#安装hey(Go语言压测工具)wgethttps://.../hey_linux_amd64-Ohey&&chmod+xhey执行压测：./hey-z2m-c20http://<INGRESS-EXTERNAL-IP>/#-z2m:持续2分钟,-c20:20个并发实时监控：#新开一个终端，持续观察Pod数量变化watchkubectlgetpods#应能看到Pod数量从1逐渐增加到3配置Ingress路径路由（15分钟）：修改IngressYAML：在rules下添加paths。yamlspec:rules:-http:paths:-path:/blogpathType:Prefixbackend:service:name:wordpress-serviceport:number:80应用更新：kubectlapply-fupdated-ingress.yamlkubectlgetingress验证：访问http://<INGRESS-IP>/blog，应能正常打开WordPress。四、总结评价与拓展延伸（10分钟）成果验收：检查学生是否成功创建HPA，并能通过kubectlgethpa看到当前指标。验证在压测期间，学生集群中的Pod数量是否按预期增加。检查Ingress配置，确认路径路由规则是否生效。知识梳理：HPA=Pod的自动空调：根据负载自动增减实例数。服务发现=微服务的通讯录：通过名字找服务，不靠IP。Ingress路由=智能交通灯：把不同路径的车流（请求）引向不同目的地。作业布置：思考题：HPA是基于Pod的平均CPU使用率。如果我们的应用是I/O密集型（如文件处理），CPU可能不高但磁盘I/O很高，HPA会触发扩容吗？为什么？课程总结：回顾整个学期所学，从单台ECS到高可用架构，再到云原生容器化，思考云计算技术演进的核心驱动力是什么？课题Serverless容器与CI/CD流水线课型理实一体授课班级授课时数2教学目标1.知识目标：•了解Serverless容器（ECI）的核心价值：无需管理服务器，按需运行容器。•理解虚拟节点（VirtualKubelet）如何将ECI无缝接入ACK集群。•掌握DevOps和CI/CD的基本流程与核心价值。2.技能目标：•能通过YAML文件在ACK集群中部署一个由ECI承载的Pod应用。•能使用阿里云云效Flow创建一个简单的CI/CD流水线，实现代码提交后自动构建镜像并部署到ECI。3.素质目标：•体验“无服务器”（Serverless）的极致运维简化模式。•培养自动化、持续交付的现代软件工程思维。教学重点•通过虚拟节点在ACK中部署ECI应用。•使用云效Flow配置从代码到部署的自动化流水线。教学难点•理解ECI与传统ECS承载的Pod在调度和计费上的区别。•配置云效Flow流水线中的构建、推送、部署各阶段任务。学情分析学生已熟悉容器和K8s，但对Serverless和CI/CD概念较为抽象。云效Flow界面操作步骤较多，容易出错。教学需提供清晰的流水线配置截图和分步指南，并强调ECI“免运维、秒级弹性”的特点。教学效果 •学生成功在ACK集群中部署了一个Nginx应用，其Pod由ECI承载（通过/eci=true标签指定）。•学生创建了云效Flow流水线，当向代码仓库推送新代码后，能自动完成镜像构建、推送到ACR，并更新ECI上的应用。教后记Serverless和CI/CD给学生带来了极大的震撼，让他们看到了云技术的未来方向。实训环节中，云效Flow的配置步骤是主要难点，部分学生因YAML模板未更新标签而失败。下次可提供一个完整的、可直接导入的流水线模板，进一步降低操作复杂度，让学生更聚焦于理念的理解。一、情境导入与任务驱动（10分钟）痛点升级：我们用HPA实现了弹性，但依然需要预先规划和管理Worker节点池。有没有一种方式，可以完全不用关心服务器，只关注代码和容器？引出Serverless与CI/CD：ECI(弹性容器实例)：真正的“无服务器”容器，秒级启动，按实际运行时间计费。云效Flow：阿里云的CI/CD工具，能将“代码提交”到“线上部署”的全过程自动化。明确任务：今天我们将体验最前沿的Serverless容器，并亲手搭建一条自动化发布流水线！二、核心概念精讲（20分钟）Serverless容器(ECI)：核心价值：零服务器管理、极致弹性（秒级）、按量付费（精确到秒）。工作方式：通过虚拟节点（VirtualKubelet）接入ACK集群。调度器将带有特定标签（如/eci:"true"）的Pod调度到ECI上运行。DevOps与CI/CD：CI(持续集成)：开发人员频繁地（每天多次）将代码集成到主干，并自动进行构建和测试。CD(持续交付/部署)：将经过验证的代码自动部署到生产或预发环境。核心价值：加速交付、提升质量、降低风险。三、技能实训（50分钟）任务：打造我的自动化Serverless应用部署ECI应用（20分钟）：前提：确保ACK集群已安装ack-virtual-node组件（可在控制台“组件管理”中一键安装）。准备YAML：教师提供eci-nginx.yaml模板。yamlapiVersion:v1kind:Podmetadata:name:nginx-ecilabels:/eci:"true"#关键！指定调度到ECIspec:containers:-name:nginximage:nginx:latestrestartPolicy:Never部署与验证：kubectlapply-feci-nginx.yamlkubectlgetpods-owide#观察NODE列，应显示为virtual-kubelet开头的虚拟节点构建CI/CD流水线（30分钟）：准备工作：在Codeup（阿里云代码托管）创建一个简单的HTML项目仓库。在ACR创建一个镜像仓库（如my-app）。创建云效Flow流水线：源码阶段：选择刚创建的Codeup仓库。构建阶段：构建工具：DockerDockerfile路径：Dockerfile镜像仓库：选择ACR中的my-app仓库，标签设为${FLOW_COMMIT_ID}。部署阶段：部署方式：Kubernetes集群：选择自己的ACK集群。命名空间：default更新策略：RollingUpdate关键：在YAML模板中，确保Pod模板包含/eci:"true"标签。运行与验证：手动运行一次流水线，观察各阶段是否成功。向代码仓库推送一次新提交，验证流水线是否被自动触发。四、总结评价与拓展延伸（10分钟）成果验收：检查学生是否成功部署了由ECI承载的Pod。验证学生的云效Flow流水线能否在代码提交后自动完成构建和部署。知识梳理：ECI=无服务器容器：彻底解放运维，只为运行付费。虚拟节点=桥梁：让ECI无缝融入K8s生态。CI/CD=自动化引擎：让软件交付又快又稳。课程总结与展望：回顾：从单台ECS→高可用架构→容器化→Serverless+CI/CD，我们见证了云计算从资源管理到应用管理的演进。展望：Serverless和GitOps是未来趋势，鼓励大家持续学习，拥抱云原生。课题云容灾备份策略与设计课型理实一体授课班级授课时数2教学目标1.知识目标：•掌握数据备份的基本类型（全量、增量）及其特点。•深入理解RTO（恢复时间目标）和RPO（恢复点目标）的核心概念及其在容灾设计中的指导意义。•了解异地容灾的基本架构与价值。2.技能目标：•能为ECS实例配置自动快照策略，实现系统盘和数据盘的定期备份。•能执行RDS数据库的备份恢复操作，验证数据可恢复性。•能配置OSS跨区域复制（CRR）规则，实现关键静态资源的异地容灾。3.素质目标：•树立“业务连续性”和“数据是核心资产”的安全意识。•培养根据业务需求（RTO/RPO）设计合理容灾备份方案的能力。教学重点•ECS自动快照策略的配置。•RDS数据库的备份恢复演练。教学难点•理解RTO与RPO的权衡关系，并能将其转化为具体的备份策略（如备份频率、保留周期）。•区分不同云产品（ECS、RDS、OSS）的备份机制与适用场景。学情分析学生对“备份”有基本认知，但对RTO/RPO等专业指标以及如何将其落地到具体云产品配置上缺乏经验。实训中需通过具体案例（如“电商大促前必须确保RPO<5分钟”）来建立指标与配置的关联。教学效果•学生成功为WordPress应用所在的ECS配置了每日自动快照策略。•学生在RDS控制台执行了一次手动备份，并成功将数据库恢复到该备份点。•学生为存放WordPress媒体文件的OSSBucket配置了跨区域复制规则，目标地域为华北2（北京）。教后记通过模拟“灾难”并进行恢复演练，让学生深刻体会到备份的重要性，课堂参与度高。主要挑战在于OSS跨区域复制需要预先在目标地域创建Bucket，部分学生遗漏此步骤导致配置失败。下次实训指南中需用加粗字体强调此前置条件。本次课程有效提升了学生的云上安全防护意识。一、情境导入与任务驱动（10分钟）灾难场景：想象一下，我们的服务器因误操作被删除，或者所在地域发生重大自然灾害，业务完全中断。我们能承受多久的停机？能接受丢失多少数据？引出核心指标：RTO(RecoveryTimeObjective)：能容忍多长的停机时间？（如：2小时）RPO(RecoveryPointObjective)：能容忍丢失多少数据？（如：5分钟）这两个指标是设计所有容灾备份方案的基石！明确任务：今天我们将学习如何利用阿里云服务，构建一套满足特定RTO/RPO要求的容灾备份体系。二、核心概念精讲（20分钟）备份类型：全量备份：备份所有数据。恢复快（RTO好），但占用空间大、耗时长。增量备份：仅备份自上次备份以来变化的数据。节省空间和时间（利于降低RPO），但恢复时需要依赖全量+所有增量（RTO可能较长）。云产品备份能力：ECS：通过快照实现块级备份。支持自动策略。RDS：提供自动备份（物理备份）和日志备份（用于精确时间点恢复），可轻松满足极低RPO。OSS：通过跨区域复制（CRR）实现Bucket级别的异步数据复制，保障静态资源的异地容灾。异地容灾：在不同地理区域部署一套备用系统。当主地域故障时，可将流量切换至备地域，实现最高级别的业务连续性保障。三、技能实训（50分钟）任务：为我的博客构建容灾备份体系ECS自动备份（15分钟）：进入ECS控制台→“快照”→“自动快照策略”。创建策略：策略名称：Daily-Backup创建时间：02:00重复日期：每天保留时间：7天将策略应用到WordPress应用所在的ECS实例。RDS备份恢复演练（20分钟）：前提：确保RDS已开启自动备份（默认开启）。制造“灾难”：在WordPress后台创建一篇新文章“DisasterTest”。执行恢复：进入RDS控制台→“备份恢复”。选择一个早于“DisasterTest”文章创建时间的备份点。克隆实例（推荐，避免覆盖原库）或直接恢复（谨慎操作）。验证：连接新克隆的数据库，确认“DisasterTest”文章不存在，证明恢复成功。OSS跨区域复制（15分钟）：进入OSS控制台→目标Bucket→“跨区域复制”。创建规则：规则名称：Replicate-to-Beijing目标地域：华北2（北京）目标Bucket：提前在华北2创建一个同名或新Bucket。同步历史文件：是验证：上传一个新文件到源Bucket，观察目标Bucket是否在几分钟后同步出现。四、总结评价与拓展延伸（10分钟）成果验收：检查学生是否成功配置了ECS自动快照策略。验证学生是否完成了RDS的备份恢复（克隆）操作。确认学生的OSS跨区域复制规则已生效。知识梳理：RTO/RPO是灵魂：所有技术手段都服务于这两个业务指标。ECS靠快照：保护操作系统和本地数据。RDS有备份：保障结构化数据零丢失。OSS能复制：守护海量静态资产。作业布置：思考题：如果我们要求RPO=0（零数据丢失），仅靠上述的备份手段能否实现？还需要什么技术？（引出数据库主从复制、多可用区部署等概念）课程反思：回顾本学期所有项目，思考在哪个环节最容易发生数据丢失风险，并提出你的加固建议。课题混合云备份(HBR)实战课型理实一体授课班级授课时数2教学目标1.知识目标：•了解混合云备份（HBR）的核心价值：统一保护本地IDC和云上数据。•掌握HBR的基本架构：备份网关、客户端、云端仓库。2.技能目标：•能在模拟的本地环境（如ECS）中安装并激活HBR客户端。•能创建备份计划，将指定的文件目录或数据库（如MySQL）备份到阿里云OSS。•能执行恢复操作，将云端备份的数据还原到本地。3.素质目标：•树立企业级数据保护意识，理解混合云是当前主流IT架构。•培养利用云服务解决传统IDC痛点的能力。教学重点•HBR客户端的安装与激活。•创建文件备份任务并执行恢复操作。教学难点•理解HBR如何通过“备份网关”实现本地与云端的安全、高效数据传输。•配置数据库（如MySQL）备份时，需要正确提供数据库连接信息和权限。学情分析学生对“本地数据中心”概念较为抽象，缺乏真实IDC环境。教学需利用ECS实例模拟本地服务器，并强调HBR在打通云-地数据孤岛中的作用。实训操作步骤清晰，但需注意客户端激活过程中的网络连通性。教学效果•学生成功在一台ECS（模拟本地服务器）上安装并激活了HBR客户端。•学生创建了备份计划，将/home/backup-test目录下的文件成功备份至云端。•学生执行了恢复任务，将备份文件成功还原到本地的/home/restore-test目录。教后记利用ECS模拟本地IDC的方案切实可行，有效帮助学生理解混合云场景。HBR客户端的安装和激活流程顺畅，学生能快速看到备份成功的反馈，成就感强。主要注意点是确保模拟IDC的ECS有访问HBR服务的内网权限。一、情境导入与任务驱动（10分钟）企业痛点：许多企业仍有大量核心业务运行在本地机房（IDC），但本地备份存在成本高、可靠性低、异地容灾难等问题。引出HBR方案：阿里云混合云备份HBR（HybridBackupRecovery）提供了一站式解决方案，无需自建备份服务器，就能将本地文件、数据库、虚拟机安全、高效地备份到云端。明确任务：今天我们将扮演企业IT管理员，为一台“本地服务器”配置云端备份，体验云如何赋能传统IDC。二、核心概念精讲（20分钟）HBR核心价值：统一管理：一套平台，同时管理本地和云上备份。安全可靠：数据传输加密，存储于高可靠的OSS。成本优化：按实际备份容量付费，免去自建备份系统的CAPEX。HBR基本架构：云端控制台：用于创建备份库、管理策略。备份网关（由HBR托管）：云端的服务组件，负责调度和管理备份任务。HBR客户端：安装在本地服务器（或ECS）上的轻量级代理，负责数据采集和上传。支持场景：文件备份：备份任意文件和文件夹。数据库备份：支持MySQL、Oracle、SQLServer等。VMware备份：整机备份虚拟机。三、技能实训（50分钟）任务：为“本地服务器”配置云端保险箱环境准备（10分钟）：模拟本地服务器：使用一台位于VPC内的ECS实例（不分配公网IP，仅内网访问）来模拟本地IDC服务器。准备测试数据：在ECS上创建目录/home/backup-test，并放入几个文本文件。安装与激活HBR客户端（20分钟）：创建备份库：进入HBR控制台→“文件备份”→“创建备份库”，选择地域。下载并安装客户端：在备份库详情页，点击“添加客户端”。下载Linux版客户端安装包和激活脚本。将安装包和脚本上传到模拟的“本地”ECS。在ECS上执行安装命令：sudotar-zxvfhbr-client-linux-*.tar.gzcdhbr-clientsudo./install.sh激活客户端：运行提供的激活脚本，输入AK/SK（或使用RAM角色）完成激活。创建备份与恢复任务（20分钟）：创建备份计划：在HBR控制台，选择已激活的客户端。新建备份计划：备份路径/home/backup-test，保留时间7天。立即执行一次备份。执行恢复操作：在备份任务列表中，找到刚创建的备份点。点击“恢复”，选择恢复路径为/home/restore-test。在ECS上验证/home/restore-test目录下是否出现了原始文件。四、总结评价与拓展延伸（10分钟）成果验收：检查学生HBR客户端是否在控制台显示为“在线”状态。验证学生的备份任务是否成功完成。确认学生能否在本地ECS上找到恢复后的文件。知识梳理：HBR=云上备份管家：轻松守护本地和云上数据。客户端=数据搬运工：部署在源端，负责上传。备份库=云端保险箱：安全存放所有备份数据。课程总结：回顾全课程：从单点云服务（ECS/OSS/RDS）到高可用架构，再到容器化、自动化，最后到混合云容灾，我们构建了一个完整的云上应用生命周期管理体系。展望未来：数据安全是永恒的主题，HBR等混合云产品将是企业数字化转型的关键支撑。课题网络安全防护体系课型理实一体授课班级授课时数2教学目标1.知识目标：•了解DDoS攻击的基本原理及云上防护机制。•掌握云防火墙（CFW）与安全组的分层防护模型及各自定位。•理解安全组“最小权限”原则等最佳实践。2.技能目标：•能为ECS实例配置符合最小权限原则的安全组规则。•能在云防火墙控制台创建访问控制策略，实现VPC间或互联网到VPC的精细化流量管控。•能确认DDoS基础防护已开启，并理解其防护阈值。3.素质目标：•树立纵深防御的安全理念，理解多层次防护的必要性。•培养严谨、规范的安全配置习惯。教学重点•安全组与云防火墙的协同工作模式。•云防火墙访问控制策略的创建与应用。教学难点•区分安全组（主机级、有状态）与云防火墙（网络级、东西向/南北向）的不同作用域和能力。•理解策略的匹配顺序（默认拒绝，按优先级匹配）。学情分析学生对“黑客攻击”有模糊概念，但对具体的防护产品和配置逻辑不清晰。容易混淆安全组和防火墙的功能。教学需通过清晰的架构图和生活化类比（如小区门禁vs楼宇门禁）来厘清二者关系。教学效果•学生成功优化了WordPressECS的安全组，仅开放80/443端口给SLB，22端口限制为管理网段。•学生在云防火墙上创建了一条策略，显式拒绝来自特定高危IP地址的访问。•学生确认了其公网资产（SLB/ECS）已处于DDoS基础防护之下。教后记通过“三层盔甲”的比喻，学生对分层防护模型有了清晰的认识。实训中，安全组的优化是学生最容易上手的部分。云防火墙的策略配置界面较为专业，部分学生对“优先级”概念感到困惑，下次可增加一个简单的策略冲突演示。一、情境导入与任务驱动（10分钟）安全威胁：我们的网站上线后，可能会面临各种网络攻击，如暴力破解SSH（22端口）、DDoS洪水攻击等。如何构建一个坚固的防线？引出纵深防御体系：第一道：DDoS防护-抵御海量流量洪水。第二道：云防火墙(CFW)-网络边界的大门，进行精细的访问控制。第三道：安全组-主机的最后一道门禁，实施最小权限。明确任务：今天我们将为我们的博客系统穿上三层“盔甲”，打造一个基础但坚固的网络安全防护体系。二、核心概念精讲（20分钟）分层防护模型：[互联网]↓[DDoS防护]→(清洗异常流量)↓[云防火墙CFW]→(南北向:互联网↔VPC;东西向:VPC↔VPC)↓[安全组]→(主机级,有状态,控制进出ECS的流量)↓[ECS实例]核心组件详解：DDoS基础防护：阿里云为所有公网IP（ECS/SLB/EIP）免费提供最高5Gbps的DDoS防护能力。超过阈值会触发黑洞。云防火墙(CFW)：提供网络层的统一访问控制，支持基于IP、端口、协议、地理位置的精细化策略，是VPC的“总闸”。安全组：实例级虚拟防火墙，有状态（返回流量自动放行），遵循最小权限原则（只开必要的端口）。三、技能实训（50分钟）任务：为我的博客穿上三层“盔甲”加固安全组（15分钟）：审查现有规则：检查WordPressECS的安全组。优化策略：入方向：删除/0对22端口的访问。添加规则：仅允许公司管理网段（如/16）访问22端口。确保80/443端口来源为SLB的IP或/0（若SLB未绑定固定IP）。出方向：保持默认（全部允许）或根据需要收紧。配置云防火墙（25分钟）：开通服务：进入云防火墙控制台，按提示开通（新用户有免费额度）。创建访问控制策略：策略类型：互联网边界防火墙访问源：输入一个模拟的恶意IP（如00，此为文档保留IP，无害）。访问目的：选择VPC边界或指定SLB/ECS的公网IP。协议/端口：ALL动作：拒绝优先级：50（数值越小，优先级越高）（演示）东西向策略：教师简要演示如何创建VPC内不同应用间（如Web到DB）的访问控制策略。确认DDoS防护（10分钟）：查看防护状态：进入云监控或DDoS防护控制台。找到资产：定位到SLB或ECS的公网IP。确认信息：查看其DDoS基础防护阈值（通常显示为5Gbps）和当前状态（正常）。（强调）：解释“黑洞”概念——当攻击流量超过阈值，IP会被暂时屏蔽以保护整个平台。四、总结评价与拓展延伸（10分钟）成果验收：检查学生ECS安全组规则是否符合最小权限原则。验证学生是否成功在云防火墙上创建了一条显式的拒绝策略。确认学生能找到其公网资产的DDoS防护信息。知识梳理：DDoS防护：抗洪水，保可用。云防火墙：管边界，做总控。安全组：守主机，行最小。作业布置：思考题：为什么安全组是有状态的，而云防火墙策略通常是无状态的？这种设计各有什么优缺点？课程反思：回顾本学期所有部署的云资源，列出你认为最需要加强安全防护的三个地方，并说明理由。课题应用安全与主机安全课型理实一体授课班级授课时数2教学目标1.知识目标：•了解Web应用面临的常见威胁（如SQL注入、XSS跨站脚本）。•掌握WAF（Web应用防火墙）的核心防护原理。•理解云安全中心（态势感知）作为统一安全管理平台的作用。2.技能目标：•能将已有的Web应用（如WordPress）接入WAF，开启基础防护。•能在WAF控制台验证对模拟攻击（如SQL注入）的拦截效果。•能在云安全中心查看并处理主机安全告警（如挖矿病毒），执行一键隔离或查杀操作。3.素质目标：•树立“应用层”和“主机层”双重安全防护意识。•培养主动监控、快速响应的安全运维习惯。教学重点•WAF的接入与防护策略配置。•云安全中心告警的识别与处置流程。教学难点•理解WAF如何通过规则引擎识别并阻断应用层攻击载荷。•区分不同级别安全告警的紧急程度和处理方式。学情分析学生对“黑客攻击”有浓厚兴趣，但对具体的攻击手法（如SQL注入）和防御机制缺乏直观感受。实训中需提供安全的、可控的模拟攻击方法，并强调在真实环境中严禁进行非法扫描和攻击。教学效果•学生成功将WordPress站点的流量切换至WAF进行代理防护。•学生通过构造简单的SQL注入测试字符串，观察到WAF返回了拦截页面。•学生在云安全中心发现了一条“异常进程”告警，并成功执行了一键查杀操作。教后记通过亲手触发并处理安全告警，极大地增强了安全防护的实战感。WAF的接入因涉及DNS解析，在无域名环境下略显抽象，下次可考虑使用阿里云提供的测试工具或沙箱环境进行更直观的演示。整体而言，课程体系完整，有效达成了教学目标。一、情境导入与任务驱动（10分钟）应用层威胁：我们的网站不仅面临网络洪水（DDoS），还可能被黑客利用代码漏洞进行精准打击，例如：SQL注入：在登录框输入'OR'1'='1，试图绕过密码验证。XSS攻击：在评论区插入<script>alert('xss')</script>，窃取用户Cookie。引出纵深防御新维度：WAF(Web应用防火墙)：专门守护Web应用，是抵御上述攻击的“智能盾牌”。云安全中心：全网资产的“安全大脑”，实时监控主机健康状况，发现病毒、木马、挖矿程序等威胁。明确任务：今天我们将为博客系统加装“智能盾牌”，并启动“安全大脑”，实现从网络到应用再到主机的全方位守护。二、核心概念精讲（20分钟）WAF工作原理：部署模式：通常采用反向代理模式。用户流量先经过WAF，清洗后再转发给源站（ECS/SLB）。防护能力：内置数千条规则，可精准识别并拦截OWASPTop10等常见Web攻击。核心价值：零代码改造即可获得专业级Web安全防护。云安全中心（态势感知）：核心功能：主机安全：病毒查杀、漏洞修复、基线检查、入侵检测。安全大屏：全局安全态势可视化。告警中心：集中管理所有安全事件。工作模式：通过安装在ECS上的安全插件（安骑士）进行实时监控和响应。三、技能实训（50分钟）任务：启动“智能盾牌”与“安全大脑”接入WAF防护（25分钟）：开通WAF：进入WAF控制台，按提示开通（新用户有免费试用）。添加防护域名：域名：使用SLB的公网IP或一个测试域名（如）。源站地址：填写SLB的公网IP。关键步骤：根据WAF提示，修改DNS解析，将域名指向WAF分配的CNAME地址。（若无域名，可演示原理）验证防护：在浏览器中访问http://<WAF防护地址>/?id=1'OR'1'='1预期结果：页面显示WAF的拦截提示，而非WordPress的错误页面。处理云安全中心告警（25分钟）：安装安全插件：确保WordPress所在的ECS已安装云安全中心插件（通常默认安装）。制造“威胁”（安全可控）：教师提供一个无害的、特征明显的测试脚本（如cloud_test_miner.sh），其行为会被安全中心识别为“挖矿行为”。学生在ECS上运行该脚本。响应告警：进入云安全中心→“安全告警处理”。找到新产生的“恶意进程”或“挖矿程序”告警。查看告警详情（进程路径、网络连接等）。执行操作：点击“一键处理”或“隔离”，完成查杀。验证：回到ECS，确认该进程已被终止。四、总结评价与拓展延伸（10分钟）成果验收：检查学生是否成功在WAF中添加了防护域名。验证学生是否观察到了WAF对模拟攻击的拦截效果。确认学生能在云安全中心找到并成功处理一条安全告警。知识梳理：WAF=Web应用保镖：专防SQL注入、XSS等应用层攻击。云安全中心=安全运营中心：统管主机安全，主动发现并处置威胁。安全是持续过程：防护、监控、响应，缺一不可。课程终极总结：回顾全20次课：我们从零开始，完成了从单点服务部署→高可用架构→容器化与自动化→全方位安全防护的完整闭环。课题数据安全与合规审计课型理实一体授课班级授课时数2教学目标1.知识目标：•了解数据加密在云上安全体系中的核心地位。•掌握密钥管理服务（KMS）的基本原理和应用场景。•理解操作审计（ActionTrail）对满足合规性要求的重要性。2.技能目标：•能创建KMS密钥，并将其用于开启OSSBucket的服务器端加密（SSE-KMS）。•能配置操作审计（ActionTrail），将云账户的操作日志投递到SLS日志服务。•能在SLS中查询并分析日志，识别潜在的异常操作（如非工作时间删除资源）。3.素质目标：•树立“数据主权”和“最小权限”原则下的安全意识。•培养满足等保、GDPR等法规要求的合规思维。教学重点•使用KMS密钥为OSS数据开启服务器端加密。•配置ActionTrail并将审计日志投递至SLS。教学难点•理解KMS如何实现密钥与数据的分离管理，以及其在自动化加解密中的作用。•在SLS中编写简单的查询语句，从海量日志中筛选出关键事件。学情分析学生对“加密”有基本概念，但对KMS这种托管式密钥服务的价值理解不深。对“合规审计”感到抽象。教学需通过具体场景（如“防止内部人员误删/窃取数据”）来阐明审计日志的价值，并提供清晰的日志查询模板。教学效果•学生成功创建了一个KMS密钥，并为一个OSSBucket启用了SSE-KMS加密。•学生成功配置了ActionTrail，将所有操作日志投递到了SLSLogstore。•学生能在SLS中执行查询，找出最近一次对ECS实例的DeleteInstance操作记录。教后记本节课将技术实践与法规要求紧密结合，有效提升了学生的数据主权意识。KMS的配置过程简洁明了，学生能快速理解其价值。SLS日志查询是主要难点，部分学生对SQL-like语法不熟。下次可提供一个更详细的常用查询语句速查表，并安排更多时间进行练习。作为安全专题的深化课，达到了预期的教学效果。一、情境导入与任务驱动（10分钟）数据安全痛点：我们的业务数据是核心资产。不仅要防外部黑客，还要防内部风险（如员工误操作或恶意行为）。如何确保数据即使被窃取也无法读取？如何追踪谁在何时做了什么操作？引出核心方案：KMS(密钥管理服务)：安全、可靠、易用的密钥托管服务，让数据“落盘即加密”。ActionTrail(操作审计)：记录所有云账户操作的“行车记录仪”，满足安全分析与合规审计需求。明确任务：今天我们将为数据加上“保险锁”，并为整个云账号装上“行车记录仪”。二、核心概念精讲（20分钟）数据加密与KMS：加密方式：OSS支持服务器端加密（SSE），其中SSE-KMS模式使用KMS托管的密钥，安全性最高。KMS价值：硬件级安全（HSM）、权限隔离（密钥权限独立于数据权限）、自动轮换、使用审计。合规审计与ActionTrail：记录内容：记录所有通过控制台、API、CLI发起的写操作（如创建、删除、修改）和关键读操作。核心价值：安全分析：追溯安全事故根源。变更追踪：了解资源配置历史。合规证明：满足等保2.0、ISO27001等法规对操作留痕的要求。日志投递：通常将日志投递到SLS（日志服务）进行存储、查询和分析。三、技能实训（50分钟）任务：为数据上锁，并启动“行车记录仪”配置KMS加密OSS（20分钟）：创建KMS密钥：进入KMS控制台→“用户主密钥”→“创建密钥”。密钥类型：通用型别名：oss-encryption-key（保持默认高级配置）启用OSS加密：进入OSS控制台，选择一个用于存放敏感数据的Bucket（如my-private-data）。“基础设置”→“服务器端加密”→“修改”。加密方式：KMSKMS密钥：选择刚创建的oss-encryption-key。验证：上传一个新文件，确认其元信息中显示已加密。配置操作审计与日志分析（30分钟）：开通并配置ActionTrail：进入ActionTrail控制台→“跟踪列表”→“创建跟踪”。跟踪名称：all-operations-trail投递位置：投递到SLS日志库（Logstore）：新建一个名为cloud-audit-logs的Logstore。（保持其他选项默认）模拟操作：在控制台手动停止或重启一台ECS实例，产生一条审计日志。分析审计日志：进入SLS控制台，找到cloud-audit-logsLogstore。查询示例1（查找删除操作）：sqlevent.eventName:"Delete*"查询示例2（查找非工作时间操作）：sql__time__<"08:00:00"or__time__>"18:00:00