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

41–50 of 141 posts

Re: Ansible 4.0

#41

Post by pram »

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 don’t know about Ansible within terraform, but I use them together for non-container infra. Terraform for deploying the actual VMs and other stuff, and Ansible for post deployment OS/application provisioning. Using them this way has been extremely flexible and easy to maintain. I also provision AMIs this way with Packer calling an Ansible playbook to set everything up. The beauty of that is you can run that same playbook on already provisioned VMs to keep them in sync too.

Re: Ansible 4.0

#42

Post by pfranz »

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've never used things like Ansible or Puppet in a professional environment, but I can appreciate how difficult my recommendation is. If you're using a technology for a significant part of your business, decouple it from the OS. Where that line is drawn is subjective.

I don't even think backwards incompatibilities are the biggest reason. In practice, the problem is often around bugfixes and upgrades. Upgrades are much easier if you can do them independently. It sucks to have to upgrade the kernel and other tooling just to grab a small bugfix--or hold off on a transition waiting until both OS issues and code base issues are resolved.

> It's not exactly clear how can Perl programs or shell scripts or Makefiles from 20 years ago play perfectly fine unchanged

In all likelihood they don't. For open source projects they probably have a lot of workarounds and cruft to support a variety of environments and spans of versions they are both written against and tested against. Internal code is written and tested against a specific version relying on your proprietary environment.

Re: Ansible 4.0

#43

Post by takeda »

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.

I wish saltstack would be more popular. It's so far the best one I used (I didn't use Puppet and CFEngine).

As for the second concern, you actually kind of can:

https://docs.saltproject.io/en/latest/ref/renderers/

yaml never bothered me, so I just used it, but you could use a different one. I suppose none of the ones from the list would make parent poster happy, but then one could write own renderer.

Re: Ansible 4.0

#44

Post by takeda »

yjftsjthsd-h wrote: post #17
nerdbaggy wrote: post #15

Earlier quoted context omitted.

salt has been great for me. SSH is just so slow compared to always on zeromq

Maybe, but I feel safe exposing openssh to the open internet, which is more than I can say for salt.

In properly set up environment things like that should never been exposed outside.

Re: Ansible 4.0

#45

Post by yjftsjthsd-h »

takeda wrote: post #44
yjftsjthsd-h wrote: post #17

Earlier quoted context omitted.

Maybe, but I feel safe exposing openssh to the open internet, which is more than I can say for salt.

In properly set up environment things like that should never been exposed outside.

Not every environment can provide an internal network.

Re: Ansible 4.0

#46

Post by asiachick »

AJAlabs wrote: post #21
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…

With verison 4.0.0, they've implemented semantic versioning which should make life easier for avoiding breaking backwards compatibility changes. https://semver.org

Does that make it easier or does it just mean you'll be more aware upfront that to get the security fixed or support you need for some new feature you need to upgrade to an incompatible version

Re: Ansible 4.0

#47

Post by BenjiWiebe »

Alex3917 wrote: post #27
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…

> 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).

Re: Ansible 4.0

#48

Post by mtlynch »

geerlingguy wrote: post #38
mtlynch wrote: post #30

> 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: Does anyone know what they're talking about? This is a pain to deal with in my app, and I've never seen it with any other pip package.

Unfortunately due to some things that happened with the way they renamed packages after the split (from ansible to ansible-core and ansible-base), it required a full 'uninstall and reinstall' operation, otherwise Pip gets things a bit confused and the installation breaks completely. There was a Herculean effort to try to get it to just upgrade cleanly, but in the end it turned out there was no way.

Ah, gotcha. Thanks for the clarification, Jeff!

Re: Ansible 4.0

#49

Post by geodel »

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 breaking changes.

I do not think it is a case of hindsight 20/20. These are basic things like object need multiple fields but it is rigidly defined with 2 fixed strings and now one need object V2 to update. Or all functionality dumped at base URL so no scope of adding sub-functionality without breaking the whole pattern. I can understand no one can plan for how complex functionality evolve over time. But here I see perennial amateur hour with every release. And it is doubly irritating when these frameworks are already many layer deep stack of bullshit abstractions so ideally they should be able to handle changes without breaking.

Re: Ansible 4.0

#50

Post by bredren »

kbenson wrote: post #34
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…

> It's not exactly clear how can Perl programs or shell scripts or Makefiles from 20 years ago play perfectly fine unchanged, but the syntax of a manifest or playbook that does a couple of simple operations cannot remain stable. It's clear when you deal with both types of systems. Perl optimized for stability and backwards compatibility at the cost of new features and new language conveniences. This is great and a st…

This is happening in Django land right now.
Post reply on HN