楼主:
derekhsu (è¯éº—的天下無雙)
2016-09-18 16:05:09※ 引述《Sanbeishuu (三杯鼠)》之铭言:
: 请问主流的几款自动化布署软件有无较适合单纯的update某个web application的呢?
: 一开始试了Jenkins,发现他好像不是这样的用途。后来才发现应该是其他的像是
: Puppet, Chef, SaltStack, Ansible, Juju?
: 目前看起来1跟2是Ruby派,3跟4是Python派,小弟是纯Java派,所以没特别偏好。
: 但如果可以的话是倾向Py派,但其实各款的script好像也不一定是用Py或Ruby写..
: 主要使用情境如下:
: 1. Standalone & portable
: 希望是可以单纯locally的去run,run这一台机器本身的deployment。
: 貌似这类软件都是为了cloud management,所以都有server/client的架构。
: 目前只先略略survey了Chef,应该是有单纯Chef-client跑CookBook的功能。
: SaltStack有看到masterless跟standalone的documentation的样子。
: 另外还希望这是可以portable的,也就是我可以调整好script后打包起来,
: 然后交给客户在on-premises的情境下,double click去完成deployment。
: 2. 只单纯的deploy一个Java web application到tomcat
: 没有要做复杂的server setup跟provisioning。想达到的其实只是单纯的
: upgrade某个web application而已。所以整个flow有点类似以下这样
: 已经有一个application跑在tomcat。该application有a.xml跟b.properties档案
: a.xml的内容会类似如下
: <Property>
: <Name>ServerURL</Name>
: <Value>192.168.1.2</Value>
: </Property>
: b.properties的内容会类似如下
: database.host=192.168.112.25
: database.port=5432
: 有一个新的版本出来了,当然他是一个war档。war档内一样有a.xml跟b.properties
: 只是这时war档内的这些configure値会是default状态。例如:
: <Property>
: <Name>ServerURL</Name>
: <Value>localhost</Value>
: </Property>
: database.host=127.0.0.1
: database.port=5432
: 自动化的把war档解压,将a.xml跟b.properties内容与正在运行的
: application有不同的地方做更改。然后可能必须在压回去war包,
: call tomcat的rest API去进行deploy,如此将web app upgrade,
: 又不需要人工去处理这些application properties的设定値。
: 3. Windows platform
: Tomcat跑在Windows平台上(Win7, Win10, Win Server 2008, 2012 etc..)
: 所以等于是master跟client或者说standalone的运行是在Windows平台上。
: Chef有Windows的msi安装档,还没确定是否可以portable的包起来。
: SaltStack的getting started doc都是Linux版本的范例..
: 4. Free~
: 目前看到Chef, Ansible, SaltStack都有付费版本或者提供SaaS。
: 但应该都有真正的freeware版吧? Ansible看不太出来
: 只有一个Ansible Tower Free trial
: 不知道有没有大大可以建议一下哪一款比较适合简单的达到这个的布署呢?
: 感谢
去年的10月开始,我开始撰写公司新的Java Web Application Deploy方式,
我的目标也跟你很接近,我想要做一个每个人只要click一下就能完成所有建
置与部署的功能,然后在部署的同时也可以根据不同的环境设定放入不同的
properties file,我一开始的时候也是survey chef后来学了Ansible之后开始
想用Ansible,但最终我舍弃这些工具,最后是全部自己搞定。
想说其实很难,但其实也不太难,因为部署这件事情,其实是很容易标准化的
动作。
我们的平台有一个非常大的前提是,我们的网站规模非常非常大,是一个ERP应用
的层级,而且不是采取microservice架构,所有里面内含的其他应用都不算,光是
把登入页面加上所有dependency(Spring 4 + JesperReport + ....)这些东西包起
来,就要80M,其他东西加上去以后包出来的war太大,所以一开始我就舍弃了用war
来封装这种做法,整个build+deploy+生效的时间会太长了,长到我没有办法接受。
所以每个同仁开发的都是一个网站的其中一个library(包含Java Source跟Javascript
等静态档案)
Jenkins除了build之外也可以拿来package跟deploy,但deploy并不适合我们这种场
景,所以Jenkins其实在我的系统里面是拿来build完之后把lib送到repository里面
。
deploy完全是自己写的,因为除了以上的原因之外,我还有需要用Tomcat的parallel
deployment,这东西其实很简单,但是没有很好的tool做这种事情。
集合以上两点我开始自干一套部署平台来整合Jenkins跟Nexus, Sonarqube还有Doxygen
,因为是标准化程度很高的应用程式,所以比起用上Ansible这类的工具,其实自干
还比较快,也不用让别人多学别的工具,你所需要的工具,顶多就是Jtsch跟JGit之类的
工具而已,纯Java的东西。
http://imgur.com/a/8wSMK
像这样,所有的版次都是这个平台自己产生提供给Gradle
http://imgur.com/a/nrK3o
每个系统目前部署的情况也可以一目了然
如果要部署到测试环境,只要按一下按钮就可以部署,如果你的系统会被多个网站共用
,由于自己管理丛集资讯,所以也可以一次部署到多个地方
如果是正式环境就再加上一些比较复杂的签核流程给给主管签核后上线。
因为全部都是你自己写的,所以你不用去思考怎么用这些DevOps工具去整合或干麻,
又因为是集中式的架构,客户的部署也是由你自己的平台来进行,如果这种直接开ssh
tunnel部署类似Ansible的方式不方便,其实也可以多做一个Agent代你完成部署工作,
,所以最终我决定全部都自己来做。其实花得时间并不会真的那么长。
整个建置程序都有Jenkins跟Gradle代劳,deploy要做的顶多就是把档案传到正确的
位置,然后透过诸如调整load balancer或是parellel deployment的方式缩短或避免
downtime,然后用healthy check来确保东西正常运作然后要不要继续部署下去而已,
没有很复杂。
当然现在更好的方式就是把整个application封装成container来deploy,那要看你们对于
container相关技术的接受程度有多高了