“Ansible for DevOps” eBook by Jeff Geerling Is Now Free
leanpub.com
leanpub.com
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.
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.
Thanks!