※ 引述《Sanbeishuu (三杯鼠)》之铭言： : 请问主流的几款自动化布署软体有无较适合单纯的update某个web application的呢? [--------] [-----------------------] update 这确实很容易，但事情不是只有 update 你现在只想到 {自动化, 部署} 不是真的 {自动化部署} 完整的思维应该是 delivery pipeline 自动化不是必要的，但要完全「非人工」介入， 并让每一个程序可以被追踪，得付出额外的努力。 当你真的做到「完善」的时候， 你要做的事就不是单纯你现在描述的这些内容了。 可以先看个入门学，培养一下概念 http://www.books.com.tw/products/0010653820 https://www.thoughtworks.com/continuous-delivery (由於成书至今有些年份，工具可能改朝换代， 或 DVCS 的接受度有变，那就依自己的情境代换一下吧。) : 一开始试了Jenkins，发现他好像不是这样的用途。後来才发现应该是其他的像是 : Puppet, Chef, SaltStack, Ansible, Juju? Jenkins 最初大家拿它来做测试为主， 并因为是基於 jvm 为主的应用程式，所以拿它来控制各种平台的活动 实在非常方便，所以才有用它的 agent 在常见的 Linux, Windows, OSX 上配合与不同的 Browser 组合互相试测（配合 selenium 更是如虎添翼） 甚至到现在，加上 android device 或 iOS device 的自动化测试依然也适用。 对它来说，工作的「单位」都是 Job，只要有安装上 java agent （在防火墙内还可以透过 JNLP 由 node 上连回 jenkins master） 就能轻松递送要做的工作。 Jenkins 比较适合在 node 数固定，且混杂异质平态，需高度客制化的情境。 因为 "Job" 的内容很多变，可以是 Ant Job、Maven Job、Gradle Job 或没限制你写什麽的 FreeStyle Job，你想改什麽，或呼叫端远指令都做得到。 不过要写成这样，已经跟「高度」客制化没什麽差别了啊。 （这隐含着，你目标的环境并没有「整理」成较一致的情况） 不过，到了 2.x 要准备发布的这个时代，加上「云端」与 Continuous Delivery 概念与 DevOps 哲学观的推挤， 它开始将 workflow 的概念合并改名字为 Delivery Pipeline 的 Pipeline。 也就是你一个完整的软体开发流程的「管线 (pipeline)」是怎麽串起来的 1. 开发者把程式送往 VCS 2. VCS 的程式被拿来 Build 成 Artifact 3. Artifact 被拿来跑单元测试 4. Artifact 加上 Configuration 丢上 UAT 跑整合测试 5. UAT 跑过後，送上 Staging 跑整合测试与烟雾测试(smoke test) 6. 通过各种测後，进行 release 的 workflow 这整个 workflow 的每一阶段都是 1 个 pipeline pipeline 内可以是另一个 pipeline 或实际执行的步骤。 且每 1 轮的 workflow 的发起都会对上 VCS 的 revision release 的 workflow 会是某个标示通过测试的 artifact （你会有 jenkins build number 与知道它是哪个 revision） 以你的情况，可能是某个 war 或 jar 会在 prod 上 deploy 并进行烟雾测试，确定状态良好後开始服务 不然就维持旧的版本 ========================================================== Puppet, Chef, SaltStack, Ansible 则是不同的动机而起的， 虽然目前比较「红」的词是 DevOps，但应该回到最初的想法去看它 他们该做的是 Configuration Management 这个工作。 但有个尴尬的问题是，你得先面对一个「选择题」。 在 Continuous Delivery 书上，它的想法是 一个应用程式的良好运作是建立在 {组态设定、程式、资料} 三者都正确的情况 并且认为 {组态设定} 应独位於程式，它的建议是 {组态设定} 不会包含在 Build 与 Package 内，应该独立於它之外。 以这个逻辑来说，应该上组态的时间点在 Deploy 或 Provision 的时候。 而 Puppet, Chef, SaltStack, Ansible 正好是在做这件事的最佳助手 能帮检查设定档在不在、程式的状态是不是在期望的状态等等 他们的用法多为「描述一种最终的状态」并且试着修正不合预期的状态 尴尬的部分是，在 Java EE 的规范是把 {组态设定} 也封状进 WAR 内的 我并不会说书上那麽建议，就一定要遵守，最适合的情况， 只有身处於那个工作场域的人自己知道。 以我目前的情境是比较倾向於把 {组态设定} 包进去的， 对我来说，来自同一个 revision 建出来的东西好追踪比较重要 同一个 team 的开发者，不用多认识其他 tool 就能建出一样的结果 这样也同时能减少 {组态设定} 管理不当的意外。 因为二组 repo 可能会不好对上， 不管是 cfg 的 revision 没跟上，或是 project 的 revison 没跟上， 都可能有意外发生，或是 deploy process 失败了，因为要 deploy 二次， 一次是 project 本身，一次是 {组态设定} 本身。 由於 DevOps tool 自己另一组 VCS repo 管理， 若是硬分割至各专案内，就变得难以看清楚 Infrastructure as Code 的全貌，除非刚好它们有机会共用一个 repo 且不会意外形成 duplicated code 那会是个较佳的型式。 (或是区分开来系统层面的 Automation 与专案元件的区分开来也是个办法) 另外，不包进去，也不另外透过 deploy 程序来更新组态设定的话， 第 3 条路就是 service discovery 的方法了 (应该是书上第 2 部，讲组态管理有提到这概念)， 通常就是跑个 agent 让你问现在的设定。 像 EC2 在机器内部提供的 metadata http://amzn.to/2cLJW4a 现在有 https://www.consul.io/ 这类的工具能做到 （但以你的情况需求 "portable" 大概不会采用 :P） 用这东西确实能让你把组态抽出来，不过实际是否真的需要那麽「弹性」 是存疑的，过度的弹性与灵活，会造成「设置困难」， 每个选项间可能又有相依关系，这也许会搞死新进的开发者， 或是终於使用者根本无法利用这些「弹性」的设计。 : 目前看起来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。 要让客户去 double-click 不觉得跟标题的「自动化」有点违悖吗 :P 或许我该先忘记 double-click 或是「自动化」其中一个提前。 假设，我舍弃了「自动化」，让客户 double-click 的话， 又能 portable、又不可以另外装些什麽软体 那我该做些什麽呢？ 弄个 executable JAR 做： 1. 下载最新的 WAR 回来（executable JAR 内知道 revsion => artifact） 2. 开一台 embedded Tomcat 跑这个 WAR (如果要改组态的话，也改吧) 3. 开始做 smoke test 确认重要的功能都可以动 (至少 DB 要连得上) 4. 如果有问题就，send log 回来 5. 如果没问题就换上新版的至 prod (这其实没有像一些不上 store 的 andoird app 给你个 apk 它是让你下载另一个 apk 用的!?) 如果我舍弃的是 double click。首先，为什麽要舍弃 double click 呢！？ 因为客服可能收到了你「最新」的安装档，但却执行了「旧的」安装档， 然後再写信问你为什麽不 work。 其实 double click 不是主因，是人工判断的品质差异比较大， 有可能他半夜被 call 来换档（可能是加班，或不同时区），不小心点错了 也可能是他没有点错，但我方给错了版本。 至少，把品质放在人少的那一方比较好控制， 你可以把那个要 double click 的档变成 windows service， 定期去查有没有新的更新，有的话就执行更新程式 (这不就是 windows update 吗？) PS. 千万不要把更新程式与 tomcat 绑在一起 你无法预知，你上新版後 tomcat 是不是会被你弄死 万一绑在一起了，他们就只好殉情了 (其实 AWS 的 Beanstalk 也是弄个 hostmanager 的 agnet 做这件事啊) PS. 不管你选择的是什麽，都得能方便的知道使用者现行的版本 例如在 http response 加上特殊 header 标上各 component 的 revision : 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的设定値。 如果你只是要简单的换 IP ... 那不如改 local host 对应的设定 C:\Windows\System32\drivers\etc\hosts : 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版本的范例.. 很遗憾的，这些程式最初的开发者都不是 Windows User。 即使用提供，因为开发者人不够多，用的人也不够多 待「踩雷」的点应该很多，需要有「爱」才用得下去， 或是加入改善它们的行列吧！ : 4. Free~ : 目前看到Chef, Ansible, SaltStack都有付费版本或者提供SaaS。 : 但应该都有真正的freeware版吧? Ansible看不太出来 : 只有一个Ansible Tower Free trial : 不知道有没有大大可以建议一下哪一款比较适合简单的达到这个的布署呢? : 感谢 看来看去，是前一篇大大自己 deploy tool 对你来说最适合。 或是问问其他 windows 深度使用的管理者，看看有没有好招！？ 我们现行的 deploy tool 也跟他相似，不过是仿 AWS Beanstalk 指定 revision 後，deploy 至各机器上 （但没有做 agent 是 rsync 去递送 + ssh remote command） 不过随着系统的环境，与 project 整理的越来越一致， 之後应该会转移至 ansible 上，透过它 deploy。 -- JCConf 工商服务 https://www.facebook.com/jcconf/posts/974947969317750 JCConf 2016 售票至 10/9 (日) 结束呦 :D 报名网址：http://twjug.kktix.cc/events/jcconf2016-register 议程网址：http://jcconf.tw/2016/ --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 211.21.157.224 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1475483798.A.9C0.html 我想是我没表达清楚，不是说要用德瑞克的实作，而是如德瑞克般自行客制。 ※ 编辑: qrtt1 (211.21.157.224), 10/04/2016 11:41:58