1. 前言
前前后后学习kubernetes也有一个来月了,关于kubernetes的博客也写了有十多篇。但是技术如果无法落地到实际的应用场景终归是纸上谈兵,所以就有了这一出:通过结合kubernetes
和azure devops
实现项目的CI/CD
以及均衡负载
写完这篇后kubernetes
的相关学习也暂时告一段落了,有种终于闯关成功了啊的感觉,当然这是题外话了。
注1:以下只是以Net Core项目为例,实际运用场景中,除了dockfile的编写有差别,剩下整个自动化部署链条中的技术也好,工具也好,都可以复用,与语言和语言框架本身无关。
注2:本文演示的也只是其中一种简便的方式,具体的自动化流程中,由于*度非常高,所以实际的流程可能会更加复杂,这里就不做赘述了
以下场景需要用到的工具或者技术:
- .Net Core
部署的应用本身
作为代码仓库
-
kubernetes
- docker
- helm【kubernetes的包管理工具】
- ingress【使用ingress绑定域名和https证书,实现域名访问】
- Azure DevOps
作为CI/CD的工具
注:以下所有的相关部署代码,都在下面这个仓库
- 仓库内容只是我自己用的一个小工具,当然具体是什么内容不重要,这篇只是演示部署相关的
2. Net Core项目本身的准备
2.1 dockerfile
你需要一个dockerfile
来构建一个docker image
, 如果是.Net Core
项目,vs提供了傻瓜式生成dockerfile
的功能,可以免去初学时编写dockerfile
的烦恼
- 本示例dockerfile路径和内容
2.2 创建kubernetes用于helm的chart包
2.2.1 说明
这一部分需要有helm相关的知识,说白了就是将你的如果熟悉k8s但不熟悉helm,可以参照:
2.2.2 chart文件目录和文件组成
自定义的chart包,位于以下路径
https://github.com/lzw5399/TocGenerator/tree/master/kubernetes
如上图可以看出是一个很经典的自定义chart包的文件目录,即:
.
├── Chart.yaml 【chart的name和version等信息】
├── templates 【k8s的资源清单模板,可以引用values.yaml的变量】
| ├── deployment.yaml
| └── service.yaml
├── values.yaml 【定义变量,供template/下的yaml使用,实现动态替换yaml内容】
3. Azure Devops创建仓库的pipeline
3.1 前言
Azure DevOps
是微软出品的DevOps
平台,里面包含了Pipelines
工具链,对个人免费,可以用于项目的CI/CD
3.2 使用azure devops准备操作
- 如果之前使用过
azure devops
,这几步可以视情况跳过。
- 进入
azure devops
注册账号 - 之后按照引导新建一个
organization
- 再新建一个
project
- 进入
project
3.3 创建service connections
这里要创建一个service connections,用于之后pipeline访问k8s的master服务器
- 点击peject setting
- 这里点击
service connections
来创建一个连接,用于访问k8s的master服务器
- 然后填写具体的凭证,之后的pipeline上需要
3.4 新建pipeline流水线
新建pipeline
流水线用于自定义部署流程
- 点击
pipelines
,然后点击create pipelines
,新建一条流水线来部署我们的应用
- 选择代码仓库位置,选github
- 然后会跳到github进行授权,授权完成后会显示github的repo列表,选择具体的仓库
- 选择完仓库后,会自动按照你当前项目的语言,在github仓库的根目录生成一个默认的
azure-pipelines.yml
文件, - 替换文件的内容,我们最终使用的yaml文件步骤大概如下
- 第一步:构建docker镜像
- 第二步:将自定义的chart包拷贝到master服务器上
- 第三步:执行
deploy.sh
脚本,完成部署
# 哪条分支会触发构建
trigger:
- master
resources:
- repo: self
# 定义变量
variables:
- name: appName
value: tocgenerator
- name: tag
value: $(Build.BuildNumber)
- name: imageNameWithoutTag
value: $(dockerid)/$(appName)
- name: imageNameWithTag
value: $(imageNameWithoutTag):$(tag)
- name: serverChartLocation
value: /root/helm-chart-folder/toc
stages:
- stage: Build
jobs:
- job: Build
pool:
vmImage: ‘ubuntu-latest‘
# 这下面是每个我们要具体执行的任务
steps:
# build docker images并且push到仓库
- task: Docker@2
displayName: docker build and push
inputs:
containerRegistry: ‘my_docker_hub‘
repository: ‘$(imageNameWithoutTag)‘
command: ‘buildAndPush‘
Dockerfile: ‘**/Dockerfile‘
buildContext: ‘.‘
tags: $(tag)
addPipelineData: false
# 将kubernetes文件夹,即chart包拷贝到k8s的master服务器
- task: CopyFilesOverSSH@0
displayName: copy helm chart to server
inputs:
# 这个endpoint就是我们刚刚创建的service connection的名字
sshEndpoint: ‘my_server‘
sourceFolder: ‘kubernetes‘
contents: ‘**‘
targetFolder: $(serverChartLocation)
readyTimeout: ‘20000‘
# 在k8s的master服务器上运行我们github仓库的根目录的deploy.sh,进行部署操作
- task: SSH@0
displayName: run deploy shell on server
inputs:
# 这个endpoint就是我们刚刚创建的service connection的名字
sshEndpoint: ‘my_server‘
runOptions: ‘script‘
scriptPath: ‘deploy.sh‘
args: ‘$(tag) $(serverChartLocation)‘
readyTimeout: ‘20000‘
3.5 创建部署shell脚本
部署脚本的位置
https://github.com/lzw5399/TocGenerator/blob/master/deploy.sh
几点说明
- echo纯粹是为了记录log使用的,下面的示例把echo部分删除了
- $1 and $2 代表外部传入的参数
- $1是image的tag,$2是k8s的master服务器上我们自定义的chart的目录
- 移除没有tag的悬挂docker image,纯粹为了节省服务器空间,为可选项
#!/bin/bash
# 出现错误退出脚本执行
set -o errexit
# $1 and $2 代表外部传入的参数
# $1是image的tag,$2是k8s的master服务器上我们自定义的chart的目录
buildNumber=$1
serverChartLocation=$2
cd $serverChartLocation
# 安装或者升级我们的helm release
# 即如果查询到了有release存在就upgrade,没有则install
if test -z "$(helm ls | grep toc-release)"; then
helm install -f values.yaml --set env.buildnumber=$buildNumber --set image.tag=$buildNumber toc-release .
else
helm upgrade -f values.yaml --set env.buildnumber=$buildNumber --set image.tag=$buildNumber toc-release .
fi
# 移除没有tag的悬挂docker image(可选)
danglings=$(sudo docker images -f "dangling=true" -q)
if test -n "$danglings"; then
sudo docker rmi $(sudo docker images -f "dangling=true" -q) >>/dev/null 2>&1
if [[ $? != 0 ]]; then
exit $?
fi
fi
exit 0
4. 触发pipeline部署流水线
这里有两种办法,
- 点击我们刚刚创建的pipeline手动run一个
- 通过push代码到仓库的指定分支(
我们设置的master
)触发构建
显示构建成功之后就可以查看了!
5. 关于均衡负载
均衡负载是kubernetes自带的基础功能之一,这里只是做了一个试验可以更加直观地感受到而已
如下
- 定义一个静态的guid
- 在/version 路由下输出guid
则如果有2个实例,且均衡负载成功的话,每次刷新这个界面,会随机显示这两个guid
- deployment的replicas实例数需要设置2以上
最后均衡负载试验的地址,也是本次实例项目的线上地址
- 如下,会出现两个不同的guid