Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ansible 4.0

groups.google.com

Post reply on HN
Print view View original

71–80 of 141 posts

Re: Ansible 4.0

#71

Post by takeda »

colechristensen wrote: post #31
aduitsis wrote: post #14

First of all, congratulations to the team of Ansible and these tools have benefited us in numerous ways that cannot be understated. Having said that, this caught my eye: > There may be backwards incompatibilities in the core playbook language. Please see the porting guide for details. Doing incompatible changes is not something specific to Ansible, for example Puppet has also done it time and again. We've been using…

The reason why kubernetes et al. are so popular is that the orchestration tools like ansible, puppet, salt, chef... they all failed to deliver ultimately great software. Plagued by mediocre quality external modules and a constant churn of semi-backwards incompatible changes which required frequent maintenance, they have just been hard to use. You ended up with lots of magic an internal domain knowledge about how to d…

> The reason why kubernetes et al. are so popular is that the orchestration tools like ansible, puppet, salt, chef... they all failed to deliver ultimately great software. Plagued by mediocre quality external modules and a constant churn of semi-backwards incompatible changes which required frequent maintenance, they have just been hard to use.

This is a good point, and most problems came because the tools were still only involved in mutating state of the machine. They eventually evolved to be declarative, but that's just cosmetic.

In the CM tools if you added declaration that package should be installed and you removed it the package will still be there. You had an entry to say that it should be uninstalled.

This basically ensures that machines that are configured the same way often ends up being drifted apart.

NixOS solves this problem by having language that instead of describing what should be updated instead has a declarative language that describes how the entire system should be built. When you change configuration it actually rebuilds the OS from scratch. It might seem like a lengthy process, but it is actually a quick because of caching. Nix just fetches missing pieces from repo and places in ints store, rebuilds things that are not in the binary cache and then updates symlinks to new locations. Because of using symlinks, upgrades are atomic, and you can also roll back your changes.

The catch? It is a paradigm shift, it also doesn't help that the language used is functional. So it's a steep learning curve.

Re: Ansible 4.0

#72

Post by mech422 »

geodel wrote: post #49
aduitsis wrote: post #14

First of all, congratulations to the team of Ansible and these tools have benefited us in numerous ways that cannot be understated. Having said that, this caught my eye: > There may be backwards incompatibilities in the core playbook language. Please see the porting guide for details. Doing incompatible changes is not something specific to Ansible, for example Puppet has also done it time and again. We've been using…

I am not much familiar with Ansible/Puppet etc. However working in Java and dealing with frameworks like Spring/boot, kafka etc I notice a phenomenon of large number of breaking changes, specially when one update in couple of years as opposed to update with every release. Now when I dig into changes it just points to extremely poor design to begin with. It just couldn't handle slight change in requirement without bre…

I tend to think this is an issue with 'designing' systems vs 'evolving' them. When you build something to 'scratch your own itch' and it suddenly becomes popular, lots of stuff you didn't think of tends to pop up. Maybe all the market studies, focus groups, ad nauseum in 'traditional' BigCo development actually did have some value.

Ansible at least had the advantage of being a 'broad' tool from the get go. So a lot of the common use cases were covered. But I'm sure surprises still popped up :-)

Re: Ansible 4.0

#73

Post by brightball »

open0 wrote: post #66
notatoad wrote: post #64

Earlier quoted context omitted.

if it was just incompatible syntax changes, that would be one thing. but it's not - it's incompatible administration and structure changes. they just stabilized the new modules shift a couple months ago, which restructured all their documentation and issue tracking, breaking uncountable links and closing thousands of open issues. and that wasn't the first time they'd done that. at this point i've started transitionin…

I wrote my own remote scriptrunner thing because I hate Ansible so much.

I did this before with perl’s SSH::Batch. You can install it from CPAN and get really simple ability to run code on groups of servers in parallel. Works great.

Eventually I switched to Ansible because it made the more complicated things a lot simpler.

Re: Ansible 4.0

#74

Post by 0xbadcafebee »

"Due to a limitation in pip, if you are upgrading from Ansible 3 (or earlier), you need to uninstall Ansible and Ansible Base before installing Ansible 4"

Was it really a limitation in Pip? Or did the Ansible devs just really want this non-backwards-compatible release to use the same name as before, just so they wouldn't have to use a new package name like "ansible4"? Even though that would allow both pre-ansible4 and ansible4 scripts to co-exist? And considering everybody has to test and update their code for ansible 4 anyway?? This seems to just cause more pain for devs and admins with no real benefit. Which is to say, par for the course.

This is the main reason I have always hated using Ansible. Arbitrary decisions leading to a cumbersome, bloated, undocumented, difficult mess.

Re: Ansible 4.0

#75

Post by [deleted] »

Jedd wrote: post #37
UI_at_80x24 wrote: post #28

Earlier quoted context omitted.

I want to love it more then I do. I think it doesn't fit my needs quite enough. When setting up a new system for a LAMP role, it might save me 5 minutes of work. When upgrading/updating my herd of LAMP servers, it might save me 5 minutes, and general 'management' of 50+ LAMP servers all in different AWS regions it's very handy. I like it. I just don't use it often enough to justify it. I honestly spend more time gett…

Your first concern is addressed by saltstack - they chose an agent based approach, with client subscription, as the default, which makes for a significantly faster experience. They subsequently offered an ssh-based option for those that wanted the poor performance of Ansible across larger fleets, or where agents were not palatable. Unfortunately it doesn't address your second concern, as it also uses yml + jinja.

[deleted]

Re: Ansible 4.0

#76

Post by deadbunny »

dralley wrote: post #40
encryptluks2 wrote: post #7

Pretty cool but Ansible just seems too slow to me. I'm just comparing this against like native scripting, Terraform, etc. I guess Ansible is still the best option for configuration management, but I keep hoping someone will come out with a new tool, preferably built with Go or Rust.

While I don't have any hard numbers, I would bet a lot of money that any "slowness" of ansible has nothing to do with the use of Python. Everything happens over SSH, that's a lot of network roundtrips.

Indeed. See saltstack for something that does the same thing, witten in python that runs much faster.

Re: Ansible 4.0

#77

Post by 0xbadcafebee »

encryptluks2 wrote: post #7

Pretty cool but Ansible just seems too slow to me. I'm just comparing this against like native scripting, Terraform, etc. I guess Ansible is still the best option for configuration management, but I keep hoping someone will come out with a new tool, preferably built with Go or Rust.

> I guess Ansible is still the best option for configuration management

Ansible is perhaps the worst option, next to CFEngine and some other legacy ones. It's just the one everyone goes for because nobody wants to maintain a puppet/chef/salt/etc server, and encoding a bastardized DSL in YAML seems easier than writing Ruby.

Re: Ansible 4.0

#78

Post by ddreier »

rbjorklin wrote: post #18
zmmmmm wrote: post #12

I know Ansible has a huge number of fans but I am genuinely curious about the future. That is, I've been trying to figure out where ansible fits in the bigger picture of the modern trend towards IaC. Is it in conflict with that because of its semi-imperative nature? Or is what it does an essential piece of how IaC needs to work to do declarative infrastructure management? I see that for example you can use ansible wi…

I’d say that a tool like Packer is heavily reliant upon Ansible to be useful so I don’t see Ansible going anywhere anytime soon. If there’s a better tool than Ansible out there to pair with Packer please let me know!

This is now our primary use of Ansible as well. We install and minimally configure systems in machine images, then use cloud-init to do the remaining 1% of config at VM build time.

Re: Ansible 4.0

#79

Post by [deleted] »

BenjiWiebe wrote: post #47
Alex3917 wrote: post #27

Earlier quoted context omitted.

> That is, I've been trying to figure out where ansible fits in the bigger picture of the modern trend towards IaC. As a developer working on a small startup, I don't like using Docker because it makes the fan on my MBP go crazy and drains the battery almost instantly. Whereas I've had zero problems with VirtualBox. Until containerization actually works properly and provides a good developer experience, I can't see m…

That's... very strange! Containerization (docker) has less overhead than virtualization (virtualbox).

[deleted]

Re: Ansible 4.0

#80

Post by dheera »

aduitsis wrote: post #14

First of all, congratulations to the team of Ansible and these tools have benefited us in numerous ways that cannot be understated. Having said that, this caught my eye: > There may be backwards incompatibilities in the core playbook language. Please see the porting guide for details. Doing incompatible changes is not something specific to Ansible, for example Puppet has also done it time and again. We've been using…

One would think at the very least you should be able to specify a version of your script some place and it be able to parse all prior versions.
Post reply on HN