Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

71–80 of 86 posts

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

#71

Post by wwright »

nightfly wrote: post #20
yjftsjthsd-h wrote: post #18

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.

The YAML syntax is awful for expressing those constructs though. It might be a DSL, but it's a very awkward one.

It can read pretty comparably to other languages, IMO

    # Write each item in the list to a file
    for ITEM in $LIST; do
      # …
    done

    - name: Write all items to individual files
      for_each: list
      do:
        # …

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

#72

Post by q3k »

divbzero wrote: post #19
decasia wrote: 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.

Ansible is not idempotent, unless you implement that idempotency yourself in its awkward little YAML ecosystem.

Example: V1 of a playbook installs htop. V2 doesn't. Now, a machine that went through V1 then V2 has a different state than a machine that just went through V2. Of course, you can make V2 explicitly uninstall htop - but that's a hack, and while it's easy for this particular example it sucks for real life problems. And even if you implement explicit 'clean up after previous versions', then you have to manage those as well, figure out how long to keep them, make sure they don't have side effects on other machines (maybe something else installed htop and actually needs it?), etc.

If you want idempotency, try NixOS.

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

#73

Post by wwright »

hinkley wrote: post #17
SteveNuts wrote: post #9

Earlier quoted context omitted.

What's the answer then?

Pulumi is the only imperative one I know about, but I can't really opine on any of them. Except... When we find a new problem, we solve it the way we always solve things. And we like to solve things with tons of impenetrable abstraction. We hardly care about legibility of stack traces let alone ease of tracing through the code. I'm sure 24-year-old me would disagree with this, but I think there's a qualitative differ…

I think a good analogy may be tests vs type systems, especially if you think about new vs old type systems.

Traditional deployments are just like traditional unit tests. All imperative, easy enough to work with, all useful, but if you don’t have good discipline it’s still really easy to sneak past them (ie, writing a test that doesn’t really test anything).

Some traditional DSLs like Puppet are like the type system in a language like C. It wants to help you declare invariants and validate them statically, but it kind of just sucks at it, and you still need a lot of discipline. And now you also need to be aware of your type system pitfalls. (Still better than no type system, though.)

I think what people want out of DSLs (and what others have mentioned in this thread) is something like a high-end modern type system like Idris: the ability to put useful, sensible invariants into your scripts and have them usefully validated. Now, like Idris, we probably won’t reach Nirvana on that for a while. (Stateful databases can throw a wrench in things, for example.) But for a lot of tasks, I think we are starting to know enough in general programming language theory as well as systems design that, as a culture, we can solve 80% of these problems with a really high level of reliability soon.

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

#74

Post by CraneWorm »

StreamBright wrote: post #65
seemslegit wrote: post #5

Bash should be recognized as the tech equivalent of asbestos.

Not only Bash but everything that is not compiled. The amount of grief interpreted languages introduced is outrageous.

Compilation does not guarantee neither readability nor ease of maintenance.

Interpreted languages typically give you a very quick feedback loop; they're great fit with scripts and utilities that you won't ever write UT for.

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

#77

Post by peterwwillis »

lima wrote: post #67
SteveNuts wrote: post #9

Earlier quoted context omitted.

What's the answer then?

A declarative configuration that specifies deployment state, using a powerful language like Cue[1], and a reconcilation mechanism - written in a real programming language - that ensures that real state matches declared state (like k8s). The Ansible/Puppet/Chef/... approach of establishing and then haphazardly poking at highly stateful server state is fundamentally flawed. Top-tier systems engineering organizations li…

Replace "language" with "standard interface/protocol", and replace "programming language based reconciliation method" with "standard interfaces for managing infrastructure and network service components", and I agree.

"One-size-and-tool-fits-all" solutions will never work for everyone. But if you standardize the operations, and the language for communicating operations in between components, and then let anyone implement any one of these parts in a platform agnostic way - including kernels, SDNs, hypervisors, storage, processing, etc - then you have platform independent ways of managing state.

At that point state will be important but trivial, the way state in a TCP connection is trivial. We care what the state is, but every component in the network can interact with the state in a standard way, to the point that nobody tears their hair out about "oh no the network protocols are sending state everywhere!!!" If any tool can read and understand the same state in the same way, any tool can manage it (meaning multiple tools managed by multiple people). That's how network protocols work; let's just extend the model into general computing.

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

#78

Post by StreamBright »

CraneWorm wrote: post #74
StreamBright wrote: post #65

Earlier quoted context omitted.

Not only Bash but everything that is not compiled. The amount of grief interpreted languages introduced is outrageous.

Compilation does not guarantee neither readability nor ease of maintenance. Interpreted languages typically give you a very quick feedback loop; they're great fit with scripts and utilities that you won't ever write UT for.

And I did not claim any of those. Btw. a typical feedback loop for many of the compiled languages is 100ms (for example ReasonML).

My main problem with interpreted languages is the duality of their implementation. Especially Python suffers from this, the high-performance part of the language is in C, C++, Fortran. When you install a package you get all of the problems of those languages on the top the Python problems (versions, environments, installed libraries, etc.).

What I would like to have is the Rust way, compile the code on any platform and target any other platform, configuring even the libc that you want to use. OcaML also works very nicely, compiling the code to native or byte code.

I think the detour to interpreted languages set us back in the long run.

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

#79

Post by akavel »

pas wrote: post #62
akavel wrote: post #61

Earlier quoted context omitted.

"cdist is written in Python" - that's a significant difference

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

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

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

#80

Post by Arnavion »

q3k wrote: post #72
divbzero wrote: post #19

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.

Ansible is not idempotent, unless you implement that idempotency yourself in its awkward little YAML ecosystem. Example: V1 of a playbook installs htop. V2 doesn't. Now, a machine that went through V1 then V2 has a different state than a machine that just went through V2. Of course, you can make V2 explicitly uninstall htop - but that's a hack, and while it's easy for this particular example it sucks for real life pr…

>Example: V1 of a playbook installs htop. V2 doesn't. Now, a machine that went through V1 then V2 has a different state than a machine that just went through V2.

This has nothing to do with idempotence. Idempotence means you can apply the same action more than once, and all applications after the first are no-ops. In Ansible's case, that applies to its tasks; eg if you run a task that starts a service but the service is already started, the task simply succeeds without any other effect, as opposed to failing or some other behavior.

Post reply on HN