NoOps

Ops make no ops | Ops的目标是没有Ops,嗯!

CloudFoundry中buildpack介绍与自定义实践

作者: |   4,140 浏览  | 

背景

用一个问题开篇:一个服务能够run起来,到底需要些什么?
做过部署系统的同学会对这个问题认识比较深,总结一下,我们可以归为如下几类:
1、程序本身的代码文件,嗯,这个不用解释
2、需要的配置,比如测试环境下有一套配置,开发环境、线上环境各有一套配置,还有甚者,一个idc一套配置
3、环境依赖,比如语言环境:Python2.7、JDK6,一些操作系统特性等
4、运行时依赖,比如我需要上游某个模块提供的rpc接口的支持,需要用到MQ等等
看起来,要部署个程序还是比较麻烦的嘞,那怎么做才会相对容易一些呢?如果程序最后能把所有依赖的东西打成一个包(比如统一要求是tar.gz格式),扔到任何一个地方去,我们只需要解压,然后使用解压出来的start.sh即可启动执行,那就太棒了!

buildpack就是解决这个问题的……

相关术语

在CloudFoundry中,最后打成的那个tar.gz的包,称为droplet,任何一个DEA拿到这个droplet,解压然后start即可。那具体应该如何打包?打包过程应该是运行一系列的脚本吧,这个脚本在哪里?一般来讲,脚本文件为了备份和版本化需求我们一般会放到git或svn上,嗯,现在可以解释什么叫buildpack了:它是一坨脚本,一般是放到git上作为一个project的形态存在,这坨脚本的作用是把用户写好的程序(CloudFoundry中一般称为app)、及其依赖的环境、配置、启动脚本等打包成droplet,这个过程称之为stage。

工作流介绍

app开发人员在命令行调用cf push之后,流程是如何走的,经过哪些步骤,在什么时候开始stage,完事之后又经历了什么,可以查看这篇博文:CloudFoundry发布app过程

buildpack目录结构

buildpack是工作在CloudFoundry这个大框架下的,我们知道,但凡工作在框架下的东西就要尊从一些规范,这是框架和你交互协调的根基。buildpack也不例外,CloudFoundry要求,buildpack至少含有一个bin目录,bin目录下有三个文件,文件名固定,分别是:
detect # 这个文件的作用是侦测你的项目,比如是个Java项目 or php项目,用的什么Runtime和Framework之类的
compile # 这是buildpack的核心文件,一般作用就是去拉取相应的Runtime(e.g. python2.7/ruby1.9.3)下来,做一下配置放到指定位置,拉取相应的Framework(e.g. Flask/Django)下来,做一下配置,放到指定位置
release # 这个文件最终要求输出一个yaml,来描述如何启动app之类的
三个脚本由Cloudfoundry顺次执行

如果编写buildpack过程需要创建其他文件夹或文件,其位置怎么安排都可以,CloudFoundry框架方面没有什么限制

自定义buildpack实例

下面我们自定义一个buildpack来支持java web项目,使用JDK7和tomcat7来跑,jdk和tomcat都要从公司内网来下载,版本可以稍微放宽,支持jdk6、7、8,tomcat也可以支持多个版本
detect内容大致如下:

compile文件做的事情稍微复杂一些,如果觉得bash不能胜任,随便用什么脚本语言来搞都OK,cf为compile脚本传入了两个参数:build dir和cache dir,build dir与传给detect文件的内容一致,cache dir是一个临时目录,比如我们在compile过程中下载jdk和tomcat之类的,就可以用cache dir做个中转。

注意:

1、为了提高下载速度,免受网络困扰,同时增加掌控力度,我们一般会把依赖的tar包放到内网某个位置去自己管理
2、build_dir/.profile.d/*.sh文件都会在运行app之前由CloudFoundry帮我们提前运行,那在此导出一些环境变量之类的就比较方便了

release文件的内容大体为:

default_process_types字段下面的web字段的值就是告诉CloudFoundry如何启动这个app,当然,我们可以在push应用的时候覆盖这个配置,稍候介绍~

如何使用自定义buildpack

这个很easy,进入app所在的目录,push即可:

–buildpack就是用来指定自定义buildpack地址的,–command是用来指定自定义启动命令的,如果你的启动脚本是在app根目录下的start.sh,那就可以用上面的这条命令来push应用

1、bin目录下的detect、compile、release三个文件要求本身有可执行权限,cf不会给你chmod +x,所以我们需要在放到git中的时候就要求有可执行权限
2、stage的时候,cf把我们的app文件放到了这里:/tmp/staged/app,运行时放到了这里:/home/vcap/app,是的,你没看错,二者目录不同,这就需要注意了,特别是安装一些lib组件的时候,当时为了支持python的buildpack就搞的比较恶心,需要安装setuptools、pip和gunicorn,最后是放在了程序启动前来做的,而不是compile阶段
3、在支持嵌入式jetty程序的时候,如果你用了WebAppContext可能也会有问题,没有任何提示信息,就是死活起不来,后来追查发现jetty会为WebAppContext自动创建一个临时目录,猜测可能是没有创建成功,至于为啥没成功一直没有追出来,最后的方案是在程序启动之前提前创建好这个临时目录:mkdir -p /home/vcap/app/work,你如果搞出来了来留言分享一下吧 :)
4、如果你的CloudFoundry跟我们一样没有采用bosh管理,很可能rootfs里缺少一些unzip之类的命令,这个也会使stage失败,提前把一些常用的工具命令装到rootfs里是个明智的选择

示例

1、javaweb的buildpack,使用tomcat作为web容器:

http://git.oschina.net/cnperl/cloudfoundry-custom-buildpack-javaweb-tomcat.git

2、支持python的buildpack:

http://git.oschina.net/cnperl/cloudfoundry-custom-buildpack-python.git

结语

总体来看,buildpack帮助paas平台完成了一个app在部署层面的抽象,主要搞定app依赖的runtime和framework,相当于搞定了静态依赖。操作系统特性通过统一定制rootfs来搞,不在buildpack问题域,配置文件差异问题,buildpack认为一个app一套配置,上层怎么处理,开发人员自己说了算,可以搭建多套CloudFoundry或者创建不同的app:dev-app/prod-app之类;运行时依赖也需要开发人员自己搞定,提前确认好相应的依赖是否已经在run,版本是否OK之类。

有任何问题欢迎留言讨论,谢谢支持:)

 

 

7 Comments

  1. wilbur
    2013/11/18 at 2:53 下午

    赞一个,up

  2. harry
    2013/11/18 at 7:51 下午

    赞一个

  3. faramir
    2013/11/22 at 11:14 上午

    Good Job.

  4. 2013/11/22 at 3:12 下午

    “搞定静态依赖”这事情不容易呀!

    这玩意感觉和RPM很类似,反而RPM更松散。有格式、可以申明依赖。

    RPM可以结合YUM仓库来解决依赖关系和版本管理。对比之下,buildpack是如何实现的呢?

    • UlricQin
      2013/11/22 at 4:36 下午

      buildpack中提供的语言环境和runtime(比如php、apache),一般有多个版本可选,如果默认版本不符合用户需求,用户可以在自己程序的某个指定文件中配置自己所需要的版本,比如我们强制要求用户程序中有个config目录,config下有个dependency.yml,如果用户提供了,OK,用用户指定的版本,如果用户没有提供,那就用buildpack默认的。yum库对应我们内部一个仓储(里边是python、jdk、apache、php之类的buildpack需要的东东),版本管理由用户自己介入指定,用刚才提到的config/dependency.yml作为媒介。还有些不太好搞的依赖,比如某个python webapp要求系统事先安装flask1.0,推荐做法是,用户自己把flask打包到自己的程序中一起上传(这是最推荐的做法,用户发布出来的包就已经是没有依赖的);也可以在根目录下提供一个requirements.txt,里边写上要安装的库,启动之前我们用pip来自动安装。如果有些依赖仍然搞不定,用户可以在启动脚本中写一些自定义命令(不是很好,也没好招)……不知道我是否表达清楚了:)

  5. ayagg
    2014/11/30 at 7:31 下午

    buildpack中的语言环境共享的话不是更好吗?一个app一个环境的话不是太冗余了?

  6. jiy
    2015/07/07 at 3:48 下午

    请问一下,如果我用的是buildpack的offline版本,想修改tomcat的server.xml文件配置,可以在java-buildpack-offline-v2.1\resources\cache目录中直接修改http_%2F%2Fdownload.run.pivotal.io%2Ftomcat%2Ftomcat-7.0.53.tar.gz.cached这种文件么(就是把后缀去掉,解压,然后修改)

发表评论