10 ms·
Bashible: An Ansible-inspired deployment/automation tool written in Bash DSL
- travbrack 7y agoI’m surprised there’s no explanation of why Bash was chosen for this.
- _frkl 7y agoI'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 around that, but it gets hacky pretty quick...). I haven't looked at this yet, but I really like the idea. Always wanted to have something like this for a few special cases. And if it's well designed, it could be a nice, lightweight and portable solution to do server provisioning, development project setups, use in Docker builds, etc.
- yjftsjthsd-h 7y ago> 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
- travbrack 7y agoMost *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.
- yjftsjthsd-h 7y agoYeah, I was mostly thrown by the reference to openwrt. I'm sure most/all GNU/Linux systems ship BASH.
- toraobo 7y agoIt's common even for embedded systems which use busybox to provide /bin/bash because bash itself is not that large.
- senorsmile 7y agoIn 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?)
- pfundstein 7y agoNeither are available on common small embedded systems that rely 90% on busybox.
- _frkl 7y agoExciting, very nice idea, I'll keep my eyes on this. It happened more than once that I had need for something like this, and I stewed over how to implement it for quite a while now. Haven't looked at it in detail yet, but from a first glance it looks well thought through.
- seemslegit 7y agoBash should be recognized as the tech equivalent of asbestos.
- digitalsushi 7y agoA fair analogy, given how much money I have made as someone who is willing to deal with metaphorical asbestos.
- akiselev 7y agoThe question is, were you the one cleaning up the metaphorical asbestos or creating it? :) There's plenty of money to be made in both.
- kohtatsu 7y agoY'all just have bias against the string system. Writing decent code in bash is just as possible as any other language. I stick to POSIX sh but same difference.
- unixhero 7y agoWhy POSIX sh? Bash is everywhere. I once in my career had access to and needed jobs performed on a mainframe with AIX running. It had bash, it had ruby, it had day, it had fish shell. I couldn't and can't understand why people insist on asceticism (Korn shell, POSIX sh) when nicer options are available.
- kohtatsu 7y agoEh, I simply don't need bash. Every few dozen scripts or so I'll change the shebang to bash to have more than 1 array, but other than that I seldom pine anything that it has to offer. I believe it's a bloated mess along with most GNU utils, so avoiding it is partially out of spite, but I wouldn't impair my code to do so.
- m4r35n357 7y agodash is 10% of the size of bash. You don't need the interactive features when running shell scripts, and the few "extra" features are pretty crap anyway (arrays? yeah right).
- zenlot 7y agoNo more DSLs for deployment/config management tasks please. Too many already.
- nightfly 7y agoI'd rather more DSLs than more things with complex logic encoded into YAML.
- zenlot 7y ago> complex logic encoded into YAML This should stop too.
- SteveNuts 7y agoWhat's the answer then?
- dijit 7y agoTerraform, I guess. But that is it's own nightmare.
- yjftsjthsd-h 7y agoTerraform is just back to "quirky DSL", though
- peterwwillis 7y agoApplications with features for user stories. AWS CLI is a very useful tool, because it can do simple things with AWS. In order to do more complex things, usually you have to "script" multiple commands together or write a Boto script in Python. But if the tool just came with those complex things already pre-designed as a feature, we wouldn't have to script it, it would be more reliable, easier, simpler, and nobody would need to bang their head against a DSL to get the functionality. Nearly everyone on AWS who has wanted to try Fargate could use the following function: "Build me an ECS cluster, create everything I need for it (a VPC, security groups, etc), create an ECR registry, upload this Docker container to the registry, create me a Fargate service with tasks for the thing I uploaded to ECR, create one ALB for the cluster, add target group forwarding rules for each Fargate service in the cluster, and manage everything in Route53, including domain and certs". Now, you could spend hours/days trying to set up Terraform or Ansible to do all of that, or script it with Bash or Python in a few hours. Or you could run something like "aws ecs user-story fargate-apps --cluster-name foo --service-container docker-image:latest --service-name some-img-name:latest --service-url https://my.custom.domain/some-img-name/ https://my.custom.domain/some-img-name/ ". No DSL. No plugins. No cobbling together 100 lego pieces and reading 200 pages of documentation. No scripting. It's a very common user story, and the AWS CLI already has literally all of the functionality you would need. But that won't happen, because the IT industry is purposely designed to be unnecessarily inefficient, complex, and expensive. If a tool like AWS CLI or Terraform just bundled this user story natively without you having to "compose" it like a DSL, the companies that produce them wouldn't make as much money, and could potentially incur more cost through the maintenance of it. An open-source community could support it, but it'd mostly be written by engineers of private companies, and companies are pathologically terrified of releasing any intellectual property without lawyers and contracts and CLAs and so on. Literally half of the reason my job exists at all is that nobody has yet bothered to release the cobbled-together lego components of an enterprise organization under the public domain.
- klysm 7y agoPortability 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.
- yjftsjthsd-h 7y agoAnsible 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.
- gautamdivgi 7y agoI think the Ansible modules can be executable binaries as well. I have heard of modules written in go.
- yjftsjthsd-h 7y agoHaving 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)
- stevekemp 7y agoAgreed. Ansible works, but it works so very slowly because it zips and transfers scripts/binaries over to the remote host without caching. I hacked up a simple system, in golang, which uses and SSH connection to run commands and transfer files. Of course I simplified the problem to only really uploading files, running commands, and simple template expansion. For a lot of services where you just need to download a binary and configure a config-file it works well but it's nowhere near as useful as Ansible's module system: https://github.com/skx/deployr/ https://github.com/skx/deployr/
- 7y ago
- decasia 7y agoAre there any other Ansible alternatives that avoid the whole YAML mess?
- divbzero 7y agoIdempotency 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.
- dnautics 7y agoIs 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 get it to deploy. Maybe the problem is that I'm not an ansible professional.
- athenot 7y agoAnsible 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 https://galaxy.ansible.com/geerlingguy/mysql
- rmrfrmrf 7y agoSome 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).
- AzzieElbab 7y agoFull circle DevOps. Nice :)
- bschwindHN 7y agoI would never trust my infrastructure management to a system of bash scripts. It's like wiring up an airplane with paper clips and hot glue. And looking at the commit history...this doesn't look like a well managed project. Almost every commit is "fix" "fix" "fix" with errors that would have been caught in a better language. It's probably also incompatible with the various versions of bash out there, as evidenced by the TODO: > Bashible uses GNU/grep, GNU/sed and other programs which may not work properly on all platforms I'm sorry, but this looks like a nightmare in the making for any team that tries to use it.
- nicey 7y agoNIH If you are looking for a DSL that uses shell: https://www.cdi.st/cdist-why.html https://www.cdi.st/cdist-why.html It's already mature and used in production at various places/datacenters.
- akavel 7y ago"cdist is written in Python" - that's a significant difference
- pas 7y agoIn my experience, Python is just as brittle, because it just as much lacks static checking. (Though of course mypy helps with the basics, and there ought to be a test or dry-run mode in every "devops" system, but I have no idea what cdist does.)
- akavel 7y agoUh, so, my thought behind that comment was that writing in bash has an advantage over Python, as no extra runtime environment is required in case of bash... sorry for not being clear enough in the comment, I now see I wrote it too vaguely...
- cfgmaster2 7y agoHow about this? Show HN: Posixcube, a shell script automation framework alternative to Ansible (github.com) https://news.ycombinator.com/item?id=13378852 https://news.ycombinator.com/item?id=13378852