※ 引述《dream1124 (全新开始)》之铭言： : ※ 引述《qrtt1 (有些事，有时候。。。)》之铭言： : 谢啦~ q大 你又帮我上了一课 : : 偏好 Ruby 的由 Chef, Puppet 下手 : : 偏好 Python 的由 Ansible, Salt 下手。 : : (至少在选择困难的议题上，你已省力了 50%) : 难怪不常听到 java 社群的人提这些工具，呵呵 单纯以实作专案需求为主的工程师， 比较少会关注与 server side 管理的相关工具 这跟特定语言的关系比较没那麽大 反而跟公司或团队的规模 对於 技术采用 的范围比较有关 因为我最初的工作是在 startup 团队里打工 本来只有纯写 java web，後来渐渐摸到一点前端 再後来也得管理 server，并参与移机作业才会摸得到这些 至於现在在公司也有参与到 Ops 的流程 现况的心得大致像 《一个人的 Ops》 http://bit.ly/1N4v3ks : : 依据过去你在版上的讨论，加上文末提到的 Java。 : : 我猜测是要部署 Java Web Application 为主， : : 有点难理解这类的应用程式为何会难部署， : : 你可能得再补充实际上的『痛点』才能让有解的人给予建议 : : 举例来说： : : 纯 Servlet Container 像 Tomcat 有 RESTful API 能更新 : : 较大一点的 Application Server 像 Weblogic 有 WLST 介面 : : 能用 jython 或 ANT 来更新程式、变更设定... 应该只是碰巧， 公司本来是用 Weblogic，但实在没用到 Application Server 的功能 随着 License 的时间到期，只好力推转纯至单纯的 Tomcat。 反正 Tomcat 单纯 update context 时会 keep session 已经算很方便的了 除了没有好看的、内建 monitor dashboard，实在没什麽好挑剔 PS. 反正现在是流行把 Log 或 Metric 导出来接 ELK stack， 单一软体的 Dashboard 也没那麽重要了 : 其实主要希望只用少数几样工具就能部署各类程式到许多作业系统， 在我看来『许多作业系统』的目标有点太大而难以达成， 即使同样是 linux，就有点懒得去搞定 ubuntu, centos 微妙的不同 或者 同是 ubuntu、同是 centos 在改用 systemd 前後的不同， 更不用说要去弄 linux, osx, windows 都符合的情况。 另外，我注意到我们着重的情境比较不同，得先把它区分清楚 免得让讨论的焦点互相悖离太多 我先前与目前的回复，较着重在实际『部署』的 product server。 据前一篇文章与这篇的资讯，你有疑问有 2 个重心： 1. 应用程式部署 2. 开发环境建置 要找一套工具同时服务二种不同导向的需求， 实在是太困难了，若是针对开发环境，比起薪资水准多少 谈硬体需求反而比较实际， 像我现在是用 mbp 2011 early 扩充到 16 GB RAM， 要开多个 vagrant box 作为不同专案的开发环境挺方便的 PS. 若针对『多种作业系统』以 Windows 为主的话， 先前知道的讯息是 Puppet 较优 （但这是我脑中没机会再更新过的讯息，若有需要得再自行研究了） : 要是这工具还能够实现你提到的 infrastructure as code 那就更好。 : 也就是说....我想尽可能采用统一的方法部署程式。 infrastructure as code 是目标 (以下简称 IaC)， 除了 Data Server (各种 DB 是需要人工细心照料)， 靠 configuration management tool（以下简称 CM） 只是能满足大部分『常见』情境 也就是那些工具被创造出来时，原作者与後继贡献者的需求集合 与自己环境接起来的『体力活』！ 由你目前的情境到 IaC 中间的历程应该是什麽？ IaC 描述的是一种状态，为了将你那些未管理、或未优化的流程 变成可被描述的态状。 所有的行为必需能变成指令与『参数』 那些还需要人工操作的部分，得找出对应的指令才有机会 难以简单用现成 command line 搞定的， 用 Browser/GUI automate toolkit 也行 如果上述都无法轻易达到，那就写自己的工具而已 : 否则，我们还真的有 Tomcat 和 Weblogic 等环境(你是不是猜到我公司...嘿嘿) : 若开发人员需要学习多套部署与管理方法才能动手开发，那也未免太麻烦。 : 在最近的 infrastructure as code 还没喊得震天价响之前， : 我就认为开发环境的建置方法应该要一致、自动、容易重建与复制。 不用 web server 的管理，这部分跟 IaC 的关联比较不大了， 你可以提供一个简单的 command 把它们的差异隐藏起来 （只是把写程式的多型的概念，拿出来用而已） 至於开发环境，无论是 Tomcat 或 Weblogic 都有 Plugin 能直接使用 以 Eclipse 来说 ，同一种 OS 更是可以直接 zip 起来，到另一台使用 相关的档案也都能比照办理。 : 现在乍看 docker 是比较可行的方案.... : : 先试着回想一个问题， : : 上一次『从无到有』建出完整的系统，所有机器是什麽时候的事了？ : : 要建出完整的系统，从一个空的 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 : 这段资讯触碰到问题的核心，真的很实用，谢谢！ : : 莫惊慌、莫害怕。 : : 即使他们什麽外挂都没有，还有最终一招『呼叫外部程式』 : : 总可以呼叫他们的 command 去做事呗 :) : 呵呵，其实这只是想尽量偷懒，我要优先评估支援范围比较广的工具。 : : 开发人员的行情 跟 做这些事没有关系 : : 开发人员的行情 跟 做这些事没有关系 : : 开发人员的行情 跟 做这些事没有关系 : : 不管薪水多少，得要为自己谋福利。 : : 包含部署应用程式的舒适感 : : 与 : : 维护部署应用程式的应用程式的便利性 : 哈..从开发人员的角度来看，像我们这样有信心驾驭这些东西的人当然想用好工具， : 但如果我真的希望能导入这些工具，那就要深入探索一些问题的答案。 : 因此这个问题才会看起来比较奇怪，其实我想问的是 「根据大家的经验， : 实力的行情价在42k左右的开发人员能否顺利使用 docker 建置开发环境」？ 我还是无法将行情与 docker 的逻辑联接起来。 比起薪资行情， 要掌握 docker 最好本身就是已经熟悉 linux 操作的使用者 不然遇到问题只能等待救援，一方无助、一方无奈，相互拖磨而已 若没有要掌握 docker，那其实也没几个指令 会 load image，start, stop, restart 应该就能动了 不然你帮忙包成 Web App 能 click click 完工也行 (也许有现成的工具) 单纯作为 "user" 那也只是多认得一些指令， 只是有没有意愿接收新知的问题。 但考虑到不同平台的便利性，我个人比较选择 vagrant + docker 等 native docker 在 windows 大家都用得真正稳定後， 才会考虑纯 docker 的配置了 先前公司部分专案有用到类似的环境，一开始是 docker。 为了让 windows 开发为主的同事使用，另外再包了一层 vagrant 《Linking Error》 https://speakerdeck.com/qrtt1/linking-error https://github.com/qrtt1/PyHUG20150303 PS. docker 也有社团能参考 https://www.facebook.com/groups/docker.taipei/?fref=ts : 为什麽要问这个问题呢？ : 或许是因为我们这里的管理者平常根本不写程式，不会接触这些开发环境， : 所以要是我们批评某工具很难用、妨碍工作，希望可以换掉时， : 他们通常很难体会开发人员的感受，不会就这样买单。 : 他们搞不好还心想「别再抱怨了，请你就是要解决这种问题的，谁工作不曾觉得难受？」 : 当我跟老板提案，想介绍这些工具进团队时， : 他们会在意新进人员能否顺利上手？ : 如果不行的话，那公司又该投入多少资源训练到OK？ 所谓的OK又是什麽程度？ : 使用这些工具是否容易不小心损坏东西？ : 导入有什麽效益？ 这些效益能否从会计的观点量化成金钱，好让他容易向更上级报告？ : 我得先准备好上述问题的答案再跟他们讨论，这样才容易成功， : 不然他们可能只会笑一笑，心想「乖喔，我知道你很认真，但别再抱怨啦~」。 : 因此，我觉得「要不要用」反而不是导入 docker 的核心议题....答案实在太明确了。 : 举凡「开发人员能否顺利上手」、「能否整合进目前的软硬体设施」、 : 「解决方案是否适合公司的环境」等等问题才是该多花时间思考的。 : 附带一提，我觉得这些管理者都是很认真踏实经营事业的人，只是有时候比较死脑筋。 : 他们分析问题的观点其实不算很多元，常常只会管理、营运和技术的角度切入事情。 : 当我从人力资源的角度向他们提倡「好工具是一种员工福利」时， : 他们的反应不太热络，我猜是不太接受这种概念，甚至根本就听不懂。 : 最近我正在准备相关资讯刺激他们，希望能够诱导他们下适当的决定。 这就...是公司内部的问题，没什麽特别想回应的。 : : 即使 Docker 的 native support 已经有宣传能在 Windows, OSX 使用 : : 但要到稳定好用不确定要再等多久， : : 而你的情境多是 java 为主的话，要新人快速地从无到有建立开发环境 : : 在有提供手册指引的话，没道理一天搞不定啊 : : （一定是有什麽我们所不知道的细节没谈到） : 我从q大先前的文章推测你们开发人员的平均实力远远超过我们， : 要是再考虑到你们使用比较好的开发工具，建置环境的手册又比较同步的话， : 我相信你们建置开发环境的速度一定很快，但我们就未必了.... 再重提一次，建置『部署环境』与『开发环境』的议题不太一样。 部署环境强调一致性，开发环境比较个人化。 不太适合把这二个不同目标的事情放在一起搞， 即使辅助的工具可能是重叠的， 但没看准目标就行动，肯定绕得路比较远些。 至於开发人员的实力，每个人擅长的不同。 好的管理者与开发者的自觉，视情境把让各自发挥出水准而已。 而我们的开发环境，只要有 JDK 跟 Tomcat 就足够了 其他的个人必备工具，就看自己的喜好了 有人用 IDE，有人不用 IDE，有人用 git cli 有人用 git GUI ... 装这些实在没什麽难度， 但我不能以我的情境去质疑你的时间， 因为我们，或着说外人根本看不到实际的痛点在哪 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 36.227.38.73 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1459741805.A.4B9.html ※ 编辑: qrtt1 (36.227.38.73), 04/04/2016 11:51:14 ※ 编辑: qrtt1 (36.227.38.73), 04/04/2016 11:52:08 ※ 编辑: qrtt1 (36.227.38.73), 04/04/2016 11:54:46 以『终极、理想型态』的观察来说， 事情不会变多，反而应该要变少，但却能做的得多。 多是多在新的工具的导入与新观点的学习， 少是少在人工的介入与品质难以均一的人为操作。 （取而代之的是，透过指令或 API 自动化或半自动化） 原本在 server side 该学的知识不会变少， 不过是否要学到深入是看个人职业取向与技能树的点法 为了维持事情的进展，有时我们可以选择无知， 并将事情委派给同事或其他服务。 越搞越忙的情况，常是在新、旧交叠的时期， 并且有不同的支持着互相拉扯， 让新的无法完全导入，旧的也无法完全退休 （这种事只能靠战绩实力或政治解决罗） 惊！我对梗太深的笑话或反串常难以辨示 @@ ※ 编辑: qrtt1 (36.227.38.73), 04/04/2016 16:16:58 ※ 编辑: qrtt1 (36.227.38.73), 04/04/2016 16:19:18