内容简介: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
下面是核心代码的主流程,如下图所示:
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
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- php如何实现session,自己实现session,laravel如何实现session
- AOP如何实现及实现原理
- webpack 实现 HMR 及其实现原理
- Docker实现原理之 - OverlayFS实现原理
- 为什么实现 .NET 的 ICollection 集合时需要实现 SyncRoot 属性?如何正确实现这个属性?
- 自己实现集合框架(十):顺序栈的实现
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Persuasive Technology
B.J. Fogg / Morgan Kaufmann / 2002-12 / USD 39.95
Can computers change what you think and do? Can they motivate you to stop smoking, persuade you to buy insurance, or convince you to join the Army? "Yes, they can," says Dr. B.J. Fogg, directo......一起来看看 《Persuasive Technology》 这本书的介绍吧!