Live data from Hacker News

Bashible: An Ansible-inspired deployment/automation tool written in Bash DSL

github.com

31–40 of 86 posts

Re: Bashible: An Ansible-inspired deployment/automation tool written in Bash DSL

#31
post #12

Portability is pretty important in the deployment/automation space and it's hard to beat bash in that capacity. It just sucks that bash sucks so much.

Ansible already is pretty portable/flexible on target systems (the joys of being agentless and working mostly over SSH). You tend to need python and sometimes some specific modules (python-apt, for instance) on the target, but that's hardly a burden.

I think the Ansible modules can be executable binaries as well. I have heard of modules written in go.

Re: Bashible: An Ansible-inspired deployment/automation tool written in Bash DSL

#33

Earlier quoted context omitted.

Idempotency and reusability are what I like about Ansible. YAML is a dependency I could do without. Maybe what we need is a set of CLI commands that mirror Ansible modules in performing idempotent operations through SSH and APIs.

Is ansible really reusible? We had an ansible deploy for bringing up MySQL database. I stopped using the codebase and came back to it months later; and I spent two days trying to get it to work (it was an unholy combination of local and community yaml) and eventually just rewrote the damn thing as a bare sequence on literal MySQL (in 20 minutes I might add) and disabled verification - definitely worst practices - to…

Ansible roles solve that. It's a way of organizing tasks in a way where you can use them from other playbooks and supply the configuration parameters for it.

And yes, there are public roles for bringing up MySQL, here's one of the more popular:

https://galaxy.ansible.com/geerlingguy/mysql

Re: Bashible: An Ansible-inspired deployment/automation tool written in Bash DSL

#34

Earlier quoted context omitted.

> it's available everywhere (even openwrt routers and those things) BASH itself? Or a Bourne-family shell? I thought most embedded systems were shipping busybox's ash as /bin/sh

Most *nix server and cloud nodes use bash for the shell. You're right about embedded systems but they're not usually the target platform for a config management system like this one or Ansible.

Yeah, I was mostly thrown by the reference to openwrt. I'm sure most/all GNU/Linux systems ship BASH.

Re: Bashible: An Ansible-inspired deployment/automation tool written in Bash DSL

#35

Earlier quoted context omitted.

Ansible already is pretty portable/flexible on target systems (the joys of being agentless and working mostly over SSH). You tend to need python and sometimes some specific modules (python-apt, for instance) on the target, but that's hardly a burden.

I think the Ansible modules can be executable binaries as well. I have heard of modules written in go.

Having written Ansible modules in POSIX sh, I can assure you that this is absolutely the case:) Internally, Ansible modules are just normal executables that expect a very specific set of parameters and return a very specific JSON-encoded format. I believe there's also a newer pure-Python API, but I ignored it after realizing that it was much easier to just use the old one. (... and, of course, I really enjoyed the notion of writing a module in shell)

Re: Bashible: An Ansible-inspired deployment/automation tool written in Bash DSL

#36

Earlier quoted context omitted.

Idempotency and reusability are what I like about Ansible. YAML is a dependency I could do without. Maybe what we need is a set of CLI commands that mirror Ansible modules in performing idempotent operations through SSH and APIs.

Is ansible really reusible? We had an ansible deploy for bringing up MySQL database. I stopped using the codebase and came back to it months later; and I spent two days trying to get it to work (it was an unholy combination of local and community yaml) and eventually just rewrote the damn thing as a bare sequence on literal MySQL (in 20 minutes I might add) and disabled verification - definitely worst practices - to…

Some of that could be due to versioning... Ansible's releases always have breaking changes, so you can get into trouble if your setup is vastly different from when the playbooks were created. I think this is part of the point of a dedicated control machine, but unfortunately the documentation (last I checked) seems to neglect the importance of it.

Along the same lines, there are also .cfg files and roles that can live outside the root directory.

I've been able to get decent reusability out of roles, but that's mostly because I can live with my servers all being deployed the same way (e.g. they all have the same nginx config with minimal customization points and share the same certificates).

Re: Bashible: An Ansible-inspired deployment/automation tool written in Bash DSL

#37

Earlier quoted context omitted.

Most *nix server and cloud nodes use bash for the shell. You're right about embedded systems but they're not usually the target platform for a config management system like this one or Ansible.

Yeah, I was mostly thrown by the reference to openwrt. I'm sure most/all GNU /Linux systems ship BASH.

Debian ship's dash for /bin/sh doesn't it?

Re: Bashible: An Ansible-inspired deployment/automation tool written in Bash DSL

#38
post #37

Earlier quoted context omitted.

Yeah, I was mostly thrown by the reference to openwrt. I'm sure most/all GNU /Linux systems ship BASH.

Debian ship's dash for /bin/sh doesn't it?

but also ships bash for interactive use, so #!/bin/bash will just work, which you should be doing anyways in scripts that want bash.

Re: Bashible: An Ansible-inspired deployment/automation tool written in Bash DSL

#39
post #3

I’m surprised there’s no explanation of why Bash was chosen for this.

I'd imagine it's because it's available everywhere (even openwrt routers and those things), and it's easier to get away with not having to use sudo (depending on the task you are doing, of course). With Ansible, you almost always need python installed on the target host. Which, in 95% of cases is not a problem. It's not ideal to install a system package just because you want to do some provisioning (there are ways ar…

In my experience, Perl is available everywhere. Some sort of bourne shell is likely available everywhere, but Perl is a safe bet. (EDIT: actually, some systems have recently started removing Perl from their base I hear... Fedora?)

Re: Bashible: An Ansible-inspired deployment/automation tool written in Bash DSL

#40
post #38
post #37

Earlier quoted context omitted.

Debian ship's dash for /bin/sh doesn't it?

but also ships bash for interactive use, so #!/bin/bash will just work, which you should be doing anyways in scripts that want bash.

/usr/bin/env bash?
Post reply on HN