Choerodon猪齿鱼实践之应用生命周期管理
Choerodon平台中的开发和部署都是围绕应用来进行的,那Choerodon平台中的应用有什么样的特性?又是怎样来进行管理的呢?本文旨在深入地介绍Choerodon平台中应用的功能特性及其生命周期的管理。
微服务架构中应用的特征
在谈起Choerodon平台中的应用时,就不得不提微服务。正是因为微服务的出现,之前的单体应用架构带来的问题才得以解决,具体问题如下:
(1)耦合程度随时间推移而逐渐提高。
(2)扩展性差,冗余能力差
(3)模块划分不清晰,无法细化对系统资源的需求
(4)维护成本随着系统的日益臃肿而不断增加
而下图也更为直观地指出了单体应用架构与微服务架构的区别。
由此可见,微服务架构中的应用会被分解为更小、完全独立的组件,这使得它们拥有更高的敏捷性、可伸缩性和可用性。换句话说,微服务架构的基本思想就是“围绕业务领域组件来创建应用,让应用可以独立地开发、管理和加速。
Choerodon平台中应用生命周期的管理
由于Choerodon平台采用的是微服务架构,因此系统内每个功能模块均被解耦为多个应用,其中每个应用都支持独立地开发和独立地部署。而Choerodon平台中一个应用的生命周期一般从创建或导入应用开始;接着在开发流水线中按照需求对应用进行开发,待提交代码跑完CI之后,会生成一个应用版本,而之后的部署与发布操作均是围绕应用版本来进行的;首先用户可以将生成的应用版本部署至对应的环境中;此外,用户在测试环境中测试无误后,可以将此应用版本发布至应用市场与全平台或全组织共享。
以上便是Choerodon平台中应用的生命周期与相关功能的大致流程,下面就按照这个流程进行展开,带大家了解Choerodon对于DevOps的实践。
应用的创建或导入
在平台中创建或导入应用时,系统会默认在对应的 gitlab group 中创建一个 project 作为此应用的初始代码库,而后再通过相应的页面功能实现对此应用的管理。从gitlab或github中导入应用库时,目前步骤和创建应用步骤类似,在导入的过程中,依然可以选择对应的模板库,以便于在平台上进行后续的开发与部署。
在创建或导入应用的过程中,选择应用模板与配置应用权限是其中不可或缺的步骤,同时也是应用的重要特性,以下为这两个模块的详细介绍:
▌应用模板
为了让开发者能将更多的精力用于应用的开发之中,在创建应用时,Choerodon平台提供了全面的预置应用模板供各个项目团队选择。其中的应用模板是由同类型应用的代码库整理而成的,引用了相应的应用模板后,即可在gitlab中快速地创建初始代码库。
目前猪齿鱼平台预置了微服务前端、微服务后端、Javalib(jar库)、Go语言、SpringBoot等多个开发常用的应用模板,此外,还有Mocha与TestNg的测试应用模板。这些应用模板均统一预置于github里面。而在这些模板中,至少都包含了 Dockerfile 文件、CI 文件以及 Chart 目录文件。
其中Dockerfile是由一系列命令和参数构成的脚本,这些命令应用于基础镜像并最终创建一个新的镜像,主要用于控制应用容器化的进程。其次是CI文件,模板中的CI文件主要用于设置在提交代码后,自动集成时要经历的所有阶段。而其中的Chart目录文件则用于将平台中的容器打包,统一置于K8S平台进行管理。
除了可以使用平台提供的预置模板,用户还可以根据实际情况自定义符合自己需求的应用模板。而用户自定义的模板将会统一置于gitlab中的应用模板库中,便于用户进行统一的管理。
▌应用权限
众所周知,所有的项目团队均是由不同的角色构成的。而在Choerodon平台的项目层中,先是简单地将角色分为项目所有者与项目成员。顾名思义,这里的项目所有者对应的是项目中项目经理的角色,而项目成员即为团队中的其他角色。项目所有者默认拥有此项目下所有应用的开发权限和部署权限,并可以对项目成员们进行应用权限的配置(目前平台内的的应用权限仅限于为项目成员配置应用的开发权限)。
在使用微服务的团队中,由于需要涉及到对多个单元应用的管理、开发与部署,而且不同的应用可能还需要不同的开发人员,在这种情况下,对每个应用进行权限的配置就变得更为必要了。在平台内的项目层创建应用或者导入应用时,Choerodon都提供了灵活的权限设置功能,以便项目所有者为相应的应用配置特定的开发人员。
应用开发
当应用创建成功后,开发人员即可在Choerodon平台的开发流水线中按照需求进行应用的开发。开发流水线是根据开发人员的日常操作整理而来的,主要通过对gitlab的封装来实现持续集成与持续交付。
平台中的开发流程从基于目标应用创建对应的分支开始,而之后的开发操作就在此分支上进行。待开发完成,提交代码之后,会触发CI,并依次执行CI文件中定义的各个阶段。CI通过后,会依据版本生成规则(详见应用版本管理部分)生成一个应用版本。此时,就需要在开发流水线中创建合并请求,而指定人员审核代码通过后,会将此分支合并至目标分支。在开发的最后过程,用户可以使用标记功能为这个版本创建一个标记,以便更好地进行版本管理。
下图为开发流水线模块主要流程:
应用版本管理
灵活的版本控制与规范的版本管理是Choerodon平台的一大特色,因为采用了语义化版本的命名规则,所以Choerodon平台内通过CI生成的版本,一般格式为:C7N_COMMIT_TIME-C7N_BRANCH;比如:若分支名为feature-demo,提交时间为2019年3月7日20:14:54,那么得到的C7N_VERSION值为:2019.3.7-201454-feature-demo。若通过标记功能创建的标记为0.15.0,那么得到的版本号就是0.15.0。此处的标记功能通常用于对外发布新版本时使用,而此时的版本格式通常为:主版本号.次版本号.修订号,版本号递增规则如下:
-
主版本号:当你做了不兼容的 API 修改,
-
次版本号:当你做了向下兼容的功能性新增,
-
修订号:当你做了向下兼容的问题修正。
此外,Choerodon还支持将先行版本号及版本编译信息加到“主版本号.次版本号.修订号”的后面,使得版本号更加灵活易懂,例如:0.15.0-alpha.1。而具体的规则可以至语义化规则进行详细了解。
应用发布与应用市场
很多时候,在开发完某个应用后,可能恰好另一个项目或者另一个组织也正好需要这个应用。在Choerodon平台内,只需将此应用对应的应用版本发布至全组织或全平台,便能实现组织内或者平台内的应用共享,同时,还可对应用的具体版本进行控制,可选的将目标应用版本发布到应用市场,而将应用的流水版本保留下来。
而应用市场则集合了本项目下可访问的已发布应用,并能将所需应用的对应版本部署至此项目下的环境中使用。此外,应用市场还提供了应用的导入与导出功能(目前支持zip格式的导入与导出)。
应用部署
应用部署是部署流水线中的主要功能,应用部署的过程就是实现应用容器化的过程。
在生成应用版本之后,我们可以将其部署到对应的环境中去进行测试验收或投入使用(此处的环境可以理解为我们平时使用的Staging环境、UAT环境和生产环境)。而部署应用成功后,会生成一个实例,我们通过管理这个实例及其相关的资源来管理容器中的应用(具体的原理和步骤将在后续的部署流水线模块相关的文章中进行详细介绍)。
以下为部署流水线模块的流程示意图:
应用维度的指标监控
管理大师彼得德鲁克:如果你不能度量它,你就无法改进它。
正如彼得德鲁克所说,如果想改进某个东西,首先得有一个明确的指标。Choerodon平台内的DevOps指标均能以应用为维度进行查看,便可知道每个应用的开发与部署的情况。
(1)首先可以通过代码提交图了解到某个应用的代码提交情况,以此实时反应出该应用的开发情况。
(2)在Choerodon平台中,还可以从应用的维度了解到某个应用的所有构建情况,包括了构建的时长与构建的次数。
(3)最后可以通过平台从应用的维度了解到某个应用在某个或是所有环境中的部署情况,包括部署时长图与部署次数图。
写在最后
在微服务架构的基础上,Choerodon平台内的功能模块被解耦为多个独立的应用。因此管理好这些应用及其对应的代码库很有必要,而Choerodon平台中提供了完善的功能来帮助用户更好的实现多应用的管理与共享。以应用为中心进行开发和部署是Choerodon平台实践DevOps的重要步骤,所以应用管理作为实践DevOps的基础,也应该受到重视。
关于Choerodon猪齿鱼
Choerodon猪齿鱼开源多云集成平台,基于开源技术Kubernetes,Istio,knative,Gitlab和Spring Cloud来实现本地和云端环境的集成,实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理,从而更快、更频繁地交付更稳定的软件。
大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性,以及参与社区贡献:
- 官网:http://choerodon.io
- 论坛:http://forum.choerodon.io
- Github:https://github.com/choerodon
- 微信:Choerodon猪齿鱼
- 微博:Choerodon猪齿鱼
欢迎加入Choerodon猪齿鱼社区,共同为企业数字化服务打造一个开放的生态平台。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
基于macOS+VMware的GNS3内VM上公网
笔者经常需要做网络实验,GNS3就是笔者最喜欢用的模拟器,为了便于实验,需要能从macos上直接ssh登陆模拟出来的vm,并且vm需要上公网。经过研究,已解决此问题,并以此分享出来 tag: macos, vmware, gns3, vm上公网 小慢哥的原创文章,欢迎转载 环境说明 本文基于以下环境: ▷ 宿主:macOS Mojave ▷ GNS3版本:2.1.14 ▷ GNS3内部的VM运行在:GNS3 VM里 ▷ GNS3 VM运行在:VMware Fusion 专业版 11.0.1 ▷ centos7.3是运行在GNS3 VM里的Qemu虚拟机 可以理解为在macOS上运行了VMware,在VMware里运行了GNS3 VM,在GNS3 VM里运行了Qemu虚拟机。 对,就是"俄罗斯套娃"。 想让GNS3内的VM上Internet公网,有2种方法,接下来分别详细讲解 方法1(内置) GNS3内置一个nat cloud,只要将vm连上这个nat cloud就可以上公网(上图中的Nat1就是nat cloud) 实现原理:nat cloud会对数据包进行SNAT,将源IP转换成ma...
- 下一篇
git 入门教程之分支总览
分支就是一条独立的时间线,既有分支,必有主干,正如一棵树谈到树枝,必有树干一样的道理.我们先前对git 的全部操作默认都是在主干上进行的,这个主干也是一种特殊的分支,名为 master 分支. 无论是穿越历史还是撤销更改,我们都或多或少接触过时间线,git 管理的版本串在一起就组成了这个时间线,其中master 分支是当前分支,HEAD 指向master ,因此HEAD 相当于指向了最新的版本. 基于分支上的操作,每一次 commit 都会提交一个新版本,并且新的 commit 指向原来的 commit,这来最新的 commit 就可以往前找,直到找到最初的commit.这就是 git 的时间线. 当我们打算开辟新的时间线时,git 在当前 HEAD 指向的 master 分支的 commit 处新建一个 dev 分支.如果主角没有主动进入时间线的话,那么仍然处于 master 分支,进入的方法就是 HEAD指向新建的 dev 分支. 不考虑孙悟空的分身特效,主角不能同时处于不同的时空下,git 也是如何,HEAD 只能指向某一个 commit ,既然刚刚已经指向了 dev 分支,所以...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Mario游戏-低调大师作品
- CentOS8安装Docker,最新的服务器搭配容器使用
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS8编译安装MySQL8.0.19
- SpringBoot2配置默认Tomcat设置,开启更多高级功能