使用Helm优化Kubernetes下的研发体验:实现持续交付流水线
整体目标
在这一篇中,我们将使用Jenkins在此基础上构建一条完整的持续交付流水线,并且让团队不同成员能够基于该流水线展开基本的协作。 - 开发: 持续提交代码并能够通过持续集成(CI)过程快速获取反馈,在通过CI验证后,能够自动化部署到开发环境,以便后续的进一步功能测试(手动/自动自动化测试)等;
- 测试: 在需要对项目功能进行验证时,可以一键部署测试环境,并且在此环境基础上可以完成功能验收(手动),以及全量的自动化验收测试等;
- 运维:一键部署生产环境,同时发布创建版本,以便在发布异常时能够快速回归。
资料来源: https://dzone.com/articles/eas ... ns-he示例项目的代码可以从 GitHub 下载,示例项目为
containerization-spring-with-helm
。接下来,我们将分阶段介绍如何通过 Jenkinsfile 定义整个过程。 项目构建阶段
当前阶段Jenkinsfile定义如下:
stage('Build And Test') { steps { dir('containerization-spring-with-helm') { sh 'docker build -t yunlzheng/spring-sample:$GIT_COMMIT .' } } }
在
Build And Test
阶段,我们直接通过源码中的Dockerfile定义了整个持续集成阶段的任务,通过docker的 Multi-Stage Builds
特性,持续集成的所有任务全部通过Dockerfile进行定义,这样无论是在本地还是持续集成服务器中,我们都可以非常方便的进行运行CI任务。 发布镜像和Helm阶段
当前阶段Jenkinsfile定义如下:stage('Publish Docker And Helm') { steps { withDockerRegistry([credentialsId: 'dockerhub', url: '']) { sh 'docker push yunlzheng/spring-sample:$GIT_COMMIT' } script { def filename = 'containerization-spring-with-helm/chart/values.yaml' def data = readYaml file: filename data.image.tag = env.GIT_COMMIT sh "rm $filename" writeYaml file: filename, data: data } script { def filename = 'containerization-spring-with-helm/chart/Chart.yaml' def data = readYaml file: filename data.version = env.GIT_COMMIT sh "rm $filename" writeYaml file: filename, data: data } dir('containerization-spring-with-helm') { sh 'helm push chart https://repomanage.rdc.aliyun.com/helm_repositories/26125-play-helm --username=$HELM_USERNAME --password=$HELM_PASSWORD --version=$GIT_COMMIT' } } }
Push镜像
通过withDockerRegistry
的上下文,Jenkins会确保docker client首先通过 credentials dockerhub
中定义的用户名和密码完成登录后,再运行 docker push
任务。这里我们使用当前代码版本的COMMIT_ID作为镜像的Tag,从而将Docker镜像版本与源码版本进行一一对应; 重写Chart镜像版本
通过readYaml
读取chart的values.yaml内容到变量data后,通过 writeYaml
重写values.yaml中的镜像tag版本与当前构建镜像版本一致。 重写Chart版本
与镜像一样,我们希望Chart的版本与源码版本能够一一对应。上传Chart
这里我们直接使用 阿里云效 提供的Helm仓库服务, 点击开通私有仓库服务 。通过Helm Push插件发布Chart到Helm仓库。其中环境变量
$HELM_USERNAME
和 $HELM_PASSWORD
是通过jenkins的Credentials加载到环境变量中: environment { HELM_USERNAME = credentials('HELM_USERNAME') HELM_PASSWORD = credentials('HELM_PASSWORD') }
部署到开发/测试环境阶段
当前阶段Jenkinsfile定义如下:stage('Deploy To Dev') { steps { dir('containerization-spring-with-helm') { dir('chart') { sh 'helm upgrade spring-app-dev --install --namespace=dev --set ingress.host=dev.spring-example.local .' } } } } stage('Deploy To Stageing') { steps { input 'Do you approve staging?' dir('containerization-spring-with-helm') { dir('chart') { sh 'helm upgrade spring-app-staging --install --namespace=staging --set ingress.host=staging.spring-example.local .' } } } }
在Jenkinsfile中我们分别定义了两个阶段
Deploy To Dev
和 Deploy To Stageing
。我们通过Kubernetes的命名空间划分单独的开发环境和测试环境。并且通过覆盖ingress.host确保能够通过ingress域名 dev.spring-example.local
和 staging.spring-example.local
访问到不同环境。 对于Staging环境而言,通过 input
确保该流程一定是通过人工确认的。 使用
helm upgrade
命令可以在特定命名空间下部署或者升级已有的Chart: helm upgrade spring-app-staging --install --namespace=staging --set ingress.host=staging.spring-example.local .
部署到生产环境阶段
当前阶段Jenkinsfile定义如下:stage('Deploy To Production') { steps { input 'Do you approve production?' script { env.RELEASE = input message: 'Please input the release version', ok: 'Deploy', parameters: [ [$class: 'TextParameterDefinition', defaultValue: '0.0.1', description: 'Cureent release version', name: 'release'] ] } echo 'Deploy and release: $RELEASE' script { def filename = 'containerization-spring-with-helm/chart/Chart.yaml' def data = readYaml file: filename data.version = env.RELEASE sh "rm $filename" writeYaml file: filename, data: data } dir('containerization-spring-with-helm') { dir('chart') { sh 'helm lint' sh 'helm upgrade spring-app-prod --install --namespace=production --set ingress.host=production.spring-example.local .' } sh 'helm push chart https://repomanage.rdc.aliyun.com/helm_repositories/26125-play-helm --username=$HELM_USERNAME --password=$HELM_PASSWORD --version=$RELEASE' } } }
在最后一个
Deploy To Production
阶段中,与Dev和Stageing的部署不同在于当人工确认部署测试环境之后,我们需要用户手动输入当前发布的版本,以确保对当前发布的Chart版本能完成一个基线的定义: helm lint
对Chart定义进行校验。 小结
通过代码提交版本(COMMIT_ID)关联了源码版本,镜像版本以及Chart版本。同时对于正式发布的软件版本而言,单独定义了正式发布的版本号。对于实践持续交付的研发团队而言,我们可以通过上述一条流水线基本实现软件交付的整个生命周期。而对于传统交付模式的团队,则可以通过将上述过程分拆到多条流水线(开发流水线,测试流水线,发布流水线)来适应自己的发布模式。回到我们的总体目标而言,通过基础设施及代码的方式,我们定义了一个相对完备且自描述的应用。通过流水线即代码的方式,定义了应用的端到端交付过程。通过Docker定义项目的构建过程,通过Helm实现Kubernetes下应用的发布管理,通过Jenkinsfile定义了软件的整个交付过程,并且不同职能的团队成员,可以方便的在此基础上实现协作。最后借用《持续交付》的话“提前并频繁地做让你感到痛苦的事!“ ,希望大家都能够Happy Coding。
本文转自DockOne-使用Helm优化Kubernetes下的研发体验:实现持续交付流水线
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Kubernetes系统架构演进过程与背后驱动的原因
带你了解Kubernetes架构的设计意图、Kubernetes系统的架构开发演进过程,以及背后的驱动原因。 ------------ 1、背景 各种平台都会遇到一个不可回避的问题,即平台应该包含什么和不包含什么,Kubernetes也一样。Kubernetes作为一个部署和管理容器的平台,Kubernetes不能也不应该试图解决用户的所有问题。Kubernetes必须提供一些基本功能,用户可以在这些基本功能的基础上运行容器化的应用程序或构建它们的扩展。本文旨在明确Kubernetes架构的设计意图,描述Kubernetes的演进历程和未来的开发蓝图。 本文中,我们将描述Kubernetes系统的架构开发演进过程,以及背后的驱动原因。对于希望扩展或者定制kubernetes系统的开发者,其应该使用此文档作为向导,以明确可以在哪些地方,以及如何进行增强功能的实现。如果应用开发者需要开发一个大型的、可移植的和符合将来发展的kubernetes应用,也应该参考此文档,以了解Kubernetes将来的演化和发展。 从逻辑上来看,kubernetes的架构分为如下几个层次: 核心层(Nucleu...
- 下一篇
使用Helm优化Kubernetes下的研发体验:基础设施即代码
容器即进程,Kubernetes则解决了如何部署和运行应用的问题。对于任何一个部署在Kubernetes的应用而言,通常都可以由几个固定的部分组成:Ingress、Service、Deployment等。直接使用Kubernetes原生的YAML定义服务,虽然能一定程度上简化应用的部署,但是对于大部分研发人员来说编写和使用YAML依然是一件相对痛苦的事情。Helm应运而生,Helm作为Kubernetes下的包管理工具,对原生服务定义过程进行了增强,通过模板化,参数化的形式大大简化用户部署Kubernetes应用的复杂度。 本文中,笔者将以一个Spring Boot程序为例,介绍如何在软件研发端到端过程中是使用Helm。本文中所使用的示例代码可以通过 GitHub 下载。 创建应用程序 项目采用Maven作为项目的编译和构建工具,项目目录结构如下: ├── README.md ├── chart │ ├── Chart.yaml # Chart基本信息 │ ├── charts # 依赖 │ ├── templates # Kubernetes模板 │ │ ├── NOTES.txt ...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8编译安装MySQL8.0.19
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Hadoop3单机部署,实现最简伪集群
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果