Knative Build实现

栏目: 编程工具 · 发布时间: 5年前

内容简介：knative-build提供将源码编译、构建、打包的整个流水线流程。其核心原理是基于pod的init contaier来定义一系列串行执行的stage。由于每一个stage都可以由用户自定义，若加以扩展，还可以用于更多场景。就是build中的每一个step所使用的构建基础工具或环境，通常通过基础镜像的形势来指定。这里对常用的集中builder做简单介绍。在buildTemplate中，对应使用的builder为镜像

knative-build提供将源码编译、构建、打包的整个流水线流程。其核心原理是基于pod的init contaier来定义一系列串行执行的stage。由于每一个stage都可以由用户自定义，若加以扩展，还可以用于更多场景。

资源模型

build

一条具体可运行的pipeline任务，里面包括多个stage（第一个stage为从代码仓库拉取源码）
step

组成pipeline的一个执行阶段，其底层通过使用init container来实现。
build-template

对同一类pipeline任务流程的抽象，通常用户指定参数的形势来实例化为具体的build。

Builder

就是build中的每一个step所使用的构建基础工具或环境，通常通过基础镜像的形势来指定。这里对常用的集中builder做简单介绍。

bazel

在buildTemplate中，对应使用的builder为镜像 gcr.io/cloud-builders/bazel 。

apiVersion: build.knative.dev/v1alpha1
kind: BuildTemplate
metadata:
  name: bazel
spec:
  ...
  steps:
  - name: build-and-push
    image: gcr.io/cloud-builders/bazel
    args: ['run', '${TARGET}']

kaniko

kaniko貌似是通过dockerfile来生成镜像的，这里需要指定dockerfile目录以及目标镜像的名称。其builder使用的image为 gcr.io/kaniko-project/executor，除此之外，google来提供了很多的工具，可以在各个阶段中用到，也可以用来扩展buildTemplate的steps。

apiVersion: build.knative.dev/v1alpha1
kind: BuildTemplate
metadata:
  name: kaniko
spec:
  parameters:
  ...
  steps:
  - name: build-and-push
    image: gcr.io/kaniko-project/executor
    args:
    - --dockerfile=${DOCKERFILE}
    - --destination=${IMAGE}
    env:
    - name: DOCKER_CONFIG
      value: /builder/home/.docker

buildkit

buildkit是 docker 提供出来的，运行这个buildTemplate的build-and-push step其实是运行了一个buildkit的client。该client向运行在远端的buildkit server发送构建的任务，其具体流程可以参考docker buildkit项目。

apiVersion: build.knative.dev/v1alpha1
kind: BuildTemplate
metadata:
  name: buildkit
spec:
  parameters:
  ...
  - name: BUILDKIT_DAEMON_ADDRESS
    description: The address of the BuildKit daemon (buildkitd) service
    default: "tcp://buildkitd:1234"
  steps:
  - name: build-and-push
    image: ${BUILDKIT_CLIENT_IMAGE}
    workingDir: ${DIRECTORY}
    command: ["buildctl", "--addr=${BUILDKIT_DAEMON_ADDRESS}", "build",
              "--progress=plain",
              "--frontend=dockerfile.v0",
              "--opt", "filename=${DOCKERFILE}",
              "--local", "context=.", "--local", "dockerfile=.",
              "--output", "type=image,name=${IMAGE},push=${PUSH}"]

代码实现

knative-build的代码主要实现对三种CRD资源的controller。三种CRS资源分别是：

build
buildTemplate
clusterBuildTemplate

下面是核心代码的主流程，如下图所示：

Knative Build实现

Controller

在后两种template资源的controller代码中，到检测到有新的template创建时，会创建对应的builder镜像（通过get image可以查询）的操作。template资源的功能主要是为实例化build提供一种快速生成的模板和工具。

再来说build，build的operator首先判断该build是否基于buildTemplate创建。如果是，就将输入参数应用到模板，再将包含多个steps的完整build资源转化为由多个initContainer串行的pod。值得注意的是，build的前两个阶段一般是挂载秘钥volume（后面会再讲到）和拉取source code的initContainer，但该字段并非必须。

对于拉取代码，这里有三种情况，见下表：

代码拉取方式	image	备注
git	`git-init`	基于git拉取代码
gcs	`gcs-fetcher`	google专用
custom	无	该情况适用于用户通过volume挂载的方式来获取源码

for i, source := range sources {
	switch {
	case source.Git != nil:
		git, err := gitToContainer(source, i)
		if err != nil {
			return nil, err
		}
		initContainers = append(initContainers, *git)
	case source.GCS != nil:
		gcs, err := gcsToContainer(source, i)
		if err != nil {
			return nil, err
		}
		initContainers = append(initContainers, *gcs)
	case source.Custom != nil:
		cust, err := customToContainer(source.Custom, source.Name)
		if err != nil {
			return nil, err
		}
		// Prepend the custom container to the steps, to be augmented later with env, volume mounts, etc.
		build.Spec.Steps = append([]corev1.Container{*cust}, build.Spec.Steps...)
	}
	// webhook validation checks that only one source has subPath defined
	workspaceSubPath = source.SubPath
}

基于远端仓库拉取代码的方式，大多的代码仓库都需要做认证。这块knative是使用 creds-init 来实现的，该镜像运行起来后会生成一个initContainer。该initContainer通过找出serviceaccount下匹配builder的sercret，然后通过挂载volume的形势，将该secret挂载到pod对应的目录下，供builder在拉取代码的时候使用。

Image

knative启动时，指定了了四个镜像，其中的三个在前面已经提到过。 nopImage 用于在所有initContainer执行完之后运行的pod，该container并不做实质性的工作，只用来结束串行的initContainer；其代码很简单，只是在main函数中打印了成功执行完build的提示消息。

var (
	// The container used to initialize credentials before the build runs.
	credsImage = flag.String("creds-image", "override-with-creds:latest",
		"The container image for preparing our Build's credentials.")
	// The container with Git that we use to implement the Git source step.
	gitImage = flag.String("git-image", "override-with-git:latest",
		"The container image containing our Git binary.")
	// The container that just prints build successful.
	nopImage = flag.String("nop-image", "override-with-nop:latest",
		"The container image run at the end of the build to log build success")
	gcsFetcherImage = flag.String("gcs-fetcher-image", "gcr.io/cloud-builders/gcs-fetcher:latest",
		"The container image containing our GCS fetcher binary.")
)

下面是启动后四个images的CRD信息。

[root@k8s-master ~]# kkb get images
NAME          AGE
creds-init    13d
gcs-fetcher   13d
git-init      13d
nop           13d

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。

码农书籍

微信小程序(开发入门及案例详解)

李骏、边思 / 机械工业出版社 / 2017-3-1 / 59.0

本书可分为3部分，第一部分作为基础章节，介绍了第一个小程序的搭建流程，让大家能快速上手；同时对小程序框架原理进行了详细介绍，为后面学习组件、API打下基础。第二部分对小程序组件、API进行介绍，对组件、API的使用、注意事项进行详细讲解，并给出示例代码。最后一部分精选5个由浅入深的案例，对小程序研发进行实战讲解，涵盖了实际项目中可能涉及的技术方案和使用方法，具备很强的实战意义。 ......一起来看看《微信小程序(开发入门及案例详解)》这本书的介绍吧!

码农工具