7 ms·

Is there a reasonable refuge for people who are: 1) Sick of YAML-as-a-scripting-language 2) Not on the k8s train yet 3) Fans of operational simplicity, like

Is there a reasonable refuge for people who are: 1) Sick of YAML-as-a-scripting-language 2) Not on the k8s train yet 3) Fans of operational simplicity, like Ansible's (no persistent agent required on the other end, just operates over ordinary SSH, that kind of thing) ?

rr808 4y ago
Old School simple bash script ( < 10 lines). tar.gz files with your whole distribution. extract to a directory with a version on it then rely on a softlink that chooses which version to use.
anotherhue 4y ago
Nixos has some of these benefits. You can do a lot with systemd and containers.
- blueflow 4y ago
  We are currently evaluating nix as an replacement for our internal build system, our main product is some kind of linux distro. Nix has real bad onboarding and documentation, the creators hopped off to some other, shinier side projects (flakes) and the rest of the community is struggling to manage the immense maintenance cost of keeping the packages up-to-date and integrated. And the external consultants we hired for it are like, hardcore believers that always tell you how great nix will be in the future, but completely disregard our needs like building offline in a separated network. Which is officially supported but unusable to due bugs. My bet is that $boss will cancel it this year.
  - VTimofeenko 4y ago
    Disclosure: I love Nix ecosystem, but I acknowledge the fact that it's perfect for my use cases which are very different from those of a business. > Nix has real bad onboarding and documentation Could not agree more. I found that diving into it head first actually did yield good results in the end but it was really not quick. > some other, shinier side projects (flakes) I would argue that flakes are an absolute necessity and logical continuation of the ecosystem development rather than a side project. Flakes allow to truly describe the desired state of the system from one place and properly pin all objects to their places.
  - JamesSwift 4y ago
    What makes you think flakes are a shinier side project? In my opinion, flakes are the One-True-Nix at this point. They simplify a large swath of issues with using Nix, and every day that sees flake adoption improve is a net-win for Nix usage overall.
    - blueflow 4y ago
      "One-True-Nix". Familiar phrase, and we are sick of it. We need our usecases solved, not a new world religion.
      - JamesSwift 4y ago
        Its nothing to do with a world religion, its correcting what I see as a flawed view that flakes are somehow something unrelated to nix and the issues involved with nix, and that time spent on flakes is time wasted from a nix consumer POV. I'm telling you that not only are flakes a main-project for nix developers, but that they serve to completely upend how nix is used. As I said, flakes directly solve several issues of nix-without-flakes. This is a huge benefit for the nix consumer.
  - kaba0 4y ago
    flakes is not a side project, it adds to the nix model, doesn’t supersede it. It is basically a lock file for a package, making it easy for anyone, even a separate repository not related to nixpkgs at all to reproduce said build with compatible versions.
jamespo 4y ago
https://www.rexify.org/ https://www.rexify.org/
- mdaniel 4y ago
  > It's just Perl Thank you, but no
  - mst 4y ago
    It's using perl as a DSL host, effectively. Plus if you haven't written perl using the last five years' or so's best practices, you'll almost certainly have a very confused idea of how the language works out when wielded appropriately. Old style scripting perl easily becomes write only line noise, sure. Sane applications perl is really quite pleasant - and it's pretty much the only common dynamic language that can give you a compile time error if you screw up a variable name (ES6's let has basically the same semantics as perl's my but sadly the errors are still runtime rather than compile time). (one may argue that typescript counts but the experience IMO still isn't the same)
geekthattweaks 4y ago
I've been trying to do more shell scripting. Often it goes quicker than the Ansible writing and is easier to read imho.
- Steltek 4y ago
  Shell scripts have so many nasty edge cases and quirks. Quoting and `find -print0` aren't enough to not get bitten. And doing the equivalent shell work in Python can be kind of exhausting and maybe prone to different errors.
yankcrime 4y ago
https://github.com/purpleidea/mgmt https://github.com/purpleidea/mgmt
- skyfaller 4y ago
  mgmt looks really promising, and I want to try it out, but if their FAQ is up to date, then this is concerning: "Auth hasn't been implemented yet, so you should only use it in trusted environments (not on publicly accessible networks) for now." https://github.com/purpleidea/mgmt/blob/master/docs/faq.md#is-this-project-ready-for-production https://github.com/purpleidea/mgmt/blob/master/docs/faq.md#i... Kind of a non-starter for my use case. I hope they get to a 1.0 release soon.
  - mdaniel 4y ago
    Yeah, it was discussed separately a couple of times (https://news.ycombinator.com/from?site=github.com/purpleidea https://news.ycombinator.com/from?site=github.com/purpleidea) and is just packed full of "this is definitely for a specialized audience" sharp edges
muxneo 4y ago
try chef, puppet or saltstack
- tilolebo 4y ago
  "Operational simplicity" would like to have a word with you.
- _joel 4y ago
  Err, they aren't simple. They're equivalent to ansible in terms of difficulty (I'd say Puppet even more of a headache) having worked with all of them.
  - CoolCold 4y ago
    I'm moving thinking that Ansible is simpler for simple things, but complex for complex things, I find it more and more often in our servers configuration to have "configuration drift" due to fact Ansible encourages to managing by parts, not as whole system. And very rare is run automatically over all nodes say every 15 minutes.
    - encryptluks2 4y ago
      Isn't that the point of things like cloud-init, and other system tools. Ansible may not be great at deploying, but the whole purpose would be to catch the drift using Ansible.
    - _joel 4y ago
      I'm not sure what you mean by parts and not a whole system. It's defined via hosts inventories which, by defintion are a whole system. You obviously include roles and further tasks for those definitions. You'd use cloud-init, as the other poster mentions, to initalise, or use ansible in SSH mode with the inventory coming from your cloud provider or just an ini/YAML list curated by yourself, then run it regularly from something Jenkins/Rundeck/Cron whatever, in which case cloud-init configures your ansible run user and ssh keys so you can kick it off from the main box and perhaps register the node, or use tags in cloud provider, loads of ways.
kirbyfan64sos 4y ago
https://github.com/itamae-kitchen/itamae https://github.com/itamae-kitchen/itamae or its statically-linked, mruby-based counterpart https://github.com/itamae-kitchen/mitamae https://github.com/itamae-kitchen/mitamae
datalopers 4y ago
You could just not do scripting in ansible playbooks and instead leave it as a declarative configuration.
Hackbraten 4y ago
You can move your scripts to Python and have them implement the Ansible module interface. Example: [1] Now all that’s left in your YAML is the declarative part. No more YAML-as-a-scripting language. [1]: https://github.com/ansible/ansible/blob/devel/examples/scripts/my_test.py https://github.com/ansible/ansible/blob/devel/examples/scrip...
- mdaniel 4y ago
  Fun fact, playbook library actions don't have to be in python, they can be in golang or shell or whatever, so long as they accept JSON on the input and emit JSON on the output I believe that's true of all the plugins, I just have personally tried it using actions and haven't for the other pluggable ones
  - bcocaTM 4y ago
    No, all other plugins require to be written in Python (they are imported into the engine), modules are executed externally on the remote and can be in ANY language, scripting or compiled.
  - champtar 4y ago
    And this means that you can use Ansible to manage hosts without python if you reimplement everything you need
shaicoleman 4y ago
pyinfra - https://pyinfra.com/ https://pyinfra.com/
- skyfaller 4y ago
  Could you explain how this is different from Ansible? That webpage says pyinfra is "Integrated with Docker, Vagrant & Ansible out of the box", so I would think the use cases aren't identical, otherwise they wouldn't bother integrating it with tools that do the exact same thing. Can anyone compare pyinfra to these other projects?
  - shaicoleman 4y ago
    The main difference is that pyinfra is a library, so you can use all the power of a general purpose programming language (functions, data structures, variables, modules, loops, conditions, calling APIs, debugging, etc.). Ansible uses YAML configuration files, and basically reinvents and tries to shoehorn a lot of above into YAML. Due to the limitations of YAML, it's extremely verbose, and requires a lot of copy paste, and quickly becomes unmaintainable. Customising and adding functionality is also a lot more difficult and time consuming with Ansible. Ansible is also extremely slow due to the way it works, and can take ages to run even if nothing has changed on the target device. The slow feedback loop and the lack of debugging can make even small changes painful, even on localhost. On remote hosts, it's even worse. pyinfra only has a dependency of a shell on the remote target, where Ansible requires Python. pyinfra cons: smaller community, less modules, doesn't have extensive hardware support (e.g. routers/switches/firewalls). Though usually it's not a big problem, because it's easy enough to add any missing functionality.
- drcongo 4y ago
  Another vote for PyInfra here, I'm actually porting all our Ansible modules over to it right now and it's an absolute joy compared to the mare I had writing the Ansible modules in the first place. I can actually debug things!
Steltek 4y ago
It sounds like you want simple and reliable. Any Ansible-alternative that you find is going to fail your primary requirement because it won't be as widely adopted, documented, and used as Ansible is. I'm not defending YAML but you might be letting perfect be the enemy of the good.
jbverschoor 4y ago
For some projects I just have some shell scripts, and a function which executes remote commands on servers. Work pretty good tbh. But ansible playbooks work fine too. Just don't use anything but hosts-file + a playbook
btmcnellis 4y ago
I'm shocked that no one has said Terraform yet. It has its own declarative DSL, which some people complain about (because people complain about everything), but it works well for what it's intended to do. Providers can be created for anything with an API, from the major cloud providers to k8s to anything else. No agent is required: it just writes state to a file, and then it diffs that file against the actual state every time it runs. (In practice, you'll probably want to put that state in a remote location like an S3 bucket, but that's very easy to do. And if you're the only one using it, you can just save it locally, which is the default behavior.) Depending on your use case for Ansible, it could be a very good fit.
- encryptluks2 4y ago
  Terraform is great for certain tasks, but even they advise against using it for local execution. Whatever you use it for you really need a provider and their module system isn't very intuitive either. Ansible has/had potential, but sucks in a lot of ways too. Unfortunately, as much as I dislike certain aspects, it really is the best generic automation tool available at the moment.
  - mianos 4y ago
    Ansible for very small scale projects. It is not scalable for larger unreliable clusters. You probably need to go to salstack if you need any scale.
    - bcocaTM 4y ago
      Yet people use daily to manage 10k-100k+ servers/devices. The term "scaling" has very different meanings depending on context and how one product scales is very different from another. You could setup a context that favors push vs pull and vice versa, you can also see different products scaling well or not depending on slight variations in context and implementation.
      - mianos 4y ago
        I am highly dubious that it would be possible to manage 100k servers, specially to do interactions with large numbers at a time. The way tower collects results in a thread pool, assuming success, simply does not work at any scale. I tried and tried. I fixed many bugs and got to about 4000 hosts before changing to another platform. If almost every server is reliable, I am sure it would work fine. That is not going to happen at scale.
mejutoco 4y ago
You could use docker-compose and context if you can live with the docker dependency https://www.docker.com/blog/how-to-deploy-on-remote-docker-hosts-with-docker-compose/ https://www.docker.com/blog/how-to-deploy-on-remote-docker-h...
rollcat 4y ago
https://github.com/rollcat/judo https://github.com/rollcat/judo - my side project.
l0b0 4y ago
Nix, CDK, and (to a lesser extent) Puppet are good alternatives, depending on exactly what you're trying to do. Nix is fantastic for reproducibility on individual machines and not borking the rest of the system when used on a non-NixOS distro. CDK is good infra-as-code for AWS. And Puppet is not-as-horrible-as-Ansible and can be used without an agent, despite all the documentation seeming to want you to use it that way.

rr808 4y ago

Old School simple bash script ( < 10 lines). tar.gz files with your whole distribution. extract to a directory with a version on it then rely on a softlink that chooses which version to use.

anotherhue 4y ago

Nixos has some of these benefits. You can do a lot with systemd and containers.

blueflow 4y ago
We are currently evaluating nix as an replacement for our internal build system, our main product is some kind of linux distro. Nix has real bad onboarding and documentation, the creators hopped off to some other, shinier side projects (flakes) and the rest of the community is struggling to manage the immense maintenance cost of keeping the packages up-to-date and integrated. And the external consultants we hired for it are like, hardcore believers that always tell you how great nix will be in the future, but completely disregard our needs like building offline in a separated network. Which is officially supported but unusable to due bugs. My bet is that $boss will cancel it this year.
- VTimofeenko 4y ago
  Disclosure: I love Nix ecosystem, but I acknowledge the fact that it's perfect for my use cases which are very different from those of a business. > Nix has real bad onboarding and documentation Could not agree more. I found that diving into it head first actually did yield good results in the end but it was really not quick. > some other, shinier side projects (flakes) I would argue that flakes are an absolute necessity and logical continuation of the ecosystem development rather than a side project. Flakes allow to truly describe the desired state of the system from one place and properly pin all objects to their places.
- JamesSwift 4y ago
  What makes you think flakes are a shinier side project? In my opinion, flakes are the One-True-Nix at this point. They simplify a large swath of issues with using Nix, and every day that sees flake adoption improve is a net-win for Nix usage overall.
  - blueflow 4y ago
    "One-True-Nix". Familiar phrase, and we are sick of it. We need our usecases solved, not a new world religion.
    - JamesSwift 4y ago
      Its nothing to do with a world religion, its correcting what I see as a flawed view that flakes are somehow something unrelated to nix and the issues involved with nix, and that time spent on flakes is time wasted from a nix consumer POV. I'm telling you that not only are flakes a main-project for nix developers, but that they serve to completely upend how nix is used. As I said, flakes directly solve several issues of nix-without-flakes. This is a huge benefit for the nix consumer.
- kaba0 4y ago
  flakes is not a side project, it adds to the nix model, doesn’t supersede it. It is basically a lock file for a package, making it easy for anyone, even a separate repository not related to nixpkgs at all to reproduce said build with compatible versions.

jamespo 4y ago

https://www.rexify.org/ https://www.rexify.org/

mdaniel 4y ago
> It's just Perl Thank you, but no
- mst 4y ago
  It's using perl as a DSL host, effectively. Plus if you haven't written perl using the last five years' or so's best practices, you'll almost certainly have a very confused idea of how the language works out when wielded appropriately. Old style scripting perl easily becomes write only line noise, sure. Sane applications perl is really quite pleasant - and it's pretty much the only common dynamic language that can give you a compile time error if you screw up a variable name (ES6's let has basically the same semantics as perl's my but sadly the errors are still runtime rather than compile time). (one may argue that typescript counts but the experience IMO still isn't the same)

geekthattweaks 4y ago

I've been trying to do more shell scripting. Often it goes quicker than the Ansible writing and is easier to read imho.

Steltek 4y ago
Shell scripts have so many nasty edge cases and quirks. Quoting and `find -print0` aren't enough to not get bitten. And doing the equivalent shell work in Python can be kind of exhausting and maybe prone to different errors.

yankcrime 4y ago

https://github.com/purpleidea/mgmt https://github.com/purpleidea/mgmt

skyfaller 4y ago
mgmt looks really promising, and I want to try it out, but if their FAQ is up to date, then this is concerning: "Auth hasn't been implemented yet, so you should only use it in trusted environments (not on publicly accessible networks) for now." https://github.com/purpleidea/mgmt/blob/master/docs/faq.md#is-this-project-ready-for-production https://github.com/purpleidea/mgmt/blob/master/docs/faq.md#i... Kind of a non-starter for my use case. I hope they get to a 1.0 release soon.
- mdaniel 4y ago
  Yeah, it was discussed separately a couple of times (https://news.ycombinator.com/from?site=github.com/purpleidea https://news.ycombinator.com/from?site=github.com/purpleidea) and is just packed full of "this is definitely for a specialized audience" sharp edges

muxneo 4y ago

try chef, puppet or saltstack

tilolebo 4y ago
"Operational simplicity" would like to have a word with you.
_joel 4y ago
Err, they aren't simple. They're equivalent to ansible in terms of difficulty (I'd say Puppet even more of a headache) having worked with all of them.
- CoolCold 4y ago
  I'm moving thinking that Ansible is simpler for simple things, but complex for complex things, I find it more and more often in our servers configuration to have "configuration drift" due to fact Ansible encourages to managing by parts, not as whole system. And very rare is run automatically over all nodes say every 15 minutes.
  - encryptluks2 4y ago
    Isn't that the point of things like cloud-init, and other system tools. Ansible may not be great at deploying, but the whole purpose would be to catch the drift using Ansible.
  - _joel 4y ago
    I'm not sure what you mean by parts and not a whole system. It's defined via hosts inventories which, by defintion are a whole system. You obviously include roles and further tasks for those definitions. You'd use cloud-init, as the other poster mentions, to initalise, or use ansible in SSH mode with the inventory coming from your cloud provider or just an ini/YAML list curated by yourself, then run it regularly from something Jenkins/Rundeck/Cron whatever, in which case cloud-init configures your ansible run user and ssh keys so you can kick it off from the main box and perhaps register the node, or use tags in cloud provider, loads of ways.

kirbyfan64sos 4y ago

https://github.com/itamae-kitchen/itamae https://github.com/itamae-kitchen/itamae or its statically-linked, mruby-based counterpart https://github.com/itamae-kitchen/mitamae https://github.com/itamae-kitchen/mitamae

datalopers 4y ago

You could just not do scripting in ansible playbooks and instead leave it as a declarative configuration.

Hackbraten 4y ago

You can move your scripts to Python and have them implement the Ansible module interface. Example: [1] Now all that’s left in your YAML is the declarative part. No more YAML-as-a-scripting language. [1]: https://github.com/ansible/ansible/blob/devel/examples/scripts/my_test.py https://github.com/ansible/ansible/blob/devel/examples/scrip...

mdaniel 4y ago
Fun fact, playbook library actions don't have to be in python, they can be in golang or shell or whatever, so long as they accept JSON on the input and emit JSON on the output I believe that's true of all the plugins, I just have personally tried it using actions and haven't for the other pluggable ones
- bcocaTM 4y ago
  No, all other plugins require to be written in Python (they are imported into the engine), modules are executed externally on the remote and can be in ANY language, scripting or compiled.
- champtar 4y ago
  And this means that you can use Ansible to manage hosts without python if you reimplement everything you need

shaicoleman 4y ago

pyinfra - https://pyinfra.com/ https://pyinfra.com/

skyfaller 4y ago
Could you explain how this is different from Ansible? That webpage says pyinfra is "Integrated with Docker, Vagrant & Ansible out of the box", so I would think the use cases aren't identical, otherwise they wouldn't bother integrating it with tools that do the exact same thing. Can anyone compare pyinfra to these other projects?
- shaicoleman 4y ago
  The main difference is that pyinfra is a library, so you can use all the power of a general purpose programming language (functions, data structures, variables, modules, loops, conditions, calling APIs, debugging, etc.). Ansible uses YAML configuration files, and basically reinvents and tries to shoehorn a lot of above into YAML. Due to the limitations of YAML, it's extremely verbose, and requires a lot of copy paste, and quickly becomes unmaintainable. Customising and adding functionality is also a lot more difficult and time consuming with Ansible. Ansible is also extremely slow due to the way it works, and can take ages to run even if nothing has changed on the target device. The slow feedback loop and the lack of debugging can make even small changes painful, even on localhost. On remote hosts, it's even worse. pyinfra only has a dependency of a shell on the remote target, where Ansible requires Python. pyinfra cons: smaller community, less modules, doesn't have extensive hardware support (e.g. routers/switches/firewalls). Though usually it's not a big problem, because it's easy enough to add any missing functionality.
drcongo 4y ago
Another vote for PyInfra here, I'm actually porting all our Ansible modules over to it right now and it's an absolute joy compared to the mare I had writing the Ansible modules in the first place. I can actually debug things!

Steltek 4y ago

It sounds like you want simple and reliable. Any Ansible-alternative that you find is going to fail your primary requirement because it won't be as widely adopted, documented, and used as Ansible is. I'm not defending YAML but you might be letting perfect be the enemy of the good.

jbverschoor 4y ago

For some projects I just have some shell scripts, and a function which executes remote commands on servers. Work pretty good tbh. But ansible playbooks work fine too. Just don't use anything but hosts-file + a playbook

btmcnellis 4y ago

I'm shocked that no one has said Terraform yet. It has its own declarative DSL, which some people complain about (because people complain about everything), but it works well for what it's intended to do. Providers can be created for anything with an API, from the major cloud providers to k8s to anything else. No agent is required: it just writes state to a file, and then it diffs that file against the actual state every time it runs. (In practice, you'll probably want to put that state in a remote location like an S3 bucket, but that's very easy to do. And if you're the only one using it, you can just save it locally, which is the default behavior.) Depending on your use case for Ansible, it could be a very good fit.

encryptluks2 4y ago
Terraform is great for certain tasks, but even they advise against using it for local execution. Whatever you use it for you really need a provider and their module system isn't very intuitive either. Ansible has/had potential, but sucks in a lot of ways too. Unfortunately, as much as I dislike certain aspects, it really is the best generic automation tool available at the moment.
- mianos 4y ago
  Ansible for very small scale projects. It is not scalable for larger unreliable clusters. You probably need to go to salstack if you need any scale.
  - bcocaTM 4y ago
    Yet people use daily to manage 10k-100k+ servers/devices. The term "scaling" has very different meanings depending on context and how one product scales is very different from another. You could setup a context that favors push vs pull and vice versa, you can also see different products scaling well or not depending on slight variations in context and implementation.
    - mianos 4y ago
      I am highly dubious that it would be possible to manage 100k servers, specially to do interactions with large numbers at a time. The way tower collects results in a thread pool, assuming success, simply does not work at any scale. I tried and tried. I fixed many bugs and got to about 4000 hosts before changing to another platform. If almost every server is reliable, I am sure it would work fine. That is not going to happen at scale.

mejutoco 4y ago

You could use docker-compose and context if you can live with the docker dependency https://www.docker.com/blog/how-to-deploy-on-remote-docker-hosts-with-docker-compose/ https://www.docker.com/blog/how-to-deploy-on-remote-docker-h...

rollcat 4y ago

https://github.com/rollcat/judo https://github.com/rollcat/judo - my side project.

l0b0 4y ago

Nix, CDK, and (to a lesser extent) Puppet are good alternatives, depending on exactly what you're trying to do. Nix is fantastic for reproducibility on individual machines and not borking the rest of the system when used on a non-NixOS distro. CDK is good infra-as-code for AWS. And Puppet is not-as-horrible-as-Ansible and can be used without an agent, despite all the documentation seeming to want you to use it that way.