Kaniko概述
当我们想将业务代码发布到Kubernetes时,最先遇到的问题就是构建Docker镜像。
以GitlabCICD为例,构建Docker镜像时有三种方法:
- Shell executor
- DockerinDocker(DinD)
- Docker socket binding(DockeroutofDocker, DooD)
第一种方式直接使用了虚拟机上shell,导致环境无法保持一致,一般很少人使用。
第二种方式在Docker里面,又安装了一个Docker,但是最外层的docker需要特权模式运行,存在一定的安全隐患,也导致无法在K8S平台中运行。
第三种方式,需要吧docker socket 暴露给runner容器,相当于给出了最高docker权限,安全性也是大问题。另外如果需要创建相同名字的docker容器,会产生冲突。同样的也无法在K8S平台中运行。
那还有什么办法吗?
有。Google发布的Kaniko 解决了特权模式的问题,构建镜像时不再依赖DockerDeamon。
Kaniko是一个Google开源的方便我们在k8s中使用dockfile构建镜像的工具。它不依赖docker daemon进程,并完全在用户空间执行dockfile文件的每一条命令。这样我们就可以在一些没法获取docker daemon进程的环境下也可以构建镜像。比如在K8S上。
kaniko会先提取基础镜像的文件系统,然后根据Dockerfile中的描述,一条条执行命令,每一条命令执行完之后都会在用户空间创建一个snapshot,并于存储在内存中的上一个状态做对比,若有变化,将新的修改生成一个镜像层添加在基础镜像上面,并将相关修改信息写入到镜像元数据中,等全部命令执行完,Kaniko会将最终镜像推送到指定的远端镜像仓库。
Kaniko的代码和官方站点
Kaniko的代码在github中有,代码deploy目录有Dockerfile,可以自行构建
https://github.com/GoogleContainerTools/kaniko
如果不想构建可以直接使用 gcr.io/kaniko-project/executor:debug
在GitlabCI中使用Kaniko
.gitlab-ci.yml配置文件如下,
注意这里设置了一个DOCKERCONFIG变量,用来存储镜像仓库的认证数据。
# DodD模式
dockerbuild:
stage: dockerbuild
image: docker:stable
before_script:
- docker info
script:
- docker login -u xxx -p xxx reg.ipcpu.com
- docker build -t reg.ipcpu.com/test/gohelloworld:${CI_PIPELINE_ID}-${CI_COMMIT_SHORT_SHA} .
- docker push reg.ipcpu.com/test/gohelloworld:${CI_PIPELINE_ID}-${CI_COMMIT_SHORT_SHA}
# Kaniko模式
KanikoBuild:
stage: KanikoBuild
image:
# we use :debug instead of :latest, because we need a shell for our scripts
name: gcr.io/kaniko-project/executor:debug
entrypoint: [""]
before_script:
- echo "start writing ayth file."
- mkdir -p /kaniko/.docker
- echo ${DOCKERCONFIG} > /kaniko/.docker/config.json
- echo "auth file write successful."
script:
- - echo "start executor."
- >-
/kaniko/executor
--context "${CI_PROJECT_DIR}"
--dockerfile "${CI_PROJECT_DIR}/Dockerfile"
--destination "reg.ipcpu.com/test/gohelloworld2:${CI_COMMIT_SHORT_SHA}"
参考资料
https://github.com/GoogleContainerTools/kaniko
https://docs.gitlab.com/ee/ci/docker/using_kaniko.html
转载请注明:IPCPU-网络之路 » 使用Kaniko构建Docker镜像