https://scs.buaa.edu.cn/doc/cloud-labs/cloud/Recent content in 云计算实验 on 软院云平台文档Hugo -- gohugo.ioenhttps://scs.buaa.edu.cn/doc/cloud-labs/cloud/container_docker/Mon, 01 Jan 0001 00:00:00 +0000https://scs.buaa.edu.cn/doc/cloud-labs/cloud/container_docker/容器与Docker综合实验 # 💡 文档中对各个概念的定义和阐述并不是严谨的，文档中用语尽量通俗易懂，大多数只是为了让同学们明白这个概念大致在说什么东西，能在头脑中有个感性的认识（这对知识的掌握和学习非常重要）。概念的严格定义还请参考对应的官方文档。 💡 容器和Docker的内容非常繁杂，实验文档不可能面面俱到，因此很多内容以链接的形式给出。请同学们在阅读文档本身的同时，不要忘记学习链接中指出的内容。 💡 同学们在执行命令时，一定要认真阅读命令的输出和log，通过阅读这些输出，你很容易了解你所执行的命令具体执行了哪些操作，这非常有助于理解其背后的运行原理。 💡 目前流行的绝大多数容器运行时都是用Go语言编写，著名的容器编排工具Kubernetes也是用Go语言编写的，基于Docker和Kubernetes建立起来的整个云计算生态中的绝大部分项目也都是用Go语言实现的。因此，如果想深入了解和学习云计算相关内容的话，建议同学们学习和掌握Go语言。当然，这并不是本次实验和这门课的要求:) 实验目的 # 理解容器的概念，了解实现容器所使用的的底层技术，理解容器与虚拟机的区别 理解容器与 Docker 之间的关系 掌握 Docker 的基本使用方法和常见命令，可以使用 Dockerfile 构建镜像 实验要求 # 请参考本实验文档，并查阅相关资料，回答以下问题并完整记录实验过程： 数据持久化。容器是 “一次性的” 和 “脆弱的”（请大家务必牢记容器这一特性），容器很容易因为各种原因被kill（如资源不足等等）。而容器产生的数据文件是和容器绑定在一起的，当容器被删除时，这些数据文件也会被删除，这是我们不想看到的。 比如，我们在机器上启动了一个mysql容器，在写入了一些重要数据后，因为某种原因该容器被意外删除了。此时即使重新启动一个mysql容器也找不会之前的数据了。请结合实验文档中的内容和查阅相关资料，讨论应该通过何种方式启动容器来避免出现这一问题？你能得出几种方案？每种方案的优劣如何？并请分别使用这些方案模拟mysql容器 创建 - 写入数据 - 销毁 - 重新创建 - 重新读到之前写入的数据 的场景，以证明方案的有效性。 请从ubuntu镜像开始，构建一个新的包含Nginx服务的ubuntu镜像，并修改Nginx主页内容为你的学号，请分别使用docker commit 和 Dockerfile两种方式完成， 并将这个新构建的镜像推送到华为云容器镜像服务SWR中。其中，使用docker commit构建的镜像的TAG为dockercommit；使用Dockerfile构建的镜像的TAG为 dockerfile。推送后，对华为云“我的镜像”页面进行截图。 Docker的安装 # 请参考 文档，并从“使用脚本自动安装”开始读起。 安装前务必联网 curl -fsSL get.docker.com -o get-docker.sh sudo sh get-docker.sh --mirror Aliyun 配置镜像源 # 我们常用的Docker官方的镜像仓库在国内的连接非常不稳定，拉取镜像时很可能非常缓慢，这时可以配置镜像源，打开 华为云容器镜像服务，点击“镜像中心”右上角的“镜像加速器”，并按照镜像加速器的提示，执行相应操作 Docker的简单使用 # 我们首先启动一个非常简单的Ubuntu容器，下面这条命令可以将会在一个隔离Ubuntu环境中执行/bin/bash进程： docker run -it --rm ubuntu /bin/bash 可以看到，docker成功为我们启动了一个Ubuntu环境中的/bin/bash进程，当前我们所在的命令行环境已经不是原来主机上的环境了。可以使用下面的命令进行验证。https://scs.buaa.edu.cn/doc/cloud-labs/cloud/cloud_course_design/Mon, 01 Jan 0001 00:00:00 +0000https://scs.buaa.edu.cn/doc/cloud-labs/cloud/cloud_course_design/ 云计算课程设计 # 背景 # 当今时代是云原生的时代。 容器化带来的优势 # 在之前的《容器与Docker》的实验中，我们从“隔离不同的应用程序”入手，介绍了引入容器的必然性。容器之间这种相互隔离的特性为使它非常便于进行弹性伸缩和迁移部署。 各位试想一下自己之前部署一个应用的过程，通常分为这么几个步骤： 编译源代码，得到编译产物（你可能需要根据不同的部署目标编译多个不同平台的编译产物，比如在macOS和Windows上开发，却需要编译Linux目标平台的产物） 在目标机器上安装运行时环境（对于部分类型的应用程序来说，这一步可以省略，如大部分Go、Rust等编写的应用） 将编译产物传送到目标机器 设置程序运行时需要的环境变量、配置文件等（大多数情况下至少需要维护开发时和运行时两种不同的配置文件和环境变量） 启动应用程序 如果是需要长期稳定运行的程序，还需要配置程序作为守护进程启动（可能需要编写systemd配置文件等） 而对于以容器形式部署的应用来说，只需要： 编写Dockerfile（这里会包含进程在运行时需要使用的环境变量和配置文件等） 根据Dockerfile构建镜像 推送镜像到目标机器，然后使用docker run启动容器 整个过程流畅而优雅，并且因为需要操作的步骤很少，所以会有更低的出错的可能（在传统的部署过程中，敲错一行命令导致部署失败是常有的事）。而且，更进一步地： 有些时候，我们将机器A上的应用迁移到机器B上时，如果使用传统部署方式，则很可能需要将1至6这几个步骤重复走一遍；而如果使用容器部署方式，只需要在机器B上拉取机器A中使用的镜像，重新启动容器即可。 有些时候，我们可能需要在同一台机器上部署和管理一个应用的多个不同的实例（如对于单进程应用，出于负载均衡，充分榨干机器性能的需要），如果使用传统部署方式，很可能需要为每个需要部署的实例修改不同的配置，并手动开启或关闭这多个实例；而如果使用容器部署的方式，则只需修改docker run的参数，对于启动的多个实例，可以轻松地使用docker本身提供的工具进行管理。 大多数情况下，一个应用程序往往会依赖若干个不同的外部服务。比如一个Java编写的后端服务，可能需要依赖数据库、对象存储等服务。这些外部服务的部署和配置在部署应用时也是一个很让人头疼的事情。而对于容器的部署方式，这些外部服务，诸如数据库、对象存储等，完全也可以实现容器化，它们的部署也可以使用基于容器的方式进行（相信各位在上次实验中已经体会到了使用容器的方式部署MySQL服务的便利性）。 微服务与容器 # 相信很多同学都接触或者实践过微服务架构（比如Spring Cloud之类的）。微服务，简单来讲就是说将原来的整个软件系统，拆分成不同的模块，每个模块对外都表现为一个独立的系统（它们可以独立进行开发、测试和部署），每个模块对外暴露规划好的接口，不同模块之间通过某种协议（一般是原生的HTTP或各种各样的RPC协议）相互调用这些接口，从而组织成整个完整的软件系统。 微服务带来了很多好处： 整个业务系统“高内聚，低耦合”。不同模块只需要维护好对外的接口即可，对内完全是自治的。这给整个软件系统的迭代更新带来了极大的便利。比如，可以根据需要很方便地增减不同模块等等。 不同模块相互独立，其之间的沟通交流一般使用的是基于HTTP的与编程语言和编程框架无关的协议。这就使得同一个软件系统内部的不同微服务模块可以交给不同团队开发，不同团队可以根据自身的技术积累，或者当前模块的特点，使用不同的编程语言和框架来实现。 不同微服务模块的部署是相互独立的。这就意味着，可以根据需要调整不同模块部署的实例个数，而无需调整整个软件系统的部署情况，从而可以充分利用硬件资源。 微服务架构的上述特点很适合互联网业务敏捷开发、快速迭代的工作方式。 不难发现，微服务的特点和容器的优势有很大的重合点，容器非常适合用来作为微服务的实现方式。即，对每个模块构建一个或多个镜像，然后以部署容器的方式部署每个微服务模块。事实上，我们当前使用的各个大厂的主要业务都是跑在容器里面的。“微服务化”和“容器化”也基本成为了同义词。 容器管理与云 # 当前大部分互联网公司的业务的部署都是以容器的方式进行的。整个软件系统被拆成一个个微服务模块，每个微服务的实例都是一个容器。这些成千上万的容器翱翔在以数以万计的服务器组成的大规模集群的资源池中。容器定义了新时代的云。而所谓的“上云”，也基本意味着“将应用以容器方式进行部署和管理”。 随着容器数量的扩大，容器管理问题也逐渐凸显出来。试想，在容器数量很少时，你可以在自己的机器上手动使用docker命令开启或关闭容器。但当容器数量数以万计时，手动操作的成本就会迅速增加，因为： 即使每个容器因为各种各样的原因崩溃的概率很低，但乘以一个很大的容器总数，就会使“每时每刻都会有若干容器挂掉”变成大概率事件。为了保证业务的正常运行，必须能够即使发现这些崩溃的容器，并将它们重新启动。 在业务迭代时，经常需要更新容器的镜像。这意味着，我们必须能够在数以万计的容器中，找到先前版本的所有容器实例，并将它们关闭移除，然后启动新版本镜像的容器。 集群中的各个机器的状态可能不同（集群可能是异构的），为了充分发挥硬件资源的能力，必须能够即使根据不同机器的状态（空闲与否）和容器占用资源的情况，将容器调度到不同机器上运行。 不仅如此，随着单纯的容器化本身只是一种“理想的愿景”，有很多实际问题需要考虑： 前面我们提到，微服务的各个模块之间需要相互调用，这也意味着，不同容器之间需要相互交换信息，那么如何定位不同的容器、容器之间以怎样的方式发送和接收消息就成为一个非常重要的问题。 容器本身是“一次性”的，它的存储相关工作一般都交给数据卷来保存。不仅如此，数据对任何业务来讲都是最宝贵的资源，为了保证高可用，数据卷的管理必须考虑备份、容灾等。当容器数量增大时，数据卷的管理将变得非常复杂。 围绕这上述这些实际生产中的问题，很多科技公司都积极尝试并给出了自己的解决方案，但最终还是Google开源的Kubernetes笑到了最后，并已经在当下成为了分布式容器管理和容器编排的事实标准。而当下繁荣的云原生生态，也正是以容器和Kubernetes为基石，围绕它们构建起来的。 如果同学们对云计算感兴趣，可以去关注一下 CNCF（云原生计算基金会），它是Linux基金会的一部分，收录了大量云计算方面的开源项目，很多国内外大厂都是它的会员，同时也会给它捐献自己的云计算方面的开源项目，在 这里你可以看到CNCF的全景图。CNCF每年都会举办很多面向学生的开源项目活动，是一个接触并深入云计算领域的非常不错的窗口，感兴趣的同学可以多留意相关信息（比如各个大厂的云原生公众号，CNCF在国内的公众号等）。 课程设计内容 # 相信大家都上过软件学院的软件工程这门课。课程的大作业一般都需要完成做一次完整的软件开发，最终一般都需要提交源代码和相关文档等。但这门课的作业检查是非常痛苦的。不同小组使用的编程语言、编程框架及其相应的版本都不一而同。助教或教师如果想实际检查源代码的正确性（即能正确编译并在部署后能呈现出你文档中描述的那种效果）是非常困难的。 因此，请以软件学院为样本，结合容器技术，设计这样一个Web应用，教师或助教部署作业任务后，学生提交源代码和必要的编译部署选项（比如编译脚本、部署参数等）；教师或助教在学生提交完成后，只需要在系统中点击“编译”和“部署”按钮，就可以完成学生作品的部署流程，并观察到学生作品的运行效果。 以上只是对系统的笼统描述，有很多细节需要考虑： 软院云平台现有课程管理、实验管理、提交作业功能，如何将这些现有功能与新系统联动起来？ 学生提交作业时使用什么方式？直接提交源代码压缩包，还是给出一个代码托管地址？有自己的代码托管平台BuGit，如果将新系统与其联动起来？ 学生在完成作业后，提交代码前，很可能也需要自己在系统上尝试编译部署进行自测，以保证自己代码的运行效果与本地测试的效果相同。 （可选）大多数情况下，学生在完成作业时，都使用版本控制系统（如Git等）来管理代码。学生很可能需要在每次提交代码时能验证本次所提交的代码没有破坏之前的功能。即，系统应该可以在每次学生提交新代码（如果使用Git进行管理的话，就是在每次提交新commit时）时自动拉取学生代码，或者运行代码库的单元测试，或者进行编译和部署，并将结果展示出来。熟悉 GitHub Actions和 CI/CD的同学应该很容易理解这里在说什么。 本次课程设计并不需要大家真正实现这一系统，而是要编写文档，描述： 对上述场景进行需求分析，可以使用用例图等形式描述系统中包含哪些角色，每个角色应该有怎样的功能。请大家重视这一部分的工作，这是你接下来设计系统的重要前提。 描述系统的设计结构，可以使用原型图、架构图、流程图等形式，说明系统从教师或助教部署作业，到教师或助教看到学生的作业效果这一端到端的流程是怎样工作的。并请结合一个典型的作业类型（例如，一个包含了前端、后端和数据库的课程作业），来举例描述系统的工作流程。 描述技术选型，描述计划使用哪些关键技术，并且这些技术是怎样为最终系统功能服务的。https://scs.buaa.edu.cn/doc/cloud-labs/cloud/kube-single-3/Mon, 01 Jan 0001 00:00:00 +0000https://scs.buaa.edu.cn/doc/cloud-labs/cloud/kube-single-3/Kubernetes基础实验 # 实验目的 # 了解Kubernetes的各种特性 熟悉Kubernetes的基础使用 背景 # 上次实验中，我们主要了解了什么是容器，以及目前最流行的容器运行时和容器管理工具Docker；并且在此过程中体会了容器技术给软件开发和部署带来的极大的便利性。 但到此为止，我们对容器的使用和管理依旧处于非常“手工”的状态，难以胜任实际生产环境中对容器管理的要求。在实际生产环境中， 通常一个应用包含多个容器；即，一个应用的部署，需要按照一定的顺序启动多个容器。例如，即便是一个最简单的前后端应用，我们也需要依次启动三个容器：数据库容器（例如一个MySQL容器）、后端应用容器、前端应用容器（通常是一个Nginx容器）。特别是在微服务场景中，后端可能涉及到几十个微服务模块，每个模块都对应着一个容器，不同服务之间又有复杂的依赖调用关系。 每个类别的服务通常会有多个容器实例。对于一些负载较高的服务，通常会部署多个相同的容器实例达到负载均衡的效果，从而提高服务整体的吞吐量。 容器是不稳定的，随时可能会因为各种各样的原因挂掉，因此，需要时刻监控容器的状态，在它挂掉的时候及时重新启动服务，保证服务整体的高可用。 大部分应用都是分布式的。即，一个应用中的不同服务是部署在不同机器上的，即使是一个服务的不同实例往往也会部署在多个机器上。如何在多台机器上做好资源（内存、CPU、磁盘）的负载均衡（即，避免出现某些机器负载过高的同时，其他机器负载空闲的情况）也是棘手的问题。 如果仅靠我们已经学到的几个docker命令显然是难以完成上述任务的。这就需要一个专门的容器编排调度工具帮我们处理这些事情。自Docker兴起后，很多厂商都进入该领域并推出了自己的容器编排调度解决方案，例如Docker Swarm、Mesos等，都想在新兴的容器市场中分一杯羹，但最终Kubernetes笑到了最后，并且作为CNCF的毕业项目，成为了当下容器编排调度领域的事实标准。本次实验我们就来认识一下Kubernetes，学习并实践其中一些基本概念。 Kubernetes以其复杂难懂著称，在本次实验中，我们主要学习其中最基本的部分，培养大家对Kubernetes的感性认识，帮助大家开始入门云计算领域。 初识Kubernetes # Kubernetes简介 # Kubernetes在希腊语中的含义是船长/领航员，这个名字生动地体现了它在容器集群管理中的作用——调度和监控全局的集装箱（container，容器）。由于Kubernetes这个单词太长，人们通常会用k8s来作为简称（Kubernetes的首尾两个字母之间正好有8个字母）。 请始终记住，Kubernetes和Docker之类的容器运行时不是互相替代的关系，也不是包含与被包含的关系，而是互补的关系。Kubernetes仅仅是一个容器编排和调度工具，其必须运行在“容器运行时（container runtime）”之上。它能做的仅仅是接收用户的命令，然后通知其下层的容器运行时做具体的工作。 上图可以看出，在之前，我们是直接通过Docker命令行或Docker HTTP接口来与Docker容器运行时通信，控制其构建镜像、推送或拉取镜像、启动或停止容器，等等。 而现在，我们可以通过Kubernetes的命令行工具（即Kubectl）或Kubernetes的HTTP接口来控制Kubernetes，然后，Kubernetes会根据我们发出的命令，“翻译”成对应的Docker容器运行时的调用，从而控制Docker容器运行时构建镜像、推送或拉取镜像、启动或停止容器等等。 另外，请注意，Kubernetes是一个非常模块化的系统，它定义了一套“容器运行时接口（CRI）”，凡是实现了这套接口的容器运行时都可以作为Kubernetes运行容器的后端。目前比较流行的有Containerd和CRI-O，实际上，从1.20版本开始，Kubernetes官方已经弃用Docker引擎作为容器运行时。 所谓“Kubernetes官方已经不再支持使用Docker作为容器运行时”，其实指的是Kubernetes官方不再维护Docker的CRI层。但由于历史惯性等原因，很多Kubernetes的下游发行版都会选择继续提供对Docker的支持（当然，这得益于Kubernetes本身与容器运行时的解耦）。 在本次实验中，为了前后知识的连贯性，我们依旧选择使用Docker作为Kubernetes的容器运行时。 创建Kubernetes集群 # 在Kubernetes官网的 Get Started中，分别给出了面向个人初学者的学习测试环境和一线生产环境的若干Kubernetes集群部署方法。对于生产环境， Kubernetes官方推荐使用 kubeadm来启动集群。但实际上，kubeadm对非专业的运维，特别是初学者来说并不十分友好（需要用户事先完成对主机的一系列配置，如开放防火墙端口、关闭swap、安装容器运行时等），再加上国内特殊的网络环境，因此不推荐初学者直接使用 kubeadm启动集群。 云计算生态非常繁荣，社区中已经有很多成熟的工具帮助用户快速启动一个标准的Kubernetes集群用于学习、测试等目的。本实验文档分别针对集群版和本地版提供创建Kubernetes集群的选项，供大家参考和使用。 集群版 # 推荐使用此种方式创建集群，这样有利于在后续章节中学习和实践Kubernetes“集群”的相关特性。如确实有问题，可以切换到个人电脑上使用“单机版”的方式。 在本次实验中，我们将部署一个简单的 k3s（注意，不是“k8s”哦！）集群。k3s是通过CNCF认证的Kubernetes的一个发行版，是基于上游的“原生”的Kubernetes的代码进一步构建的。k3s和Kubernetes的关系可以简单类比为Ubuntu、CentOS等于Linux之间的关系。你可以在这里找到k3s官方维护的 k3s的中文文档。 实际上，还有很多其他的Kubernetes发行版，比如k0s之类的。只不过k3s的中国化做得非常好，在国内的网络环境下使用非常便利，也有大量的资料可以使用，所以我们选用其作为本次实验的主要工具。当然，不同Kubernetes发行版之间存在着各种各样的差异，但这并不影响我们学习Kubernetes的基础知识。 准备一台能够连接互联网的Linux机器。如果你选择使用软院云平台分配的机器，可以直接进行下一步；否则，请查看 安装要求，确保你的机器满足其中所述条件。 保证你的机器已经连接互联网。 切换到root用户（如果你觉得root操作危险，请保证自己有足够的能力使用普通用户权限完成所有操作） sudo -i 安装 Docker curl -fsSL https://get.docker.com/ -o get-docker.sh && sh get-docker.sh --mirror Aliyun 确保机器已经安装Docker，并且其版本高于或等于 19.03，可以使用 docker info 命令验证，请注意是否正确配置 Docker Registry 镜像地址，以保证可以顺利从 docker.https://scs.buaa.edu.cn/doc/cloud-labs/cloud/kube-single-4/Mon, 01 Jan 0001 00:00:00 +0000https://scs.buaa.edu.cn/doc/cloud-labs/cloud/kube-single-4/Kubernetes进阶实验 # 实验目的 # 了解Kubernetes的各种特性 熟悉Kubernetes的进阶使用 Pod Controller # 在介绍容器的时候我们提到过，container是脆弱的。在实际的生产环境中，container中运行的进程很可能因为各种各样的原因挂掉（比如JVM进程OOM），这时候，快速恢复业务的方法是重新启动一个新的容器实例。 另一方面，为了实现负载均衡或并行计算，我们需要维护相同的多个容器实例，来共同完成任务。 上述两方面的讨论，归结起来可以表示为：在集群中维护一定数量的容器实例。 纯粹由人工来维护一定数量的容器实例当然是可以的，但那将是十分低效和不可靠的。Kubernetes给出了一种新的解决方法——Pod Controller，来解决这一问题。 在学习Pod Controller之前，我们先来了解一下Kubernetes中的Controller机制。 Controller # 在这里引用Kubernetes文档中给出的关于控制器的讨论： 在机器人技术和自动化领域，控制回路（Control Loop）是一个非终止回路，用于调节系统状态。 这是一个控制环的例子：房间里的温度自动调节器。 当你设置了温度，告诉了温度自动调节器你的期望状态（Desired State）。 房间的实际温度是当前状态（Current State）。 通过对设备的开关控制，温度自动调节器让其当前状态接近期望状态。 和上述提到的“温度自动调节器”类似，Kubernetes中的控制器（Controller）将会监控当前集群中的状态，并努力使集群的当前状态满足用户设置的目标状态。 Pod Controller # Pod Controller，顾名思义，就是用于调节集群中当前Pod状态的Controller。下面，我们依次来介绍几种Kubernetes最常用的Pod Controller。 Deployment # Deployment的主要作用是努力使当前集群中的Pod数量与用户期望的状态相同。 我们先来看一个简单的Deployment的YAML定义： apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 selector: matchLabels: kkk: hahaha template: metadata: labels: kkk: hahaha kubernetes: yyds spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 apiVersion、kind、metadata都是Deployment的元信息配置，与Pod中的写法非常类似，不再赘述。https://scs.buaa.edu.cn/doc/cloud-labs/cloud/paas_course_design/Mon, 01 Jan 0001 00:00:00 +0000https://scs.buaa.edu.cn/doc/cloud-labs/cloud/paas_course_design/PaaS 云平台课程设计 # 背景 # 今天，大型单体应用正被逐渐分解成小的、可独立运行的组件，我们称之为微服务。微服务彼此之间解耦，所以它们可以被独立开发、部署、升级、伸缩。这使得我们可以对每一个微服务实现快速迭代，并且迭代的速度可以和市场需求变化的速度保持一致。每个微服务所需的资源都不会太多，也解决了日渐庞大的单体应用难以部署的问题。 然而，随着微服务的数目越来越多，管理和部署它们就变得越来越困难，不同的微服务还可能依赖不同的组件库。于是，容器技术和容器编排平台 k8s 横空出世。k8s 是集群的操作系统，帮助开发者纳管底层基础设施，内部实现的调度算法帮助运维团队获取更高的资源利用率。使用 k8s，开发者可以更方便地部署应用，并且可以通过设置副本来保持应用的高可用，k8s 还会对出错的容器组自动修复。 诚然 k8s 给运维带来了巨大的便利，但 k8s 在实际使用中仍然存在着一些痛点： 搭建 k8s 集群的步骤比较繁琐 k8s 的操作接口仍不够友好，编辑并应用多个 yaml 文件，有时只为了完成一个操作 功能不够全，还不足以满足实际使用的需要 如图所示，一个完整的开发流程应该包括：应用开发、代码托管、CI/CD、镜像托管、运行部署、观测告警等，k8s 主要提供的是“运行部署”的这部分功能。因此很多企业也根据 k8s 的以上痛点，在 k8s 之上搭建一些 PaaS 平台，借助 k8s 强大的资源管理能力，封装出更加人性化的用户接口，提供更多拓展的功能，以满足企业级应用的需要。比较有代表性的 PaaS 平台是 kubesphere 和 openshift。 在本次实践中，你们将负责为软件学院的老师同学们设计和实现一个云 PaaS 平台，它将容器化技术与 k8s 结合，为同学们提供一个便捷的方式来提交、编译、部署和运行他们的作业。这个平台的基本功能是将整个作业的生命周期从源代码提交到可运行的服务都自动化。除此之外，你也可以添加额外的租户管理、存储管理、DevOps、日志与监控告警等功能。 实验要求 # 下面描述了 PaaS 平台的一些基础功能点和进阶功能点，希望同学们先专注于设计实现基础功能，等基础功能完成后再去挑战进阶功能，进阶功能为选做。 对于基础功能点，完成它的要求为： 编码实现，提供前端页面和后台逻辑，可以完整流畅地使用这个功能 对于进阶功能点，除了编码实现外，你也可以选择以下两种方式完成它： 给出技术选型，可以使用原型图、架构图、流程图等形式，说明这一功能端到端的流程是怎样工作的。 给出需求分析，编写用例表，并在表格中详细描述主要流程和子流程，给出数据规约，必要时提供活动图。 基础功能 # 镜像管理 平台需要提供镜像管理功能，具体应包含以下用例： 学生可以在平台创建一个私有镜像，可以提供包含 Dockerfile 的源代码（可以是代码的压缩包，也可以是一个代码仓库地址等等），或可以提供镜像的压缩包，或可以直接让平台去拉取公共仓库里的镜像 学生可以浏览、删除自己的镜像，也可以提供一个 Dockerfile 修改某个镜像 平台还应该提供一个公共镜像库，内置一些非常常用的镜像，如：Nginx、MySQL、Redis、WordPress 等，让用户可以直接使用它们 Hint：在镜像管理部分，可以自己在本地通过 Docker Image 管理，也可以考虑搭建一个私有的 Docker Registryhttps://scs.buaa.edu.cn/doc/cloud-labs/cloud/data_analysis/Mon, 01 Jan 0001 00:00:00 +0000https://scs.buaa.edu.cn/doc/cloud-labs/cloud/data_analysis/大数据分析实践 # 背景 # 虽然过去人们研究了与预期寿命相关的多个因素，包括人口统计、收入构成和死亡率等，但免疫和人类发展指数等因素并未被充分考虑。此外，过去的研究多数基于全国范围内一年的数据集进行多元线性回归分析。因此，世界卫生组织（WHO）下属的全球卫生观察站（GHO）数据库跟踪了全球众多国家的健康状况以及许多其他相关因素，现向公众开放一份关于免疫、健康、经济、社会和其他因素的数据集。数据集中综合了 2000 年至 2015 年 193 个国家的数据，由于一些不太知名的国家的数据查找较困难，如瓦努阿图、汤加、多哥、佛得角等，因此该数据集中已排除这些国家，最终由 22 列、2938行组成，特征如表 1 所示。 本次实践需要你在 k8s 上搭建一个 Hadoop 平台，并使用 Hive 等工具对上述数据集进行分析。数据集在 这里 下载，数据集来源： Kaggle。 实验要求 # 在 k8s 上搭建一个 Hadoop 平台，并通过 Hive 对上述数据集进行分析，下面列举了一些值得关注的问题： 数据集中各种因素是否都会影响预期寿命？实际上影响寿命的是哪些变量？ 一个预期寿命较低的国家（<65岁）是否应增加其医疗支出以提高平均寿命？ 婴儿和成年人的死亡率如何影响寿命？ 预期寿命与饮食习惯、生活方式、锻炼、吸烟、饮酒等因素之间是否存在正相关或负相关？ 教育对人类寿命有何影响？ 预期寿命与饮酒之间是否存在正相关或负相关关系？ 人口密集的国家是否倾向于具有较低的预期寿命？ 免疫接种覆盖率对预期寿命的影响是什么？ 你也可以自行选择一些自己感兴趣的问题来研究，要求至少写出 2 个问题的分析过程。 实验步骤 # 使用助教团队提供的镜像启动一个 Hive 容器组，其中 hive-deployment.yaml 文件在 这里 获取 kubectl apply -f hive-deployment.yaml 暴露端口到宿主机上，这个文件是把 Hive 容器的 10000 端口映射到主机的 30000 端口，10002 端口映射到主机的 30002 端口，你可以根据需要修改，其中 hive-service.yaml 文件在 这里 获取https://scs.buaa.edu.cn/doc/cloud-labs/cloud/faq/Mon, 01 Jan 0001 00:00:00 +0000https://scs.buaa.edu.cn/doc/cloud-labs/cloud/faq/ FAQ #