ios传感器应用开发最佳实践_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 中进行相应的操作，此开关默认为关闭状态。如下图所示：

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