Live data from Hacker News

Ansible 4.0

groups.google.com

111–120 of 141 posts

Re: Ansible 4.0

#111
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 a MacOS issue. You're forced to use virtualization for being able to use containers. Quite backwards!

Re: Ansible 4.0

#112
post #51

Earlier quoted context omitted.

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

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 "Copy this file".

Re: Ansible 4.0

#113
Does anyone use Ansible in GitOps ? If so, what other tools do you use? Gitlab? Other? If not, what would you recommend for non-Kubernetes infrastructure for GitOps?

Re: Ansible 4.0

#114

Their versioning is unnecessarily confusing. Why call it version 4 and then when you run --version it shows a different version? $ ansible --version ansible [core 2.11.0] $ python -c 'from ansible_collections.ansible_release import ansible_version; print(ansible_version)' 4.0.0

Because after Ansible 2.9 they made a huge change in how module resolution works and put most of the modules in a separate repository to be versioned independently.

Re: Ansible 4.0

#115

This broke us. Some crap about sftp. Three hours down the drain.

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.

Re: Ansible 4.0

#116

Earlier quoted context omitted.

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.

I've been following pyinfra precisely because every new Ansible release makes my heart sink knowing how much work it's going to cause me and how inscrutable debugging our playbooks is every time. I've been trying to find the time to port over all our existing Ansible playbooks but have really only scratched the surface so far. However, I have high hopes, pyinfra looks like a well thought through project.

Join the club of staying on Ansible 2.9 forever! It’s 2015 MacBook level good and still being developed. 2.9.21 was released two weeks ago and 2.9.22 is coming soon.

The way Ansible is developed it’s way easier to fork your own and backport bug fixes and features you need because it’s a toss up whether the fix you need actually got merged or whether it languishes in the GH issues.

Re: Ansible 4.0

#117
post #115

This broke us. Some crap about sftp. Three hours down the drain.

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.

Re: Ansible 4.0

#118

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…

Yes, that's another reason I am sticking with Bash for teaching for my book on deployments. Your Bash will only change if your tools change. If you want to know how things work under the hood, you don't want to go through a rabbit hole of Python modules that also change beneath you.

Re: Ansible 4.0

#119
post #59
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.

I hope that you do understand the difference of server provisioning and container orchestration, as mentioned above, solve completely different problems.

Re: Ansible 4.0

#120

Earlier quoted context omitted.

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

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 and then copy this file over here, and don't forget to symlink it over there)". Am I wrong?

Post reply on HN