解读与部署:基于 Kubernetes 的基础设施即代码

灵雀云

在基于Kubernetes的 .NET Core 微服务和 CI/CD 动手实践工作坊中,我们使用一系列脚本,尽可能地对所有环境的安装和配置工作进行了自动化。工作坊中的每一个与会者都只要按照说明,执行几个脚本,就可以自动地准备好自己的一整套 CI/CD 和微服务部署基础设施。

“基础设施即代码”指的是,使用代码描述所有基础设施的安装和配置过程,包括这些基础设施软件的各项设置和日常使用数据,都要使用代码进行描述。从而享受基于代码的版本管理和自动化执行等能力。这一概念强调,不仅软件本身的生产(持续集成即代码)和部署过程(持续部署即代码)可由代码来描述,用于托管并运行软件的基础设施(即服务器环境本身)的创建和配置过程也要能以代码的方式描述并维护。

概要介绍

在工作坊中,现场参与的每个人,都基于提前准备好的Kubernetes集群搭建了可供开发用的 Git 服务器和 CI/CD 工具体系,并成功部署了微服务。工作坊还带着与会者体验了将 .NET Core 应用从 IDE 代码开发、把代码提交到 Git 服务器,经过 CI/CD 自动编译、发布容器镜像,并最终自动部署到 Kubernetes 平台的完整过程。

支持这一过程的基础设施的整体示意图为:

PIC1.png

具体实现代码、脚本和配置,都在这个 GitHub 仓库:https://github.com/netconf-cn2 ... ices/其中各个微服务,请回到上一级别,自行下载。

整个代码库的结构如下:

1587103113(1).jpg

本文,我们概要地探讨这整个过程的原理和大致步骤。还有两篇文章分别介绍 CI/CD 部分及微服务部署部分的实现原理。

CI/CD软件

一般来说,一个典型的团队 CI/CD 基础设施包含下列内容:

•代码服务器,用于存储各个产品的源代码,以及日常工作中使用的各类脚本和配置。

•持续集成软件,用于自动地对产品源代码进行一系列自动化处理,比如安装依赖、编译、单元测试、格式检查等,并最终产生可以直接运行的二进制格式软件。

•制成品产物(发布物)存储软件,用于存储最终生成的二进制格式软件。

•容器注册表,用于存储软件的容器镜像(包含二进制格式软件、软件依赖的操作系统和第三方软件与配置等内容)的存储软件。

基本上,社区中关于这些软件的选用已经有了一些“偏好” 。基于社区的偏好,我们在工作坊中做了这样一些选择:

1587103211(1).jpg

由于要在Kubernetes集群中安装,所以上述这些软件,我们都需要使用它们的容器版本。容器注册表的安装和配置比较麻烦,为了简化工作坊现场的流程,所以我们选用现成的外部容器注册表服务。

CI/CD 软件的安装过程在脚本文件 provision-cicd.sh 中,这是一个 Bash 脚本文件。这个脚本文件既可用于 CI/CD 软件的部署(deploy),也可以用于整个工作坊环境的清理(delete)。当以部署模式(deploy)运行时,脚本会首先在 Kubernetes 集群上创建多个命名空间(namespace),并在 cicd 命名空间中依次启动安装 Jenkins、Nexus、Gogs 和 Sonarqube 等软件,最后会在 cicd 命名空间中启动一个初始化脚本(cicd-installer)。cicd-installer 初始化脚本将负责等待软件完成安装,并向它们导入必要的初始化数据。

在安装过程中,会用到一些“变量”,比如表示当前用户的 deploy_suffix 等。在我们为各个软件编写的Kubernetes安装文件(.yaml)中的相应位置上均引用了变量。而在 provision-cicd.sh 脚本文件中,在执行 kubectl apply 之前,它借助 tmpl.sh 脚本文件完成变量的填充,变量的值声明在 cicd-infra/vars 文件中。这也要求,在部署之前,工作坊的参与者需要提前编辑这个变量文件,确保其中的各个值都是正确的。

PIC2.png

微服务的部署

微服务的部署分成了两部分:微服务公用基础设施和各个微服务本身。之所以要分成两个部分,是因为对于特定的部署环境(如 dev)来说,公用基础设施只需要部署一次;而各个微服务则有可能随着代码的持续更新而需要经常部署。

微服务公用基础设施

工作坊的微服务依赖一些公用的基础软件,比如 Redis 缓存服务和 SqlServer 数据库服务。

这些基础设施的安装过程在脚本文件 provision-infra.sh 中,这也是一个 Bash 脚本文件。它的原理很简单,而且微服务基础设施的安装过程没有变量。所以,它直接在在相应部署环境对应的命令空间(如 dev)执行 kubectl apply ./service-infra/infra.yaml 就完成了安装。安装动作之后,脚本会等待安装完成,确保数据库处于运行状态之后,再执行数据库表结构的初始化操作,并向其中导入种子数据。

PIC3.png

微服务的部署各个微服务的部署本来应该是相当直观的,不过由于涉及到微服务的容器版本,所以实际过程却要稍微麻烦一点。

微服务的部署脚本文件是 provision-services.sh 中,这又是一个 Bash 脚本文件。脚本会从 services/service-list 文件中读入要部署的微服务的信息(容器镜像名称及标签),并逐个调用对应微服务所在项目目录中的 k8s.yaml 文件来执行部署。在部署过程中,也会涉及前面讲过的类似的变量处理过程,即读入 services/vars 文件,用于为微服务部署过程提供变量值。所以,同样,工作坊的参与者需要提前编辑这个变量文件,确保其中的各个值都是正确的。

由于将待部署的微服务列表使用单独的配置文件 services/service-list,因此不管是手工执行脚本部署,或是工作坊中练习的使用 CI 进行自动化部署,都可以通过编辑这个文件来指定要部署的微服务列表和版本。

PIC4.png

环境初始化在工作坊中,我们实现了一种“预配置”的效果。也就是,当工作坊与会者打开刚刚安装完成的 Jenkins 之后,会发现微服务的流水线已经创建完成了;当他们打开 Gogs 时,会发现上面已经预置了各个微服务的代码仓库。实际上,诸如此类的始化工作还有很多。而且,最重要的是,这些初始化工作也是由代码来描述的。

在工作坊的准备过程中,为了实现自动完成这些初始配置工作,我们结合使用了多种技术。这里先简单列举其中用到的几种技术,后面另外会写文章重点解读特定环节的实现原理:

1.Jenkins 的预置流水线是用 Jenkins 写入配置文件实现的

2.Gogs 的预置代码仓库是用 Gogs 的 RESTful API 导入的

3.Nexus 修改内置密码是用基于 RESTful API 的脚本接口完成的

4.SqlServer 的表结构是通过直接在 Pod 上执行指定的命令行程序实现的

通过结合使用这些技术,我们不光用 yaml 文件描述了这些软件的安装过程,还能够以代码的方式描述在这些软件上需要完成的配置。

总结

整个工作坊的基础环境就是由这几个部分构成的,各个部分都是使用代码来描述的。这里所讲的代码包含各种类型的代码,有供 Kubernetes 集群用的 yaml 文件,有 Bash 脚本文件,还有变量文件等。这些代码文件都有两个特点:

1.都是文本文件,可以由源代码版本管理工具管理

2.都以某种形式参与到自动化的执行过程中

符合这两个特点,最终部署出一个“基于 Kubernetes 的基础设施环境”,也就实现了基于Kubernetes的基础设施即代码。

事实证明,这个实践为可靠地重复创建工作坊环境提供了充分的保障,为工作坊的顺利举办和后期持续优化建立了不错的基础。

阅读 300

容器技术专栏
容器技术、docker 微服务 DevOps

灵雀云Alauda成立于2014年,由原微软Azure云平台的核心创始团队创立。作为容器服务和企业级PaaS领域的领军企业,灵雀云的技术团队拥有全球领先、超大规模企业级云平台的开发、运维和管理经验,并在西雅图和北京都设有研发中心。

144 声望
13 粉丝
0 条评论

灵雀云Alauda成立于2014年,由原微软Azure云平台的核心创始团队创立。作为容器服务和企业级PaaS领域的领军企业,灵雀云的技术团队拥有全球领先、超大规模企业级云平台的开发、运维和管理经验,并在西雅图和北京都设有研发中心。

144 声望
13 粉丝
宣传栏