※ 引述《qrtt1 (有些事，有时候。。。)》之铭言： 谢啦~ q大 你又帮我上了一课 : ※ 引述《dream1124 (全新开始)》之铭言： : 偏好 Ruby 的由 Chef, Puppet 下手 : 偏好 Python 的由 Ansible, Salt 下手。 : (至少在选择困难的议题上，你已省力了 50%) 难怪不常听到 java 社群的人提这些工具，呵呵 : 依据过去你在版上的讨论，加上文末提到的 Java。 : 我猜测是要部署 Java Web Application 为主， : 有点难理解这类的应用程式为何会难部署， : 你可能得再补充实际上的『痛点』才能让有解的人给予建议 : 举例来说： : 纯 Servlet Container 像 Tomcat 有 RESTful API 能更新 : 较大一点的 Application Server 像 Weblogic 有 WLST 介面 : 能用 jython 或 ANT 来更新程式、变更设定... 其实主要希望只用少数几样工具就能部署各类程式到许多作业系统， 要是这工具还能够实现你提到的 infrastructure as code 那就更好。 也就是说....我想尽可能采用统一的方法部署程式。 否则，我们还真的有 Tomcat 和 Weblogic 等环境(你是不是猜到我公司...嘿嘿) 若开发人员需要学习多套部署与管理方法才能动手开发，那也未免太麻烦。 在最近的 infrastructure as code 还没喊得震天价响之前， 我就认为开发环境的建置方法应该要一致、自动、容易重建与复制。 现在乍看 docker 是比较可行的方案.... : : 请问大家方便解答下列的疑惑吗？ : : 1. 如果系统的使用量不会经常变动，管理者多半不用经常调整丛集里的伺服器配置， : : 甚至有许多系统不是丛集，这样的话导入这类工具的效益会不会很差呢？ : 先试着回想一个问题， : 上一次『从无到有』建出完整的系统，所有机器是什麽时候的事了？ : 要建出完整的系统，从一个空的 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. 请问他们目前跟持续整合伺服器结合的状况怎麽样？ : 莫惊慌、莫害怕。 : 即使他们什麽外挂都没有，还有最终一招『呼叫外部程式』 : 总可以呼叫他们的 command 去做事呗 :) 呵呵，其实这只是想尽量偷懒，我要优先评估支援范围比较广的工具。 : : 4. 请问有没有人试过在开发人员行情於 42k 左右之团队引入 Docker 建置 : : 个人的开发环境呢？ 不知道这些人能否顺利上手？ 会不会遇到很特殊的问题？ : 开发人员的行情 跟 做这些事没有关系 : 开发人员的行情 跟 做这些事没有关系 : 开发人员的行情 跟 做这些事没有关系 : 不管薪水多少，得要为自己谋福利。 : 包含部署应用程式的舒适感 : 与 : 维护部署应用程式的应用程式的便利性 哈..从开发人员的角度来看，像我们这样有信心驾驭这些东西的人当然想用好工具， 但如果我真的希望能导入这些工具，那就要深入探索一些问题的答案。 因此这个问题才会看起来比较奇怪，其实我想问的是 「根据大家的经验， 实力的行情价在42k左右的开发人员能否顺利使用 docker 建置开发环境」？ 为什麽要问这个问题呢？ 或许是因为我们这里的管理者平常根本不写程式，不会接触这些开发环境， 所以要是我们批评某工具很难用、妨碍工作，希望可以换掉时， 他们通常很难体会开发人员的感受，不会就这样买单。 他们搞不好还心想「别再抱怨了，请你就是要解决这种问题的，谁工作不曾觉得难受？」 当我跟老板提案，想介绍这些工具进团队时， 他们会在意新进人员能否顺利上手？ 如果不行的话，那公司又该投入多少资源训练到OK？ 所谓的OK又是什麽程度？ 使用这些工具是否容易不小心损坏东西？ 导入有什麽效益？ 这些效益能否从会计的观点量化成金钱，好让他容易向更上级报告？ 我得先准备好上述问题的答案再跟他们讨论，这样才容易成功， 不然他们可能只会笑一笑，心想「乖喔，我知道你很认真，但别再抱怨啦~」。 因此，我觉得「要不要用」反而不是导入 docker 的核心议题....答案实在太明确了。 举凡「开发人员能否顺利上手」、「能否整合进目前的软硬体设施」、 「解决方案是否适合公司的环境」等等问题才是该多花时间思考的。 附带一提，我觉得这些管理者都是很认真踏实经营事业的人，只是有时候比较死脑筋。 他们分析问题的观点其实不算很多元，常常只会管理、营运和技术的角度切入事情。 当我从人力资源的角度向他们提倡「好工具是一种员工福利」时， 他们的反应不太热络，我猜是不太接受这种概念，甚至根本就听不懂。 最近我正在准备相关资讯刺激他们，希望能够诱导他们下适当的决定。 : 即使 Docker 的 native support 已经有宣传能在 Windows, OSX 使用 : 但要到稳定好用不确定要再等多久， : 而你的情境多是 java 为主的话，要新人快速地从无到有建立开发环境 : 在有提供手册指引的话，没道理一天搞不定啊 : （一定是有什麽我们所不知道的细节没谈到） 我从q大先前的文章推测你们开发人员的平均实力远远超过我们， 要是再考虑到你们使用比较好的开发工具，建置环境的手册又比较同步的话， 我相信你们建置开发环境的速度一定很快，但我们就未必了.... --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 118.160.90.128 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1459698080.A.FF2.html 哈, 那也希望抢得到票 每一次都是忙一忙回头看就什麽位子都没了 可否拗板上TWJUG的高手帮忙留座位啊? XD 你们的讲者太强了, 议题也很深入, 我恐怕没什麽料好讲啊~~~ ※ 编辑: dream1124 (118.160.90.128), 04/05/2016 00:20:25