SpringCloud 应用在 Kubernetes 上的最佳实践 — 部署篇(工具部署)

作者 | 孤弋  阿里云高级技术专家,负责 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 中进行相应的操作,此开关默认为关闭状态。如下图所示:

SpringCloud 应用在 Kubernetes 上的最佳实践 — 部署篇(工具部署)_第1张图片

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 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

你可能感兴趣的:(SpringCloud 应用在 Kubernetes 上的最佳实践 — 部署篇(工具部署))