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

121–130 of 141 posts

Re: Ansible 4.0

#121

Post by aweiland »

lmm wrote: post #109
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 could never get why Ansible was popular - to me it felt like a real step backwards from Puppet. Running a bunch of commands once is rarely what you want (except perhaps for deployments, but there are dedicated tools for that).

Ansible helps get us to immutable infrastructure. Puppet does just the opposite.

Re: Ansible 4.0

#122

Post by scrollaway »

kspacewalk2 wrote: post #120
dale_glass wrote: post #112

Earlier quoted context omitted.

Ansible does try to do the 'write down the state you want your infrastructure to be in' thing. Eg, - name: "Ensure sshd is started and enabled on boot" systemd: state: started enabled: yes name: sshd You're not saying 'enable the sshd service', but 'the desired state for sshd is started and enabled'. But this is not perfect, because it's easy to eventually end up with imperative commands, like "run this script", or "…

That does not seem avoidable. I have never used kubernetes, but this seems highly suspect: >With kubernetes, you write down the state you want your infrastructure to be in, and k8s figures out how to get there My guess is that this devolves to "run this script" or "copy this file" in practice as well. Or it just becomes tautological, i.e. "here's the state I want the system to be in (and that means run this script an…

Yeah you're (mostly) incorrect. I recommend looking into terraform and how it handles state, that will give you a better idea of how it's possible to do infrastructure in a "this is what i want, figure out how to get there" way.

Terraform isn't the best implementation of it; k8s has full control over the infra so it's even more powerful in that regard.

Re: Ansible 4.0

#123

Post by j1elo »

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 fun how one's own perpectives and opinions change and adapt with the experience of facing real-world problems over years of professional (or otherwise any kind of) experience.

I was contrary to the idea of 3rd party software repositories, and was of the opinion that one should strive to depend as much as possible from system provided packages.

But the same experience that you mention now, is what gave my point of view a 180 degree change, and now I'd rather install something from pip or NPM. I can just pin the desired version, and they more or less have the policy of holding past versions in a frozen state, so if I know for a fact that version 1.2.3 is exactly right for my needs, I'll keep using that one regardless of system.

The weak point of packaging systems (my experience is Debian and Ubuntu) is that normally there are not many (if _any_ at all) alternative versions offered for the same software. They are built with the general assumption that you should use the latest ones, and of course they don't even attempt to offer a history of versions of every package. So every time you upgrade, it happens what you say, "divert attention to the tool's problems instead of using the tool to solve problems" (very good wording by the way, I liked it a lot)

Re: Ansible 4.0

#124

Post by kspacewalk2 »

lmm wrote: post #109
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 could never get why Ansible was popular - to me it felt like a real step backwards from Puppet. Running a bunch of commands once is rarely what you want (except perhaps for deployments, but there are dedicated tools for that).

For deployments, for upgrades, for setting up testing/staging machines. We picked it because it's agentless (just seems to self-evidently be better for our scale) and written in Python (the devil we know and love). Ours is a reasonably stable and a fairly small environment (~40-50 hosts, mostly containers), and it has been a very good fit.

Granted, moving from wiki pages and ad-hoc scripts to any system would have been a big improvement.

Re: Ansible 4.0

#125

Post by lmm »

aweiland wrote: post #121
lmm wrote: post #109

Earlier quoted context omitted.

I could never get why Ansible was popular - to me it felt like a real step backwards from Puppet. Running a bunch of commands once is rarely what you want (except perhaps for deployments, but there are dedicated tools for that).

Ansible helps get us to immutable infrastructure. Puppet does just the opposite.

How so? Ansible describes a sequence of mutative steps, Puppet describes a desired end state; the latter seems far more amenable to immutable infrastructure than the former.

Re: Ansible 4.0

#126

Post by igetspam »

jbmsf wrote: post #61
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…

When I set up a product deployment system, I want: 1. IaC for the network, database, container definitions, and other cloud things. I use terraform here. 2. CI/CD for the application software, which ultimately builds a container image from version control, tags it in some well-know way, and tells the container scheduler to redeploy. I tend to use CircleCI, but any CI solution will do. 3. Configuration management for…

I've used ansible for parts of IaC. It was terrible. The person who made that decision had one tool in his box and it was ansible. I use it as part of packer, if I need complex changes while generating AMIs and I use it for my field deployed metal. It's great for both of those use cases.

Re: Ansible 4.0

#127

Post by bostonsre »

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…

Yea, I think with both ansible (and stuff like puppet) and kubernetes they are both powerful tools that are pretty leaky abstractions. They are great for sharing and implementing recipes, but that abstraction layer makes it a little more difficult to become a master chef and understand/control exactly what's happening. They are awesome to have in your toolbox, but I still find it incredibly useful to have a tool like python in there as well.

Re: Ansible 4.0

#128

Post by overtomanu »

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…

Can you give some examples of breaking changes in spring boot? Thinking of using it for some projects

Re: Ansible 4.0

#129

Post by r1cka »

secondcoming wrote: post #117
Spivak wrote: post #115

Earlier quoted context omitted.

Why are you blindly upgrading? The only safe way to use Ansible in production or on a team is to pin the version everyone uses because even minor releases can break playbooks and change behavior.

I'm not sure of the details, but it has something to do with the modern way of CI/CD pulling in random 3rd party docker containers.

Sounds like your docker was pulling latest instead of a versioned tag. I'd update that and be happy this only cost you a few hours.

Re: Ansible 4.0

#130

Post by guitarsteve »

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

Docker on Mac spins up a Linux VM behind the scenes so it’s both virtualization and containerization. :-)
Post reply on HN