关于java:SpringCloud-应用在-Kubernetes-上的最佳实践-部署篇工具部署

4次阅读

共计 2113 个字符,预计需要花费 6 分钟才能阅读完成。

作者 | 孤弋  阿里云高级技术专家,负责 EDAS 的开发和用户体验优化工作。

导读:上一篇文章《SpringCloud 利用在 Kubernetes 上的最佳实际 — 部署篇(开发部署)》咱们介绍了从 IDE 插件内介绍了如何进行利用部署的形式,除此之外,目前 EDAS 还反对了额定的工具对其余场景进行笼罩,这一篇内容次要就是介绍 EDAS 上围绕部署的工具体系。

相干文章举荐:

  • 《SpringCloud 利用在 Kubernetes 上的最佳实际 —— 开发篇》
  • 《SpringCloud 利用在 Kubernetes 上的最佳实际 — 部署篇(开发部署)》

IDE 插件中进行部署

因为 IDE 是离开发人员的代码最近的工具,所以 IDE 插件中的部署能力也是专门为开发人员提供的部署工具,他的特点就是速度快、应用简略,同时也笼罩了 ECS 集群与 Kubernetes 集群中的 War/Jar、以及自定义镜像的部署形式。具体应用形式,咱们都曾经整顿成了官网文档,请在 EDAS 的官网帮忙文档中,查看《应用 Cloud Toolkit 疾速部署利用至 EDAS》章节。

不过对于线上的利用而言,如果轻易一个开发人员都能进行随便的变更,这是一件很不平安的事件。EDAS 在命名空间设计的时候,也思考到了这个问题,解决的方法就是 EDAS 上的命名空间,其用处是用来隔离环境之间的服务与配置用的。能够了解成通常意义上的环境,如:开发、测试、生产等。为防止用户在 IDE 插件中误将线上环境进行变更,咱们对命名空间退出了一个 容许近程调试 的选项,开启之后能力在 IDE 中进行相应的操作,此开关默认为敞开状态。如下图所示:

Maven 插件中进行部署

Maven 插件的应用场景介于开发人员与运维人员之间,他的设计次要秉承当下比拟风行的 DevOps 的理念,能够将部署流程配置化的形式进行公布。即咱们能够将部署的配置信息,随代码工程搁置在一起,进行版本跟踪,同时也能将利用的配置依据 Spring 中的 Profile 进行辨别。依照相应的配置做好之后,只须要执行简略的  mvn toolkit:deploy  即可实现部署。具体能够参见 EDAS 官网文档的《应用 toolkit-maven-plugin 插件部署利用》。

CI/CD 中进行部署

一套规范的 DevOps 流程必定少不了 CI/CD 的存在,作为市场上应用最广的 CI/CD 工具 Jenkins,以其简略易用和其丰盛的插件能力而著称。EDAS 也补齐了这一平台的插件,这款插件也涵盖了 EDAS 中所有支流场景的部署,尤其在 Kubernetes 这一块,同时集成了镜像构建、推送、部署的能力。具体能够参见 EDAS 官网文档的《在 Jenkins 中应用 edas-jenkins-plugin 构建利用到 EDAS》。

同时,目前还有很多的用户在应用云服务云效,云效中集成了弱小的流水线的能力,EDAS 是其中的一个内置的流水线的工作模版,名称为 部署到 EDAS,详情请参考 EDAS 官网文档《应用云效部署 Java 利用至 EDAS》。

应用 Terraform 进行编排

Terraform 是一种平安无效地构建、更改和版本控制基础设施的工具(基础架构自动化的编排工具)。它编写了形容云资源拓扑的配置文件中的根底构造,例如虚拟机、存储账户和网络接口。Terraform 的命令行接口(Command Line Interface,CLI)提供一种简略机制,用于将配置文件部署到阿里云上,并对其进行版本控制。

EDAS 也集成了当下比拟风行的 Infrastructure As Code 的理念,拥抱 Terraform 的生态,提供了一个官网插件,让用户能够以 Infrastructure As Code 的形式将利用编排到对应的底层 IaaS 层资源与其余 PaaS 资源上,文档参见:《应用 Terraform 部署利用至 EDAS》。

应用 CLI 工具中进行部署

对于一个资深的运维人员而言,可能最喜爱的操作的形式还是命令行工具。除了应用习惯之外,因为命令行工具同时具备很好的脚本化,和其余的脚本语言进行联合后能具备更丰盛的能力。

EDAS 中的 CLI 工具,目前是依靠于阿里云的命令行入口,已 POP API 为命令,API 的参数为命令行的参数进行构建,也就是说其本质还是转换成为一次 POP API 的调用。官网文档请参考:《应用 CLI 疾速部署 EDAS 利用》。

结语及后续

EDAS 的部署工具基本上围绕着开发人员、运维人员、DevOps 场景进行构建,不过对于一次部署而言,触发往往只是提交一个工作,而咱们其实更关怀工作提交之后的后果,甚至后果对于业务的影响。因为咱们每一次工作的触发,其实都是对线上环境的一次变更,变更则很容易产生故障,对业务产生不连续性,依据阿里巴巴团体的教训,超过半数重大故障是因为变更产生。所以在 2018 年末,提出了线上变更的三条准则:可灰度、可回滚、可监控。EDAS 也是逐渐将这一理念中的各种能力在产品中践行;所以接下来的章节将围绕着线上变更来进行,下一讲将进入第一大节《可灰度》。

点击中转云原生架构白皮书详情页

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术畛域、聚焦云原生风行技术趋势、云原生大规模的落地实际,做最懂云原生开发者的公众号。”

正文完
 0