Live data from Hacker News

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

github.com

21–30 of 86 posts

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

#21
post #7

Earlier quoted context omitted.

I'd rather more DSLs than more things with complex logic encoded into YAML.

I'd argue that Ansible is using a DSL, just one that happens to be expressed in YAML. I mean, it has loops, conditionals, various forms of subroutines (roles, plays that can be included)... I don't think that using a YAML format rather than being C-shaped makes it any less a DSL.

At that point you should at least use something elegant like s-expressions.

There are so many things I hate about ansible.

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

#22
post #8

Earlier quoted context omitted.

> complex logic encoded into YAML This should stop too.

What's the answer then?

Make packages to describe the state of individual app configurations and version your config files, describe the server state as a set of packages.

Ansible made sense when people were physically provisioning things, no one (sane) runs apps on physically provisioned servers now except people deploying cloud platforms.

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

#25
post #21

Earlier quoted context omitted.

I'd argue that Ansible is using a DSL, just one that happens to be expressed in YAML. I mean, it has loops, conditionals, various forms of subroutines (roles, plays that can be included)... I don't think that using a YAML format rather than being C-shaped makes it any less a DSL.

At that point you should at least use something elegant like s-expressions. There are so many things I hate about ansible.

Could you elaborate on how and why s-expression solve address the issues of yaml-based DSL? Thanks

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

#26
post #21

Earlier quoted context omitted.

At that point you should at least use something elegant like s-expressions. There are so many things I hate about ansible.

Could you elaborate on how and why s-expression solve address the issues of yaml-based DSL? Thanks

[deleted]

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

#27
post #3

Earlier quoted context omitted.

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…

> 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.

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

#28
post #8

Earlier quoted context omitted.

> complex logic encoded into YAML This should stop too.

What's the answer then?

I believe the format/DSL of Homebrew would be excellent for this purpose. In a certain sense, you could actually use it as is: take the formulas you want, add specific configuration, and deployment is just cloning your repository and running install for all your formulas.

Each installation runs in a couple of steps, each of which has a default but can also be configured individually. It has lots of helpers for adding/replacing in configuration files, for testing, for temporary files and cleanup, for patching, and for specifying options. It’s got dependency management built in, etc.

And if (when!) you need more flexibility, you don’t have to learn about the insanity that is a for-loop in YAML, but can use a language that you either already know or should have no trouble understanding, ruby.

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

#29
post #15

Are there any other Ansible alternatives that avoid the whole YAML mess?

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 get it to deploy.

Maybe the problem is that I'm not an ansible professional.

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

#30
post #8

Earlier quoted context omitted.

> complex logic encoded into YAML This should stop too.

What's the answer then?

Applications 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/ ". 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.

Post reply on HN