#provisiong

When I know puppet first time, I got very excited.  Puppet helps me a lot for managing 30 machines. However, I found it has also pain. It was hard to debug because execution order is not as written.  There was also a lot of pain of recipe dependencies. I tried some 3rd party recipes but most of it won’t work or don’t suit my use case.

Chef boomed after puppet. Cookbook on chef was just a Ruby DSL. Even if I don’t know how to write ruby, DSL was easy to understand [Note1]. It was easier to debug, and dependency management was not so pain as puppet. However, I faced chef server node down issue because of CouchDB created ton’s of cache files. (Note that this is old issue, and I believe they don’t use CouchDB backend anymore.) Anyway, there were burden of provisioning master server management.  We should operate it & manage it. (HA, backup etc.)

Fabric got popular after those days around me. I’ve using python for most of work, so Frabric suits me. Server-less architecture looks nice for me. When the fabric script grew up, there was pain of management python “Code”. We should be responsible for write nice python provision code, which are extensible & fault torrent.  

I thought “OK, provisioning is naturally painful.. Anyway, we should fight with many Frankenstein like middle ware & application servers and configurations.. Provisioning tool doesn't matter..”

Now, I’m using Ansible. Ansible looks like YAML DSL + Fabric.  YAML DSL works nice to hide burden of manage “Code”. Debugging is straightforward.  Actually, We can run from middle of provisioning using --start-at-task parameter. This feature makes debugging faster. Sever-less architecture. Clean configuration variable management.