※ 引述《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