Open cjuexuan opened 7 years ago
ps:我们正常项目打包也不会将prod.conf之类的扔到resouce里面去,应该是放到了和main同级的universal中去,这里是因为直接用的sbt native demo的截图
问下, 在使用 sbt docker 插件和使用 shell 脚本相比,为什么会使用 sbt docker 插件?
@timzaak 这个主要考虑到sbt的docker 插件可以帮你生成docker file,也可以和已有的task挂上依赖关系,比如我们将stage和docker build以及docker push挂在一起,只需要执行一个命令就可以了
嗯。 thanks.
请教一下如果自己写一个sbt-profile的插件应该从哪里入手
@Mvpanswer7 稍微封装下sbt-native-packager就可以了
重回sbt之路
背景
当年考虑团队统一,我们在我们的两个纯scala项目中选择使用了maven而不是sbt作为默认的构建工具,现在主要存在以下几个问题
当初弃坑sbt主要还考虑到java用户通常在不同env上使用不同的profile,其他地方都是同名调用,比如可能在test这个profile下有一个url.properties,在prod上有一个同样的文件,而sbt通过Config去隔离env用起来还是很难用的,另外一个问题是当初没找到类似maven中copy dependency这样的插件,而我们spark项目中使用assembly jar的话,其实很不好排查jar的冲突问题,所以我们的做法都是平铺在一个lib目录中,如果能解决这两个问题,及格分就达到了,另外docker的支持首先想到的就是sbt调用shell,然后docker build,后来想了下,我们大sbt肯定会有类似的打包工具的插件,找了下也找到了,所以几个问题都基本解决了,下面详细说下我们对于这几个问题的解决思路
解决profile的问题
在scala用户中,可能的一个做法就是我提供
dev.conf
,test.conf
,prod.conf
,并且在打包的时候全变成application.conf
,目录结构看起来像这样project里面会放一个BuildEnv的插件
此时的 build.sbt会写成
这样来解决多环境问题,不过公司项目底层的一些库基于spring那一套弄的,所以我们只能解决历史遗留问题
我们的项目结构看起来像这样
而spring的xml长这样
此时就要用到
sbt native packager
由于我们内部的发布系统依赖一个run.sh的文件,所以刚好可以用来做启动脚本
所以我们的生成project的方法可以这样
我们目标是将profile里面的文件同名的搬运到打包出来的conf文件夹下面去,这样就可以通过sbt的启动的环境变量去区分对应的profile文件夹
调用逻辑如下
run.sh如下
打完包之后就目录结构如下了
把这个目录在jenkins同步出去就比较完美解决了
docker 的问题
docker的问题更简单了
sbt docker
把docker这个命令的以及dockerPush,stage挂上依赖关系,最后只需要执行dockerPush就可以了
最后jenkins配置下
copy dependency
用了sbt native packager之后自动解决了这个问题,所以整个过程还是非常完美的
总结
这次切换首先让编译速度飞起来了,第二个顺便解决了docker的问题,总体来说还是比较完美