One of the first things I did when I started my deep-dive into network automation topics was to figure what tools people use to automate stuff and (on a pretty high level) what each one of these tools do.

You often hear about Ansible, Chef and Puppet when talking about network automation tools, with Salt becoming more popular, and CFEngine being occasionally mentioned. However, most network automation engineers prefer Ansible. Here are a few reasons.

Before you start writing a comment telling me how everything could be done with your favorite tool, which is theoretically true assuming your tool is Turing-complete, do consider that it’s also possible to build a hand-made log cabin with a Swiss Army knife… but it might be a bit awkward and take a long time. OTOH, if I made a fundamental error of judgement, please do chime in.

As I explained in the Network Automation Tools webinar (also part of Ansible for Networking Engineers and Building Network Automation Solutions online courses) Chef and Puppet focus mostly on configuration and state management: given the current and desired state of managed devices (including configuration), execute the changes needed to bring the current state to desired state. Both of them are idempotent (making no changes unless necessary) and can manage dependencies (for example: you have to create a group before creating accounts belonging to that group).

Managing configurations and soft state (active/disabled services) is great, but we need to do much more in networking. For example, I’ve seen Ansible used for device provisioning (breaking out of the Setup process), creating reports, performing compliance checks, upgrading software, validating networking topology…

Also, Chef and Puppet take the eventually we’ll get there somehow path. It works great, but networking engineers prefer to have more control: we want to do this one thing at this particular time. Maybe it’s just our mentality, or maybe we have to do things a bit different because of the huge blast radius of our mistakes. In any case, Ansible (which is just a generic automation/orchestration framework) fits better to our way of doing things.

Everyone claims Ansible is simpler to master than Chef or Puppet (read also more explicit opinion). I know you can get going in a few hours (and if you believe in Google-and-Paste here are a few sample playbooks to get you started), but if you’re serious about becoming a network automation engineer it’s nonetheless worth investing some time into learning it properly. Ansible documentation is great, and there are tons of examples out there, but if you prefer a guided tour, do check out the Ansible for Networking Engineers webinar or online course.

Finally, once you’re ready to move beyond simple automation and start working on full-blown solutions, it’s time to step back and look at the bigger picture. Yet again, you’ll probably get there on your own, or you could enroll into the Building Network Automation Solutions online course.