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

91–100 of 141 posts

Re: Ansible 4.0

#91

Post by takeda »

takeda wrote: post #43
Jedd wrote: post #37

Earlier quoted context omitted.

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.

Came too late, so can't edit anymore, but here's an example of a custom renderer, that allows writing states using java properties format: https://github.com/saltstack/salt-contrib/blob/master/render...

Re: Ansible 4.0

#92

Post by flal_ »

otabdeveloper4 wrote: post #89
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…

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

Exactly : not everyone gets to play with a kube cluster. Also there is a lot of sysadmins that don't trust docker-in-prod...

Re: Ansible 4.0

#93

Post by rualca »

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.

This assertion makes absolutely no sense at all, and reads like a Markov chain of buzzwords.

Kubernetes is containers autoscaling, blue-green deployments, revertible deployment histories.

Ansible and the like is configuration as code. That's it.

The closest there is between kubernetes and configuration-as-code tools is Docker's dockerfile.

Re: Ansible 4.0

#94

Post by Fizzadar »

yjftsjthsd-h wrote: post #84
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…

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

There's pyinfra (https://github.com/Fizzadar/pyinfra) if you like Python (disclaimer: I started the project), heavily inspired by Ansible just without the yaml/jinja2 hybrid stuff.

Re: Ansible 4.0

#95

Post by yjftsjthsd-h »

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

Earlier quoted context omitted.

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 fr…

In a word: Hetzner. Dedicated servers scattered across data centers, sufficiently numerous to make IPAM too painful to manually tie them together with wireguard. It's possible that some sort of overlay network or VPN could be made to work, but I could also just expose port 22 with only public key auth enabled, use ansible, and be done.

Re: Ansible 4.0

#96

Post by Fizzadar »

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.

SSH can be quicker, I believe ansibles use of SSH processes is more the issue. An old but still relevant benchmark exists in my pyinfra project which uses SSH (amongst other protocols) but a Python implementation, and its significantly quicker and more scalable than ansible: http://docs.pyinfra.com/en/1.x/performance.html

Re: Ansible 4.0

#97

Post by cies »

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!

We dropped Ansible and Packer when we went with containers (instead of AMIs). Ok we still use a small bit of Ansible: the vault feature.

Re: Ansible 4.0

#98

Post by zmmmmm »

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…

There have been a litany of bugs and long running issues in docker for Mac causing high CPU usage. It is worth checking out the issues to see if one of the fixes works for you. Many of them relate to how volumes are mounted. I finally settled on a config and this is a non-issue. Of course, having to do this for any piece of infra is terrible, but docker is such a lingua franca on the server side that its worth it in this case.

Re: Ansible 4.0

#99

Post by gouggoug »

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…

> How does Kubernetes not also result in the same?

Here's the difference between kubernetes and ansible (and alikes) (and I'm over-simplifying a bit of course, but the idea is there)

* With kubernetes, you write down the state you want your infrastructure to be in, and k8s figures out how to get there

* With ansible, you write down how to get to the state you want and ansible runs those steps, and hopefully they end up in the same state. The issue is that if you run the same set of steps on a Debian linux distribution, and on a Ubuntu distribution, well, they might end up in a similar state, but they actually aren't; for starters: one is debian, the other is unbuntu.

Re: Ansible 4.0

#100

Post by KronisLV »

rualca wrote: post #93
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. This assertion makes absolutely no sense at all, and reads like a Markov chain of buzzwords. Kubernetes is containers autoscaling, blue-green deployments, revertible deployment histories. Ansible and the like is configuration as code. That's it. Th…

I think it still makes some sense. For example, if you look at the process of software development like this:

  [business requirements] -> ... -> [deployed and working software]
Then it stands to reason that Ansible and Kubernetes are just two ways of getting to the same end result.

Where they differ, is the approaches that they take to achieving that result:

  Ansible: [run a playbook ahead of time] -> [the environment for your app will be set up] -> [you can deploy to it through Jenkins/GitLab/whatever] -> [your app will run, but Ansible will know almost nothing about it unless run]
  Kubernetes: [create a cluster ahead of time] -> [you'll be able to run any containers on it] -> [you can deploy to a registry through Jenkins/GitLab/whatever] -> [Kubernetes will make sure that your app remains running]
So essentially, i believe that many people have the stance, that they can probably just set up an environment for an application and forget about it (or at least not constantly monitor it), which is more in line with what Ansible provides, whereas Kubernetes is more suited to situations where it's impossible to have "stable software" (i.e. most business applications, since they don't have the quality of projects like the Linux kernel).

If you want fault tolerance, you have to do additional work with Ansible, like writing systemd services for restarts, manually setting up your load balancers and working on ensuring proper failover, as well as service discovery. And i'd reason that if something is hard to do, oftentimes it simply won't be done at all! Yet with Kubernetes, a lot of that comes out of the box (even though i think that it's often too complicated, K3s does seem sane, but personally Docker Swarm or Hashicorp Nomad hit the sweet spot of features vs complexity).

Post reply on HN