关于“怎么构建一个确定的运行环境”这件事，有多个流派，其中一个是配置管理，另一个是provision流。
配置管理流派，适合于物理服务器、虚拟机等等，有机会长期存活的环境。因为它们有机会长期存活，在其生命周期里需要使用技术手段去维持一个有序可控的状态，排除软件运行时累计的旧日志和临时数据、手工操作带来的计划外变更等等影响。
而provision流派，直接从模版构建一个（容器或虚拟机）实例起来运行，用完就扔，基本上没有重新调整的价值。这种东西往往依赖于服务注册与发现机制，因为在它真正起来运行之前，网络通信方面的参数无法被外界预知，外界不知道如何跟它通信；对于日志和数据，也提倡使用显式远程的方式去访问。
再说说配置管理工具的几点随想：
我最近一年在给下属的一个公司做一些产品运维工作，其中遇到把设备投放到客户的网络环境去运行这种情况。考虑到网络通信的问题，我只好选择了“反向连接”的saltstack软件。在通信的角度来考虑，配置管理工具可以分为：master主动连接minion（ansible等）、minion主动连接master（puppet、saltstack等）
今天听师兄说他的一个同事因为认知问题，把一批机器glibc给删掉了。尝试恢复的时候，他发现ansible无法正常运行（我猜想sshd启动python的时候因为缺glibc而失败了），只好改用saltstack。因为saltstack的salt-minion是长期运行的，一旦启动之后，外部依赖较少，才能在glibc被删除这么极端的条件下苟活。在“有没有agent”的角度考虑，配置管理工具可以分为：有agent（saltstack、puppet、cfengine等）和无agent（ansible等）
另外，其实还有一个分类角度，就是主动和被动。saltstack和ansible是主动式的，运维工程师可有更多的主动权，可以用手工指定minion，或者指定批次规模分批执行等手段，控制变更的节奏；cfengine、puppet等是agent定时刷新式的（虽然听说也可以主动？不过我经验较少还没用过），得按定时器来，这种情况下就得运维工程师多看监控了，一不小心，死都不知道怎么死的。
