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)
?
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/scrip...
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
"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#i...
Kind of a non-starter for my use case. I hope they get to a 1.0 release soon.
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.
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.
If almost every server is reliable, I am sure it would work fine. That is not going to happen at scale.
It's another tool pretending to be declarative.
I appreciate that "the map is not the terrain," and that "plan" is speculating about a future configuration of the world, but come on -- if "terraform plan" is going to require _live credentials_ to run, and then only use those to enumerate the active regions, what are we even doing here?!
Tform started off as a cool idea with good principles and over time has morphed into a shitty scripting language for managing multi cloud infra without clickops.
It's like a game of telephone were every new participant in the chain is one more place to have "let me help you" turn into "what the hell was that?"
1 = and that's not even getting into the tire fire of the providers being either some Internet rando or an already overloaded team trying to have PRs make it through and out to release. I believe the the recent "we're not reviewing PRs anymore, exhausted" was just scoped to the hashicorp/terraform repo specifically, but it could very easily also apply to every code-gen shim that sits between TF and the underlying cloud SDK
Can anyone compare pyinfra to these other projects?
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.
Thank you, but no
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)
https://www.docker.com/blog/how-to-deploy-on-remote-docker-h...
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.
> 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.
But ansible playbooks work fine too. Just don't use anything but hosts-file + a playbook
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.
each of them configuring only subpart of the whole system. Some of them may have intercrossing functions, like changing sysctls. Thus, it's enforcing state of subset of services, and if, for example after Nginx playbook you logically need to run Monitoring playbook, it can be forgotten/skipped -> configuration drift grows.
Hope it clarifies.