7 ms·

“Ansible for DevOps” eBook by Jeff Geerling Is Now Free

89 points by codetrotter 3y ago

asfarley 3y ago
I’m currently using some of his Ansible scripts, they are the right balance of complexity for my projects.
AndrewDavis 3y ago
I prefer paper books, and have a copy of this. But it'll be great to have the ebook too for access to updates since my paper copy was printed. Thanks!
ed-209 3y ago
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.
- ChrisRR 3y ago
  Do you have a link to that? I've done a quick google but I have zero server experience so don't know what you're referring to
- planetafro 3y ago
  I do understand your point but would counter that, if done right, you can revert your last commit. :)
  - anyoneamous 3y ago
    Sadly it's not that simple. For example: - 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.
    - listenallyall 3y ago
      > 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.
    - okeuro49 3y ago
      > 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.
chologrande 3y ago
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.
- jonwest 3y ago
  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?
  - chologrande 3y ago
    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.
    - jonwest 3y ago
      Forgot about Packer! Thanks! That’s probably the closest equivalent.
  - tiew9Vii 3y ago
    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.
NickKampe 3y ago
Incredible book that helped me along on my journey, forever grateful!

89 points by codetrotter 3y ago

I’m currently using some of his Ansible scripts, they are the right balance of complexity for my projects.

I prefer paper books, and have a copy of this. But it'll be great to have the ebook too for access to updates since my paper copy was printed. Thanks!

ed-209 3y ago

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.

ChrisRR 3y ago
Do you have a link to that? I've done a quick google but I have zero server experience so don't know what you're referring to
planetafro 3y ago
I do understand your point but would counter that, if done right, you can revert your last commit. :)
- anyoneamous 3y ago
  Sadly it's not that simple. For example: - 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.
  - listenallyall 3y ago
    > 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.
  - okeuro49 3y ago
    > 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.

chologrande 3y ago

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.

jonwest 3y ago
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?
- chologrande 3y ago
  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.
  - jonwest 3y ago
    Forgot about Packer! Thanks! That’s probably the closest equivalent.
- tiew9Vii 3y ago
  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.

NickKampe 3y ago

Incredible book that helped me along on my journey, forever grateful!