配置管理 vs provisioning 及配置管理工具的几点随想

关于“怎么构建一个确定的运行环境”这件事,有多个流派,其中一个是配置管理,另一个是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定时刷新式的(虽然听说也可以主动?不过我经验较少还没用过),得按定时器来,这种情况下就得运维工程师多看监控了,一不小心,死都不知道怎么死的。

This entry was posted in 默认分类 and tagged . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *