kubernetes+Azure DevOps实现.Net Core项目的自动化部署&均衡负载

1. 前言

前前后后学习kubernetes也有一个来月了，关于kubernetes的博客也写了有十多篇。但是技术如果无法落地到实际的应用场景终归是纸上谈兵，所以就有了这一出：通过结合kubernetes和azure devops实现项目的CI/CD以及均衡负载

写完这篇后kubernetes的相关学习也暂时告一段落了，有种终于闯关成功了啊的感觉，当然这是题外话了。

注1：以下只是以Net Core项目为例，实际运用场景中，除了dockfile的编写有差别，剩下整个自动化部署链条中的技术也好，工具也好，都可以复用，与语言和语言框架本身无关。
注2：本文演示的也只是其中一种简便的方式，具体的自动化流程中，由于自由度非常高，所以实际的流程可能会更加复杂，这里就不做赘述了

以下场景需要用到的工具或者技术：

• .Net Core

部署的应用本身

• Github

作为代码仓库

• kubernetes
  • docker
  • helm【kubernetes的包管理工具】
  • ingress【使用ingress绑定域名和https证书，实现域名访问】
• Azure DevOps

作为CI/CD的工具

注：以下所有的相关部署代码，都在下面这个仓库

• 仓库内容只是我自己用的一个小工具，当然具体是什么内容不重要，这篇只是演示部署相关的

https://github.com/lzw5399/TocGenerator

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，可以参照：

kubernetes系列(十六) - 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

https://dev.azure.com

3.2 使用azure devops准备操作

• 如果之前使用过azure devops，这几步可以视情况跳过。

1. 进入azure devops注册账号
2. 之后按照引导新建一个organization
3. 再新建一个project
   
4. 进入project

3.3 创建service connections

这里要创建一个service connections，用于之后pipeline访问k8s的master服务器

1. 点击peject setting
   
2. 这里点击service connections来创建一个连接，用于访问k8s的master服务器
   
3. 然后填写具体的凭证，之后的pipeline上需要

3.4 新建pipeline流水线

新建pipeline流水线用于自定义部署流程

1. 点击Pipelines，然后点击create pipelines，新建一条流水线来部署我们的应用
   
2. 选择代码仓库位置，选github
   
3. 然后会跳到github进行授权，授权完成后会显示github的repo列表，选择具体的仓库
4. 选择完仓库后，会自动按照你当前项目的语言，在github仓库的根目录生成一个默认的azure-pipelines.yml文件，
5. 替换文件的内容，我们最终使用的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: 
      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: 
      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: 
      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

几点说明

1. echo纯粹是为了记录log使用的，下面的示例把echo部分删除了
2. $1 and $2 代表外部传入的参数
3. $1是image的tag，$2是k8s的master服务器上我们自定义的chart的目录
4. 移除没有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部署流水线

这里有两种办法，

1. 点击我们刚刚创建的pipeline手动run一个
2. 通过push代码到仓库的指定分支(我们设置的master)触发构建

显示构建成功之后就可以查看了！

5. 关于均衡负载

均衡负载是kubernetes自带的基础功能之一，这里只是做了一个试验可以更加直观地感受到而已

如下

1. 定义一个静态的guid
   
2. 在/version 路由下输出guid
   

则如果有2个实例，且均衡负载成功的话，每次刷新这个界面，会随机显示这两个guid

• deployment的replicas实例数需要设置2以上
  

最后均衡负载试验的地址，也是本次实例项目的线上地址

https://toc.codepie.fun/version

• 如下，会出现两个不同的guid