Skip to main content

6 篇博文 含有标签「DEVOPS

View All Tags

· 11 分钟阅读

Choerodon猪齿鱼V0.23版本中的部署 > 应用部署 > 流水线功能在猪齿鱼中停用,需要切换为开发 > 应用流水线功能,相比于老版的流水线,新版本的应用流水线增强了猪齿鱼的管理功能,提供了更多的扩展。通过 Gitlab 和 猪齿鱼的 DevOps 实现提交代码后自动更新服务的流程。

前置条件

开发规范

开发人员在特性分支(feature-*)进行功能开发,完成功能开发之后将特性分支合并到环境分支develop进行部署。

自动化部署配置

在猪齿鱼中配置 K8s Config Map

功能路径:应用部署 > 资源 > 资源视图 > 选择环境 > 配置映射

在配置映射中需要定义CM的名称,这里以hzero-dev为例,在配置映射中维护公共的环境变量,例如注册中心地址等.

调整 Chart 中的配置文件

创建完成配置映射之后,需要在k8s部署时读取cm配置,这一步需要调整项目下的helm配置。

注意配置的缩进,直接拷贝(Ctrl + V)IDEA会自动调整缩进,请使用Paste as Plain Text保证缩进不会被自动调整。

  • charts/hzero-platform/templates/_helpers.tpl
{{/* vim: set filetype=mustache: */}}
{{- /*
service.labels.standard prints the standard service Helm labels.
The standard labels are frequently used in metadata.
*/ -}}

{{- define "service.image" -}}
{{- printf "%s:%s" .Values.image.repository (default (.Chart.Version) .Values.image.tag) -}}
{{- end -}}

{{- define "service.microservice.labels" -}}
choerodon.io/version: {{ default (.Chart.Version) .Values.image.tag }}
choerodon.io/service: {{ .Chart.Name | quote }}
choerodon.io/metrics-port: {{ .Values.deployment.managementPort | quote }}
{{- end -}}

{{- define "service.labels.standard" -}}
choerodon.io/release: {{ .Release.Name | quote }}
{{- end -}}

{{- define "service.match.labels" -}}
choerodon.io/release: {{ .Release.Name | quote }}
{{- end -}}

{{- define "service.logging.deployment.label" -}}
choerodon.io/logs-parser: {{ .Values.logs.parser | quote }}
{{- end -}}

{{- define "service.monitoring.pod.annotations" -}}
choerodon.io/metrics-group: {{ .Values.metrics.group | quote }}
choerodon.io/metrics-path: {{ .Values.metrics.path | quote }}
{{- end -}}

{{/*
Return the appropriate apiVersion for deployment.
*/}}
{{- define "app.deployment.apiVersion" -}}
{{- if semverCompare "<1.9-0" .Capabilities.KubeVersion.GitVersion -}}
{{- print "apps/v1beta2" -}}
{{- else -}}
{{- print "apps/v1" -}}
{{- end -}}
{{- end -}}

{{/*
Return the appropriate apiVersion for statefulset.
*/}}
{{- define "app.statefulset.apiVersion" -}}
{{- if semverCompare "<1.9-0" .Capabilities.KubeVersion.GitVersion -}}
{{- print "apps/v1beta2" -}}
{{- else -}}
{{- print "apps/v1" -}}
{{- end -}}
{{- end -}}

{{/*
Return the appropriate apiVersion for ingress.
*/}}
{{- define "app.ingress.apiVersion" -}}
{{- if semverCompare "<1.14-0" .Capabilities.KubeVersion.GitVersion -}}
{{- print "extensions/v1beta1" -}}
{{- else -}}
{{- print "networking.k8s.io/v1beta1" -}}
{{- end -}}
{{- end -}}
  • charts/hzero-platform/templates/deployment.yaml

26~28行定义读取CMCM的名称来自于values.yaml

apiVersion: {{ include "app.deployment.apiVersion" . }}
kind: Deployment
metadata:
name: {{ .Release.Name }}
labels:
{{ include "service.labels.standard" . | indent 4 }}
{{ include "service.logging.deployment.label" . | indent 4 }}
spec:
replicas: {{ .Values.replicaCount }}
selector:
matchLabels:
{{ include "service.labels.standard" . | indent 6 }}
template:
metadata:
labels:
{{ include "service.labels.standard" . | indent 8 }}
{{ include "service.microservice.labels" . | indent 8 }}
SERVICE_CODE: {{ .Chart.Name | quote }}
annotations:
{{ include "service.monitoring.pod.annotations" . | indent 8 }}
spec:
containers:
- name: {{ .Release.Name }}
image: "{{ .Values.image.repository }}:{{ .Chart.Version }}"
imagePullPolicy: {{ .Values.image.pullPolicy }}
envFrom:
- configMapRef:
name: {{ .Values.configMap.name }}
env:
{{- range $name, $value := .Values.env.open }}
{{- if not (empty $value) }}
- name: {{ $name | quote }}
value: {{ $value | quote }}
{{- end }}
{{- end }}
ports:
- name: http
containerPort: {{ .Values.service.port }}
protocol: TCP
# readinessProbe:
# httpGet:
# path: /health
# port: {{ .Values.deployment.managementPort }}
# scheme: HTTP
readinessProbe:
exec:
command:
- curl
- localhost:{{ .Values.deployment.managementPort }}/actuator/health
failureThreshold: 3
initialDelaySeconds: 60
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 10
resources:
{{ toYaml .Values.resources | indent 12 }}
volumeMounts:
- mountPath: /Charts
name: data
{{- if not (empty .Values.persistence.subPath) }}
subPath: {{ .Values.persistence.subPath }}
{{- end }}
volumes:
- name: data
{{- if .Values.persistence.enabled }}
persistentVolumeClaim:
claimName: {{ .Values.persistence.existingClaim | default ( .Release.Name ) }}
{{- else }}
emptyDir: {}
{{- end }}
  • charts/hzero-platform/values.yaml

6~7行定义了CM的名称,这里需要和猪齿鱼配置映射的名称匹配。

# Default values for hzero-platform.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.
replicaCount: 1
configMap:
name: hzero-dev

image:
repository: registry.choerodon.com.cn/hzero-hzero/hzero-platform
pullPolicy: Always

env:
open:
# 数据库地址
SPRING_DATASOURCE_URL: jdbc:mysql://db.hzero.org:3306/hzero_platform?useUnicode=true&characterEncoding=utf-8&useSSL=false
# Redis DB
SPRING_REDIS_DATABASE: 1
metrics:
path: /actuator/prometheus
group: spring-boot

logs:
parser: spring-boot

persistence:
enabled: false

service:
enabled: false
type: ClusterIP
port: 8100
name: hzero-platform
deployment:
managementPort: 8101

resources:
# We usually recommend not to specify default resources and to leave this as a conscious
# choice for the user. This also increases chances charts run on environments with little
# resources,such as Minikube. If you do want to specify resources,uncomment the following
# lines,adjust them as necessary,and remove the curly braces after 'resources:'.
limits:
# cpu: 100m
memory: 1.7Gi
requests:
# cpu: 100m
memory: 1.2Gi

创建部署配置

功能路径:部署 > 应用部署 > 资源 > 创建部署配置

在部署配置选择对应服务,如果项目中有values.yaml文件,这里会自动带出。将环境相关的信息替换完成后保存。

创建应用流水线

功能路径:开发 > 应用流水线

在应用流水线中创建流水线,基本的流程至少需要包含构建、发布和部署三个流程,代码检查是可选的部分。

代码检查配置

选择需要检查的代码分支,检查类型分为两类,SonarMaven用来检查Maven项目,SonarScanner用来检查通用项目,自定义配置用来配置私有的Sonar服务信息。

构建配置

构建这一步主要执行Maven编译打包和Docker镜像构建,共享目录设置定义是否使用缓存,比如历史拉取的Maven资源等等。

Maven构建这一步,没有特殊需要,一般只需要执行

mvn package -Dmaven.test.skip=true -U -B

Docker构建这一步需要配置一些文件路径,Dockerfile文件路径需要填写文件的相对路径,镜像构建上下文是执行镜像打包命令的目录,一般是构建产物所在的目录,例如Maven默认构建的包所在的目录为target目录,这里填写的是构建产出物的相对路径。

生效“应用流水线”

在上一步创建完应用流水线之后,如下所示:

注意:如果你的目标分支不是master还需要做一些手工处理,需要手工将master分支的.gitlab-ci.yml文件复制或者合并到目标分支

测试自动化部署

完成所有配置之后,在项目中提交代码或者直接在应用流水线中选择全新执行,然后在猪齿鱼的应用流水线中和 Gitlab 的CI/CD > Pipelines中可以看到编译和镜像打包步骤的执行。

在部署节点执行完成之后,在部署 > 应用部署 > 资源中查看相关的服务可以看到实例的替换。

触发器部署

在实际项目开发过程中,可能存在部分基础组件项目,这些项目不会直接部署到服务器,而是需要打包成可以来的JarMaven仓库中,然后再部署依赖了此模块的项目,为了解决这类的需求,需要借助Gitlab的触发器来实现。

创建触发器

如果项目依赖了其他的模块,需要在模块代码更新之后自动部署,可以在Gitlab中创建触发器。

触发触发器

新建好触发器之后,复制下方提示中的脚本到被依赖模块项目的应用流水线的自定义阶段。

自定义CI配置:

如果需要将当前工程部署到Maven仓库供其他项目拉取,在CIMaven构建步骤中选择自定义仓库配置

然后执行打包命令

mvn clean deploy -Dmaven.test.skip=true -Dmaven.springboot.skip=true -Dmaven.javadoc.skip=true -U -B -s settings.xml

完整的应用流水线配置如下所示:

关于猪齿鱼

Choerodon 猪齿鱼作为全场景效能平台,是基于Kubernetes,Istio,knative,Gitlab,Spring Cloud来实现本地和云端环境的集成,实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理,从而更快、更频繁地交付更稳定的软件。

更多内容

大家可以通过以下社区途径了解Choerodon猪齿鱼文档、最新动态、产品特性:

【Choerodon官网】

https://choerodon.io/zh/

【汉得开放平台】

https://open.hand-china.com/

【汉得开放论坛】

https://openforum.hand-china.com/

也可加入Choerodon猪齿鱼官方社区用户交流群,交流猪齿鱼使用心得、Docker、微服务、K8S、敏捷管理等相关理论实践心得,群同步更新版本更新等信息,大家可以加群讨论交流。

①-Choerodon猪齿鱼官方交流(已满);

②-Choerodon猪齿鱼官方交流(可加);【微信号发至客服邮箱[email protected],运营小伙伴拉您入官方交流群】

欢迎加入Choerodon猪齿鱼社区,共同为企业数字化服务打造一个开放的生态平台。

· 5 分钟阅读

1.jpg

  • 时间:2019年11月15日
  • 地点:广州阳光酒店
  • 指导单位:上海市经济和信息化委员会等
  • 主办单位:dbaplus社群
  • 支持单位:粤港澳合作促进会 金融专业委员会

▧ 收获1:主流数据库选型、架构设计、迁移实践,一网打尽!

时下数据库可选种类众多,成本低、灵活性强的开源数据库无疑成为了越来越多企业的新尝试。至于如何进行选型、设计、迁移与应用,希望Gdevops广州站能给到你答案。

  • 中国电信甜橙金融 创新中心总经理 张小虎 《分布式数据库能力验证与落地实践》

  • 腾讯 云数据库总负责人 丁奇(林晓斌) 《云上MySQL产品研发和运维的挑战与实践》

  • 贝壳找房 技术总监 肖鹏 《数据库选型那些事儿》

  • 腾讯 云数据库产品副总监 邵宗文 《图数据库及其应用场景解读》

  • SequoiaDB巨杉 数据库研发副总裁 许建辉 《云架构下的分布式数据库设计实践》

  • 爱可生 技术总监 明溪源 《金融行业MySQL高可用实践》

  • 《Oracle/MySQL DBA工作笔记》作者 杨建荣 《迁移到MySQL的架构和性能探索》

  • 微众银行 数据库运维经理 胡盼盼 《微众银行Redis应用实践》

▧ 收获2:DevOps与AIOps的落地,互联网、金融、电信行业之间有何异同?

这两年,DevOps和AIOps从概念逐渐落地开花,尤其在一些互联网大厂和传统名企的成功实践之下,可学习借鉴的案例越来越多。如果你的企业还困扰于不知从何落地,不妨来Gdevops广州站看看有没有合适的范例参考?

  • 微博 广告大数据团队负责人 彭冬 《智能运维:从0搭建大规模分布式AIOps系统》

  • 新炬网络 运维产品部总经理 宋辉 《打通任督二脉:一体化智能运维平台建设与落地》

  • 中国联通大数据 技术部平台组核心技术负责人 余澈 《运营商的大数据运维及集群治理实践》

  • 阿里 搜索事业部技术专家 施立 《阿里搜索数据化DevOps和AIOps探索与实践》

  • 前汇丰银行 DevOps负责人 周纪海 《DevSevOps在国际大型银行的落地和实践》

  • JFrog 高级架构师 高欣 《基于Kubernetes的DevOps实践之路(拟)》

议程安排

agenda.jpg

Choerodon猪齿鱼社区 · 专属优惠

名额有限,马上扫码报名吧~

qr-code.png

关于猪齿鱼

Choerodon 猪齿鱼是一个全场景效能平台,基于 Kubernetes 的容器编排和管理能力,整合 DevOps 工具链、微服务和移动应用框架,来帮助企业实现敏捷化的应用交付和自动化的运营管理的平台,同时提供 IoT、支付、数据、智能洞察、企业应用市场等业务组件,致力帮助企业聚焦于业务,加速数字化转型。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性,以及参与社区贡献:

· 20 分钟阅读

作者 | Christopher Lee & Sean D. Mack

如果您曾经对敏捷或DevOps的历史、结构、原则或共性有过疑问,那么您将在这篇文里找到答案,本文被拆分两篇,上篇《使用DevOps强化敏捷(上)》主要介绍敏捷和DevOps的历史、差异和好处,本篇主要介绍敏捷和DevOps的几个共性。

敏捷和DevOps的目标是一致的,因此在实践过程中会发现它们有所重叠。在许多方面,DevOps和敏捷的交叉关系到协作文化以及从这种文化中产生的现代技术实践和过程。

协作文化

敏捷和DevOps之间的核心共性之一是他们都强调打造协作文化。这两种方法都着眼于打破壁垒,增加成员共同责任感。通过打破隔离,DevOps和Agile减少了交接,提高了向客户交付的速度。DevOps将这种协作概念扩展到了运维团队中,而敏捷关注QA是否包含在内。

在敏捷中,我们看到协作文化直接融入到了敏捷宣言的核心原则中。第一个定义“个人和交互重于流程和工具”明显地表达了合作的需要。此外,第三个原则,“客户协作重于合同谈判”,强调需要将这种协作扩展到开发团队之外,也扩展到客户当中。

敏捷教练Susan McIntosh在她的文章《敏捷心态到底是什么》中提到,“敏捷心态是一种支持敏捷工作环境的态度。其中包括尊重、协作、改进和学习反馈、对归属的自豪感、专注于提供价值以及适应变化的能力。这种心态对于培养高绩效团队是必要的,而这些团队反过来又为客户带来了惊人的价值。”

在敏捷中有许多协作的例子,诸如结对编程、Mob编程和Swarming等实践都允许更大的团队合作开发软件,虽然这与开发的原概念相悖(开发原本是指由一个单独的程序员单独完成的任务)。此外,敏捷工作还将QA无缝链接到流程中,作为团队任务的一部分。RonLichty表示:“我将通过Scrum中的产品所有者角色将产品管理集成到团队中。PdMs向开发人员“越过墙”抛出需求的历史由来已久,这与开发人员向测试人员“越过墙”抛出代码的历史没有太大不同!”RonJeffries写了他在极限编程中处理故事的方法。Atlassian建议通过使用单页仪表板缩小PRD(产品需求文档)来保持需求的精简。

2.png

DevOps的许多基本概念也是围绕协作的概念构建的。事实上,这个可以追溯到早先反对将开发、运维和QA分割之时。DevOps运动的基础之一,正是人们认识到开发、运维和QA彼此独立会导致利益冲突、增加交接成本。

Thoughtworks的首席科学家Martin Fowler指出协作在DevOps中扮演重要角色,他认为,“DevOps文化的主要特征是增加了开发和运维角色之间的协作……开发和运维之间不应该存在壁垒。”和从一开始就一起工作解决问题相比,切换周期和文档是一个糟糕的替代品。调整资源结构,使运维人员能够尽早参与到团队中来是很有帮助的。

另外,建立协作文化的一个关键方法是在所有参与交付的团队之间制定共同的目标。使开发、运维和QA之间在明确的目标上保持一致,并将重点放在客户需求和最终交付上。

DevOps鼓励协作的另一种方式是将运维活动集成到Sprint中。这可以通过在Sprint中加入运维团队成员来实现,甚至更好的方法是,将运维职责分给所有Sprint团队成员。

除了交付特性和“功能”之外,在高性能的DevOps组织中,通常还向交付产品的团队提供维护这些产品的职责。一旦系统的稳定性得到证明,它就会移交给另一个团队进行维护。其他公司包括开发团队,作为操作问题的寻呼机轮换的一部分。这就产生了共同的责任,并加强了共同的目标和责任。

当然,DevOps不是一份工作,它不是一个角色,也不是任何一个人或团队的责任。DevOps的核心是协作,这与敏捷宣言中的原则保持一致。

小批量、短周期

小批量和短周期是敏捷化的关键。通过减少对系统的更改,敏捷可以更快地为客户带来价值。这种快速部署能带来快速反馈,客户或用户可以快速查看已开发的内容,团队能在必要时快速调整路线。这与瀑布式方法形成了鲜明的对比,在瀑布式方法中,客户可能要等上几个月甚至几年才能看到交付成果,只有到那时才能确定产品是他们所想的还是所要的。DevOps采用小批量的概念,并通过持续集成和持续部署(CI/CD)对其进行扩展。CI/CD提供的工具链加速团队对客户的价值,将周期从几周缩短到几天甚至几小时。

小批量是精益的关键。起源于20世纪30年代的精益为敏捷和开发人员提供了一些核心基础,它专注于消除浪费和减少批量,减少正在处理的工作量,从而减少等待下一个阶段处理的库存量。

这一概念与敏捷的核心原则相呼应,敏捷的核心原则规定“经常交付产品,从几周到几个月,优先选择较短的时间段。”小批量和较短的周期时间有很多好处。根据DonReinersen的说法,为了让产品开发增加价值,结果必然会有不确定性。我们不应该试图最小化失败,而应该接受可变性。我们可以通过有效地学习和高效地生成信息来减少不确定性。VirtualCTO官诺亚•坎特(Noah Cantor)强调了短反馈循环的影响,“有很多学术研究和行业研究表明,反馈周期越长,人们从中学习的知识就越少。反之亦然——反馈周期越短,人们可以从中学习的越多。”

有很多方法可以确保你在敏捷中拥有小批量和较短的周期时间。最基本的方法之一是将用户故事分割成适合迭代的片段。减少故事的规模很多,比如将功能拆分为单个用户故事或任务等。

当划分和拆分用户故事时,重要的是确保您不创建合成型团队,而是坚持使用功能团队。垂直而不是水平地拆分用户故事。也就是说,观察端到端的特性,而不是应用程序的特定层。

小批量和短周期也是DevOps的关键。DevOps的重点是从左到右增加产品流。通过使用精益的工具(如价值流图),可以识别瓶颈并消除它们,从而增加对客户的价值流。

此外,较短的循环时间是DevOps第二和第三种方法的关键。与敏捷一样,更短的周期意味着价值能更快地传递给客户,因此团队可以更快地获得反馈,以便能快速向客户发布特性或更改,并根据反馈快速调整。

DevOps中缩短循环时间和I迭代周期的关键之一是持续集成(CI)和持续部署(CD)。通过持续的集成,一些更改会不断地被合并和验证,从而使整个产品始终具有潜在的可交付性。而持续部署会确保产品始终处于可部署状态,允许随时向客户交付价值。这两个实践采用了敏捷方法中最初引入的快速开发和交付,并将其周期进一步减少到每天甚至每小时。

工作可视化

可视化是DevOps和敏捷中的另一个关键元素。对于像Scrum和看板这样的敏捷实践,通常采用板的形式来共享信息。DevOps利用并进一步扩展了这些方法,来共享系统在某一特定时间内的执行情况,这可以通过大型可视仪表盘和共享仪表盘的形式等展现。

虽然敏捷宣言并没有规定工作可视化的必要性,但是概念是实践的基础。宣言强调“个人和交互重于流程和工具”和“客户协作重于合同谈判”以及“响应变化重于遵循计划”,这三个方面都能通过工作可视化而得到加强。

敏捷促成了“信息辐射源”概念的发展,这是一种位于敏捷开发团队附近的大型图表,能显示整个开发周期的工作进展。Alistair Cockburn在2000年创造了“信息辐射源”这个术语,并在他2001年出版的《敏捷软件开发》一书中做了介绍。

工作可视化能直接暴露出时间的缺漏,以优化工作和流程。通过为团队提供可视化工作的方法,使团队能够一起工作更加方便,这些板还帮助快速识别瓶颈。

DevOps的第二种方法集中于增强反馈和共享操作信息,这是一种很好的方法。这可以包括Scrum板,也可以包括关于系统性能、用户体验以及代码和基础结构性能的实时数据。这些信息图表就像在整个建筑的战略位置张贴的大型监视器。

1.png

在DevOps手册中,作者还用了整整一章的篇幅来讨论遥测的问题。他们在他们的“创建遥测技术以发现和解决问题”一章中写道,“我们的目标是将这些信息辐射到组织的其他部门,确保任何想要我们正在运行的任何服务的信息的人都能获得这些信息……使价值流中的每个人都可以实时共享信息和提出观点。”

Etsy是一家以DevOps思想领导能力闻名的工艺电子商务公司,在工作可视化的领域也做了很多工作。“如果Etsy的工程有宗教信仰,那就是图形教会。”Patrick McDonnell在DevOps手册中谈到了监控部署数据的好处,他说:“通过这样做,我们可以更快地看到任何意外的部署副作用。我们甚至开始在办公室周围安装电视屏幕,以便每个人都能看到我们的服务表现。”

持续学习

敏捷和开发人员的核心原则中都有持续学习。在敏捷中,这个概念是敏捷宣言的一部分,在DevOps中,它是DevOps的第三种方法的一部分。

敏捷宣言强调“响应变化而不是遵循计划”,因此,它构建了一个强调适应需求的原则。在这种适应性中,假设团队不断的反思和改进,在持续的敏捷短周期中,团队便能够审查事情的进展情况,并对他们交付的产品和交付过程进行快速调整。此外,“客户协作重于合同谈判”的宣言宗旨意味着严格的反馈循环、倾听和从客户反馈中学习。在敏捷中,产品团队可以快速地向客户交付功能,并快速地从实际反馈中学习和快速调整。

DevOps也强调持续学习,其第三种方法便聚焦于此。在IT革命网站上,Kim写道:“DevOps第三种方法是创造一种能促进两件事的文化:一是持续实践、冒险和从失败中学习;二是理解重复和实践是精通某件事的先决条件。”

同时,敏捷和DevOps都把不断学习和不断实验的精神付诸实践。在Scrum中,有被置于流程中的回顾会,用以确保团队花时间对每一次迭代进行反思、从错误中学习并总结成功的经验。回顾会是团队对前一次迭代进行反思并寻找改进的会议,小组成员会讨论哪些进展顺利,哪些进展不顺利,并列举需要改进的方面。

Sprint演示是敏捷流程中持续学习的另一个很好的例子。许多敏捷团队会在每次迭代结束时对Sprint可交付成果进行演示,这样可以让团队成员互相学习,更好地理解产品的所有部分。Sprint演示中还能加入项目涉众的快速反馈,为团队提供了一个互提意见和互相学习的机会,帮助大家继续成长。

在DevOps中,不断学习和不断实验的精神通过事故事后分析等行为得到了强调。JohnAllspaw帮助推出了事后无指责概念,之后这成为了现在DevOps实践的一个共识。他在博客中写道:“事后总结最重要的事情不是一系列可以采取的行动,而是组织学习。”

在Etsy,员工不仅毫无责备地看待事件,甚至还庆祝失败。庆祝失败的原因之一是犯错误的人实际上是最好的工程师,这些人是那些为企业做出最大改变和推动创新的人。因此,重要的不仅仅是限制责备,实际上还灌输了一种文化习惯,这种习惯将庆祝失败视为学习的机会。Etsy的CTO每年会颁发一个很有声望的奖项,以庆祝今年最大的失败。DevOps通过灌输诸如无指责事后分析和失败庆祝等习惯来鼓励一种开放讨论失败并不断学习和成长的文化。

『由于篇幅原因,本文被拆分两篇,上篇主要介绍敏捷和DevOps的历史、差异和好处,点击蓝字即可阅读《使用DevOps强化敏捷(上)》。』

关于猪齿鱼

Choerodon 猪齿鱼是一个全场景效能平台,基于 Kubernetes 的容器编排和管理能力,整合 DevOps 工具链、微服务和移动应用框架,来帮助企业实现敏捷化的应用交付和自动化的运营管理的平台,同时提供 IoT、支付、数据、智能洞察、企业应用市场等业务组件,致力帮助企业聚焦于业务,加速数字化转型。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性,以及参与社区贡献:

· 18 分钟阅读

作者 | Christopher Lee & Sean D. Mack

译者 | 温馨

如果您曾经对敏捷或DevOps的历史、结构、原则或好处有过疑问,那么您将在这篇文里找到答案,本文被拆分两篇,上篇主要介绍敏捷和DevOps的历史、差异和好处。

敏捷和DevOps从表面上看可能是不同的,但如果关注他们的目标,会发现它们其实非常相似。两者的目标都是更快地为客户创造价值并更快地改变市场需求。DevOps采用敏捷中介绍的原则,并将其扩展使用到代码以外的部署和运维操作中。

敏捷和DevOps的目标是一致的,因此在实践过程中会发现它们有所重叠。在许多方面,DevOps和敏捷的交叉关系到协作文化以及从这种文化中产生的现代技术实践和过程。连续测试和小批量生产等过程中更容易看到了这一点,在使工作尽量可见化的过程中,公开工作流和系统遥测,有助于确保向客户快速交付工作产品,能加速向客户传递价值。

敏捷和DevOps专注于提供客户价值,这不是为了提供更多功能,而是为了尽可能快速有效地向最终客户提供正确的增值功能。DevOps使用敏捷的概念并对其进行了扩展延伸,因此您可以通过实现DevOps实践来增强敏捷性。

什么是DevOps?什么是敏捷?

在开始研究DevOps和敏捷之间的关系之前,首先要对这些术语的含义有一个共同的理解。虽然有许多定义,但它们可以从根本上理解为一套原则,从中可以衍生出工程师文化和实践。

敏捷的存在时间比DevOps长,定义也更为成熟。首次定义于2001年2月的《敏捷宣言》,该宣言包含了以下几条定义:

  • 个人和交互重于流程和工具
  • 工作软件重于公共文档
  • 与客户协作重于合同谈判
  • 响应变化胜过遵循计划

尽管已经有了对DevOps宣言的尝试,但还没有哪一个宣言能够获得敏捷宣言所具有的那种广泛接受度。作为一个一般概念,DevOps重视协作,特别关注开发和运营团队之间的交叉功能以及这两个方面的责任。敏捷教练Anthony Gardiner说,“我测试,我编码,我部署,我在周末起床并修复错误——我让我的代码更好,所以我不必在周末起床。”DevOps可以被认为是一种为客户提供价值的方法,专注于协作和小批量,聚焦持续集成,自动化,持续测试和持续交付。

虽然没有单一的定义,Gene Kim、Kevin Behr和George Spafford在他们的开创性书籍《凤凰计划》中介绍了DevOps的“三种方法”。这三种方法是许多DevOps实践的核心。

Kim后来在《DevOps Handbook》中对这些方法进行了扩展,他与Jez Humble和Patrick Debois合著了这本手册。

这三种方法包括:

方法一系统思维强调整个系统的性能,而不是特定工作或部门的性能——大到可以是一个部门,小到可以是单个贡献者。
方法二增强反馈循环创建从右到左的反馈循环。以缩短和增强反馈为流程改进计划的目标,以便持续进行必要的修正。
方法三持续实践和学习的文化创造一种能促进两件事的文化:一是持续实践、冒险和从失败中学习;二是理解重复和实践是精通某件事的先决条件。

历史

追溯到20世纪90年代,敏捷已存在的时间比DevOps长得多,后者在将近20年后才出现。然而,这两套原则都源于精益制造,其历史可以追溯到20世纪40年代。虽然DevOps的流行度持续增长,但敏捷仍然比DevOps更广为人知。谷歌趋势表示“敏捷”一词的搜索量大约是“DevOps”一词的三倍。

敏捷的根源可以追溯到20世纪40年代的精益流程,其中包括看板,一种可视化丰田生产系统一部分工作流程的方法。限制理论也是后来发展起来的。然而,敏捷的软件开发方法在20世纪90年代真正起步,当时一群软件开发人员常受到瀑布式开发方法中涉及的高度严格的流程的困扰。这些常导致软件项目花费了数月甚至数年才导致失败。在20世纪80年代和90年代,诞生了几种软件迭代开发方法作为瀑布方法的替代,包括极限编程(XP)和看板。1995年,引入了敏捷开发的Scrum实践。然后,在2001年Snowbird山度假村的著名会议上,一群思想领袖齐聚一堂,共同编写敏捷宣言。敏捷发展至今,其中许多变化和实践都是从最初的宣言演变而来的,包括现代敏捷。虽然敏捷制定了总体原则,但实践敏捷原则的方法有很多,Scrum和看板是最受欢迎的两种(关于它们的区别,可阅读《Kanban VS Scrum:哪个是最好的敏捷项目管理框架》)。

DevOps是一套更为新的原则,它源于精益制造中的一些相同概念。“DevOps”一词于2009年首次推出,当时Patrick Debois在比利时举办了“Devopsdays”活动。2013年,Gene Kim(作者),Kevin Behr(作者)和George Spafford(作者)撰写了他们的书《凤凰计划》,其中提出的许多内容构成了DevOps的基础概念。2014年,随着DevOps企业峰会的启动,DevOps不断扩展到企业环境中。今天,DevOps继续与敏捷一起成长和发展。

关键差异

虽然敏捷和DevOps具有很多一致性,但需要注意的是它们的侧重点不同。敏捷主要关注应用程序的构建,而DevOps则将这一重点扩展到构建和运营应用程序。DevOps采用了敏捷的许多概念,并将这些概念扩展到构建过程之外并带入生产。正是这个扩展导致了真正的差异。

如果说存在不同,那么主要在于聚焦点的不同。敏捷教练Martin Corbett表示,“敏捷专注于分解工作,以尽快为客户提供更多价值,而DevOps专注于将代码从构建扩展到部署的项目,例如持续部署。”此外,敏捷专注于构建工作软件以及开发和QA之间的协作,而DevOps则专注于开发、QA和运营之间的协作。

虽然许多人都在寻找敏捷与DevOps之间的差异,但实际情况是,这两种方法具有非常相似的目标和基础原则,并且最终具有比差异更多的相似性。

DevOps是敏捷的延伸

在许多方面,DevOps可以被视为敏捷的延伸,甚至是敏捷的自然演变。在瀑布开发流程中,有一个明确的交接(它是强制执行的过程)。敏捷作为一个持续的过程,需要一种新的方法,DevOps有助于实现这种方法。

为了实现精益和敏捷最佳实践的核心小批量发布,在DevOps中普及的全栈工程师的概念是这种需求的最佳答案。为了减少交接,工程师必须悉知系统的所有部分,以便团队中的任何成员都能理解操作要求,而无需交付给其他团队。同样,跨职能团队必须成为常态,以便小型,独立的团队可以提供功能齐全的产品,而无需向运营团队进行额外的交接。

此外,敏捷的持续流程需要一定程度的构建和部署自动化。其中大部分都是在DevOps的CI / CD实践和工具中提供的。CI / CD需要快速部署经过全面测试并且功能齐全的代码给客户。因此,很容易看出CI /CD是敏捷实践所必需的自然演化。这些做法持续发展,使发布周期时间进一步缩短,从数周到数天甚至数小时。

从另一个角度考虑,如果您有一个只有在开发完成后才能开始的为期两周的QA周期,那么在一两周内就很难将代码推出。同样,诸如变更审批、释放资源、硬件购买和安装等需要耗费时间的事情,都会影响你按时推出代码。更不用说,您可能还有很多的交接工作,或者有一个周期长又繁重的发布过程。如何进行为期两周的迭代并进行为期两个月的发布过程?对此的明显答案是DevOps。

这并不是说没有DevOps就无法实现敏捷。敏捷在DevOps之前很久就存在,并且肯定有敏捷团队不遵循许多DevOps实践。正如Noah Cantor所说,“你可以做敏捷实践和DevOps实践,但你不能采用敏捷原则或DevOps原则,因为它们太相似而不能分开。”并不是说它们不可分割,只是敏捷作为DevOps的前身,同时激发了DevOps的影响力。

好处

精益一直是DevOps的核心,就像敏捷是从精益中生长出来的一样。DevOps也是如此,所以这两者有很大的共同点并不奇怪。DevOps采用Agile中的概念,并将其扩展到代码部署之外。DevOps采用这些概念并将其应用于应用程序和服务的管理。它利用并优化了敏捷的原则,并且沿用了敏捷组织早已意识到的长处。

并不是说为DevOps而做DevOps,或者说为敏捷而做DevOps。2017年DevOps状态报告显示,高性能DevOps团队的部署速度提高了46倍,交付时间缩短了44倍,更改失败率降低了5倍,平均恢复时间缩短了96倍(MTTR)。在具有成熟DevOps实践的组织中,这些数字显然被低估了。

当我们查看敏捷和DevOps重叠的每个区域时,DevOps放大了敏捷实践,我们希望您能够采取一些具体措施来推动组织的发展。构建协作的最关键步骤之一是制定共同目标。有了共同的目标,您可以确保开发,运营,QA都一致朝着同一目标努力。

小批量交付为推动DevOps实践加速组织提供了另一个绝佳机会。在Scrum或看板等流程中,要将操作任务和操作思想集成到工作中。如果您正在使用Scrum,您也可以考虑使用看板,它更容易适应操作流程。

无论使用哪种方法进行小批量交付,您都可能希望确保使用相同的系统来跟踪整个团队的工作。通过统一跟踪系统,您可以确保不积压工作,并真实反应所有计划内和计划外工作,让您更容易地使工作可见。作为敏捷的一个关键原则,我们还可以扩展使工作可见的概念,以显示运营工作、系统操作和架构支持等工作。组织还可以通过信息辐射体(比如看板)跨团队分享这些信息。

当您着眼于构建更具协作性的文化时,要把每一次失败都当作组织学习的机会。在这个文化中建立一些仪式,比如无可指责的事后反思、黑客马拉松和失败奖励等。

对于本文中讨论的重叠,存在组织上的含义。在敏捷和DevOps中包含QA意味着我们必须开始构建跨职能团队,并培养具有广泛知识技能的人员。这种重叠是随着“全堆栈工程师”的概念而发展起来的。虽然每个人都知道一切可能不现实,但我们当然可以努力确保团队中的每个人都有共同的责任和目标,包括质量和运营,如果他们乐于负责和学习的话。

有许多方式可以采用敏捷原则并使用DevOps强化它们,但最重要的是组织文化的一致性。如果团队在目标上没有保持一致,那么敏捷中规定的团队方法将不能扩展到部署以外的操作中使用。如果所有技术交付团队都遵循相同的目标,即可立即开始打破这些组织之间的孤岛。如果我们可以通过敏捷开始打破组织孤岛并通过DevOps强化这项工作,我们将拥有真正的高性能组织。

『由于篇幅原因,本文被拆分两篇,下一篇主要将介绍DevOps和敏捷之间的几个共性,欢迎大家持续关注。』

关于猪齿鱼

Choerodon 猪齿鱼是一个全场景效能平台,基于 Kubernetes 的容器编排和管理能力,整合 DevOps 工具链、微服务和移动应用框架,来帮助企业实现敏捷化的应用交付和自动化的运营管理的平台,同时提供 IoT、支付、数据、智能洞察、企业应用市场等业务组件,致力帮助企业聚焦于业务,加速数字化转型。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性,以及参与社区贡献:

· 13 分钟阅读

本文将会对Gitlab CI进行简要介绍,包括Gitlab Runner,Gitlab CI中的相关概念以及.gitlab-ci.yml的常用配置。

那么,GitLab CI 是什么?

GitLab CI 是GitLab内置的进行持续集成的工具,只需要在仓库根目录下创建.gitlab-ci.yml 文件,并配置GitLab Runner;每次提交的时候,gitlab将自动识别到.gitlab-ci.yml文件,并且使用Gitlab Runner执行该脚本。

Gitlab Runner

简介

GitLab-Runner就是一个用来执行.gitlab-ci.yml 脚本的工具。可以理解成,Runner就像认真工作的工人,GitLab-CI就是管理工人的中心,所有工人都要在GitLab-CI里面注册,并且表明自己是为哪个项目服务。当相应的项目发生变化时,GitLab-CI就会通知相应的工人执行对应的脚本。

Runner类型

GitLab-Runner可以分类两种类型:Shared Runner(共享型)和Specific Runner(指定型)。

  • Shared Runner:所有工程都能够用的,且只有系统管理员能够创建。
  • Specific Runner:只有特定的项目可以使用。

Runner搭建

▍1. Runner 安装

以Linux为例:

# For Debian/Ubuntu
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash

# For RHEL/CentOS
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash

其他系统请参考官网文档: https://docs.gitlab.com/runner/install/

▍2. 获取Runner注册Token

安装好Runner之后,需要向Gitlab进行注册,注册Runner需要GitLab-CI的url和token。可根据需求注册选择所需类型Runner。

获取Shared Runner注册Token: 使用管理员用户登录,进入Admin Area->OverView->Runners界面。

1

获取Specific Runner注册Token: 进行项目仓库->settings->CI/CD界面

2

▍3. 注册Runner

执行gitlab-ci-multi-runner register命令进行Runner注册,期间会用到前期获取的url及token;注册完成之后,GitLab-CI就会多出一条Runner记录:

3

更多系统注册,请参考阅读官方文档:https://docs.gitlab.com/runner/register/

相关概念

▍管道(pipeline)

每个推送到 Gitlab 的提交都会产生一个与该提交关联的管道(pipeline),若一次推送包含了多个提交,则管道与最后那个提交相关联,管道(pipeline)就是一个分成不同阶段(stage)的作业(job)的集合。

▍阶段(Stage)

阶段是对批量的作业的一个逻辑上的划分,每个 GitLab CI/CD 都必须包含至少一个 Stage。多个 Stage 是按照顺序执行的,如果其中任何一个 Stage 失败,则后续的 Stage 不会被执行,整个 CI 过程被认为失败。

4

以图中所示为例,整个 CI 环节包含三个 Stage:build、test 和deploy。

  • build 被首先执行。如果发生错误,本次 CI 立刻失败;
  • test 在 build 成功执行完毕后执行。如果发生错误,本次 CI 立刻失败;
  • deploy 在 test 成功执行完毕后执行。如果发生错误,本次 CI 失败。

下图是Gitlab对阶段和阶段状态的展示:

5

6

▍作业(Job)

作业就是运行器(Runner)要执行的指令集合,Job 可以被关联到一个 Stage。当一个 Stage 执行的时候,与其关联的所有 Job 都会被执行。在有足够运行器的前提下,同一阶段的所有作业会并发执行。作业状态与阶段状态是一样的,实际上,阶段的状态就是继承自作业的。

作业必须包含script(由Runner执行的shell脚本),随着项目越来越大,Job 越来越多,Job 中包含的重复逻辑可能会让配置文件臃肿不堪。.gitlab-ci.yml 中提供了 before_script 和 after_script 两个全局配置项。这两个配置项在所有 Job 的 script 执行前和执行后调用。

Job 的执行过程中往往会产生一些数据,默认情况下 GitLab Runner 会保存 Job 生成的这些数据,然后在下一个 Job 执行之前(甚至不局限于当次 CI/CD)将这些数据恢复。这样即便是不同的 Job 运行在不同的 Runner 上,它也能看到彼此生成的数据。

在了解了 Job 配置的 script、before_script、after_script 和 cache 以后,可以将整个 Job 的执行流程用一张图概括:

7

创建.gitlab-ci.yml 文件

什么是.gitlab-ci.yml文件

从7.12版本开始,GitLab CI使用YAML文件(.gitlab-ci.yml)来管理项目配置。该文件存放于项目仓库的根目录,并且包含了你的项目如何被编译的描述语句。YAML文件使用一系列约束叙述定义了Job启动时所要做的事情。

Job

Job是.gitlab-ci.yml文件中最基本的元素,由一系列参数定义了任务启动时所要做的事情,用户可以创建任意个任务;每个任务必须有一个独一无二的名字,但有一些保留keywords不能用于Job名称,image,services,stages,types,before_script,after_script,variables,cache。

Job被定义为顶级元素,并且至少包括一条script语句,如果一个 Job 没有显式地关联某个 Stage,则会被默认关联到 test Stage。

示例:

job1:
# 关联到bulid阶段
stage: build
# 所需执行的脚本
script:
- execute-script-for-job1

参数详情

下面是关于配置CI/CD管道的常用参数详细说明。

▍stages

用于定义所有作业(job)可以使用的全局阶段,gitlab-ci.yml允许灵活定义多个阶段,stages元素的顺序定义了作业执行的顺序。Job关联的stage名相同时,该多个Job将并行执行(在拥有足够Runner情况下)。下一个阶段的job将会在前一个阶段的job都完成的情况下执行。

如果文件中没有定义 stages,那么则默认包含 build、test 和 deploy 三个 stage。Stage 中并不能直接配置任何具体的执行逻辑,具体的执行逻辑应该在 Job 中配置。

示例:

stages:
- build
- test
- deploy

▍stage

阶段是根据每个Job定义的,并且依赖于全局定义的阶段。它允许将作业(Job)分组到不同的阶段。

示例:

stages:
- build
- test
- deploy

job 1:
stage: build
script: make build dependencies

job 2:
stage: build
script: make build artifacts

job 3:
stage: test
script: make test

job 4:
stage: deploy
script: make deploy

▍script

script是一段由Runner执行的shell脚本。

示例:

job:
script: "bundle exec rspec"

这个参数也可以使用数组包涵好几条命令:

job:
script:
- uname -a
- bundle exec rspec

有些时候,script命令需要被单引号或者双引号所包裹。举个例子,命令中包涵冒号的时候,该命令需要被引号所包裹,这样YAML解析器才知道该命令语句不是“key: value”语法的一部分。当命令中包涵以下字符时需要注意打引号:: { } [ ] , & * #? | - < > = ! % @ `

▍image and services

这两个选项允许开发者指定任务运行时所需的自定义的docker镜像和服务。

示例:

#为每个作业定义不同的映像和服务
test:2.1:
image: ruby:2.1
services:
- postgres:9.3
script:
- bundle exec rake spec

test:2.2:
image: ruby:2.2
services:
- postgres:9.4
script:
- bundle exec rake spec

▍before_script和after_script

before_script是用于定义一些在所有任务执行前所需执行的命令, 包括部署工作,可以接受一个数组或者多行字符串。after_script用于定义所有job执行过后需要执行的命令,可以接受一个数组或者多行字符串。

示例:

#定义全局 before_script:
default:
before_script:
- global before script
#覆盖全局before_script
job:
before_script:
- execute this instead of global before script
script:
- my command
after_script:
- execute this after my script

▍only and except

  • only和except两个参数说明了job什么时候将会被创建:
  • only定义了job需要执行的所在分支或者标签
  • except定义了job不会执行的所在分支或者标签

以下是这两个参数的几条用法规则:

  • only和except如果都存在在一个job声明中,则所需引用将会被only和except所定义的分支过滤
  • only和except允许使用正则
  • only和except允许使用指定仓库地址,但是不forks仓库

此外,only和except允许使用以下一些特殊关键字:

描述
branches当一个分支被push上来
tags当一个打了tag的分支被push上来
api当一个pipline被piplines api所触发调起,详见piplines api(https://docs.gitlab.com/ce/api/pipelines.html)
external当使用了GitLab以外的CI服务
pipelines针对多项目触发器而言,当使用CI_JOB_TOKEN并使用gitlab所提供的api创建多个pipelines的时候
pushes当pipeline被用户的git push操作所触发的时候
schedules针对预定好的pipline而言(每日构建一类~,具体请看https://docs.gitlab.com/ce/user/project/pipelines/schedules.html)
triggers用token创建piplines的时候
web在GitLab页面上Pipelines标签页下,你按了run pipline的时候

下面的例子,job将会只在issue-开头的refs下执行,反之则其他所有分支被跳过:

job:
# use regexp
only:
- /^issue-.*$/
# use special keyword
except:
- branches

更多配置详情,请参考官网文档: https://docs.gitlab.com/ee/ci/yaml/README.html#parameter-details

验证.gitlab-ci.yml

GitLab CI的每个实例都有一个名为Lint的嵌入式调试工具,它可以验证.gitlab-ci.yml文件的内容,进入项目仓库->CI/CD->CI Lint,示例如下:

8

参考文档:

关于猪齿鱼

Choerodon 猪齿鱼是一个全场景效能平台,基于 Kubernetes 的容器编排和管理能力,整合 DevOps 工具链、微服务和移动应用框架,来帮助企业实现敏捷化的应用交付和自动化的运营管理的平台,同时提供 IoT、支付、数据、智能洞察、企业应用市场等业务组件,致力帮助企业聚焦于业务,加速数字化转型。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性,以及参与社区贡献:

· 12 分钟阅读

本篇将为大家介绍如何将应用导入到 Choerodon 猪齿鱼。Choerodon 平台上导入应用有两个入口,第一个入口在应用管理页签内,是从 gitlab/github 导入应用,第二个入口在应用市场中,可以在其它平台的应用市场导出后再导入。

为什么要从外部代码管理平台导入应用

Choerodon 平台最开始发布的版本中只有应用市场的导入功能,后来在版本迭代中,越来越多的用户开始搭建并使用了 Choerodon 平台,其中包含了很多其他软件公司。而且这些软件公司有一个共同点,在了解 Choerodon 平台之前,他们的日常开发,产品的迭代已经使用上了 gitlab,所以他们的代码仓库都存在已有的 gitlab 上。

由于 Choerodon 平台与 gitlab 的高度耦合,Choerodon 平台的组织、项目、用户等都和 gitlab 的组、用户等资源一一对应的。Choerodon 的数据库中存了大量两者的中间关系表。所以 Choerodon 一般不建议直接将已有的 gitlab 迁移到 Choerodon 的 gitlab,一方面,gitlab 版本不一致,可能导致迁移失败;另一方面,中间会缺少很多关键数据,严重影响后续的其他功能。在 Choerodon 社区中也有很多用户自行写了脚本去迁移,或者直接迁移数据库,迁移的过程步骤很繁琐复杂,都或多或少出现了问题,出于此,Choerodon 才开发了从 gitlab 或者 github 导入应用到 Choerodon 平台的功能。

在介绍应用导入方法之前,先简单介绍一下应用的代码仓库组成。

Choerodon 代码仓库的主要组成

  1. 各种开发语言或者开发框架的基础代码

  2. Chart 文件夹:Choerodon 持续交付中的应用部署用的是 K8S(开源的容器集群管理系统),helm 是 K8S 一个软件包管理工具,里面存放了大量的 chart 包,每个 chart 包可以定义各种应用部署所需要的 K8S 对象文件,Chart 文件夹就是用来存放打包成 chart 包的文件。

  3. DockerFile:用来打包应用到镜像中,容器化应用,在各种流行的系统中部署,例如 linux,windows 等。

  4. Gitlab-ci.yaml:gitlab-ci 文件是 gitlab runner 所执行的脚本文件,里面可以定义各种脚本,比如在 Choerodon 中各种应用的打包,以及镜像的生成与推送,chart 包的打包与推送都是放在 gitlab-ci 文件中实现。

应用市场中的应用导入

应用市场里面的应用导入,是指从其他 Choerodon 平台的应用市场中导出应用之后,再在自己的 Choerodon 平台中导入。导入导出的内容是一个 tgz 包,里面包含了应用的一个或多个版本对应的 chart 包,导入成功之后,会生成一个没有代码仓库的应用,同时给该应用生成指定的版本。但不能对该应用进行开发生成新版本,应用部署时只能部署导入应用的指定版本。

为什么应用市场中可以导入应用

在自己的平台中,如果开发者的一个服务依赖于 mysql,但是自身平台下并没有开发部署 mysql 的团队,若此时恰好另外一个平台开发了 mysql 应用,就可以在自己的本地下新建一个 mysql 应用,把另外一个平台的 mysql 代码仓库拷贝过来,然后生成版本部署供自己使用。

这个过程很麻烦很繁琐,而且在一段时间内,开发者不会对这个应用进行开发,只需要使用,除非有版本大的更新,这大大消耗了人力物力。Choerodon 的部署是基于 helm chart 的,部署应用只需要对应版本的 chart 包 ,如果提供一个上传下载 chart 包的途径,就能直接拿到 mysql 的 chart 包,然后上传到自己的 chartmusume 仓库中,就可以在本平台进行部署了 。基于这个原因,有了猪齿鱼应用市场以及应用的导出导入功能。

应用市场导入导出的原理

当其他 Choerodon 平台一个应用发布到应用市场之后,可以选择导出应用的一个版本或多个版本的 chart 包(从 chartmusume 仓库中下载下来)和应用的相关信息 json 文件,以及各应用版本的 docker 镜像信息,将其打包成一个 zip 文件。

然后在本 Choerodon 平台中,将之前导出的 zip 导入,此时会解压该 zip 包 ,将其中的应用以及应用版本信息存入数据库中,将其中的 chart 包上传到本平台的 chartmusume 中,将应用版本的 docker 镜像从其它平台的 harbor 库拉取下来,并推送到自己的 harbor 仓库中(如果其它平台镜像不是公开的)。

之后就可以在本平台对于该应用的特定版本进行部署了,简单示例图如下:

应用管理中的导入应用

应用管理里面导入的应用是指从外部代码管理平台(gitlab/github)导入已有的应用到 Choerodon 平台,根据导入时选择的模板类型生成对应的 dockerfile,chart 文件夹,gitlab-ci.yaml 文件。该应用有对应的代码仓库,可以在已有基础上进行开发,并能通过 gitlab 的持续集成生成各种版本,用作后续的部署。

外部应用导入步骤

第一步:应用导入需要填写来源应用的仓库地址,如果之前的代码仓库来源于 github 的仓库,或者 gitlab 的公开仓库,那么不需要填写授权 token,如果是 gitlab 的私有仓库(大部分)则需要填写具有 clone 仓库权限的用户 token。

第二步:填写好名称、编码,选择指定的模板(会根据指定的模板找到指定类型的 dockerfile,charts,gitlab-ci.yaml 文件嵌入到已有的代码仓库中)

第三步:选择特定项目成员或所有项目成员拥有该应用的权限,用于权限隔离

第四步:进行 harbor 仓库和 chart 仓库设置(如无特殊需求,使用默认即可),然后点击导入即可。

外部应用导入实现逻辑

首先将填写的源仓库地址使用 jgit,(jgit 提供了一套类似 Git 命令的 Java API,可以方便地在程序中进行 git 操作)克隆到本地缓存中,填写完仓库地址和 token 之后会校验填写的 token 是否有权限克隆,没有权限则会提示无权限。

然后根据填写的编码去 gitlab 对应的组下面创建一个空的 gitlab project(包含 webhook,以及 ci 需要的 token),再根据所选的应用模板类型去将 Choerodon 模板库克隆模板到本地缓存,并找到模板中的 dockerFile 文件,chart 文件夹,gitlab-ci.yaml 文件。

将找到的模板中的文件赋值到源仓库本地缓存的各个分支中(此过程会校验是否存在对应内容,有则不复制)。之后使用 jgit 操作每个分支,git add , git commit,,更换源仓库的远程 remote(远程 remote 地址为之前在 Choerodon 关联的 gitlab 创建的空 gitlab project 仓库地址)。

最后使用 git push 将合并到好代码推送上去,逻辑图大致如下:

应用导入成功之后,会将原来代码仓库所有的分支,以及分支所有的 commit 记录导入到新的 Choerodon 平台关联的 gitlab 中,并会在数据库中增加对应的记录,实现应用的无缝迁移。

更多 Choerodon 猪齿鱼持续交付相关文章 ▼

关于猪齿鱼

Choerodon 猪齿鱼是一个全场景效能平台,基于 Kubernetes 的容器编排和管理能力,整合 DevOps 工具链、微服务和移动应用框架,来帮助企业实现敏捷化的应用交付和自动化的运营管理的平台,同时提供 IoT、支付、数据、智能洞察、企业应用市场等业务组件,致力帮助企业聚焦于业务,加速数字化转型。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性,以及参与社区贡献: