Live data from Hacker News

Ansible 4.0

groups.google.com

101–110 of 141 posts

Re: Ansible 4.0

#101

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…

I've been maintaining the ansible scripts for a dev vagrant box for 5 years. I've found it needs constant care and feeding/tweaking. I finally just gave up and install what I need locally with brew. Also vbox uses all the memory and makes the fans go brrrr.

Ditto on the constant care. And the Ops comment on brittle 3rd party modules is spot on.

I went back to a shell script to configure our developer VMs when I realised I was spending more time debugging Ansible updates than scripting it myself would take. And now I know exactly what's going on.

Re: Ansible 4.0

#103
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

Re: Ansible 4.0

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

> My biggest most scornful vehement hatred is for yml files and python being white-space sensitive. I will piss on the shoes of the person that ever thought of that. Fuck them.

Amen. The irony of making something invisible syntactically significant is quite something.

Re: Ansible 4.0

#105
post #82
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…

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.

and then you use something like helm to orchestrate and end up being in the same place where you left ansible:

lots of environment specific magic and flow-breaking with every upgrade of anything

same with cloud envs and terraform

Re: Ansible 4.0

#106
post #42

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

Re: Ansible 4.0

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

So Ansible is a Configuration as Code tool (CaC). You know for configuring your servers and network things.

Terraform is a Infrastructure as Code tool (IaC). Great at deploying the underlying raw resources.

Just like you can take a screw driver and use it as a hammer, punch or pry bar. You could also deploy infra with Ansible or configure servers with Terraform. I have done it, seen others do it and try my best to avoid it. You really want the best tool for the job but sometimes you need the best tool for the person/situation. A air powered hammer is a really nice tool to have but if you are in a place where they don't have compressed air, then a regular hammer will do and if the locals don't have hammers, then find a rock. So sometimes we do weird things with our tools, is it useful? Possibly to the person at the time.

I don't think Ansible is trying to fit into IaC. I think CaC and IaC are just a set of tools that are trying to fit into DevOps/SRE.

A really nice approach I have built for clients over the years when deploying non-containerized applications is to use Packer with Ansible to build a image of the server. Then use Terraform to deploy the infra. Then comeback with Ansible to do runtime stuff like Security tools, enroll into monitoring and also deploy the running application if not already baked into the image.

If you are containerized then just switch out packer for docker.

Re: Ansible 4.0

#108
post #87

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"

https://xkcd.com/1987/

Python does some things really well, but their package managers leave what to be desired [especially for the uninitiated].

Re: Ansible 4.0

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

Re: Ansible 4.0

#110

Earlier quoted context omitted.

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

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.
Post reply on HN