云原生2.0时代已经到来IDC发布《IDC FutureScape: 全球云计算2020 年预测——中国启示》显示，云原生应用所影响的领域正逐渐从互联网走向非互联网，从传统应用升级走向云原生。当下，云原生技术的成熟正极大地影响着个人、企业乃至整个社会的生产生活方式。为进一步推进云原生技术的普及，帮助广大技术爱好者快速掌握云原生相关技能，让学员具备云原生系统基础管理动手能力，华为云学院联合CNCF、华为云云原生团队重磅推出《华为云云原生王者之路集训营》系列课程。继《黄金系列》课程之后，在30000+黄金课程学员的呼声和期待下，华为云学院宣布：云原生王者之路《钻石系列》课程预备上线，钻石集训营正式开始啦！   黄金课程学员学习心得学员A：作为云原生基础教学，云原生黄金课程能够让人快速了解概念，具备初步动手能力，沙箱实验很棒，可以实践锻炼，学以致用！学员B：从基础的微服务K8S等理论知识，到K8S集群管理、服务管理等进阶知识，我学到很多，期待钻石进阶课程。学员C：这次学习让我了解了什么是云原生，跟随云原生大佬学习k8s，入股不亏，钻石课程快来吧！  钻石系列课程简介钻石系列课程由华为云云原生核心团队11名大咖讲师倾心打造，在黄金系列课程的基础上，对云原生技术底层原理进行深度剖析，包括Kubernetes的运行时、调度、网络、存储、运维等核心技术原理和主流方案架构，Istio的控制面、数据面、流量治理、传统微服务框架接入等技术原理和方案架构，同时精选多个企业典型应用场景，作为学员上机实践案例，帮助学员将所学技术快速与企业业务相结合，服务于企业生产。钻石集训营将以直播课程与专家答疑同步的方式，带着大家进行在线学习，帮助大家在云原生技术进阶之路上学的更轻松！   集训营特邀专家大咖阵容本阶段钻石系列课程由11位华为云云原生领域大咖专家倾力打造，全面深入地对云原生的知识体系剖析。   集训营面向对象1.计算机、软件工程等专业的大学生2.涉及Kubernetes、Istio等技术的应用开发者3.其他的云原生技术兴趣爱好者  集训营直播安排直播课程期间，每晚19-20点专家讲师进行课程直播与在线答疑，次日10点可在华为云学院解锁直播课程回看。  集训营亮点4大任务：课程学习+实战演练+认证实践+结业考核5大亮点：1.黄金-钻石-王者系统化课程，带你进阶化提升2.精选典型应用场景，理论实践相结合，多阶考核与测验3.华为云云原生团队核心架构师授课带学、答疑解惑4.云原生专属学习圈，每日打卡，教辅相伴，升阶无忧5.学练考一站式，课程、实验、微认证等多元化学习体验   集训营丰富好礼参与课程学习打卡，赢价值200USD HCIA职业认证考试券、华为手环B6、筋膜枪、富士INSTAX 一次成像相机、雷柏机械键盘、华为手环4e、微认证代金券、沙箱实验点折扣券等超丰富奖品！训练营学员还可享有CKA/CKAD/CKS认证套购8.5折，单独购买9折优惠！  报名时间及方式登录“华为云学院”,从 “云原生王者之路钻石集训营”活动页进入，点击“立即报名”即可报名成功。添加小助手微信HWcloudedu，备注“云原生”加学习群，心动不如行动，快去报名吧！ 课程详情请扫描下方二维码了解，参与日期截止至8月12日，课程免费向开发者开放，名额有限，招满即止，还等什么，马上占位吧！   

冒泡排序:优点=>数据较少的容器，入门简单。缺点=>对于大规模的数据就显的效率较低冒泡排序=>简答来说就是前后数据比大小，(升序) i>i+1 交换位置。流程：1、比较相邻的俩个数，第一个值大于第二个则值交换,以此类推，完成第一次循环的次数为 arr.lenght-12、第一次的循环已经的得到最小的结果，下一次的循环拿下标为[1]的元素进行判断画图可以看的更清楚点冒泡动画这个据很细节了，第一次的循环时确定最小的那个值，第二次的循环确定第二小的.....代码实现: //定义需要排序的数组 var arr = [2, 4, 5, 3, 1]; //利用冒泡排序将原数组进行升序排列 for (var i = 0; i < arr.length - 1; i++) { for(var j=0;j<arr.length-1;j++) { if(arr[j]>arr[j+1]){ var temp = arr[j+1]; arr[j+1] = arr[j]; arr[j] = temp; } } } //输出排列后的数组 console.log(arr);快速排序思想=选择数组中间数作为基数，并从数组中取出此基数准备两个数组容器，遍历数组，逐个与基数比对，较小的放左边容器，较大的放右边容器；递归处理两个容器的元素，并将处理后的数据与基数按大小合并成一个数组，返回。不太懂得话上动画快速排序动画let quickSort = function (arr) { // 递归出口就是数组长度为1 if (arr.length <= 1) return arr //获取中间值的索引，使用Math.floor向下取整； let index = Math.floor(arr.length / 2) // 使用splice截取中间值，第一个参数为截取的索引，第二个参数为截取的长度； // 如果此处使用pivot=arr[index]; 那么将会出现无限递归的错误； // splice影响原数组 let pivot = arr.splice(index, 1)[0], left = [], right = []; console.log(pivot) console.log(arr) for (let i = 0; i < arr.length; i++) { if (pivot > arr[i]) { left.push(arr[i]) } else { right.push(arr[i]) } } return quickSort(left).concat([pivot], quickSort(right)); } //let arr = [2, 9, 6, 7, 4, 3, 1, 7] // console.log(quickSort(arr))参考文章:https://juejin.cn/post/6856546833025237006#heading-5

【问题来源】    星网    【问题简要】    所有服务的部署是否可以支持docker容器化部署【问题类别】    服务安装    【AICC解决方案版本】    AICC 8.13.0       【期望解决时间】  今日内【问题现象描述】           用户想知道所有服务的部署是否可以支持docker容器化部署

docker run -u root --rm -d -p 8080:8080 -p 50000:50000 -v jenkins-data:/var/jenkins_home -v /var/run/docker.sock:/var/run/docker.sock \ jenkinsci/blueocean 也可以先把镜像下载到本地，然后再执行docker run docker pull jenkinsci/blueocean容器安装的好处是简单，不容易出错。root@ecs-385f:~# docker run  -u root  --rm  -d  -p 8080:8080  -p 50000:50000  -v jenkins-data:/var/jenkins_home  -v /var/run/docker.sock:/var/run/docker.sock  jenkinsci/blueocean Unable to find image 'jenkinsci/blueocean:latest' locallylatest: Pulling from jenkinsci/blueocean540db60ca938: Pull complete 2a961b9363b0: Pull complete d6a479880c83: Pull complete 8eaeff69d97a: Pull complete 351ca2eaf86b: Pull complete f6c722701e33: Pull complete 2e4f785df836: Pull complete d3df0c4abbde: Pull complete bc5608b67244: Pull complete 3f8e7265de76: Pull complete b43472033709: Pull complete 8c8d6280a0e7: Pull complete a1ce0802fc1d: Pull complete 8fe1c5ba0c97: Pull complete d29f411ffa58: Pull complete 0bf0f39d44a7: Pull complete Digest: sha256:38bcb5122b85482dec0c3dfd6ba29bdc3e8c9a2eb43258f670096e0b4cbfcb2eStatus: Downloaded newer image for jenkinsci/blueocean:latest164454a8906fe71a35467704f161813f198860f8f878870aa3a60ae68e7b6a1broot@ecs-385f:~# docker psCONTAINER ID        IMAGE                                COMMAND                  CREATED             STATUS                  PORTS                                              NAMES164454a8906f        jenkinsci/blueocean                  "/sbin/tini -- /usr/…"   13 seconds ago      Up 11 seconds           0.0.0.0:8080->8080/tcp, 0.0.0.0:50000->50000/tcp   distracted_bartikroot@ecs-385f:~# curl 114.115.168.136:8080<html><head><meta http-equiv='refresh' content='1;url=/login?from=%2F'/><script>window.location.replace('/login?from=%2F');</script></head><body style='background-color:white; color:white;'>Authentication required<!----></body></html>                                                                                                                                                                                                                                                                                                            root@ecs-385f:~# 浏览器访问EIP：8080root@ecs-385f:~# cat /var/jenkins_home/secrets/initialAdminPasswordcat: /var/jenkins_home/secrets/initialAdminPassword: No such file or directory没有这个文件是因为Jenkins并没有部署在ecs上，而是部署在容器里。root@ecs-385f:~# docker exec -it 164454a8906f sh/ # cat /var/jenkins_home/secrets/initialAdminPassword8f92c205facbxxxx11849b1a13e655/ # 复制上述字段到Jenkins登录页面。提示安装插件的界面：

云原生和云工作负载的演进云计算发展之大成，来自于处理器、存储、网络等几个关键计算要素的交替迭代进步；而云计算的部署使用模式，跟历史上的交流电和自来水一样，目标是把计算能力发展成随用随取的市政资源。这将是 IT 基础设施的一次变革，其颠覆性发展，带来了使用“云原生”应用的需求，也带来了对安全机制“云原生”的需求。“云原生（Cloud Native）”一词，经常被作为形容词定语，冠在不同子领域名词前面，引来了很多理解上的困惑。从云租户的视角来看，他们关心的是要运行于云上的应用和业务，以及最重要的，要付多少钱。因此，如果以业务、应用作为讨论的基础，那么宽泛的说，“云原生”描述的是充分利用原生云能力（自动扩展、无中断部署、自动化管理、弹性，等等）来进行应用设计和部署的方法。在这个形而上的框架下，微服务、容器技术、云数据库技术、K8S、弹性搜索、遥测（Telemetry）等，都是形而下的技术。简单的把原有企业网的环境和虚机迁移到 IaaS 云里，或者把原有单一应用（monolithic application）直接打包到虚机里运行，乃至做些 API 对外提供接口，这些做法离云原生都还远。为了实现“云原生”属性，云应用需要在发布、服务方式、随需弹性、数据和工作负载（workload）管理等多方面都重新构建。所谓工作负载，是对运行应用所需要的资源和进程的抽象化定义。最初的工作负载形式就是物理服务器。随着 IDC 走向虚拟化，工作负载演进为虚拟机形式。到今天，云服务中容器成为工作负载的主流，而正在出现和发展的工作负载新形式 Serverless（无服务程序），直接对应用 run-time 虚拟化，改变了传统意义上的服务进程监听-运行模式，是更加精细粒度的瞬态工作负载（ephemeral Workload）。可见随着云计算和云原生需求的发展，云工作负载的形式越来越抽象灵活，同时其部署和运行的生命周期也可越来越短。多种形式和生命周期的云工作负载会长期共存，目前并没出现彼此淘汰的情况，同时这些演进和共存，也使得抽象化定义很有必要。云原生带来的云安全领域变化安全机制一直是跟随 IT 基础设施和业务来为其服务的，云安全也不例外。其保护的对象就是面向访问和使用云系统、云应用的流程机制。与传统企业网络安全机制显著不同的是，云安全的管理责任由云运营商和用户共同分担。更重要的是，传统物理边界变得模糊后，安全不再围绕企业数据中心和终端来设计部署，安全边界也不再是数据中心边缘和企业网边缘的某个盒子。在云计算时代，应该基于以数据为中心（Data-centric）的原则来部署安全，关心的问题应该是：谁，能访问什么业务和数据，应该授予何种访问权限，为什么需要这些权限，在授权范围访问是如何进行的，等等，而不再是“业务在哪里”和“边界在哪里”。换句话说，传统安全边界变成了无处不在的边界能力——动态创建、策略强化、权限管控、安全访问。云原生环境对安全在业务、管理和部署上的关键要求包括：云业务持续不断的交付要求，需要持续不断的安全保障。亚马逊、沃尔玛等级别的云用户的更新部署要求可达每日数百次，弹性和无中断成为标配要求，因此安全必须也做到轻量化、持续不断，并嵌入部署工具中各个环节来确保成为“检查点”。对工作负载（Workload）的安全防护是必须的，而且要随着工作负载的演进而不断演进。传统企业安全防护，端点、网络、边界，各个层级相对清晰，而云环境下，这些边界界限变得很模糊，承载计算的工作负载则是直面威胁的对象。因此，工作负载的安全，是一个需要横向保护多种负载，也需要纵向对每类负载深入做好保护的问题。对多系统和混合栈的支持，以及自动化配置。云安全要考虑到云的公有、私有、混合等形态，也要考虑云工作负载的多样性和演进，同时还需要支持多种操作系统。而云应用带来的配置复杂度，让自动化要求在云原生的背景下有格外重要的意义。从责任共享和云原生要求这两个角度出发，云安全产品可以简单直观的分成三大类：第一类是对云原生要求不高的传统安全产品，比如防火墙、防入侵、端点安全、服务器监控、终端检测响应和 SIEM 等，云运营商可直接将第三方安全产品部署上云。第二类是云运营商为配套云服务而提供的安全产品，也可称为“云运营商原生提供的安全（Native Cloud Security）”。常见的有威胁检测、云数据库安全、API 安全、容器和工作负载安全、用户行为监控、合规与风险管理等。一般由运营商从第三方购买整合或自己开发。第三类则是基于云原生应运而生的“新安全”产品和服务。与云天生具有较好的亲和力，比如云工作负载保护平台 CWPP（Cloud Workload Protection Platform）、云安全态势管理 CSPM（Cloud Security Posture Management）、云访问安全代理 CASB（Cloud Access Security Broker）、微隔离 Micro-segmentation，等等。第一类是传统安全厂商的静态存量市场（搬一块少一块），第二类和第三类则是云安全市场的创新和整合频繁出现的地方，创业公司层出不穷，安全大厂并购频繁，云运营商也亲自下场买买买，因此这是安全厂商的机会所在。CWPP 与 CSPM：数据面和控制面的分工与合作CWPP 的能力集和分类根据 Gartner 的定义，云工作负载保护平台 CWPP，意指在现代混合多云数据中心架构下，以租户的云工作负载为中心的安全机制。CWPP 是 IaaS 安全的关键环节之一，也是促进企业“上云”的保障。时至今日，随着云工作负载保护在云计算中重要性的提升，CWPP 已经与传统大户——终端安全防护 EPP（Endpoint Protection Platform）分庭抗礼。2019 年全球的 CWPP 市场收入为 12.44 亿美元，在 2018 年 10 亿美元的基础上，增长超过 20%。三个最大的玩家分别是：趋势科技、赛门铁克和 McAfee，占一半的营收。2020 年 4 月 Gartner 发布的 CWPP 市场指南对业界已经很熟悉的 CWPP 能力金字塔进一步精简，从最核心按重要性递减排序为八层：原有的文件加密和防病毒不再纳入：加固、配置和漏洞管理；基于身份的隔离和网络可视化；系统一致性保证；应用控制/白名单；预防漏洞利用和内存管理；服务器工作负载行为监测、威胁检测和响应；主机防入侵和漏洞屏蔽；扫描恶意软件。不同安全厂商针对特定领域，聚焦一种或多种能力，这也造就了 CWPP 具体产品实现的不同基因。Gartner 据此把厂商分成七大类：广泛能力和多系统支持，漏洞扫描和配置合规，基于身份的隔离和可视化与管控，应用管控与状态执行，服务器行为监测和威胁检测和响应，容器和 K8S 保护，以及对 Serverless 的保护。其中，志翔科技的至明®智能主机安全响应系统产品（ZS-ISA），对服务器、虚拟机和容器都能监测和保护，并支持基于用户角色的精细管控 RBAC 和安全可视化，因此被归类为 CWPP 中的“基于身份的隔离和可视化与管控”。CSPM：硬币的另一面软件定义业务（Software Defined X）已经在多个领域流行，如软件定义网络 SDN、软件定义广域网 SD-WAN、软件定义边界 SDP 等。控制面和数据面分离，是 SDX 中的一个重要概念。比如 SDN 的模型中，网络策略在控制面计算并下发到数据（转发）面，数据面不用具备复杂计算能力，直接执行策略做转发即可。控制面和数据面的分合逻辑关系，在处理器设计中有，在网络设计中有，在云安全中同样有。CWPP 和 CSPM 就是一对分别聚焦数据面和控制面的安全机制。CWPP 是对云工作负载进行保护，是对数据面的安全防护。CSPM 则聚焦控制面的安全属性，包括配置策略和管理工作负载、合规评估、运营监控、DevOps 集成、保障调用云运营商 API 完整性等等。当前几乎所有的云安全事件都涉及配置错误和管控失当，而涉及到 IaaS 和 PaaS 服务的配置复杂性和用户自助之普及，更凸显正确配置和合规的重要性，这就让控制面的安全机制变得越加重要。CSPM 和 CWPP 是同一块硬币的两面，对于保障云应用的实际运行，密不可分。CSPM 负责在云运营商提供的基础工具之外，强化控制面的安全，检查和强化正确的配置；CWPP 负责数据面的安全问题，保护好各种云工作负载，两者配合的目的，都是为了云计算业务的正常开展和租户敏感数据得到妥善保护。实际上这种“策略配置检查-策略下发执行-业务过程防护”的逻辑，其内在哲学与通信网络中的做法完全一致。数据面和控制面的云安全产品会融合组成解决方案来服务多种云和多租户。很有意思的是，从 CWPP 和 CSPM 的融合趋势来看，从 CWPP 往控制面发展的厂商很多，而反之则较少。笔者的解读是，CWPP 在操作系统、平台和网络层面有较多特性，属于“通才”基础能力，而 CSPM 往往是和某个云运营商在配置和 API 能力上深度绑定的。从通识教育向某个方向垂直发展，符合我们求知和教育的一贯做法，大学里大家都是先上公共基础课，再学专业基础课，最后本科高年级才到专业课。云安全在中国：IaaS 和混合云的安全仍是重点云计算市场的发展，在全球呈现出“美国”和“美国之外”两个板块的两极趋势。美国公有云和 SaaS 的发展，明显领先全球其他地区几个身位。中国的云计算和云安全市场，跟美国比存在较大差异，这其中有发展阶段的原因，建设习惯的原因，也有 IT 生态环境和竞争等原因。即使如此，我国在云计算整体大趋势上的发展，基本是与我国经济体量和发展水平对称的。到 2019 年，我国云计算的市场营收，仍以 IaaS 为主，至今 SaaS 还没有广泛流行。在云计算的下半场，公有云+私有云结合的混合云仍然会是中国云市场主要形态。互联网公司布局公有云，传统行业客户出于政策监管考虑，会选安全性和可控性更强的私有云/专有云，并需要深度定制的方案和服务支持。另一方面，无论中国还是美国，安全市场都看起来高度分散。美国 2019 年有 5000 余家安全企业，中国的对应数字是 3000 余家。随着云计算给信息基础设施带来的变革，加上 5G、物联网和传统产业数字化（产业互联网）的发展，“云原生”带来的是极为广阔的安全市场空间。因此高度分散和海量的安全企业，背后反映的是蓬勃发展的安全细分领域，以及资本市场对于安全企业的青睐。上市等活动在安全市场非常活跃，这种活跃还将会会随着云计算的普及持续多年。IaaS 和混合云的安全作为我国云计算市场一段时间内的重点，对安全生态有很强的促进作用。细分领域的厂商可以做深做精，而在全环节解决方案上，融合、合作、联盟就成为必然选项。比如，企业主要使用 IaaS 服务的算力来处理敏感数据，则选择上 CWPP 来保护云工作负载，并使用 CSPM 来保证配置无误，这两者的亲和力会进一步促进融合。又如，机器学习、可视化、用户实体行为分析（UEBA）等技术，会逐渐成为各项安全产品背后的技术，特别是提升日志分析、SIEM、特权账号管理的能力。再如，软件定义边界 SDP 和其演进出来的零信任安全框架，融合身份权限、访问控制、安全管理等，将成为新的云业务访问方式，逐渐取代传统 VPN 等。志翔科技的产品技术发展方向与以上行业发展方向正是一致的。志翔的至明智能主机安全响应系统（ZS-ISA）连续两年入选 Gartner CWPP 市场指南，也证明了我们在前瞻趋势方向判断上的准确和产品技术上的领先能力。后续，我们会在 CWPP 的微隔离、权限管控和可视化支持的基础上，继续增加主机监测响应、安全分析和机器学习能力，整合云原生 API 来提供适配头部云运营商的 CSPM 能力，并与合作伙伴一起构筑全环节安全防护能力。目前志翔云安全产品已服务于金融、能源电力、政法等多个领域，并将持续创新，助力政企“上云”和“云上”业务的可信安全体系构建。————————————————版权声明：本文为CSDN博主「CSDN资讯」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/csdnnews/article/details/107536630

【摘要】 kubectl常用命令：获取pod，查看pod相关信息，重启pod，上传下载pod中的文件等命令。1.        获取pod1)   获取指定命名空间的pod：kubectl get pods –n namespace2)   获取所有命名空间的pod：kubectl get pod --all-namespaces2.        重启podkubectl get pods -n namespace，获取到controller的NAME。1)   重启：kubectl delete pod xxx -n namespace （备注：xxx替换为上面获取的pod的NAME即可。）2)   强制重启：kubectl delete pod xxx --force --grace-period=0 -n namespace （备注：xxx替换为上面获取的pod的NAME即可。）3)   重启多个：a)     kubectl delete pod NAME1 NAME2b)     kubectl delete pod NAME1 NAME2 --force --grace-period=0 -n namespace3.        进入podkubectl exec -ti xxx /bin/bash –n namespace xxx替换为要进入容器的id4.        查看pod相关信息1)   describe查看pod版本等信息：kubectl describe pod 容器名字 -n namespace2)   查看pod端口：kubectl get service –n namespace3)   查看pod所在的node的IP地址：kubectl get pods –owide –n namespace5.        从本地拷贝文件到pod中1)   先上传文件到master节点2)   然后在master节点的上传的文件存放目录执行：kubectl cp 文件名 namespace/xxx:/tmp/文件名 （备注：xxx为容器名称）3)   如执行命令：kubectl cp dbs-iaasclient-1.4.1.jar default/dwscontroller-87859b8bc-k4wb9:/tmp/dbs-iaasclient-1.4.1.jar后，该文件就在了容器中的/tmp路径中了6.        从pod下载文件到本地中1)   先在pod中查看要下载文件的路径：2)  在master节点的执行：kubectl cp namespace/xxx:文件名 /master存放该文件的目录/文件名（备注：xxx为容器名称）如，执行命令kubectl cp dws/dwscontroller-c9d6f657d-ggk27:a.log /tmp/a.log后，该文件就在master的/tmp路径中了3)   再通过其他方式从master节点下载下来即可。想了解GuassDB(DWS)更多信息，欢迎微信搜索“GaussDB DWS”关注微信公众号，和您分享最新最全的PB级数仓黑科技，后台还可获取众多学习资料哦~转载来自：https://bbs.huaweicloud.com/blogs/266491

　1234<form>  <input name="name">  <input type="submit" value="提交"></form>以这种方式提交，input 值为22222222时，后面递交的url 就会变为localhost:3980/input.html?name=222222其中有些值得注意的细节：    设置type=submit后，输入控件会变成一个按钮，显示的文字为其value值，默认值是Submit。    form[method]默认值为GET，所以提交后会使用GET方式进行页面跳转。    input[type]默认值为text，所以第一个input显示为文本框。input其实是一个由输入控件改装过来的按钮，这源于Web早期的简陋设计。我们给它设置name便可以验证这一点：<input name='btn' value='提交' type='submit'>提交后的Url就会变为localhost:3980/input.html?name=222222&btn=提交注意其中的URL为/?key=foo&btn=ok。作为按钮的input控件同时被当做一个表单输入提交给了服务器。 它到底是交互控件还是数据控件呢？定位是有些不清晰。再加上它的样式难以定制、不可作为其他标签的容器， 所以建议不要用input作为表单提交按钮。注意：input的type属性还可以是button，这时它只是一个按钮，不会引发表单提交。2、button[tpe=submit]button的语义很明确，就是一个按钮不含数据，作用就是用户交互。但它也有type和value属性。 type的默认值是submit，所以点击一个button会引起表单提交：1234<form> <input name='key'> <button>确定</button></form>如果你在做IE浏览器的兼容，请记住button[type]在IE中的默认值是button，这意味着它只是一个按钮而不会引发表单提交。　　另外，我们通过设置元素内容的方式来指定button的文字。这意味着button是一个容器控件， 其中可以包含任意的HTML标签，同时样式更容易定制。这也是为什么Bootstrap 文档中大量使用button作为示例的原因之一。但是，button会很乱。button可以设置name和value。提交表单时，value会被作为表单数据提交给服务器。 在IE中，甚至会把button开始与结束标签之间的内容作为name对应的值提交给服务器。button和input的相似还不止于此，button也可以设置type=reset，此时点击按钮会导致表单被重置（这还挺有用的）。 w3school给出了如下的示例：123456<form action="form_action.asp" method="get"> First name: <input type="text" name="fname" /> Last name: <input type="text" name="lname" /> <button type="submit" value="Submit">Submit</button> <button type="reset" value="Reset">Reset</button></form>对于button就不多说了，建议用button作为交互用的按钮，来提交表单。同时请注意设置type=submit来兼容IE。回车键提交表单Enter键是可以提交表单的！但是你可能已经注意到了，并非所有的表单都可以用Enter键来提交。来看HTML2.0 标准：    When there is only one single-line text input field in a form, the user agent should accept Enter in that field as a request to submit the form.    当表单中只有一个单行的文本输入控件时，用户代理应当接受回车键来提交表单。“单行”指的是type为text而非textarea，显然在textarea中回车提交表单是怎样的难以接受。 其实在实践中，有多个单行的input也可以用Enter提交，比如登录页面。4.阻止表单提交阻止表单提交也是一个常见的话题，通常用于客户端的表单验证。通用的办法是设置onsubmit：1234<form onsubmit="return false;"> <input name='key'> <input value='ok' type='submit'></form>只需要在onsubmit的一系列语句最后返回false，便可以阻止它提交。 如果你希望调用一个方法来决定是否阻止提交，记得在此处返回方法的返回值：1234<form onsubmit="return false;"> <input name='key'> <input value='ok' type='submit'></form>

　　最近复习了一遍Spring IOC容器的初始化过程，结合书籍《Spring源码深度解析》总结了一下，IOC容器的初始化过程，大概分为以下三点：1、定位资源：　　定位相关的配置文件，扫描相关注解2、加载资源：　　将配置信息加载到内存中3、注册：　　根据载入的配置信息，初始化对象，并将其装载至容器中POM文件<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>org.example</groupId> <artifactId>springTest</artifactId> <version>1.0-SNAPSHOT</version> <dependencies> <!-- https://mvnrepository.com/artifact/org.springframework/spring-context --> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>5.0.2.RELEASE</version> </dependency> </dependencies> </project>测试代码public class ServiceB { public static void main(String[] args) { ApplicationContext context = new ClassPathXmlApplicationContext("spring.xml"); Object serviceA = context.getBean("serviceA"); System.out.println(serviceA); }xml配置<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context" xmlns:cache="http://www.springframework.org/schema/cache" xmlns:p="http://www.springframework.org/schema/p" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd http://www.springframework.org/schema/cache http://www.springframework.org/schema/cache/spring-cache.xsd"> <context:component-scan base-package="com.donkeys.spring"/> <bean id="serviceA" class="com.donkeys.spring.service.ServiceA"></bean> </beans>资源定位过程解析　　代码中，使用的是ClassPathXmlApplicationContext类去加载Sping的配置文件，所以先给出该类类图ClassPathXmlApplicationContext构造方法 public ClassPathXmlApplicationContext( String[] configLocations, boolean refresh, @Nullable ApplicationContext parent) throws BeansException { super(parent); //根据传入的配置文件名称，调用父类的setConfigLocations方法，解析配置文件路径, setConfigLocations(configLocations); //refresh = true //refresh() 方法会重启整个容器 if (refresh) { refresh(); } }　　构造方法中一共做了2件事，首先是设置配置文件的路径，然后对整个容器进行刷新。　　这里我们重点关注refresh()方法；进入refresh()方法AbstractApplicationContext类的refresh()方法@Override public void refresh() throws BeansException, IllegalStateException { synchronized (this.startupShutdownMonitor) { // Prepare this context for refreshing. //为刷新前做准备 prepareRefresh(); // Tell the subclass to refresh the internal bean factory. //获取IOC容器，这里就是处理资源定位以配置文件加载/注册的方法 ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory(); // Prepare the bean factory for use in this context. prepareBeanFactory(beanFactory); try { // Allows post-processing of the bean factory in context subclasses. postProcessBeanFactory(beanFactory); // Invoke factory processors registered as beans in the context. invokeBeanFactoryPostProcessors(beanFactory); // Register bean processors that intercept bean creation. registerBeanPostProcessors(beanFactory); // Initialize message source for this context. initMessageSource(); // Initialize event multicaster for this context. initApplicationEventMulticaster(); // Initialize other special beans in specific context subclasses. onRefresh(); // Check for listener beans and register them. registerListeners(); // Instantiate all remaining (non-lazy-init) singletons. finishBeanFactoryInitialization(beanFactory); // Last step: publish corresponding event. finishRefresh(); } catch (BeansException ex) { if (logger.isWarnEnabled()) { logger.warn("Exception encountered during context initialization - " + "cancelling refresh attempt: " + ex); } // Destroy already created singletons to avoid dangling resources. destroyBeans(); // Reset 'active' flag. cancelRefresh(ex); // Propagate exception to caller. throw ex; } finally { // Reset common introspection caches in Spring's core, since we // might not ever need metadata for singleton beans anymore... resetCommonCaches(); } } }　　这里主要关注**obtainFreshBeanFactory()**方法/** * Tell the subclass to refresh the internal bean factory. * @return the fresh BeanFactory instance * @see #refreshBeanFactory() * @see #getBeanFactory() */ protected ConfigurableListableBeanFactory obtainFreshBeanFactory() { //刷新IOC容器 //这里使用了委派设计模式，父类定义了抽象的refreshBeanFactory方法，具体调用实现调用子类的refreshBeanFactory方法 refreshBeanFactory(); //获取一个新的容器 ConfigurableListableBeanFactory beanFactory = getBeanFactory(); if (logger.isDebugEnabled()) { logger.debug("Bean factory for " + getDisplayName() + ": " + beanFactory); } return beanFactory; }　　**obtainFreshBeanFactory()**方法总共干了2件事，　　重置容器，refreshBeanFactory()方法中会设置相关标志，清除旧的容器，同时为Spring上下文生成一个新的容器，获取一个新的容器AbstractRefreshableApplicationContext的refreshBeanFactory()方法　　下面我们进入**refreshBeanFactory()**方法/** * This implementation performs an actual refresh of this context's underlying * bean factory, shutting down the previous bean factory (if any) and * initializing a fresh bean factory for the next phase of the context's lifecycle. * 该方法会将之前的bean工厂全部关闭，并初始化一个全新的bean 工厂类 用于Spring 上下文的生命周期 * bean工厂就是IOC容器 */ @Override protected final void refreshBeanFactory() throws BeansException { //判断是否之前也有容器 //如果有就销毁掉 if (hasBeanFactory()) { destroyBeans(); closeBeanFactory(); } try { //创建一个新的工厂 DefaultListableBeanFactory beanFactory = createBeanFactory(); beanFactory.setSerializationId(getId()); customizeBeanFactory(beanFactory); //读取Bean对象的定义 //这里也是使用的委派设计模式 loadBeanDefinitions(beanFactory); synchronized (this.beanFactoryMonitor) { this.beanFactory = beanFactory; } } catch (IOException ex) { throw new ApplicationContextException("I/O error parsing bean definition source for " + getDisplayName(), ex); } }　　这里创建了新的容器工厂，同时将新的工厂传入了loadBeanDefinitions()方法中，下面来看一下在loadBeanDefinitions方法中具体做了什么操作。AbstractXmlApplicationContext的 loadBeanDefinitions(DefaultListableBeanFactory beanFactory)方法　　在AbstractRefreshableApplicationContext类的refreshBeanFactory方法中，调用了loadBeanDefinitions方法，但是这个方法它的一个抽象方法，具体实现应由子类去实现，我们在程序启动时，使用的ClassPathXmlApplicationContext类。根据文章开头的类图可以知道，这里会调用子类AbstractXmlApplicationContext的loadBeanDefinitions方法去完成本次加载@Override protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws BeansException, IOException { // Create a new XmlBeanDefinitionReader for the given BeanFactory. //使用默认的beanFactory去创建 XmlBeanDefinitionReader XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory); // Configure the bean definition reader with this context's // resource loading environment. //设置资源的加载环境 beanDefinitionReader.setEnvironment(this.getEnvironment()); //设置资源读取器 beanDefinitionReader.setResourceLoader(this); //设置实体解析器 beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this)); // Allow a subclass to provide custom initialization of the reader, // then proceed with actually loading the bean definitions. //初始化 bean对象定义读取器 initBeanDefinitionReader(beanDefinitionReader); //使用初始化完成的读取器，调用loadBeanDefinitions方法 loadBeanDefinitions(beanDefinitionReader); }　　总的来说，这里只干了一件事，那就是初始化配置//设置资源读取器 beanDefinitionReader.setResourceLoader(this); //初始化 bean对象定义读取器 initBeanDefinitionReader(beanDefinitionReader);　　设置资源读取器，这里设置的资源读取器就是当前这个对象本身　　通过类图我们可以发现我们这个类的顶级父类ApplicationContext，继承自DefaultResourceLoader这个类，该类实现了ResourceLoader接口，说明这个类的实例化对象本身是具有资源读取器的功能的　　初始化bean对象定义读取器，这里设置xml文件的校验方式　　下面我们继续看**loadBeanDefinitions(XmlBeanDefinitionReader reader)**方法protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException, IOException { //从子类对象中获取到资源定位 Resource[] configResources = getConfigResources(); if (configResources != null) { //XmlBeanDefinitionReader 读取器调用其父类的 reader.loadBeanDefinitions(configResources); } String[] configLocations = getConfigLocations(); if (configLocations != null) { reader.loadBeanDefinitions(configLocations); } }　　先看这一行//这行代码的具体实现是由子类完成的，通过类图可以知道AbstractXmlApplicationContext的子类为ClassPathXmlApplicationContext //这里主要将我们最开始在构造方法中设置好的配置文件进行返回 Resource[] configResources = getConfigResources();　　再看这一行//如果返回的配置文件不为空，就将返回的已经封装好的资源文件进行读取， if (configResources != null) { //XmlBeanDefinitionReader 读取器调用其父类的 reader.loadBeanDefinitions(configResources); }　　至此。资源文件定位过程已经加载完成。后续就是读取和注册。整个IOC容器加载过程中最重要的是读取过程，我们可以从刚刚的定位过程来看，虽然叫定位过程，但是其实就是一个配置文件读取器的初始化过程，这个过程会设置相关的解析策略以及校验策略。最终读取器生成后，就可以将我们早早设置好的配置文件载入然后进行读取。————————————————

运行容器（1）运行Nginx应用运行Nginx应用。[root@master ~]# cat nginx.yamlapiVersion: apps/v1 kind: Deployment metadata:   name: nginxspec:  replicas: 1   selector:     matchLabels:       app: nginx  template:     metadata:      labels:         app: nginx    spec:       containers:      - name: nginxapp-container        image: nginx:latest        imagePullPolicy: IfNotPresent        ports:         - name: nginxapp          containerPort: 80[root@master ~]# kubectl create -f nginx.yamldeployment.apps/nginx created（2）查看Pods验证Pods是否正常运行。[root@master ~]# kubectl get podsNAME                    READY   STATUS    RESTARTS   AGEnginx-75dcbbc897-c4xbp        1/1       Running    0            93s……（3）开放端口使用expose将service的80端口开放出去。[root@master ~]# kubectl expose deploy/nginx --port 80service/nginx exposed（4）测试Nginx应用[root@master ~]# kubectl get svcNAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGEkubernetes       ClusterIP     10.96.0.1         <none>        443/TCP   3h18mnginx           ClusterIP     10.100.220.6      <none>        80/TCP    9s[root@master ~]#  curl 10.100.220.6:80……<h1>Welcome to nginx!</h1><p>If you see this page, the nginx web server is successfully installed andworking. Further configuration is required.</p><p>For online documentation and support please refer to<a href="http://nginx.org/">nginx.org</a>.<br/>Commercial support is available at<a href="http://nginx.com/">nginx.com</a>.</p><p><em>Thank you for using nginx.</em></p></body></html>使用curl工具可以成功获取到Nginx网页信息，说明80端口已开放成功。3.3.Kubernetes运维（1）Node的隔离与恢复在硬件升级、硬件维护等情况下，需要将某些Node隔离。使用kubectl cordon <node_name>命令可禁止Pod调度到该节点上(单节点不需执行)，在其上运行的Pod并不会自动停止，管理员需要手动停止在该Node上运行的Pod。[root@master ~]# kubectl cordon node查看Node的状态，可以观察到在node的状态中增加了一项SchedulingDisabled，对于后续创建的Pod，系统将不会再向该Node进行调度。[root@master ~]# kubectl get nodes通过kubectl uncordon命令可完成对Node的恢复。[root@master ~]# kubectl uncordon node[root@master ~]# kubectl get nodes可以看到Node节点已恢复调度，允许Pod调度到该节点上。通过kubectl drain <node>命令可实现对node节点的驱逐，该命令会删除该节点上的所有Pod（DaemonSet除外），在其他Node上重新启动它们。（2）Pod动态扩容和缩放在实际生产系统中，经常会遇到某个服务需要扩容的场景，也可能会遇到由于资源紧张或者工作负载降低而需要减少服务实例数量的场景。此时可以利用kubectl scale deployment命令来完成这些任务。通过执行下面的命令将Nginx Deployment控制的Pod副本数量从初始的1更新为5。[root@master ~]# kubectl scale deployment nginx --replicas=5deployment.extensions/nginx scaled执行kubectl get pods命令来验证Pod的副本数量增加到5。[root@master ~]# kubectl get podsNAME                    READY   STATUS    RESTARTS   AGEnginx-ccb467dc5-2f6n2   1/1     Running   0          34s......将--replicas设置为比当前Pod副本数量更小的数字，系统将会“杀掉”一些运行中的Pod，即可实现应用集群缩容。[root@master ~]# kubectl scale deployment nginx --replicas=2deployment.extensions/nginx scaled[root@master ~]# kubectl get podsNAME                    READY   STATUS    RESTARTS   AGEnginx-ccb467dc5-bl4jp   1/1     Running   0          2m50snginx-ccb467dc5-jlr4c   1/1     Running   0          5m21s（3）应用滚动升级当集群中的某个服务需要升级时，需要停止目前与该服务相关的所有Pod，然后重新拉取镜像并启动。如果集群规模比较大，这个工作就变成了一个挑战。如果采取先全部停止，然后逐步升级的方式，会导致较长时间的服务不可用。Kubernetes提供了rolling-update（滚动升级）功能来解决上述问题。滚动升级通过执行kubectl rolling-update命令一键完成，该命令创建了一个新的Deployment，然后自动控制旧的Deployment中的Pod副本数量逐渐减少到0，同时新的Deployment中的Pod副本数量从0逐步增加到目标值，最终实现了Pod的升级。注意：系统要求新的Deployment需要与旧的Deployment在相同的命名空间（Namespace）内，即不能把别人的资产偷偷转移到自家名下。下面的示例在第一次部署时使用httpd:2.2.31，然后使用滚动升级更新到httpd:2.2.32。定义httpd.yaml文件。[root@master ~]# cat httpd.yamlapiVersion: apps/v1kind: Deploymentmetadata:  name: httpdspec:  selector:     matchLabels:       app: httpd  replicas: 3  template:    metadata:      labels:        app: httpd    spec:      containers:        - name: httpd          image: httpd:2.2.31          imagePullPolicy: IfNotPresent          ports:            - containerPort: 80启动Deployment。[root@master ~]# kubectl create -f httpd.yaml deployment.apps/httpd created[root@master ~]# kubectl get podsNAME                     READY   STATUS    RESTARTS   AGEhttpd-5ddb558f47-46tf5   1/1     Running   0          49shttpd-5ddb558f47-5dg96   1/1     Running   0          49shttpd-5ddb558f47-672sk   1/1     Running   0          49s查看Deployment。[root@master ~]# kubectl get deployments httpd -o wideNAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTORhttpd    3/3      3           3        93s    httpd     httpd:2.2.31  run=httpd可以看到，IMAGES为httpd:2.2.31。把配置文件中的httpd:2.2.31改为httpd:2.2.32，再次启动。[root@master ~]# cat httpd.yaml apiVersion: apps/v1kind: Deploymentmetadata:  name: httpdspec:  selector:     matchLabels:       app: httpd  replicas: 3  template:    metadata:      labels:        app: httpd    spec:      containers:        - name: httpd          image: httpd:2.2.32          imagePullPolicy: IfNotPresent          ports:            - containerPort: 80[root@master ~]# kubectl apply -f httpd.yamlWarning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl applydeployment.apps/httpd configured再次查看Deployment。[root@master ~]# kubectl get deployments httpd -o wideNAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTORhttpd    3/3      3       3            7m53s   httpd   httpd:2.2.32  run=httpd查看Deployment的详细信息。[root@master ~]# kubectl describe deployment httpd…...Events:  Type    Reason             Age   From                   Message  ----    ------             ----  ----                   -------  Normal  ScalingReplicaSet  22m   deployment-controller  Scaled up replica set httpd-5ddb558f47 to 3  Normal  ScalingReplicaSet  15m   deployment-controller  Scaled up replica set httpd-8bdffc6d8 to 1  Normal  ScalingReplicaSet  14m   deployment-controller  Scaled down replica set httpd-5ddb558f47 to 2  Normal  ScalingReplicaSet  14m   deployment-controller  Scaled up replica set httpd-8bdffc6d8 to 2  Normal  ScalingReplicaSet  14m   deployment-controller  Scaled down replica set httpd-5ddb558f47 to 1  Normal  ScalingReplicaSet  14m   deployment-controller  Scaled up replica set httpd-8bdffc6d8 to 3  Normal  ScalingReplicaSet  13m   deployment-controller  Scaled down replica set httpd-5ddb558f47 to 0上面的日志信息就描述了滚动升级的过程：① 启动一个新版Pod。② 把旧版Pod数量降为2。③ 再启动一个新版，数量变为2。④ 把旧版Pod数量降为1。⑤ 再启动一个新版，数量变为3。⑥ 把旧版Pod数量降为0。这就是滚动的意思，始终保持副本数量为3，控制新旧Pod的交替，实现了无缝升级。kubectl apply每次更新应用时，kubernetes都会记录下当前的配置，保存为一个revision，这样就可以回滚到某个特定的版本。创建3个配置文件，内容中唯一不同的就是镜像的版本号。httpd.v1.yaml：[root@master ~]# cat httpd.v1.yaml apiVersion: apps/v1kind: Deploymentmetadata:  name: httpdspec:  selector:     matchLabels:       app: httpd  revisionHistoryLimit: 10 # 指定保留最近的几个revision  replicas: 3  template:    metadata:      labels:        app: httpd    spec:      containers:        - name: httpd          image: httpd:2.2.31          ports:            - containerPort: 80httpd.v2.yaml：[root@master ~]# cat httpd.v2.yaml apiVersion: apps/v1kind: Deploymentmetadata:  name: httpdspec:  selector:    matchLabels:       app: httpd  revisionHistoryLimit: 10 # 指定保留最近的几个revision  replicas: 3  template:    metadata:      labels:        app: httpd    spec:      containers:        - name: httpd          image: httpd:2.2.32          ports:            - containerPort: 80部署Deployment。[root@master ~]# kubectl apply -f httpd.v1.yaml --recorddeployment.apps/httpd configured[root@master ~]# kubectl apply -f httpd.v2.yaml --recorddeployment.apps/httpd configured--record的作用是将当前命令记录到revision中，可以知道每个revision对应的是哪个配置文件。查看Deployment。[root@master ~]# kubectl get deployments -o wideNAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTORhttpd    3/3        1           3      31m      httpd   httpd:2.2.32 app=httpd查看revision历史记录。[root@master ~]# kubectl rollout history deployment httpddeployment.apps/httpd REVISION  CHANGE-CAUSE1         <none>2         kubectl apply --filename=httpd.v2.yaml --record=trueCHANGE-CAUSE即-record的结果。执行如下操作，回滚到指定版本revision 1。[root@master ~]# kubectl rollout undo deployment httpd --to-revision=1deployment.extensions/httpd rolled back[root@master ~]# kubectl get deployments -o wideNAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTORhttpd    3/3       3            3      35m     httpd    httpd:2.2.31 app=httpd再次查看Deployment可以看到httpd版本已经回退了。查看revision历史记录，可以看到revision记录也发生了变化。[root@master ~]# kubectl rollout history deployment httpddeployment.extensions/httpd ......

尊敬的合作伙伴：       您好，请从support网站下载最新的《边缘计算二次开发指南》，该脚本同最新的文档一起更新，本帖将不再更新，谢谢。502H：cid:link_0T2：cid:link_1AR-CORE：cid:link_2T1由于开源社区不再维护Debian 8，请使用T2系列的《二次开发指南》制作debian10的32位容器以及app

这段时间一直困在k8s的深坑里，部署k8s并不困难，但是之后的运行却是反反复复的遇到各种故障。总结一下k8s故障排查的途径：kubectl describe pod/deployment/service 查看pod/deployment/service的基本信息，会有少量的出错信息，找到后用做关键字搜下，就能滤掉一波故障。tailf /var/log/messagesjournalctl -f -u kubelet查看各个组件运行的最新日志，同样，找到报错关键字搜资料。kubectl logs  <pod> -c <contrainer>进入容器查看容器的日志，这个途径有局限，就是pod上的容器必须已经跑起来了，但是大部分故障是跑不起来。kubectl get <pod> -o yaml这条命令，个人理解是把运行的pod生成一个容器。

InitContainers是一种专用的容器，在应用程序容器启动之前运行，可以包括一些应用程序镜像中不存在的实用工具和安装脚本，可以完成应用的必要数据初始化等工作。总的来说就是在正式的容器启动之前做一些准备工作的。挂接的volum/file等等，是容器内外交换信息的工具，而InitContainer可以视为一个在容器胜生成之前的信息灌入的流程。顾名思义,InitContainers用于初始化工作,执行完就结束,为一次性的任务。IniteContainers支持大部分应用容器配置,但不支持健康检查。应用场景：环境检查:例如确保应用容器依赖的服务启动后再启动应用容器初始化配置（给应用容器准备配置文件）示例:部署一个web网站,网站程序没有打到镜像中,而是希望从代码仓库中动态拉取放到应用容器中。root@ecs-beijing1:~# vi pod-initcontainer.yaml              ---apiVersion: v1kind: Podmetadata: name: init-demospec: initContainers:   - name: download     image: busybox     command:       - wget       - "-0"       - "/opt/index.html"       - http://www.ctnrs.com     volumeMounts:       - name: wwwroot         mountPath: "/opt" containers:   - name: nginx     image: nginx     ports:       - containerPort: 80     volumeMounts:       - name: wwwroot         mountPath: /usr/share/nginx/html volumes:  - name: wwwroot    emptyDir: {}"pod-initcontainer.yaml" 28L, 504C written                                                                         root@ecs-beijing1:~# kubectl apply -f pod-initcontainer.yamlpod/init-demo createdroot@ecs-beijing1:~# kubectl get podNAME        READY   STATUS     RESTARTS   AGEinit-demo   0/1     Init:0/1   0          33sroot@ecs-beijing1:~# kubectl exec -it init-demo --bashroot@init-demo:~#cd /usr/share/nginx/html root@init-demo:/usr/share/nginx/html# lsindex.htmlroot@init-demo:/usr/share/nginx/html# cat index.html.....    <script src="/js/jquery.min.js"></script><script src="/js/feather.min.js"></script><script src="/js/fresh.js"></script><script src="/js/jquery.panelslider.min.js"></script><script src="/js/modernizr.min.js"></script>  </body></html>页面已经下载到容器里面了。

原作者： FutureCity原文链接：https://bbs.huaweicloud.com/blogs/2669891 业务场景普惠金融是行业热门课题，近几年央行政策支持中小微企业发展（特别是制造业），银行也把该方向作为业务拓展重点。但小微企业的信用评估是一个难点，小微企业一般都没有大额固定资产作授信抵押，银行也缺少高质量的数据作为评价依据，小微企业的贷款普遍存在难度大、周期长、额度低等问题。政府拥有小微企业多维度的数据，如纳税、社保、用水用电等，信用评估价值高，受限于政府网络和数据安全管理要求，政府数据不能直接提供给银行。那么，有没有一种方式，在不共享数据的情况下，实现数据的分析应用，即数据可用不可见。数据隐私计算技术，可用于满足该场景需求，如华为云可信智能计算服务 TICS (Trusted Intelligent Computing Service)，提供跨组织数据安全共享方案，政府无须将数据提供给银行，银行基于 TICS 的安全计算环境，运行数据分析模型，获取业务所需的分析结果。2 方案架构以政府和银行小微企业数据共享场景为例，政府数据部署在华为云数据库服务 RDS，银行数据存储在本地数据中心的 Mysql Server，通过边缘节点 IEF Edge Node 接入。TICS 服务同时支持云、边两种数据接入方式，基于华为云边缘服务 IEF 实现 TICS Agent 的远程部署和持续更新。TICS 可信聚合计算通过 TICS AGG 节点实现，AGG 提供基于 TEE 或 SGX 两种硬件隐私计算环境，也支持半同态加密、差分隐私等软件类的隐私计算能力，适用于联邦数据分析（基于标准 SQL）与联邦学习等业务场景。本方案架构设计参考下图：银行本地数据中心接入公网，有 3 种方式，不同方式下 IEF Agent 的接入配置要求说明如下：无网络限制的透明代理（ NAT 网关）透明代理的工作方式类似于 NAT 网关，银行内网服务器的数据包默认全部发送给透明代理（作为网关），透明代理再将数据包转发给外网访问地址，内网应用感知不到代理的存在，故称为透明代理。该方式边缘节点的接入配置最简单，只需完成 IEF Agent 的标准配置即可，参考链接 IEF 边缘节点注册与纳管 。带网络限制的透明代理（ NAT 网关）该方式下，银行对访问公网有网络限制，需要根据域名 / IP 地址和端口号，开通网络权限。需要放通的网络权限，参考 开通外网访问权限。带网络限制的普通代理和透明代理不同，普通代理是一个独立服务器，内网应用须配置代理访问地址，确保访问外网的数据包先发给代理，再由代理转发外网目的地址。本文介绍的最佳实践配置，主要针对最复杂的第 3 种场景：带网络限制的普通代理，如 squid 上网代理（其他类型的代理配置类似）。普通代理工作在 TCP/IP 协议应用层，代理的配置在应用级别生效，而非操作系统级别，本地服务器中的不同应用程序，均须添加代理配置，这一点尤其要注意。上图名词解释：TICS Service: 华为云 可信智能计算服务 管理节点，提供数据联盟管理、用户权限配置、代理管理等功能TICS AGG: TICS Aggregation Node 可信计算聚合节点，多方数据的融合计算在该节点完成TICS Agent: TICS 代理，提供数据接入管理、安全隐私规则配置、数据分析和联邦学习任务运行等功能，是 TICS 服务业务操作的关键组件，每个 TICS 数据联盟的参与方可拥有 1 个或多个 TICS AgentSWR: 华为云 容器镜像服务 Software Repository for Container，用于 IEF Agent 边缘容器镜像管理IEF Service: 华为云 边缘计算服务 Intelligent Edge Fabric 管理节点，负责边缘节点创建、管理和边缘容器应用同步操作等Edge Node: 部署 IEF Agent 的边缘节点，一般是一台硬件服务器或虚拟机IEF Agent: 部署在 Edge Node 上的边缘节点管理软件，负责与云端 IEF Service 进行通信，管理本地运行的边缘容器实例如 TICS Agent，支持实例更新、状态监控、日志管理等功能CCE: 华为云 云容器引擎 Cloud Container Engine，云上托管的 Kubernetes 集群，在本案例中，用于政务 TICS Agent 代理的部署CCE Node: CCE 节点即 Kubernetes 节点，是云端的一台虚机或裸金属服务器POD: Kubernetes 集群运行计算任务的最小单位，本案例用于部署政府侧的 TICS Agent，是 1 个或多个容器的集合，参考 POD 名词解释RDS: 华为云 托管 Mysql 数据库，本案例用于存储政务共享数据NAT: 网络地址转换网关 Network Address Translation，用于内外网通信转接，内网访问外网的网络流量均重定向到 NAT 网关，再转发给外网目的地址3 前置条件3.1 开通外网访问权限银行本地边缘节点，访问公有云的 IEF 和 TICS 服务，须开通以下网络端口：目的 IP 地址访问域名目的端口用途119.3.227.164ief2-placement.cn-north-4.myhuaweicloud.com443边缘计算 IEF 服务端49.4.115.239ief2-edgeaccess.cn-north-4.myhuaweicloud.com443边缘计算 IEF 连接网关119.3.215.28ief2-telemetry.cn-north-4.myhuaweicloud.com8065/8102/8149边缘计算 IEF 日志与计量端口49.4.112.92ief2-software-north-4.obs.cn-north-4.myhuaweicloud.com443边缘容器镜像存储49.4.112.18swr.cn-north-4.myhuaweicloud.com443容器镜像管理服务接口49.4.112.6tics.cn-north-4.myhuaweicloud.com443TICS 服务端接口49.4.112.113obs.cn-north-4.myhuaweicloud.com443OBS 服务接口139.9.118.165无域名访问地址30001~30016TICS 聚合计算节点 AGG 端口以上网络配置基于华为云北京四 Region，其他 Region IP 地址和域名均不同，须进行相应调整。参考链接 获取 IEF 云端服务 IP 地址3.2 注册华为云账号TICS 服务同一数据联盟参与方可以进行数据共享，数据联盟每个参与方都是华为云租户，因此使用 TICS 服务必须先注册华为云账号。登录 华为云官网 即可完成账号注册。3.3 申请 TICS 服务公测TICS 服务目前处于受邀公测阶段，请登录华为云 TICS 服务 ，点击 “立即体验” 按钮，即可申请公测。公测申请提交后，华为云 TICS 服务管理人员将在约 1~2 天内完成审批。3.4 加入 TICS 服务联盟任何华为云账号均可发起创建 TICS 数据联盟，公测阶段资源有限，建议参与测试的用户优先加入现有数据联盟。用户将华为云账号提供给 TICS 服务管理员（可通过华为云销售获取联系方式），由 TICS 服务管理员将账号加入到数据联盟。华为云账号格式一般为 hwxxxxxxxx (hw 加 8 位数字)，登录华为云账号中心即可查看。TICS 服务管理员将账号添加到数据联盟后，用户将在 TICS 服务 “通知管理”模块收到加入数据联盟申请，选择同意即可加入该数据联盟。3.5 准备华为云费用银行采用边缘服务方式接入华为云，涉及一定的华为云费用。边缘节点部署 IEF Agent 是免费的，在 IEF Agent 运行容器实例需要收费，收费标准参考链接 IEF 服务定价。TICS Agent 部署在边缘节点上需要一个容器实例，费用为 1099 ￥/月/实例。用户可自行充值华为云账号完成测试，也可联系华为云销售申请华为云测试券，覆盖测试所需费用。注：完成实名认证的企业账号才能申请测试券，请登录华为云官网 账号中心>实名认证，参考 实名认证操作指南 完成认证。3.6 准备 IEF 边缘节点边缘节点是部署在银行本地数据中心的服务器或虚拟机，支持 X86 和鲲鹏 ARM 架构，推荐配置如下：操作系统：CentOS 7.6硬件配置：cpu >= 8 core，内存 >= 16G环境依赖：docker 18.06.3 版本IEF 边缘节点须具备外网访问权限，和云端互动时，均由边缘节点发起访问，因此边缘节点无需独立公网 IP 地址。更多边缘节点规格要求，参考 配置边缘节点环境 。4 部署 IEF Agent在边缘节点上部署 IEF Agent，须先登录华为云 IEF 服务控制台 ，选择功能模块 边缘资源>边缘节点，点击红色按钮 “注册边缘节点”，根据提示，下载边缘节点安装程序 edge-installer_1.0.0_x86_64.tar.gz 和配置文件 ief-node.tar.gz (ief-node 是节点名称)，导入到边缘节点服务器。参考下面配置，在普通代理上网的环境下，完成 IEF Agent 部署和云端纳管。以 sudo 权限登录边缘节点执行如下命令解压软件包到 /opt 文件夹sudo tar -zxvf edge-installer_1.0.0_x86_64.tar.gz -C /opt解压配置文件到 /opt/IEF/Certsudo mkdir -p /opt/IEF/Cert sudo tar -zxvf 边缘节点名称.tar.gz -C /opt/IEF/Cert配置 IEF Agent 外网访问代理vi /opt/IEF/Cert/user_config http_proxy=proxy_ip:proxy_port # proxy_ip 和 proxy_port 请修改为现网的代理 IP 地址和端口号，下同 https_proxy=proxy_ip:proxy_port安装 IEF Agentcd /opt/edge_installer sudo ./installer -op=install验证边缘节点是否纳管成功登录华为云 IEF 服务控制台 边缘资源>边缘节点，查看新建边缘节点的运行状态，“运行中”表示纳管成功。更多相关配置参考 IEF 边缘节点注册与纳管。5 部署 TICS AgentTICS Agent 是部署在 边缘节点上的一个容器实例，登录华为云 TICS 服务控制台，即可发起创建 TICS Agent，华为云 IEF 服务会负责将 TICS Agent 的容器镜像（保存在 SWR 上）同步到边缘节点，完成 TICS Agent 的部署操作。参考下面配置，完成 TICS Agent 在边缘节点上的部署：配置 docker 外网访问代理从云端获取 TICS Agent的容器镜像将执行 docker pull 操作，须配置 docker 的访问代理，否则将导致镜像获取失败。sudo mkdir -p /etc/systemd/system/docker.service.d vi /etc/systemd/system/docker.service.d/http-proxy.conf [Service] Environment="HTTP_PROXY=proxy_ip:proxy_port" # proxy_ip 和 proxy_port 请修改为现网的代理 IP 地址和端口号，下同 Environment="HTTPS_PROXY=proxy_ip:proxy_port" :wq # 保存文件 # 重启 docker sudo systemctl daemon-reload sudo systemctl restart docker获取华为云账号 AK/SK访问密钥 AK/SK Access Key ID/Secret Access Key 包含访问密钥ID（AK）和秘密访问密钥（SK）两部分，是华为云账号的长期身份凭证，TICS Agent 代理部署须配置 AK/SK 信息，授予代理接入权限。AK/SK 登录华为云官网 账号中心>基本信息>管理我的凭证>访问密钥，点击“新增访问密钥”，即可下载访问密钥，文件名为 credentials.csv。详细操作指南参考 访问密钥 。注：访问密钥生成后，只能下载一次，请妥善保管。下载TICS Agent 配置登录华为云控制台 TICS 服务，选择 通知管理>下载代理配置，保存至本地，解压后得到 3 个文件，在下一步创建 TICS Agent 代理中会用到agent.p12 - 联盟配置tics_league_datacloud.json - 代理密钥truststore.jks - CA 证书创建 TICS Agent登录华为云控制台 TICS 服务，选择 代理管理>部署代理，在部署代理页面，依次完成以下操作：导入联盟配置 agent.p12上传文件 代理密钥 tics_league_datacloud.json上传文件 CA 证书 truststore.jks导入当前账号 AK/SK credentials.csv配置代理登录密码，该密码请注意保存，后面和代理登录账号 admin 一起用于代理管理页面的登录选择 IEF 边缘节点部署，纳管节点选择已创建好的 IEF 边缘节点主机路径配置边缘节点上数据保存路径，如 /home/tics，须确保该路径已创建且具备写权限点击 “立即创建” 按钮，完成代理创建操作配置 TICS Agent 外网访问代理TICS Agent 通过 java sdk 与华为云 TICS AGG 进行通信，须配置 java 访问外网的代理配置，确保与 AGG 通信正常。以 sudo 权限登录边缘节点，执行以下命令：docker ps # 查看 docker 容器实例 docker exec -ti xxxx /bin/bash # xxxx 对应 tics 容器实例 id vi /etc/hosts # 配置容器实例内部 TICS 服务域名解析 49.4.112.6 tics.cn-north-4.myhuaweicloud.com hostname # 获取当前主机名，后面配置将用到 vi /opt/cloud/tics/tics-agent-console/bin/common.sh JAVA_OPTS="-Dhttps.proxyHost=proxy_ip -Dhttps.proxyPort=proxy_port -Dhttp.nonProxyHosts=当前主机名" # proxy_ip 和 proxy_port 请修改为现网的代理 IP 地址和端口号，下同 :wq # 重启服务，使配置生效 su service sh stop.sh sh start.sh & vi /opt/cloud/tics/tics-agent-web/bin/common.sh JAVA_OPTS="-Dhttps.proxyHost=proxy_ip -Dhttps.proxyPort=proxy_port -Dhttp.nonProxyHosts=当前主机名" :wq # 重启服务，使配置生效 su service sh stop.sh sh start.sh &验证 TICS Agent 是否部署成功登录华为云控制台 TICS 服务，选择 代理管理，点击代理名进入代理管理页面，点击代理登录地址 “前往代理Agent”，打开代理登录界面，输入步骤 4 中的代理用户名 Admin 与代理登录密码，完成代理登录。登录代理页面后，查看右上角的状态符号，显示为绿色，则表示代理通信正常，代理部署成功。注：边缘节点部署方式下，TICS Agent 代理登录 IP 地址为内网 IP 地址，请确保测试使用的 PC 或笔记本，与 TICS Agent 内网网络连通性。

4月24日-26日，华为开发者大会2021（Cloud）在全国36座城市、63个线下分会场同步启，旨在汇聚业界大咖、华为科学家、顶级技术专家、天才少年和众多开发者，搭建一个全球性的交流和实践平台，共同探讨和分享最新的ICT技术在行业的深度创新和应用。作为互联网之都，杭州近年来一直在国内数字化、信息化产业中占据着龙头地位，并保持着高速、健康的发展态势，被业内誉为“数字经济第一城”。在杭州的发展过程中，华为一直在不遗余力地通过校企合作等方式添砖加瓦。本次华为开发者大会2021（Cloud）分会场走进了杭州电子科技大学，与高校师生围绕产业创新和鲲鹏生态、技术开源等展开了深入的探讨和学习。会上，杭州电子科技大学校团委副书记杨乐发表讲话。在讲话中杨乐谈到：ICT大大改变了人们的工作、沟通、学习和生活方式。未来，联接、AI、云、计算、行业应用等多种先进技术和机会互相催化、有机融合，必将催生大量的技术创新和应用创新，为社会发展开启了充满想象的广阔前景。杭州电子科技大学将与华为携手，保持对基础研究的持续投入，鼓励自由探索，敢于质疑现有理论，勇于开拓新的方向。鲲鹏展翅，打造5G时代多样化算力底座预计2025年，全球联网的设备数量将突破1000亿，数以ZB计的海量数据，需要被分析、处理。未来十年，是计算体系架构创新的黄金十年，算力需求的不断增长，将推动计算体系架构的创新。计算体系架构创新将主要从从两个方向展开：从通用计算走向通用计算加异构计算的多样性算力创新，和从硬件到基础软件、到应用使能的全栈协同创新。基于这一趋势，2019年，华为向业界正式发布鲲鹏、昇腾计算产业战略，并坚持“硬件开放、软件开源、使能伙伴、发展人才”，开放主板，有序推进与伙伴的整机合作；操作系统openEuler、企业级数据库openGuass、全场景AI计算框架MindSpore全部如期开源，得到伙伴的积极响应和支持。会上，华为向与会成员展示了鲲鹏投资全场景芯片族布局，包含鲲鹏处理器、昇腾AI处理器、智能SSD控制器芯片、智能网卡芯片以及智能管理芯片等。共建生态，把企业级数据库能力带给用户和伙伴会上，在谈到openGauss时，华为布道师张琼指出openGauss是一款高性能、高安全、高可靠的企业级开源关系型数据库(RDBMS)，且具备智能运维管理能力。截至目前，该数据库已完成了内部自用、产品化再到云&开源阶段，2021年将专注于生态构建，分享企业级数据库管理能力，促进数据库教育事业发展，引领生态建设。与此同时，华为布道师张琼还就openEuler进行了介绍。作为面向多样性计算的原生开源操作系统，openEuler定位于聚焦内核能力，释放多样化算力，加速行业应用创新。它具备操作系统完整功能集，能够原生自主演进。目前，openEuler已强力参与基础系统开源项目，成为核心成员，做到自维护、自演进，非常适合开发者学习。在此值得一提的是，会上华为布道师张晓雨还就“如何使用iSula生态链进行容器镜像构建和运行”进行了介绍。他指出，iSula 是华为自主研发的通用容器引擎，旨在统一的架构设计来满足 CT 和 IT 领域的不同需求。相比 Golang 编写的 Docker，轻量级容器具有轻、灵、巧、快的特点，不受硬件规格和架构的限制，底噪开销更小，可应用领域更为广泛。此外，他还通过实操向与会学子展示了iSula容器引擎的使用方法和iSula-build容器镜像构建工具的使用方法，帮助高校学子更好的了解到了iSula生态链对于容器镜像构建和运行的作用。作为浙江省首批重点建设的5所高校之一，杭州电子科技大学一贯坚持“以人为本，追求卓越”的育人理念，致力于培养家国情怀、国际视野、创新精神和实践能力的高素质人才。截止2020年7月，杭州电子科技大学已建设国家级人才培养模式创新实验区一个，国家级虚拟仿真实验教学中心一个，国家级实验教学示范中心三个，国家级精品课程两门，先后为国家和社会培养输送了16万余名优秀人才，获得了全国普通高等学校毕业生就业工作先进集体”“全国毕业生就业典型经验高校”等荣誉称号，为培养信息产业人才做出了卓著的贡献。近年来，华为正逐步将其已经成熟的技术进行开源，帮助更多产业开发者快速成长。通过供应链、技术等方面的优化，不断为开发者提供更加的平台。对于产业创新，质量的提升是要求也是衡量标准，全栈智能的创新技术是引擎，而拥有产业视角和创新技术的人才是关键。可以说，随着产业创新浪潮的兴起，产业开发者的时代已经来临，让我们一起，加入产业创新，加速产业创新，成为了不起的开发者！

ModelArts为用户提供了多种常见的预置引擎，但是当用户对深度学习引擎、开发库有特殊需求场景的时候，预置AI引擎可能不再满足用户需求。ModelArts底层采用容器技术，您可以自行制作容器镜像上传并在ModelArts上运行。自定义镜像支持自由文本形式的命令行参数和环境变量，灵活性高，便于支持任意计算引擎的作业启动需求。当前ModelArts自定义镜像功能支持以下两种场景：创建训练作业导入模型让我们看看如何在ModelArts中使用自定义镜像创建训练作业和导入模型吧！关联服务介绍使用自定义镜像功能可能涉及以下云服务：容器镜像服务、对象存储服务、弹性云服务器。容器镜像服务：容器镜像服务（Software Repository for Container，SWR）是一种支持镜像全生命周期管理的服务， 提供简单易用、安全可靠的镜像管理功能，帮助您快速部署容器化服务。您可以通过界面、社区CLI和原生API上传、下载和管理容器镜像。ModelArts训练和导入模型使用的自定义镜像需要从SWR服务管理列表获取。您制作的自定义镜像需要上传至SWR服务。对象存储服务：对象存储服务（Object Storage Service，OBS）是一个基于对象的海量存储服务，为客户提供海量、安全、高可靠、低成本的数据存储能力。在创建训练作业和导入模型时往往存在数据交互，您需要的云上数据可以存储至OBS服务。弹性云服务器：弹性云服务器（Elastic Cloud Server，ECS）是由CPU、内存、操作系统、云硬盘组成的基础的计算组件。弹性云服务器创建成功后，您就可以像使用自己的本地PC或物理服务器一样，在云上使用弹性云服务器。在制作自定义镜像时，您可以在本地环境或者ECS上完成自定义镜像制作。在您使用自定义镜像功能时，ModelArts可能需要访问您的容器镜像服务SWR、对象存储服务OBS等依赖服务，若没有授权，这些功能将不能正常使用。建议您使用委托授权功能，将依赖服务操作权限委托给ModelArts服务，让ModelArts以您的身份使用依赖服务，代替您进行一些资源操作。详细操作参见使用委托授权。使用自定义镜像创建训练作业端到端样例可参考最佳实践-使用自定义镜像创建训练作业~1.准备工作完成访问授权的配置，详细操作参见使用委托授权。已在OBS服务中创建桶和文件夹，用于存放样例数据集以及训练代码。2.制作自定义镜像，您可以使用ECS或者应用本地已有的主机进行自定义镜像的制作。    在制作镜像用时，需满足ModelArts定义的规范。自定义镜像中不能包含恶意代码。基础镜像中的部分内容不能改变，包括“/bin”、“/sbin”、“/usr”、“/lib(64)”下的所有文件，“/etc”下的部分重要配置文件，以及“$HOME”下的ModelArts小工具。不可以新增属主为“root”且权限包含“setuid”或“setgid”位的文件。自定义镜像大小不能超过5GB。日志文件输出，为保证日志内容可以正常显示，日志信息需要打印到标准输出。     ModelArts还提供基础镜像用于自定义镜像的制作。基础镜像中有一些必要的工具，帮助用户快速实现代码下载、训练日志输出、上传日志文件至OBS等功能。3.上传镜像至SWR服务。上传镜像的详细操作可参考SWR用户指南。4.使用自定义镜像创建训练作业。使用自定义镜像导入模型端到端示例请参考使用自定义镜像导入模型~1.准备工作完成访问授权的配置，详细操作参见使用委托授权。已在OBS服务中创建桶和文件夹，用于存放数据以及相关文件。2.制作自定义镜像    在制作镜像用时，需满足ModelArts定义的规范。自定义镜像中不能包含恶意代码。自定义镜像大小不超过30GB。镜像对外接口         镜像的对外服务接口需要为8080，推理接口需与config.json文件中apis定义的url一致，当镜像启动时可以直接访问。健康检查接口         自定义镜像需要提供健康检查接口供ModelArts调用，在config.json文件中配置，参见模型配置文件编写说明。日志文件输出        为保证日志内容可以正常显示，日志信息需要打印到标准输出。镜像启动入口        如果需要部署批量服务，镜像的启动入口文件需要为“/home/run.sh”，采用CMD设置默认启动路径。镜像依赖组件        如果需要部署批量服务，镜像内需要安装python、jre/jdk、zip等组件包。3.上传镜像至SWR服务。上传镜像的详细操作可参考SWR用户指南。4.选择从容器镜像导入模型，可参考从容器镜像中选择元模型。5.将模型部署为在线服务。