# dinp-builder **Repository Path**: cnperl/dinp-builder ## Basic Information - **Project Name**: dinp-builder - **Description**: DINP中的编配平台,负责把用户代码打包为Docker image - **Primary Language**: Go - **License**: Not specified - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 7 - **Forks**: 9 - **Created**: 2015-02-09 - **Last Updated**: 2023-08-28 ## Categories & Tags **Categories**: containers **Tags**: None ## README Builder ======= 这是DINP中的一个编配平台,核心作用就是把用户提供的代码包,变成一个image推送到Docker-Registry # 设计理念 - 平台不管编译,用户自己编译好,然后把编译好的代码扔给平台 - 不管是什么语言的代码,最终都打包成一个docker image,通过docker来做规范化 ## 编译与否的问题 用户的代码要部署在PaaS平台上,首先要做的就是把代码扔给平台,那么问题来了,通过什么方式扔给平台呢?通过git?还是直接上传?扔上来的是源代码?还是已经编译完成的?解释型语言当然是不需要编译的,但是编译型的呢,比如golang,java,我们要让用户给我们.go、.java文件然后我们去编译?还是用户编译好,直接给我们二进制,给我们.class文件? 平台刚起步,我们希望在可接受的范围内,做的事情越少越好,这样出错的几率就越少,之后平台慢慢发展,可以再加入一些新的feature。所以我们选择让用户把编译之后的代码交给我们,比如java的话,就扔个war包给我们即可;golang的话需要编译成二进制(编译成64位Linux的,因为平台是64位Linux)。 有些PaaS,比如tsuru,是让用户把代码push到某个指定repo的指定分支的,然后后端的git receiver就会触发编译、上线脚本。看起来是挺好的,但是这样处理比较麻烦,坑太多,以后再说吧 接下来是要确定通过什么方式把代码扔给平台,我们目前支持两种方式,一个是在页面直接上传,一个是给一个可以下载的http地址,平台去下载。 ## 使用docker来做规范化打包 用户的代码可能是不同语言写的,比较常见的比如Java、PHP、Python,用户给我们的是一个tar.gz包,我们要怎么把其变成一个docker image呢? 最简单的实现方式:dinp提供一个base image,里边就只是Ubuntu或者centos的环境,用户自己搞定runtime依赖,比如Java的话,用户的tar.gz包中应该包含JDK、tomcat、webapp,然后约定一个启动脚本,比如就是根目录的control文件,平台只需要`./control start`即可启动。如果用户是PHP的代码,需要把nginx、php-fpm、code打包进来。 但是这种方式太麻烦,如果是golang的话可以使用上面的方式,因为golang是静态编译的,也没啥依赖。Java、php、Python、Ruby让用户这么搞,那不得哭了…… 我们可以针对不同的语言做不同的base image,比如Java的,base image中提前把JDK和tomcat做好,用户直接上传一个war包,搞定!比如PHP的base image,提前把nginx、php-fpm之类的做好,用户直接把php code上传,搞定! 嗯,这也是Builder平台现在采用的方式,我们做了一些base image,让用户在页面上选择使用哪个,用户选择了base image,也就间接的告诉了我们他是什么类型的代码了(比如java的程序肯定要选择一个java的base image)。然后我们根据不同类型的程序生成一个Dockerfile,把用户的代码和base image揉在一起,搞定! # 安装方法 代码在 [这里](https://github.com/dinp/builder) ,这是个golang的项目,使用beego框架,安装起来也比较简单,就是通常的golang项目的编译方式 mkdir -p $GOPATH/src/github.com/dinp # 假设你已经配置好了GOROOT和GOPATH cd $GOPATH/src/github.com/dinp git clone https://github.com/dinp/builder.git cd builder go get ./... go build mv conf/app.conf.example conf/app.conf # modify conf/app.conf ./builder 项目采用[UIC](http://ulricqin.com/project/uic/)作为单点登录系统,所以要想运行测试的话得先把UIC搭建起来 简单解释一下`conf/app.conf`各项配置的作用 - appname、httpport没啥好说的 - runmode取值是dev或者prod,可以参看beego的文档 - db打头的是数据库配置,数据库初始化脚本在schema.sql - tmpdir、logdir是就是一些临时目录,不解释 - buildtimeout是编译超时时间,超过了这个时间就会被kill,单位是分钟 - uicinternal、uicexternal是UIC的配置,为啥分成两个呢?Builder和UIC通常是在一个内网的,相互之间的访问可以走内网,所以有个uicinternal,但是有的时候UIC的内网地址用户是没法访问的,所以在sso登录的时候还是需要redirect到UIC的外网地址 - registry是docker私有源,读者可以使用docker registry搭建 - buildscript是Builder内部用到的一个脚本文件地址,默认配置即可 - tplmapping这个很重要,这是base image的配置,在registry中增加了base image,也要在此配置一下,这样用户才能在页面上看到 - token,这是与UIC通信的凭证,与UIC的token配置成一样即可 # 问题 编配的时候用户要查看log,这造成了单点状态,目前可以通过挂载分布式文件系统解决