Unobin means one binary. It's a tool for cloud automation inspired by Ansible, but unlike Ansible, an unobin playbook compiles to a standalone binary.
First get unobin:
GO111MODULE=on go get -u github.com/cloudboss/unobin/unobin
To start a new playbook project, you will use the unobin init command. Unobin playbooks compile to go, so in addition to giving the project a name, you will also need to give it a Go import path. This is usually the name of the Git repository where you will host the project.
Start the project, giving it the project name with -p and Go import path with -i:
unobin init -p myplaybook -i github.com/cloudboss/myplaybook
Now you will have a directory created with the project name, containing an example playbook playbook.ub, a Go module definition go.mod, and a resources directory containing a template. Change to the project directory and compile:
cd myplaybook
unobin compile -p playbook.ub
Now there will be an executable called playbook with the contents of resources compiled into it. To run the playbook, you need some input variables. These are written in JSON. For the example playbook you only need one variable called name:
echo '{"name": "MyName"}' > vars.json
./playbook apply -v vars.json
An unobin playbook includes the runtime. It's like having Python, Ansible, and all dependencies included in the playbook itself.
All playbooks have the same command line arguments with automatically generated help. If you know how to run one, you know how to run all of them.
The goal is: if it works on my machine, then it works on your machine. You don't need to do extra steps or install anything before you can run a playbook. Just download the binary and run it.
No, not that kind of serverless. It means unobin playbooks don't need to connect to a server or run from a control node. You run a playbook where you need it, whether from CI/CD or an individual machine that runs it to configure itself. The only "server" you need is for storage to host the playbook binary; use Artifactory, Nexus, a cloud storage bucket, or bake it into an image so it's already there when your machines boot.
There is one source for input variables: they are passed in as an argument to the playbook. Unlike Ansible, there are no levels of precedence for variables.
There is only one pass through the playbook. There are no lookup plugins to run at a different time from the task where they are called. In unobin, "lookups" are just ordinary tasks that produce output. The templating language is minimal, may only be used for task arguments, and is evaluated at the beginning of each task's execution.
All playbooks validate their input variables against a schema. The playbook will only run if the inputs pass validation.
| Unobin | Ansible | Chef | |
|---|---|---|---|
| No server | ✓ | ||
| Local mode | ✓ | optional | ✓ |
| Syntax | Unobin | YAML+Jinja2 | Ruby |
| Works on my machine | ✓ | maybe | maybe |
| Works on your machine | ✓ | maybe | maybe |