Show HN: Automation the KISS way. No YAML involved

• tricorder

  5 50 5.6 Rust

  Automation the KISS way

I'd be happy to have some feedback on the source code (as Rust is not my main language) or on what features you'd like to see implemented.

Thank you :)

Link to the Github repository: https://github.com/linkdd/tricorder

• z-run

  3 35 7.3 Go

  z-run -- scripting library lightweight Go-based tool

  

I couldn't agree more with you about Ansible... I've started using Ansible in two projects, and I think it was enough for me... Ansible is perhaps great when you have granular tasks, that maybe don't need to communicate between them, or perhaps that don't have too much logic (or worse loops). However, as soon as your Ansible "scripts" start becoming actual "scripts", everything gets out of hand... (Also the performance is terrible due to the fact that each task is "bundled" on the host, copied remotely, extracted, executed, deleted, repeat for each and every instance of the same task...)

----

Now about your `tricorder`, by looking at the readme, I gather it just allows one to run the same command over multiple hosts (filtered by name or tag), but nothing beyond that? How could one run for example a pipeline of tools on the remote hosts? (I assume `bash -c 'tool-1 | tool-2'`, but with careful escaping?)

Perhaps a first step towards actually being an "Ansible replacement" would be to bring back in some "scripting" ability. For example instead of giving each command as arguments, there could be a "library of scripts", and the user can choose one of those to run on each remote host. Then those scripts could be written in whatever language the user chooses (`bash`, Python, Ruby, etc.)

Also, with regard to the "library of scripts", one thing that Ansible got right is the possibility to put multiple different tasks in the same file, thus one doesn't need 20 files for 20 small tasks, but instead these can be put inside the same YAML file.

----

For example this is how I did it in my own "Ansible replacement", <https://github.com/volution/z-run>, like for example, one can write something like these snippets: <https://github.com/volution/z-run/blob/development/examples/...> (see `ssh / launch / simple` that runs locally which just calls `z-run ssh "${_target}" ':: ssh / remote / main' "${@}"`, which is in itself a non trivial `bash` script, one that will run remotely.)

In the end, what I think we need, is a tool to easily run "scripts" on a remote system, but make it as easy to use as it would be on the local machine. (Sort of like the RPC but across SSH and for scripts.)

• InfluxDB

  www.influxdata.com featured

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

• cheats

  1 71 10.0 Shell

  cheats allows you to create interactive cheat sheets for the command line.

I think that tricorder belongs to that later category and isn't a true library of scripts dispatcher.

[1] https://github.com/lucaswerkmeister/cheats

• automate

  1 7 10.0 Shell

  Native bash script for automate tasks in a multiple servers (by byjg)

> For example instead of giving each command as arguments, there could be a "library of scripts", and the user can choose one of those to run on each remote host. Then those scripts could be written in whatever language the user chooses (`bash`, Python, Ruby, etc.)

For running scripts from a library, I've used ByJG's automate.sh[1] that call'em recipes. Unlike z-run, they're bash only and there's no select menu and looks simpler.

[1] https://github.com/byjg/automate

• ocurrent

  2 135 7.1 OCaml

  Keeps things up-to-date (a CI/CD pipeline OCaml eDSL)

  

Keep working on this. It’s a splendid idea. Would be cool to eventually have a recipe where you import the crate, then program the deploy in rust, invoking your tool which builds my-build.rs, or a proper cargo build.

The following not true apples to apples, but pretty close. Rather than another crummy stringy DSL, the ocaml community said “we want to program our CI pipelines in OCaml”. So, they created https://github.com/ocurrent/ocurrent. You build your pipeline in an incredible language—then the CI server simply invokes your pipeline code, assuming you’ve implemented a basic interface.

• SaaSHub

  www.saashub.com featured

  SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

  

Suggest a related project