Saw him do a talk where he went from hello world to automating a bunch of LEDs in couple hours and easily followed along the whole way through.
Ansible is so much more powerful than Terraform (IHMO, due to its pre-cloud roots). Too bad about lack of a "revert" feature/pattern and lack of multi-repo glue/scaffolding.
- Run a playbook which asserts the existence of a user
- Playbook fails at a later stage
- Executing an earlier version of the playbook which doesn't have the user assertion won't cause the user to be removed, just ignored. You need a different (assert not-existing) statement to actually remove the user.
In general these things won't be impactful - but they do mean that if you iterate on your deployment playbooks, you will end up with orphaned files/resources scattered around unless you explicitly tidy them up.
IME using Ansible for small-scale automation is no faster than just running the tasks manually, once development time is taken into account - you need tens of servers to make it worthwhile, by which point containers start to look more appealing.
> IME using Ansible for small-scale automation is no faster than just running the tasks manually, once development time is taken into account - you need tens of servers to make it worthwhile, by which point containers start to look more appealing.
Ansible has a very low learning curve. I cringe with the thought of the time it would take documenting then typing in all the commands to setup my servers manually. That's just not feasible. Ansible provides a sweet spot between traditional "pet" servers and containerisation.
It's not only the number of servers that matters. It's also about being able to create ephemeral staging/developer environments, and easily being able to easily migrate to different VM providers.
> IME using Ansible for small-scale automation is no faster than just running the tasks manually, once development time is taken into account
You aren't wrong here but still the payoff is typically worth it, especially for small scale. "Development time" is one factor but the alternative -- building servers or infrastructure manually -- causes all kinds of problems when individual servers are not consistent.
Ansible is great, but (imo) aged. Sure it's good for dealing with legacy hardware that cannot support terraform like state, but (imo) untyped yaml and excessive playbook runtimes turn into significant development drain as you scale.
Ansible solved a large problem (config management) before the kubernetes era, but containerization accomplishes the same goal for most applications before deployment.
I don’t disagree, but what is there for a terraform-like state config management system for bare metal and VMs when they are necessary? What provisions the machines that run the clusters?
Hate to only shill hashi stack but packer if you must. All you need is a container runtime and linux kernel. After that you shouldn't have to think about the core node.
If you're _really_ bare metal - build the base image, boot pxe and run apt update - not much more complicated than that.
I see Ansible as a glorified task runner and every time I’ve used it, never get the same results twice. Idempotency is by convention only and if a single step fails it can be hard to recover.
Nix has its warts however I think what Nix tries to achieve is what most people want on bare metal instead of Ansible. Declarative, you describe the end state then nix makes it happen. Exactly the same as Terraform.
It’s been a very long time since I’ve used Chief/Puppet but found them much better than Ansible also. The thing is any professional job I do now, every one uses Ansible as much as I dislike programming in YAML.
I agree with you there as well. Ansible was great in theory but I’m with you in that I feel like I rarely got idempotent results like I would with Terraform.
Is there anything in Ansible that is susceptible to aging?
I mean, Ansible is a tool designed to apply idempotent changes on one or more computer nodes following a declarative specification, and that only requires ssh access to work. What is there to age?
> Sure it's good for dealing with legacy hardware that cannot support terraform like state,
What? Exactly what leads you to believe that anything in Ansible is tied to hardware, let alone legacy hardware? And what do you mean by "terraform like state"?
> but (imo) untyped yaml and excessive playbook runtimes turn into significant development drain as you scale.
I don't understand what you tried to say, and frankly your comment sounds like an AI-generated buzzword soup.
With Ansible you need to specify the configuration state you want your nodes to have, and you need to apply configuration changes in a consistent sequence. This means not only specifying the configuration changes but also the verification and validation checks. The extent of your playbooks depend on how extensive your configuration is.
> Ansible solved a large problem (config management) before the kubernetes era (...)
Your comment makes absolutely no sense at all. Kubernetes provides a way to create clusters and run apps on them, but COTS hardware or VM instances aren't magically born into a working cluster node. What Kubermetes does is something that bears no resemblance to what Ansible actually does. Ansible is used to configure nodes without requiring anyone to install any specialized software other than setting up a working SSH connection. I personally use Ansible for stuff like setting up a Kubernetes cluster on COTS hardware running fresh Ubuntu installs using MicroK8s. How exactly do you expect to pull that off with Kubernetes?
2. I mean I don't use ansible with any cloud, only with hardware or legacy on prem stacks - older versions of Cisco, Netapp, Vmware. I prefer a stateful system like terraform to a stateless one like ansible.
3. I like typed languages. I hate yaml. Logic in ansible playbooks (yaml) is inevitable and a nightmare at scale.
4. Having moved to a container orchestrator, all of my nodes are immutable, I do not change or modify them. Hardware and VM instances _can_ be born magically into existence. Nearly all infra providers support [cluster-api](https://cluster-api.sigs.k8s.io/) or some other autoscaling controller. Network infrastructure can now be managed with TF, so I go that route.
> Ansible solved a large problem (config management) before the kubernetes era, but containerization accomplishes the same goal for most applications before deployment.
Depends on the size of your business. For small-medium size businesses, Ansible and VMs require much less support and developer knowledge than Kubernetes and containerisation.
I worked for a business with a million customers who served them using 10 VMs.
Kubernetes for small and medium businesses is extremely inefficient. I definitely wouldn't want to be dealing with that at this stage of my business's growth.
Not sure how containerization would help in case of for instance network devices or baremetal servers management. You've picked only a small use case for Ansible, there's much more.
21 comments
[ 3.7 ms ] story [ 65.2 ms ] threadThanks!
Ansible is so much more powerful than Terraform (IHMO, due to its pre-cloud roots). Too bad about lack of a "revert" feature/pattern and lack of multi-repo glue/scaffolding.
- Run a playbook which asserts the existence of a user
- Playbook fails at a later stage
- Executing an earlier version of the playbook which doesn't have the user assertion won't cause the user to be removed, just ignored. You need a different (assert not-existing) statement to actually remove the user.
In general these things won't be impactful - but they do mean that if you iterate on your deployment playbooks, you will end up with orphaned files/resources scattered around unless you explicitly tidy them up.
IME using Ansible for small-scale automation is no faster than just running the tasks manually, once development time is taken into account - you need tens of servers to make it worthwhile, by which point containers start to look more appealing.
Ansible has a very low learning curve. I cringe with the thought of the time it would take documenting then typing in all the commands to setup my servers manually. That's just not feasible. Ansible provides a sweet spot between traditional "pet" servers and containerisation.
It's not only the number of servers that matters. It's also about being able to create ephemeral staging/developer environments, and easily being able to easily migrate to different VM providers.
You aren't wrong here but still the payoff is typically worth it, especially for small scale. "Development time" is one factor but the alternative -- building servers or infrastructure manually -- causes all kinds of problems when individual servers are not consistent.
Ansible solved a large problem (config management) before the kubernetes era, but containerization accomplishes the same goal for most applications before deployment.
If you're _really_ bare metal - build the base image, boot pxe and run apt update - not much more complicated than that.
Nix has its warts however I think what Nix tries to achieve is what most people want on bare metal instead of Ansible. Declarative, you describe the end state then nix makes it happen. Exactly the same as Terraform.
It’s been a very long time since I’ve used Chief/Puppet but found them much better than Ansible also. The thing is any professional job I do now, every one uses Ansible as much as I dislike programming in YAML.
Is there anything in Ansible that is susceptible to aging?
I mean, Ansible is a tool designed to apply idempotent changes on one or more computer nodes following a declarative specification, and that only requires ssh access to work. What is there to age?
> Sure it's good for dealing with legacy hardware that cannot support terraform like state,
What? Exactly what leads you to believe that anything in Ansible is tied to hardware, let alone legacy hardware? And what do you mean by "terraform like state"?
> but (imo) untyped yaml and excessive playbook runtimes turn into significant development drain as you scale.
I don't understand what you tried to say, and frankly your comment sounds like an AI-generated buzzword soup.
With Ansible you need to specify the configuration state you want your nodes to have, and you need to apply configuration changes in a consistent sequence. This means not only specifying the configuration changes but also the verification and validation checks. The extent of your playbooks depend on how extensive your configuration is.
> Ansible solved a large problem (config management) before the kubernetes era (...)
Your comment makes absolutely no sense at all. Kubernetes provides a way to create clusters and run apps on them, but COTS hardware or VM instances aren't magically born into a working cluster node. What Kubermetes does is something that bears no resemblance to what Ansible actually does. Ansible is used to configure nodes without requiring anyone to install any specialized software other than setting up a working SSH connection. I personally use Ansible for stuff like setting up a Kubernetes cluster on COTS hardware running fresh Ubuntu installs using MicroK8s. How exactly do you expect to pull that off with Kubernetes?
2. I mean I don't use ansible with any cloud, only with hardware or legacy on prem stacks - older versions of Cisco, Netapp, Vmware. I prefer a stateful system like terraform to a stateless one like ansible.
3. I like typed languages. I hate yaml. Logic in ansible playbooks (yaml) is inevitable and a nightmare at scale.
4. Having moved to a container orchestrator, all of my nodes are immutable, I do not change or modify them. Hardware and VM instances _can_ be born magically into existence. Nearly all infra providers support [cluster-api](https://cluster-api.sigs.k8s.io/) or some other autoscaling controller. Network infrastructure can now be managed with TF, so I go that route.
Depends on the size of your business. For small-medium size businesses, Ansible and VMs require much less support and developer knowledge than Kubernetes and containerisation.
I worked for a business with a million customers who served them using 10 VMs.