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

131–140 of 141 posts

Re: Ansible 4.0

#131

Post by JeremyNT »

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…

Kubernetes itself tries Very Hard to completely abstract those implementation details. Like, obsessively hard. You (assuming "you" are somebody who wants to run something in k8s) should never need to know or care what it's doing "under the hood" to run your pod in the way you say.

What's happened though is that Kubernetes expects for you to hand it an artifact that encapsulates all of the messy steps required before it can "run the thing." In practice that means the "run the script and symlink stuff" kind of glue is still present, it's just moved into Dockerfiles (which are, more or less, just fancy shell scripts themselves), build scripts, CI/CD pipelines, and startup scripts.

The big shift is more that the responsibility for managing this junk is pushed, organizationally, onto whoever knows how to operate the actual application (because they'll be creating the Dockerfile). Usually that's a developer.

So it's not wrong to say:

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

But it's not really a complete explanation, because it assumes you've already gotten to the point that you've bundled an artifact up that will "do the right thing" when Kubernetes provides the fundamental pieces of infrastructure you define in your template.

Re: Ansible 4.0

#132

Post by pfranz »

saargrin wrote: post #106
pfranz wrote: post #42

Earlier quoted context omitted.

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

what do you mean decouple it from the OS ? this is not coupled to OS to begin with,ansible is just a bunch of python modules in a long trenchcoat

> we always found it mildly annoying that upgrading a system (Linux, FreeBSD) would [...] bring along the danger of the new version not having a package for the "old" version of Puppet or Ansible that we were using.

If this is the only issue, it sounds only mildly annoying. Either upgrade your tooling to use the newer version of be prepared to package up that old version of Puppet/Ansible--as long as you control what version is installed and are comfortable with the range of versions the package manager offers.

The type of scenario I had in mind is relying on something like Python, Ruby, Perl, etc. Something the OS may also deeply rely on. This came up a lot when macOS stopped updating a lot of GPL2 stuff to avoid shipping GPL3 or when they announced they'd stop shipping Python, Perl, and Ruby. You also see it when people try and change system Python version outside of the package manager in Linux and can no longer boot--the same thing can just as easily happen with libraries.

Re: Ansible 4.0

#133

Post by jimmySixDOF »

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…

It sounds like you think kubernetes et al. are a suitable replacement for ansible et al. , however k8s are not able to provision settings on a Web Application Firewall from F5 and the iLO links on your HP blade server farm. Et Al. Your statement works if you are letting AWS/MS/Google do all that for you and all you are responsible for are package dependencies and joining the right VLANs. Not everyone is so lucky and actual Configuration Management tools like Ansible+, while not perfect, make Domain Specific (i.e. real world Multi-Vendor) large environments run on time for most of the time.

Re: Ansible 4.0

#134

Post by takeda »

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

Earlier quoted context omitted.

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.

I never used Hetzner but based on my research, Hetzner says that they only have 3 data centers:

- Nuremberg, Germany

- Falkenstein/Vogtland, Germany

- Helsinki, Finland

so you could place 3 instances, one in each and would have to use public IP to communicate between them.

But, Hetzner also offers Cloud Network, which is essentially a LAN that you should prefer for communicating.

Anyway, whatever works for you, using Ansible is easier, because doesn't require any prior setup, but you pay that back with worse experience keeping things running and slower speed.

Re: Ansible 4.0

#136

Post by Jedd »

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.

I agree - Saltstack felt like a significantly superior design, but alas the RHEL effect won out.

Re: Ansible 4.0

#137

Post by colechristensen »

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…

I’m not saying kube really fixes all of these problems or is a better solution, but it exists as a response to a crappy solution. in other words one problematic solution replaced another problematic solution. Stay in the field long enough and you see a pendulum where one kind of solution with problems is replaced by a different kind of solution with different problems... and then it swings back and a new general goes back to a new iteration of the first kind of solution and gets to rediscover the old problems again, back and forth over and over.

Re: Ansible 4.0

#138

Post by colechristensen »

jimmySixDOF wrote: post #133
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…

It sounds like you think kubernetes et al. are a suitable replacement for ansible et al. , however k8s are not able to provision settings on a Web Application Firewall from F5 and the iLO links on your HP blade server farm. Et Al. Your statement works if you are letting AWS/MS/Google do all that for you and all you are responsible for are package dependencies and joining the right VLANs. Not everyone is so lucky and…

I actually don’t like kibernetes.

And of course you’re right, the use cases don’t totally overlap. However there is a big chunk of the core functionality which is absolutely competing ways to solve the same set of problems.

Re: Ansible 4.0

#139

Post by notatoad »

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?

i haven't even explored the options for shifting to another ansible-like system, i've just gone back to the supposed "bad old days" of a collection of random tools with shell scripts to fill in the gaps.

a combination of docker containers and terraform (for managing aws) is doing most of the heavy lifting for me.

Re: Ansible 4.0

#140

Post by aweiland »

lmm wrote: post #125
aweiland wrote: post #121

Earlier quoted context omitted.

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.

We run ansible-pull as the very last step of a CloudFormation build (instance or autoscaling group). So it's a local pull, not a push from somewhere else. Only done once, hence the immutability. To make changes you replace the instance.

Puppet (can) keep it's hooks into an already running instance and continue making changes to it.

Post reply on HN