Hacker News Reader

Comment by zmmmmm | Hacker News Reader

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 within terraform. Do people really do that and is it useful? Or is it something you would only do if you have a lot of legacy infrastructure already configured via Ansible.

Curious on the general take here.

View on HN

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.

It's hard to say. I don't see too much point in running Ansible inside Terraform or Terraform inside Ansible (yes, you can go either way). Ansible lagged for years on its support of kubernetes and helm (it had it, but it didn't work). Now (like in the last 12 months) got good support for both, but it might be too late. Terraform has the majority of mind share when it comes to Kubernetes support.

If you're only doing AWS or Google Cloud, Ansible can do that. Whether it does it better or worse than Terraform is all dependent on your use case.

If you're doing anything on premise, or outside of GCP/AWS, Ansible can do that as well. From the using OOB management (HP iLO/Dell iDRAC) to install the OS, to configuring vmware clusters to deploying k8s to declaring resources within k8s. Got network switches and firewalls at your office? You can manage that with Ansible. If you have a bunch of edge compute, Ansible can manage that as well.

What it comes down to is if you've got teams working with anything outside of AWS/GCP. They'll probably be using Ansible, and since you've already go Ansible knowledge across your organization, it would make sense to leverage that expertise and Ansible's cloud integrations.

All of that said - Terraform is much more popular when it comes to the major cloud platforms. If all you have is cloud, then you'll probably start with Terraform and stay there.

https://github.com/ansible-collections/community.kubernetes https://www.ansible.com/integrations/cloud/amazon-web-servic... https://www.ansible.com/integrations/cloud/google-cloud-plat... https://www.ansible.com/integrations/networks

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 my container definitions, injecting environment variables for config/secrets into the definition or runtime. I tend to use Ansible or Terraform here.

For me, the main criteria is whether the product has a large number of components with configuration that needs to reuse common structures. If I'm just deploying one or two components (e.g. your typical early-stage monolith), Terraform is fine. Bt if you have many users contributing to many components and want to provide higher-level tools, I vastly prefer using Ansible; you just have more control.

That is, I believe in Ansible as a tool for applying configuration from source control to some other system; I would no longer use it to provision cloud resources.

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.

Even in container world, I still find Ansible/Chef useful for a number of low-level system tuning tasks. Things like setting NUMA affinities, modifying kernel parameters, setting IRQ interrupts, loading kernel modules, setting NIC parameters, etc. That kind of stuff is often overlooked, but done right can have pretty dramatic performance impact.

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!

This is now our primary use of Ansible as well. We install and minimally configure systems in machine images, then use cloud-init to do the remaining 1% of config at VM build time.

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.

I don’t know about Ansible within terraform, but I use them together for non-container infra. Terraform for deploying the actual VMs and other stuff, and Ansible for post deployment OS/application provisioning. Using them this way has been extremely flexible and easy to maintain. I also provision AMIs this way with Packer calling an Ansible playbook to set everything up. The beauty of that is you can run that same playbook on already provisioned VMs to keep them in sync too.

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.

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.

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.

> 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 myself switching unless forced.

That's... very strange! Containerization (docker) has less overhead than virtualization (virtualbox).

well, with Docker for Mac, you get both!

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

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.

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.

That's a MacOS issue. You're forced to use virtualization for being able to use containers. Quite backwards!

I think a big part of its future will be using it to implement Kubernetes operators. See https://www.ansible.com/integrations/containers/operators

It seems like a good fit in that role, as the other main option is writing your operator in Go, which is even more imperative, and usually ends up seeming a little too low level and like overkill for the tasks an operator actually has to do at runtime. Either one can be a good option, but many people will go with ansible, and I see it carving out quite an important little niche with operators.

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 getting it setup, testing, and deploying then I do using it. In my heart I know that this is the right approach, and the way I should be managing my servers. But the time-saved just isn't there. The consistency is awesome.

I have 2 complaints about Ansible. (1) Minor annoyance - It's slow. It's as slow as if I were sending individual commands from SSH. A scripted solution that is as slow as my typing is a hard sell. It doesn't make spelling mistakes but it does make different mistakes. I can live with this annoyance, but I have literally spun up a new server, SSH'd in, created my Ansible user, and launched my "Initial Server deployment script", went for lunch; and came back to it just finishing.

That example is even excusable. But a simple script: "check for system updates & report back if needed" for 50 servers is slow as fuck. Running them in parallel would be better.

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. Even though I have vim templates for .yml, Even though I have 'turn tabs to spaces', even though I have whitespace characters SHOWN; There is ALWAYS atleast one someplace.

I hold a hatred that only Khaan can feel towards Kirk about this.

But other then that, I really want to love it.

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

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

> Running them in parallel would be better.

It does run in parallel by default though: https://docs.ansible.com/ansible/latest/user_guide/playbooks...

thanks - its really helpful to hear the warts-and-all version of experience like this. Appreciated!

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

This maybe a Frankenstein baby but when I’m dealing with ec2’s I appreciate creating the AMI using Ansible and Packer. Then referencing said AMI from a terraform script. I rarely do this anymore as I’ve moved the majority of infra under Kubernetes but the couple times I did it this way it didn’t feel dirty.

I use ansible to setup my LXC containers for personal stuff like pihole and freeipa. I'm not really sure what my alternative is. I can destroy / create the container and set it up in one command.

We do use ansible for provisioning in combination with AWS CDK. The cases are simple as when you don't utilize container services, but roll out your own server infrastructure using EC2.

Reply on news.ycombinator.com