Ansible 2.13

https://github.com/ansible/ansible/blob/stable-2.13/changelogs/CHANGELOG-v2.13.rst

by gtirloni • 4 years ago

91 93 4 years ago

mdaniel11• 4 years ago

I hate that I have to say this, but be aware that one cannot "pip install ansible==2.13" (https://pypi.org/project/ansible/#history) since they took over the "ansible" name to mean the "ansible distribution", which includes the project you linked to as well as a bazillion separately versioned galaxy dependencies

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

tehbeard• 4 years ago

So they did the work to split modules out of "core" for ease of development, and then completely mangled the versioning?

mdaniel11• 4 years ago

I believe it's likely just a nomenclature problem; had they left "ansible" pointing at GH/ansible/ansible and called the new thing "superansible" (or whatever) it would have been so much easier to reason about and wouldn't have needed a damn near secret side-repo named "ansible-build-data" in which they would hide the actual, no kidding, git tags

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?

qbasic_forever3• 4 years ago

When would you ever want to install just the core without any plugins? It seems like what they have now, 'pip install ansible' and you get a working distribution, is exactly what users expect.

sascha_sl• 4 years ago

It's just unintuitive that the package that provides the "ansible" binary isn't ansible. And then it gets even more confusing with the title of this post. It should really be "ansible-core 2.13".

Steltek4• 4 years ago

Is pip an end user's package manager or is it a developer's dependency manager?

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

mdaniel11• 4 years ago

I hear you, and we do run into that _a lot_ in triaging SO reports since some folks "apt-get install ansible", others "sudo pip install", and rarest of them all "python -m venv && pip install" and the end result matters a great deal as far as "sure, the thing was installed, but WHERE and was it installed completely?"

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"`

apple4ever• 4 years ago

They really bungled the versioning.

corrral• 4 years ago

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)

jamespo• 4 years ago

https://www.rexify.org/

mdaniel11• 4 years ago

It's just Perl

Thank you, but no

geekthattweaks• 4 years ago

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

Steltek4• 4 years 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• 4 years ago

https://github.com/purpleidea/mgmt

skyfaller2• 4 years 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#i...

Kind of a non-starter for my use case. I hope they get to a 1.0 release soon.

muxneo• 4 years ago

try chef, puppet or saltstack

tilolebo• 4 years ago

"Operational simplicity" would like to have a word with you.

_joel4• 4 years 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.

ciupicri• 4 years ago

If I remember correctly puppet required installing an agent. To add to the injury it wasn't available on the RHEL (clone) ISO and right now it's also missing from Fedora EPEL.

chucky_z• 4 years ago

https://cinc.sh/ a good (FOSS) replacement for chef.

anotherhue• 4 years ago

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

blueflow2• 4 years 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.

kirbyfan64sos• 4 years ago

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

rr8083• 4 years 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.

datalopers• 4 years ago

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

Hackbraten• 4 years 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/scrip...

mdaniel11• 4 years 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

shaicoleman2• 4 years ago

pyinfra - https://pyinfra.com/

skyfaller2• 4 years 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?

drcongo2• 4 years 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!

Steltek4• 4 years 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• 4 years 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

btmcnellis2• 4 years 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.

encryptluks22• 4 years 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.

c7DJTLrn2• 4 years ago

Terraform does the job but it's pretty dirty and unreliable. I've had so many cases where a plan looks all great, PR gets approved and merged, and then something happens during the apply causing it to fail because all validation is done in the cloud API, not in the provider code.

It's another tool pretending to be declarative.

_joel4• 4 years ago

You'll find a lot of places use Terraform and a config management tool. Terraform is great to build out cloud infra (not just instances but load balancers, object storage etc), but when it comes to mantaining system configuration and application state, it's less optimal.

mejutoco• 4 years 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-h...

rollcat3• 4 years ago

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

l0b0• 4 years 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.

tryauuum5• 4 years ago

I hate ansible so much it's unreal

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?

mdaniel11• 4 years ago

Is there a competing config-management tool that behaves more like you want? I'm just curious because I haven't used the others in anger enough to know how they solve the problem you described

tryauuum5• 4 years ago

I am a fan of SaltStack. With SaltStack approach, you don't have to write additional yaml to see the output of external command's execution. You see / don't see the output of commands based on logging settings in your client (salt-call).

# 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

INTPenis• 4 years ago

So run ansible -m command instead.

omniglottal• 4 years ago

Executing a task while collecting its output is a different operation than a task to display arbitrary output generated by a command's output. Imagine two shell commands: # foo=$(cat bar) # echo $foo

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.

tryauuum5• 4 years ago

I don't understand the first part of your comment, why do you compare different commands. My complaint is that ansible runs external command, always internally collects it output, but doesn't display it.

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!

tryauuum5• 4 years ago

Another part of ansible that I hate is that it encourages bad development practices.

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.

marenkay• 4 years ago

This I disagree with a lot. Ansible does have a lot of unfinished playbooks out there or half baked ones. But there is solid documentation there which makes it pretty clear how to properly design things. Have a feeling people just don't read it.

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.

allarm2• 4 years ago

Is there any sane reason why in all standard modules the keyword “src” has 3 letters but “dest” has 4 letters instead of “dst”, which is pretty standard everywhere? Drives me crazy every time.

zufallsheld• 4 years ago

If it drives you crazy, why not make a pr to add an alias for dst? For the copy module this line (and the docs) need to be changed: https://github.com/ansible/ansible/blob/cb448097e4ef581a4749...

p4l4g4• 4 years ago

I know the feeling. We use ansible extensively in our company. While it is probably the best tool at the moment to get the job done, it is not a pleasant tool for larger/complex setups.

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.

gtirloni2• 4 years ago

it is not a pleasant tool for larger/complex setups.

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.

snird• 4 years ago

I love Ansible.

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.

rr8083• 4 years ago

The only thing I use Ansible for is to parallelize running the same script on a bunch of servers. Would be nice to have a simpler app to do this.

gtirloni2• 4 years ago

Maybe try Fabric (https://www.fabfile.org)

drcongo2• 4 years ago

Or PyInfra - it's very good at that job. https://docs.pyinfra.com/en/2.x/index.html

Ansible 2.13

Related Stories