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

2020 年 7 月 18 日
笔记
.NET Core, DevOps, Kubernetes

1. 前言
2. Net Core项目本身的准备
- 2.1 dockerfile
- 2.2 创建kubernetes用于helm的chart包
  - 2.2.1 说明
  - 2.2.2 chart文件目录和文件组成
3. Azure Devops创建仓库的pipeline
4. 触发pipeline部署流水线
5. 关于均衡负载

1. 前言

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

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

注：以下只是以Net Core项目为例，实际运用场景中，只要是无状态服务，除了dockfile的编写有差别，剩下整个自动化部署链条中的技术也好，工具也好，都可以复用，与语言和语言框架本身无关。

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

.Net Core

部署的应用本身

Github

作为代码仓库

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

作为CI/CD的工具

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

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

//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包，位于以下路径

//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

//dev.azure.com

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脚本

部署脚本的位置

//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以上

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

//toc.codepie.fun/version

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

Tags: .NET Core DevOps Kubernetes