Ansible 2.13
github.com
github.com
For example, "ansible 5.7.1" is actually this: https://github.com/ansible-community/ansible-build-data/blob... which includes "ansible" 2.12.5
It makes even talking about it hard
The first time someone had to create a GH release named "these are not the releases you're looking for" would have been a great opportunity to acknowledge how off the rails things had gone: https://github.com/ansible/ansible/releases/tag/v2.2.1.0-0.3...
Related to that, I consider it almost purposefully misleading of them to leave the PyPI "source" link pointed at GH/ansible/ansible since that is _for sure_ not what is going to be pip installed for those version numbers. It'd be like pointing the ansible PyPI at the Jinja2 GH repo -- yes, that is one of the things that pip installing will put on disk, but where did the rest of it come from?
https://github.com/rollcat/judo#passing-arguments-to-scripts implies that project is for sure not for me, but I wish you all the best with it!
That's one of the design decisions, there should ideally be only one "obvious" way of achieving a certain goal. Per-invocation parameters can already be passed via environment variables ("-e FOO" to pass from your local environment; "-e BAR=42" to set explicitly); I'm also considering using envdir (or a similar scheme) to set per-host parameters (https://github.com/rollcat/judo/issues/11).
I could allow specifying command line arguments somehow with the -s flag, but that would complicate parsing, quoting/unquoting, etc. I would have to teach the user about quoting rules, and probably shoot myself in the foot at least once in the process. I try to actively avoid creating hard problems by solving an equivalent, easier problem.
If this is not clear from the readme, I'll take this as a bug report, and try to improve the readme :)
But, "looking at the sources" is now extremely complicated since the "user" reports "I installed ansible==5.7.1" -- so which URL do I go to in order to see why "{{ lookup('something') }}" has IndexError-ed?
I cheated in asking you that, since it depends on what "something" is in that stanza, given that "{{ lookup('ini') }}" is hosted at https://github.com/ansible/ansible/blob/v2.12.5/lib/ansible/... but "{{ lookup('dig') }}" lives in https://github.com/ansible-collections/community.general/blo... and to even get that number, I had to go sniffing in "lib/python3.10/site-packages/ansible_collections/community/general/MANIFEST.json" to know
The root of this problem is whether pip is an end user's package manager, where a meta package makes sense, or is it a developer's tool, where you want to manage finer grained dependencies?
I’m a fan of Ansible in general and this is not a world-ending mistake, but should be corrected to avoid confusion.
This is why language specific tools always gave me pause. It's focused on supporting the language and not the end user. I can't happily install programs from an array of languages anymore using a single common tool anymore. I have all this annoying overhead to memorize instead:
- Mapping which program comes from what language
- How to install things using that language's package/dependency manager
- How to access those programs, if they aren't installed to a common location
- How to keep everything up to date
I used "pip install" because it was shorthand, but the problem manifests with "brew install ansible" also since at this moment it says "5.7.1" but with a totally wrong `head "https://github.com/ansible/ansible.git", branch: "devel"`
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)
?
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)
"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.
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.
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.
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
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.
But ansible playbooks work fine too. Just don't use anything but hosts-file + a playbook
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
https://www.docker.com/blog/how-to-deploy-on-remote-docker-h...
I recently re-wrote the infrastructure setup of a startup. They had a Chef infra-as-code before, written for CentOS 7. Since CentOS is dead, and I took the opportunity to move to Debian, it wasn't worth it to keep working with Chef so I re-wrote in Ansible.
And it was fantastic. Maybe because Chef is so awful and convoluted my reference point is skewed. But I loved every moment.
It was simple, the documentation is great, the extended packaged are great (I set up an highly available redis sentinel infra with one ansible-galaxy import and ~20 lines playbook).
Yeah, Kubernetes and Docker are the cool kids. But Ansible is killing it if you still live in a world of VMs.
It's the small things. Why do I have to write more than one task and register intermediate variables if I want to execute a command and see its output?
# EDIT: people pointed out that running ansible with additional -v's will indeed print commands. I don't understand how'd I missed that... I've certainly run ansible with -v a lot.
And my favorite part of SaltStack is that you can use jinja in any place of your states
(though it's indeed a questionable approach)
Yes, it's the little things we need to understand, else we'll be confused by false enumeration. Ansible excells at ensuring one (idempotent) task is indeed just one task. Try the '-v' flag for the verbosity you're looking for from one task, as it's intentionally hidden from the default output.
Thank you for the "-v". I've run ansible with various amounts of -v in the past but I didn't notice that it does display stdout_lines with it!
Anyone can write a working playbook and put it in some git repo. If you are not actively fighting against it, you might end up with several git repos, hundreds of playbooks and no way to easy understand what code applies to what servers.
Configuration management solutions that feature agent on managed machines and don't do everything over SSH encourage people to organize their efforts in one repo. Because you cannot manually apply your config to server without pushing it to git.
For work related use cases, I find it very unlikely you would ever pull in a git repo or playbook from galaxy. Coming from Puppet, Chef I always thought Puppet was in a bad state but then I realized it is 2022 and Ansible has exactly zero roles for LDAP that work, or even resemble a thing that would ever make sense to run in a real installation.
Also, if we're talking about what code would run on which server, I do not see where other configuration management tools would perform better. Have you seen the humongous mess one needs to do in Puppet and Hiera when one wants to build a configuration that is multi-os and multi-arch (like just a simple Debian/Ubuntu plus x86_64/aarch scenario not even Windows)? Or even what it would be like if one also manages firmware blobs there?
If I may be so frank... configuration management is a shit show on every available solution. And I am saying that as someone actively being a part of these ecosystems and contributing.
Like you said, it's the small things. The thing that annoys me most are probably variable scoping and precedence rules. Scoping is practically non-existent; a variable declared in one role can be freely accessed in another, which can easily lead to clashes when your variable names are too generic.
I'd say it still is. People forget you can code your own modules in whatever language you want and just expose a nice declarative interface through Ansible.