Richard Bucker

Chef, Puppet, Ansible and SaltStack

Posted at — Aug 16, 2014

I’ve been writing batch installer for years. Different batch sh, bash, zsh, bat, ant, nant; and dynamic languages like perl, python and ruby. But at the end of the day they are all the same. It’s some engine that runs some code that produces some expected outcome. And if you’re lucky and the tool provides something that looks like a DSL such that the scripts are easy and fast to construct then you’ve hit the jackpot.All of this comes to mind as I’m building my own installer DSL. No matter how I parse my work product it looks exactly like the others. It’s just a script being executed by an engine. The script can be embedded into a “solo” executable, pulled from a repository, pushed to an agent, tunneled through SSH and a REST API. The only thing that makes my tool different is that (a) it’s almost 100% cross platform  [Linux, Darwin, Windows] (b) everything that is needed is statically linked (c) automatic self-update (d) scheduling and (e) orchestration, (f) supports the DevOps method. (some of this is vaporware but it’s intended)One thing that causes me to question this tool is that most of my work is targeted for Linux and Darwin. So while Windows support is possible it’s not required. And so my target systems only need some basic sh or bash support in order to deploy some appcode. This is plenty of overkill. I think the sweet-spot is that everything is self contained. Let’s see what happens after my first application is deployed and how it might integrate with a generic Docker container.**Of course the single counter argument is containers and especially the Dockerfile.