※ 引述《dream1124 (全新开始)》之铭言： : 请问大家有使用过 Puppet, Chef, Ansible, Salt 这些组态管理与配置工具的经验吗？ : (configuration management and orchestration tools) 简单地说，使用这些工具，避不了有扩充他们的时候 那些时候，即使你不是自己动手写他们的 plugin 那也要找别人的来用 这时你得面对的是他们的 source code 实做的语言。 这样就能粗略地分为二类： 偏好 Ruby 的由 Chef, Puppet 下手 偏好 Python 的由 Ansible, Salt 下手。 (至少在选择困难的议题上，你已省力了 50%) : 我觉得同事部署应用程式的方法实在太辛苦了，希望能帮他们想点办法。 : 据我查的资料，上列方案至少都能够批次自动调整作业系统的设定， : 有些甚至还有中央控制的伺服器可以排程配置很多电脑的组态设定。 : 但是各家厂商宣传文件和比较表令我看得头昏眼花，有些问题也没找到答案， 依据过去你在版上的讨论，加上文末提到的 Java。 我猜测是要部署 Java Web Application 为主， 有点难理解这类的应用程式为何会难部署， 你可能得再补充实际上的『痛点』才能让有解的人给予建议 举例来说： 纯 Servlet Container 像 Tomcat 有 RESTful API 能更新 较大一点的 Application Server 像 Weblogic 有 WLST 介面 能用 jython 或 ANT 来更新程式、变更设定... : 请问大家方便解答下列的疑惑吗？ : 1. 如果系统的使用量不会经常变动，管理者多半不用经常调整丛集里的伺服器配置， : 甚至有许多系统不是丛集，这样的话导入这类工具的效益会不会很差呢？ : 据我所知，这些工具的操作与管理介面似乎相当不一致， : 我们恐怕难以大幅藉着过去的软体使用经验快速评估任何一种方案， : 只能一头栽进去，花费大量时间了解状况。 : 另外，虽然公司未来有可能会部署应用程式到国外的资料中心， : 但系统使用量多半相当稳定，可能没有扩充性(scalability)的问题。 : 因为有这些考量，使我不太确定是否值得导入这类工具。 先试着回想一个问题， 上一次『从无到有』建出完整的系统，所有机器是什麽时候的事了？ 要建出完整的系统，从一个空的 Server 安装好 OS 後， 需要多少步骤、时间才能完工呢？ 而这些安装的细节是怎麽保存、怎麽与现状同步的？ 在过去，我们是依赖着一代一代传下来的交接文件， 随着 Server Admin 换人，或新专案启动多少会影目前的配置 文件能不能近可能接近与『现况』同步的状态是相当大的挑战 PS. scale in/out 大部分是架构设计的问题， 部署工具的角色主要在： 1. 建出一个基础只差修正 config 或更新部分应用程式 2. 异动管理（部分程式更新或设定变更） 不太有时间让你要 scale out 时用 deploy tool 慢慢从无到有装起来 通常会包成能比较快速启动的型式（VM 的 image） 或是预先好的安装包（例如 RPM, DEB） http://techblog.netflix.com/2016/03/how-we-build-code-at-netflix.html : 2. 请问他们目前跟持续整合伺服器结合的状况怎麽样？ : 我知道 ansible 有 jenkins 的外挂，但是不清楚其他的组态管理工具 : 有没有现成的整合工具或套件，使它能够跟主流的持续整合系统一起 : 实现高度自动化的持续部署机制？ 莫惊慌、莫害怕。 即使他们什麽外挂都没有，还有最终一招『呼叫外部程式』 总可以呼叫他们的 command 去做事呗 :) : 3. 请问像 kubernetes 这样的工具跟前面那些组态管理工具有什麽不同？ : 差别是不是在组态管理的对象...前四样是作业系统，kubernetes则是容器呢？ : http://blog.kubernetes.io/ k8s 是 docker clustering system 跟前面的东西的用途是相当的远的！ : 4. 请问有没有人试过在开发人员行情於 42k 左右之团队引入 Docker 建置 : 个人的开发环境呢？ 不知道这些人能否顺利上手？ 会不会遇到很特殊的问题？ : 不知道能否期待使用 windows 10 的 docker 将新人建置 java 开发环境的时间 : 从三天缩减至一天？ : 在此先谢谢大家分享的经验！ 也欢迎私信交流！ 开发人员的行情 跟 做这些事没有关系 开发人员的行情 跟 做这些事没有关系 开发人员的行情 跟 做这些事没有关系 不管薪水多少，得要为自己谋福利。 包含部署应用程式的舒适感 与 维护部署应用程式的应用程式的便利性 即使 Docker 的 native support 已经有宣传能在 Windows, OSX 使用 但要到稳定好用不确定要再等多久， 而你的情境多是 java 为主的话，要新人快速地从无到有建立开发环境 在有提供手册指引的话，没道理一天搞不定啊 （一定是有什麽我们所不知道的细节没谈到） ============================================================== 回头来讲为何要支持导入这些工具， 长远的目标从开发环境到部署环境（product, staging, testing) 都期望朝向 Infrastructure as Code 的目标前进 具体地描述是说，我在 server 上改了什麽（更加哪些软体或防火墙设定） 我能简单地在版本控制系统里 diff 或 blame 一下就知道发生了什麽事 当某些配置有问题时，我可以平行的建出一套一模一样来模拟它 或当有人手残下了 rm -rf / 时，我们在较短的时间， 以没那麽慌乱的步调来进行重建的工作， 不会因为当时『压力山大』而再做了更多蠢事。 使用 code 代替不时 out of date 的 operation 文件， 在人员异动时，也比较没有麻烦，大家一同执行一下程式 双方结果都一样後，那再说明一特例需要微调的部分即可。 ============================================================== 大致理解 Infrastructure as Code 之後， 谈另一个概念是 immutable server，你只会部署 1 次 那次部分之後上面的所有东西都不会再变了（除了资料与暂存状态） 有新的变更就得再重新生一份 image 出来部署 这与利用 configuration management tool 来持续同步 server 到最新的状态是不太一样的『风格』 （注意，你也可以使用 configuration management tool 来做， 只是它们只有同步第 1 次，之後都不变了，并封装起来使用） 这风格的优点是养 server，不再像养宠物。 宠物生病了要医好他，爱他一生一世。 immutable server 坏了就把旧的丢弃，生一份新的取而代之。 http://martinfowler.com/bliki/ImmutableServer.html https://www.vagrantup.com/ https://www.packer.io/ （docker 也算是这种风格『复兴』的重要推手） PS. 除了做 immutable server，vagrant 辅助开发就已经很方便了。 我在专案下都附 1 个 vagrant 管理的 vbox 并设好 private ip jdbc 在 dev 阶段的 config 都是连自己的 vagrant box 内的 mysql 在部署阶段由 deploy tool 上正式 server 的设定 [OSDC 2013][20130420 1120~1150][第一会议室] ihower - A brief introduction to Vagrant https://www.youtube.com/watch?v=5hyxqeG_mt8 导入 Vagrant 做开发配置 https://ingramchen.io/blog/2014/06/vagrant-up.html =============================================================== (工商服务?!) (不过我没收钱，也没有人会付钱给我，只是刚好知道曾有这些课程) ITHOME 就协办相关 workshop，让社群、业界讲师开课： 1. Ansible 自动化组态管理实战讲堂 2. Chef 自动化组态管理实战讲堂 另外可以留意，只要有任何免费、付费资源通常会来这宣传 https://www.facebook.com/groups/DevOpsTaiwan/?fref=ts --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 36.227.38.73 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1459614489.A.583.html ※ 编辑: qrtt1 (36.227.38.73), 04/03/2016 00:30:39 ※ 编辑: qrtt1 (36.227.38.73), 04/03/2016 00:55:29 ※ 编辑: qrtt1 (36.227.38.73), 04/03/2016 21:42:45