※ 引述《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大先前的文章推测你们开发人员的平均实力远远超过我们，
要是再考虑到你们使用比较好的开发工具，建置环境的手册又比较同步的话，
我相信你们建置开发环境的速度一定很快，但我们就未必了....
个人感受, 要常在多套环境间切换才比较用得上 docker若跑段 shell 在本机装 MySql ok, 很没动力用 docker 弄总之诸如此类, 看环境常不常切换, 一次要换多少台, 硬件配备如何 (若 CPU RAM 够跑多 VM 蛋糕一块也无不可啊 XD总之 docker 也是跑 shell, 就是试误跟切换方便要 as code 的话我觉得装 VM 留 shell 也差不多另外用 docker 没有比用纯 shell 难, 若会写 shell 有Ubuntu 环境可以直接踹看看, 应该一两个钟头够摸个大概