服务集群部署，脚本有的时候就没法做到，有其他方法可以实现此需求吗？

经历：
1.在把项目迁移至容器中，前期确实需要去写很多脚本去配置服务的配置文件，并且在项目的配置文件更新后，脚本中需要抽出很多参数，到后期脚本维护成本太高了。
2.集群部署，拿redis集群来说：redis slave需要知道redis master的信息，通过脚本去实现很难获取到，并且使用compose启动容器的时候，有的时候master还没启动起来，slave会报错。
尝试过的解决方法：
3.开始尝试利用etcd服务来做服务发现，容器启动时自动往etcd（K/V存储服务）注册一些容器的信息，slave启动的时候去etcd服务中获取，服务发现基本解决。不过容器创建的时候名字什么的有约束，得根据之前定义好的去填；
4.名字服务，在利用容器去实现服务部署的时候有个关键的点是想，容器启动后服务就应该是正常可以工作的，如服务之间的相互通信和相互发现等，然后利用skydns去解决了容器的名字服务；这样容器之间利用名字就可以实现通信；
5.3、4功能都有了，容器的启动顺序还没解决，看了开源的解决方案，--link这个是有严格的依赖，但如果多服务之间的依赖管理和升级就很麻烦，非常无奈，我们又实现了一套类似操作系统的服务启动优先级设置，给容器设置启动的优先级；
6.以上功能都满足后，基本60%能满足一个简单的集群部署了，但是如果多环节之间要做交付，或者redis里面的配置文件需要变更，这些需求就比较痛苦，很多情况下还的重新构建镜像，然后在重新部署，这个基本上那个企业也不能接受。容器的世界真的是太让人陶醉，但周边的管理工具在容器的世界中基本上都失效了，之前配置文件配置通过puppet工具就都能实现，但容器的世界中，不能在容器中再跑一个puppet agent。我们的实现是自己开发了一个类似puppet的配置中心CCE（容器配置引擎）。有了配置中心管理，才能去满足你不用去写脚本的需求。说的有点多了，我理解的大概是这个样子，如果想继续了解详情，欢迎一起再探讨！

楼主，请把平台、什么镜像，要写什么类型的脚本等基本环境的东西列出来，大家才有可能回答，你说的在笼统了。