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

81–90 of 141 posts

Re: Ansible 4.0

#81

Post by dheera »

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 use bash scripts too on almost all my systems. Containerize deployments. Dockerfiles are a godsend and work indefinitely.

Re: Ansible 4.0

#82

Post by pat2man »

binoct wrote: post #51
colechristensen wrote: post #31

Earlier quoted context omitted.

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…

> You ended up with lots of magic an internal domain knowledge about how to do things, and often had to get clever to get the result you wanted. How does Kubernetes not also result in the same? I'm not questioning plenty of improvements and the somewhat different domain it brings to the table overall but genuinely curious. From what I've seen any tool designed to integrate and manage complex, disparate systems is goi…

Kubernetes doesn't attempt to be an API that can solve any orchestration issue, it is an abstraction on the underlying architecture. It's a lot easier to be backwards compatible here (and if you are not, create an operator that is).

Now whether its the right abstraction is a matter of debate. But ultimately like VMs or containers, its so far proven to be a valuable tool, at least for medium sized companies.

Re: Ansible 4.0

#83

Post by endgame »

takeda wrote: post #71
colechristensen wrote: post #31

Earlier quoted context omitted.

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…

Nix is an incredibly far-sighted vision, and it's great to work with... once you get your head around it all. I much prefer to build containers using it, and it does a much better job of "provisioning" than any other tool I've used. I remember being appalled when I first used Ansible and discovering that adding a package, then removing the stanza to add that package, resulted in the package persisting on the system.

Re: Ansible 4.0

#84

Post by yjftsjthsd-h »

notatoad wrote: post #64
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…

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…

> at this point i've started transitioning as much of my administration stuff as i can away from ansible

Any preferred alternatives you can share?

Re: Ansible 4.0

#85

Post by apple4ever »

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 run Mitogen which makes it super fast. There was some discussion of merging them. But the Ansible side got all grumpy and refused. It was a bad decision, because it hurts Ansible being so slow.

Re: Ansible 4.0

#86

Post by lazystone »

zymhan wrote: post #59
tundrax wrote: post #53

Earlier quoted context omitted.

Ansible, chef etc. are provisioning tools, not container orchestrators.

The point is that had they worked well, containers may not have become as popular as they are now. Containers are only somewhat used for scalable microservices. They're mostly just an easier way to deploy software than creating your own RPM package and using orchestration tools to deploy it on VMs.

Those things solve completely different problems.

Re: Ansible 4.0

#87

Post by pbreit »

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…

How is this possible in 2021:

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

Re: Ansible 4.0

#88

Post by zmmmmm »

UI_at_80x24 wrote: post #28
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 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…

thanks - its really helpful to hear the warts-and-all version of experience like this. Appreciated!

Re: Ansible 4.0

#89

Post by otabdeveloper4 »

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…

Ansible is way, way, way more popular than Kubernetes in the real world.

(Yeah, k8s does a whole lot more and is more opinionated, but still...)

Re: Ansible 4.0

#90

Post by takeda »

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

Earlier quoted context omitted.

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

Not every environment can provide an internal network.

Actually you always have an option to properly secure.

If you have own data center and more than one machine you do have a LAN.

I'm guessing you're talking about public cloud like AWS.

Similarly you can have private subnets (which is the best practice).

If you have a single instance that's only public, you can place definitions on local S3 and have instance pull it. You can secure everything so it's not accessible from outside, and you don't need service to be available from the outside.

If you have multiple instances and all are on public subnets and talk to each other over the Internet, you should rethink your design, but at very least have firewall configured. Security groups that list themselves could help.

Let me know if you have some other scenario.

Post reply on HN