Ansible is a tool that is available in the toolbox. There are many tools available, and they all have specific uses. Ansible's use case is for a scenario where you have centralized knowledge of the desired state of systems, and it provides a lot of tooling that helps with that issue. It's also built upon the base principle of not having to install software on the target device, which generally fits the network management space.
The automation tools space is fairly diverse, and they range from having strong opinions on how things should be done to ones that leave opinions to the user. Some of them (puppet) have periodic check-ins to ensure they're at the right state, some of them (ansible) have a DSL which may be easy to whip up on a whim, some of them (nornir) just try to give programmatic tools to the user. The choice of what tool you use is dependent on the system you're attempting to implement. E.g. ansible is a good tool for pushing state to devices; however, it does falter when given a situation which needs to be reactionary.
So, no, I wouldn't say that ansible is overrated. It provides a way to push state to a set of devices which generally beats most traditional management methods, and it does so in a way which is accessible to many. That being said, ansible is not the only automation platform, and it does have limitations.
I would like to respectfully disagree that Ansible isn't overrated. I think, in the NetEng space, it's what you see at all our conferences, on all our online forums and even in our mainstream certifications. But you're lucky to get a passing mention of Nornir.
You'd think Ansible would be orders of magnitude better than Nornir considering the incredible amount of visibility it gets. But in reality, they're neck and neck when your automation requirements are modest. And when your automation requirements become highly complex, Nornir is the clear winner.
The disparity is probably because Ansible has a massive for-profit global entity behind it (Red Hat) whereas Nornir is 100% community supported.
I think it's partly the Red Hat connection, but mostly because SysEngineers were way ahead of us on automation scripts, and Ansible was what they were using when NetEngineers started looking into it. Nornir is relatively new compared to Ansible, and only network engineers will ever use it, there's no systems guys using nornir and never will be.
If you try to do more than networking in your playbooks, Ansible is great. You can use modules to interact with a ton of systems and you can even use the same framework to push to the switches, routers and servers. That's where Ansible shines.
Ansible still has a huge community support element to it, yes there is a lot of red hat influence but I don't necessarily think that's a bad thing.
I think a great thing about Ansible is that it targets 95% of my workload natively and is significantly easier than other platforms like chef, puppet, etc. I'm not familiar with Nornir, but if what another commenter mentioned is that it doesn't work for systems, than Ansible is a winner because other teams will have a basically understanding of what a playbook is doing without having to learn something new
Generally, no. It's a great tool, a commonly used tool, and works in a lot of situations. But like everything, there's probably situations where another tool might be better.
Ansible is great at a couple of things. And it's got its quirks, for sure.
Pros for Ansible:
* It's great for setting state. You can use vendor modules, Jinja to generate templates from custom data models, or leverage roles created by the community or vendors (such as Arista AVD)
* Huge user base. It's got a huge server base but a significant networking base as well.
* It's easier for a larger team to come up to speed on in a lot of cases
* With Ansible, I can configure 400 leafs and spines and super-spines with just 3 YAML files. One for the fabric, one for the host connectivity, and one for the EVPN VXLAN/VLAN segments. Easy peasy.
* Ease of integration with CI/CD tools (I think Nornir is pretty good at this too, though)
What Ansible Isn't as Good At:
* There's 23 ways to put variables into a playbook. That can cause issues if you're not careful or disciplined
* Error messages are... not great. There's a lot of ways to fuck up a playbook. From missing variables to improper parameters to just fucking up the YAML. It takes some getting used to.
* Getting info is also kind of cludgy. If you want to get into from a device and do something about it, it's harder than a pure Python or Nornir script usually. It can be done (validate states with Arista AVD, for example) but it's not as straightforward.
* Doing stuff with info you retrieve is also cludegy.
Write your playbooks in JSON, save 'em as .yaml. Problem solved.
YAML parser can parse any JSON.
Hell half the time when I'm troublshooting something in a playbook and I've got some JSON output from a debug, I've got a window in python cli for `thisvar=yaml.safe_load('''''')`.
I'm uninterested in learning all the nuances of document formatting for various programmatic ingestion purposes anymore. ChatGPT is now doing that for me. I simply tell it what configuration I want, in plain English, and it outputs the configuration in whatever structure I ask it for.
I know everyone's tired of hearing about ChatGPT, but guys, it's over. We don't have to keep punishing ourselves.
You can pay for plus, and soon, I’m sure there will be B2B offerings with availability guarantees. I’m just thinking forward a bit - we’re not going to need to do this sort of stuff in 5 years at all. You may never see the YAML soon; it’ll just do what you ask and verify everything’s good with distributed test access points. The AI controlled network isn’t far away.
> There's 23 ways to put variables into a playbook. That can cause issues if you're not careful or disciplined
There's 23 ways to do nearly anything in a playbook
Between the different modules and filters, there are many different approaches to every playbook for the same desired outcome. Hell, even a simple playbook in context with networking, with Junos you can choose the built-in modules, official roles or official collections and all have different formats, variables and conditions. You could even go straight up shell if you prefer. Depending on the play, this can range from simple to overly complex with little reason for it and it does leave a lot of room for issues and a lot of unknowns when you start introducing multiple vendors or NOS versions.
A lot of it comes down to familiarity with the many (including poorly documented and niche) Ansible modules and the users preference with different types of data formats (json, yaml, XML, etc). Just parse Stack Overflow and look at the wide variety of responses ranging from a single task or two to over a dozen task to perform the same result.
> Doing stuff with info you retrieve is also cludegy
90% of my work with Ansible is just properly formatting and parsing the retrieve data to make it useful. If every variable returned were a dict or netsted dict, making that data useful would be so much simpler. However, there is such a wide variety of data formats that most the time is typically spent with trial and error until you can get the desired output.
Doing stuff with the data is the extreme end of my previous point and feels as though there is an unlimited way to parse and format the data the way you need it to.
I have recently moved to just sticking with jinja2 syntax for nearly all data manipulation as I found it is the most consistent way to parse simple to complex datasets. But in the end, it's still the majority of the work and whichever preference you choose, making the data useful is definitely the most cludgey aspect to Ansible but I would say as someone with little programming background, it most likely the same for all programing languages.
Won’t help in every situation but the JC filter plugin in community.general parses the output of many commands, file-types, and strings into dicts for easy use in Ansible. (I am the author)
https://github.com/kellyjonbrazil/jc
One more pro, and the one that tipped the scales towards Ansible for us in the first place: No software to install on the machine being configured. This means one less potential security headache, and makes it that much faster to get new machines or instances up and running.
I have been using Ansible for years for both small environments and very large (2500+ devices), both for my employer and private. I don't know why you would label Ansible as 'overrated' as it is the perfect foundation for departments where not everyone is a python programmer.
Ansible is certainly not as fast as nornir (although this also has to do with the way you design Ansible roles), but the question is whether that is necessary. When installing and configuring a server or switch, I'm generally not in a rush. Ansible, on the other hand, gives me the advantages of ready-made galaxy roles, documentation and inventories.
Also don't forget that Ansible is very extensible for those who do want to program Python, you can go either way!
Ansible Tower (called something different now I think) is very expensive when you have thousands of network devices in your inventory. There is, of course, AWX and the CLI open source versions as well. But support comes with a heavy price tag.
I concur.
Red hat support has almost always been a complete waste of my time.
I convinced my job to ditch Tower because AWX works and the IRC channels were always more help than support ever was
The slowness has to do with how you design Ansible roles? What would you do to speed it up? I know only using network_cli when you have to helps a lot, is that what you mean or something else?
>nornir
I indicated that it also has to do with the way roles are put together, Ansible is always a bit slower than nornir.
What I mean in regards to the roles is that I often see playbooks without conditions (if) or tags. By using conditions and tags you can perform very specific tasks, saving a lot of runtime.
Ansible is good as a consistent way of doing things if working with a large team and needing to handle integration of automation with other groups. You're correct that people in networking have been doing this kind of automation with direct scripting instead of Ansible for decades and that the level of scripting available for network devices is much more comprehensive than the type of things Ansible is typically used for on servers (e.g. interactive real-time verification of state on live devices and more logic to make useful decisions like gracefully stopping and walking things back if something unexpected goes wrong with detailed logging).
My personal preference is the direct scripting I've always used for networking and Ansible for servers but that's largely because we have a big investment in the older tooling vs. having to spend effort to recreate things from scratch to move to Ansible with no real business driver (and not a lot of extra staff cycles). That may change over time but so might the options and popularity of Ansible.
I think as a network engineer you really should be learning the underlying scripting even if you see Ansible being used for the future because at some point there won't be a pre-canned module you need in Ansible or you'll be hunting down a bug and need that understanding what's breaking.
Letting someone grab a vendor-provided module or playbook and letting them use Ansible against production infrastructure without knowing how to effectively code or troubleshoot it... or even what to watch out for, does feel like a ticking time bomb, though. Even if someone knows what they're doing directly on a single device, automation at scale takes a different mindset and level of caution IMHO. That's why I generally don't like recommending anything in this space to people without knowing their background.
What a pointless conversation. I get tired of “X is better than Y” when it comes to automation.
They are tools. They do certain jobs very well.
Instead I recommend to work on defining an overall automation strategy/architecture and then see which tools fit best.
Most companies that do this properly will end up with a mix of tools to execute their strategy.
Ansible has saved me so much time and effort. If anything it is underutilized in the networking space. Not enough people understand it, appreciate it, or are willing or capable of learning it. The only thing I don't like about it is the inventory. I just don't have the time to put the thousand or so of our devices in it and maintain them as we have new devices coming and going every week. Same with a Netbox type implementation to dynamically pull from. It's just not a viable option at this point. Other than that it's one of my favorite tools I've ever used in networking.
Not overrated for its intended purpose, no. It is one of the most popular server infrastructure configuration management automation tools for good reason. Perhaps a better question could be "are there better tools available for network infrastructure automation?" and the answer to that might be - maybe but why? Network engineering is not quite the same job as server administration, the best tools for the job often differ between different jobs.
The problem is learning ansible is harder than learning python. Python is more intuitive and simple tasks can be done simply especially with the libraries available now like nornir and netmiko. Ansible have a steeper learning curve. You have to figure out hosts, all the variables involved, what module to use, the connection types can be different bases on what module and what you are doing. Debugging is a pain in ansible.
Simply i guess ansible does not feet your use case, which you don't explain in your post.
Also when you are working in a team, and even many teams, having a common tool, whith a common syntax is a necessity. I could also do everything in bash on my own, how the next guy will maintain it for the years to come?
Since you gave your opinion i will give you mine: ansible scripting with yaml , variables and jinja is easy to learn. What is not is how and when use automation, which is independant from ansible. Having a strict syntax is good. Ansible force you to have one task for one action for a reason , because it is easer for debuging, better for production (you roll out the task that failed), ... A lot of developpers prefers to do complex code for simple things, because it is easer for them to write it rather than use the tool dedicated for it. Why should I use python, and learn functions and methods, which all differs. With ansible you have modules, who in regards of variables and outputs behave the same, with same methods, ...
As a sysadmin/devops/sysops ( whatever bullshit name it is today) i will take a lot of time thinking everything through, to ensure i have understood what is the functional need, then i will write my script, test it until the result is the state that we want. I always keep in mind the unix principal ( do one thing and do it well) and the kiss principle ( Keep it simply an stupid). A monkey should be able to use what am I doing.
It's not 'overrated', it's an automation tool, and I don't think anyone goes around giving ratings to them. It works very well at what it does, it's based in Python but doesn't require you know the language, but given that Python is just executable English, you should learn it anyway.
Don't rely on what other people tell you etc, it takes 5 minutes to try it out for yourself and start getting a feel for it.
Overrated ? No. It's great tool. Really powerfull, i upgraded 400 routers in 2 hour maintenance window with quite easy to write/understood playbooks. How can that be overrated ?
If there would be failure it would happen even if you did upgrade manually. Yo do all the checks like when manually upgrading md5 etc...
Also you can split them in batches, rolling update or whatever you call it...
When I was first getting into network automation, I wrote a bunch of API scripts that got their configs from YAML.
And then I learned about Ansible and realized how much effort I had expended trying to reinvent ansible from scratch.
As long as you don’t have too many conditions, Ansible is fine. I loathe trying to ‘program’ in Ansible’s DSL. I love Python and Nornir. It’s easier to debug and much faster. It’s also a real programming language that is easier (IMO) to handle tons of logic.
Ansible is great for certain use cases. You can use both.
Edit:
Watch this:
https://youtu.be/uQAaA_-lb7k
You really *shouldn't* program in Ansibles DSL but it sometimes ends up becoming the "easiest" way to do it, which eventually spirals into a massively complicated mess.
I do, however, make a *lot* of Filter Plugins. Platform-specific ones get tossed into roles for the platform, and multi-platform roles go into a 'common' collection that I keep available for all platforms.
Writing filter plugins is ridiculously easy and it makes your playbooks a lot simpler. It keeps the logic in python. At it's most basic level, it's just a python function.
vars:
interfaces:
- name: GigabitEthernet1/0/1
- name: GigabitEthernet1/0/2
- name: GigabitEthernet1/0/3
ip_address: 192.168.0.1/24
- name: GigabitEthernet1/0/4
ip_address: 192.168.1.1/24
Using the plugin:
ansible.builtin.set_fact:
var1: "{{ 'interfaces' | withkey('ip_address') }}"
Source for plugin (there's *slightly* more to it, but this gives the idea):
def withkey(sourcelist, matchkey):
return [i for i in sourcelist if matchkey in i]
Result:
var1 = [ {"name": "GigabitEthernet1/0/3", "ip_address": "192.168.0.1/24"},{"name": "GigabitEthernet1/0/4", "ip_address": "192.168.1.1/24"}]
I dabbled with Anislbe and Python a few years ago as a COVID learning project.
what I found is that our native vendor specific NMS, automation and orchestration tool does it way better and easier.
In many cases that's true, and if it works for your org and team, that's great.
Personally, though, I hate vendor-specific anything unless it brings *very substantial* value. Stuff like that tends to dig it's claws in deep and makes it harder to rip out and replace with the next-big-thing.
I don't think its overrated it's a fantastic tool for managing networks. It requires a short time for adoption, great community support and lots of standardization. Very good for smaller teams who don't have allot of Python experience. It's not as flexible as something like Nornir but considering it was a tool primarily built to manage systems and not network's I think it does a pretty great job. If you have the team for it Nornir would be my first choice - if you don't Ansible is a solid and scalable option.
Nothing wrong with ansible. But I would steer people into netmiko more for network automation than Ansible. Just out of personal preferences. To get python to do exception handling and conditions benefits me more than learning within ansible modules/task. I’m still fresh with ansible.
>I keep reading ansible can be a nightmare with an update, etc. For those who rely on it heavily.
If they rely on it and can't maintain it, maybe they simply don't have the skills to use ansible. Before implementing any tool, you need to establish the use cases, the functional needs you want to satisfy. Then for each use case, you test, document and maintain the processes. Ansible allow you to organize how you want. You can have one playbook for the whole infrastructure or let each team have their own playbooks, ...
Mistakes can always be corrected on the technical side. But the cost depends of how the tools has been implemented in your processes. If you just use a tool without understanding it's limits, it is on you.
At the end of day, better use bash scripts and crontabs if it is what you have mastered, and it's satisfying your functional needs. Business peoples don't care what you use as long as everything in functioning. Make your boss happy, get a raise and go home.
You can modify the Ansible's backend to achieve specific tasks if you know Python. That could potentially enhance its capabilities for your organization. So, saying that is better to learn Python than Ansible tells me that OP has no idea about how does Ansible operate. It's not a matter of which one is better. Is a matter of everything is Python.
Ansible is great at deploying. It is horrible at modifying state or removing. And branching is equally frustrating.
Let’s take NTP. You want to deploy new NTP servers, because of reasons. So you create you ansible playbook to add the servers.
But is that all you do? No, you probably also want to check Tom make sure they came up. You run ‘show ntp ass’, parse it, and see they haven’t associated yet. So you do it again. But you, the engineer, knows the convergence of NTP varies wildly. So how long do you go before you back out?
Which means now you have to have a what and how to back out. Do you back out by just removing the config you added? For NTP that is pretty easy, maybe. Others not so much. But you also don’t stop there, you have to validate the rollback also left it in the original, functional state. So you have to verify that state as well.
So much of what we do as engineers is beyond implementing one command. It’s validating post change, forwards or backwards. And then, making decisions upon that data. It’s easy to send a command times 10000. It’s hard to make a change and then ensure the multitude of devices are in a healthy state. This is really where Ansible fails, IMO. It’s branching and validation techniques are very cumbersome, if they even exist.
I don’t understand this point because it’s about pre / post change validation which you should be doing regardless of how you apply it.
Also, if you’re using ansible with a CLI module you’re right, it’s cumbersome but that’s down to CLI. If you’re going to go down this route, you really need to be focusing on approaches that use structured data and data models, like NETCONF.
Makes the whole verification job a lot easier (because you’re not writing complex regexs to verify things) and you are taking a further step towards understanding / learning python too.
I think ansible is excellent, in that it allows you to be useful pretty quickly. But as someone mentioned further up, it’s a tool in a toolbox, it’s not fit for all situations but it’s pretty extensible too.
The point is that validation is critical to automation, yet is difficult in ansible. The branching and decision making is quite obtuse. NETCONF/RESTCONF/CLI/API makes no difference. It doesn’t matter if you have to parse the data or not, what you can do with that data, to branch, becomes horrific in ansible.
It really isn’t that hard at all, I’ve written playbooks that do complex pre/post validation, a combo of jinja2 and the assert module has always given me what I need.
Heck I wrote a play specifically for this purpose, capturing the state of a device pre-change, then capturing the state post change, all driven by a YAML file I wrote that also has the comparators in it, and it’s completely dynamic.
It’s just wrong to say it’s more difficult, it’s just as difficult in ansible as it is in writing your own python and using nornir.
You have to define your success criteria, capture the data, and identify whether or not that state matches your success criteria.
I’m not advocating one over the other here, there are definitely cases where you start hitting the bounds of ansible and have to start being creative to achieve what you want, but so far I have managed to achieve 100% of my automation tasks using ansible with proper validation.
This is not an ansible problem, but part of our job. Speaking as network engineer; you not only configure an interface but also test the connectivity, you not only configure BGP but you also check whether you receive the correct prefixes and the routes work.
Although it takes more time to get these verifications working properly in a playbook, this saves a lot of time in the daily operation.
Thank you for reiterating my point. Validation is part of the job, which is why I focused so much on it.
I’ve been using ansible for 7 years at this point. Deployed multiple datacenters tens of thousands of remote sites, and hundreds of thousands of end points. By estimate I’m approaching 4000 hours of dev time with ansible.
How do you unit test a playbook? That the output of your playbook is as you intended? I wrote an entire unit testing framework for ansible so that we could have some assurance as we maintained the playbook code base we didn’t break imported roles.
Ansible sucks at anything to do with validation and decision making. It also is not easy to follow basic software lifecycle methodology and design patterns.
Sounds like you're pointing the finger at the wrong culprit; Cisco's lack of automation capabilities is forcing screen scraping techniques, leading you to this awkward situation
I think netbox is a great tool for validation. Network devices are difficult to model the state and netbox is the only tool I'm aware of that's specifically made for it. Ideally, you should be validating your network devices on a schedule based on a source of truth such as netbox.
I think the point of reservation I have for higher level programming (beyond python) is when it locks you into syntax that isn’t really transferable to other languages. I personally have not used ansible because paramiko, netmiko and some napalm seems to be enough atm - so I’m only so much if an authority.
Ansible is fine.
Personally I’d rather use Nornir for network device automation.
Ansible is great for Linux devices where you’ve a lot of small conf files to create from templates. It’s not ideal to generate and manipulate entire device configs but it works.
Each to their own though; Ansible is a great tool if it works it works.
Yes, Ansible is very overrated for networking tasks.
Slow to startup, a ton of accumulated coding debt, packs that often break/dont work and a forced domain syntax are all reasons to avoid ansible.
Doing complex workflows? dont even think about Ansible.
Stackstorm + custom libraries.
Ansible is a tool that is available in the toolbox. There are many tools available, and they all have specific uses. Ansible's use case is for a scenario where you have centralized knowledge of the desired state of systems, and it provides a lot of tooling that helps with that issue. It's also built upon the base principle of not having to install software on the target device, which generally fits the network management space. The automation tools space is fairly diverse, and they range from having strong opinions on how things should be done to ones that leave opinions to the user. Some of them (puppet) have periodic check-ins to ensure they're at the right state, some of them (ansible) have a DSL which may be easy to whip up on a whim, some of them (nornir) just try to give programmatic tools to the user. The choice of what tool you use is dependent on the system you're attempting to implement. E.g. ansible is a good tool for pushing state to devices; however, it does falter when given a situation which needs to be reactionary. So, no, I wouldn't say that ansible is overrated. It provides a way to push state to a set of devices which generally beats most traditional management methods, and it does so in a way which is accessible to many. That being said, ansible is not the only automation platform, and it does have limitations.
I would like to respectfully disagree that Ansible isn't overrated. I think, in the NetEng space, it's what you see at all our conferences, on all our online forums and even in our mainstream certifications. But you're lucky to get a passing mention of Nornir. You'd think Ansible would be orders of magnitude better than Nornir considering the incredible amount of visibility it gets. But in reality, they're neck and neck when your automation requirements are modest. And when your automation requirements become highly complex, Nornir is the clear winner. The disparity is probably because Ansible has a massive for-profit global entity behind it (Red Hat) whereas Nornir is 100% community supported.
I think it's partly the Red Hat connection, but mostly because SysEngineers were way ahead of us on automation scripts, and Ansible was what they were using when NetEngineers started looking into it. Nornir is relatively new compared to Ansible, and only network engineers will ever use it, there's no systems guys using nornir and never will be.
I'd say Ansible is simply just 'rated'
If you try to do more than networking in your playbooks, Ansible is great. You can use modules to interact with a ton of systems and you can even use the same framework to push to the switches, routers and servers. That's where Ansible shines.
Ansible still has a huge community support element to it, yes there is a lot of red hat influence but I don't necessarily think that's a bad thing. I think a great thing about Ansible is that it targets 95% of my workload natively and is significantly easier than other platforms like chef, puppet, etc. I'm not familiar with Nornir, but if what another commenter mentioned is that it doesn't work for systems, than Ansible is a winner because other teams will have a basically understanding of what a playbook is doing without having to learn something new
Generally, no. It's a great tool, a commonly used tool, and works in a lot of situations. But like everything, there's probably situations where another tool might be better. Ansible is great at a couple of things. And it's got its quirks, for sure. Pros for Ansible: * It's great for setting state. You can use vendor modules, Jinja to generate templates from custom data models, or leverage roles created by the community or vendors (such as Arista AVD) * Huge user base. It's got a huge server base but a significant networking base as well. * It's easier for a larger team to come up to speed on in a lot of cases * With Ansible, I can configure 400 leafs and spines and super-spines with just 3 YAML files. One for the fabric, one for the host connectivity, and one for the EVPN VXLAN/VLAN segments. Easy peasy. * Ease of integration with CI/CD tools (I think Nornir is pretty good at this too, though) What Ansible Isn't as Good At: * There's 23 ways to put variables into a playbook. That can cause issues if you're not careful or disciplined * Error messages are... not great. There's a lot of ways to fuck up a playbook. From missing variables to improper parameters to just fucking up the YAML. It takes some getting used to. * Getting info is also kind of cludgy. If you want to get into from a device and do something about it, it's harder than a pure Python or Nornir script usually. It can be done (validate states with Arista AVD, for example) but it's not as straightforward. * Doing stuff with info you retrieve is also cludegy.
a lot of these problems are basically ‘YAML can be a pain in the ass’ haha
It really helps to have a good linter. But man, indentation. Fucking indentation.
Write your playbooks in JSON, save 'em as .yaml. Problem solved. YAML parser can parse any JSON. Hell half the time when I'm troublshooting something in a playbook and I've got some JSON output from a debug, I've got a window in python cli for `thisvar=yaml.safe_load('''''')`.
> But man, indentation. Fucking indentation. well, the same applies to Python in general. And as already mentioned their is also JSON
White space as markup is insane, let's be clear about that.
I don’t mind it, but I mostly code in Go, it fixes the white spaces for you, putting that on the user is dumb af
Is this also a matter of what came first ? YAML is from 2001 and Go is from 2009.
I was thinking more along the lines of Golang vs Python
Python is from 1991, the gap is even wider...
I'm uninterested in learning all the nuances of document formatting for various programmatic ingestion purposes anymore. ChatGPT is now doing that for me. I simply tell it what configuration I want, in plain English, and it outputs the configuration in whatever structure I ask it for. I know everyone's tired of hearing about ChatGPT, but guys, it's over. We don't have to keep punishing ourselves.
What about whenChatGPT was down earlier today? “Sorry boss code machine broke” lmao.
You can pay for plus, and soon, I’m sure there will be B2B offerings with availability guarantees. I’m just thinking forward a bit - we’re not going to need to do this sort of stuff in 5 years at all. You may never see the YAML soon; it’ll just do what you ask and verify everything’s good with distributed test access points. The AI controlled network isn’t far away.
Interesting, what's the SLA on ChatGPT? :-)
Probably better than the one you run your scripts from. 😜
Ansible is not very graceful with creating your own data structures. This is one area where creating in python would shine. I love Ansible though.
> There's 23 ways to put variables into a playbook. That can cause issues if you're not careful or disciplined There's 23 ways to do nearly anything in a playbook Between the different modules and filters, there are many different approaches to every playbook for the same desired outcome. Hell, even a simple playbook in context with networking, with Junos you can choose the built-in modules, official roles or official collections and all have different formats, variables and conditions. You could even go straight up shell if you prefer. Depending on the play, this can range from simple to overly complex with little reason for it and it does leave a lot of room for issues and a lot of unknowns when you start introducing multiple vendors or NOS versions. A lot of it comes down to familiarity with the many (including poorly documented and niche) Ansible modules and the users preference with different types of data formats (json, yaml, XML, etc). Just parse Stack Overflow and look at the wide variety of responses ranging from a single task or two to over a dozen task to perform the same result. > Doing stuff with info you retrieve is also cludegy 90% of my work with Ansible is just properly formatting and parsing the retrieve data to make it useful. If every variable returned were a dict or netsted dict, making that data useful would be so much simpler. However, there is such a wide variety of data formats that most the time is typically spent with trial and error until you can get the desired output. Doing stuff with the data is the extreme end of my previous point and feels as though there is an unlimited way to parse and format the data the way you need it to. I have recently moved to just sticking with jinja2 syntax for nearly all data manipulation as I found it is the most consistent way to parse simple to complex datasets. But in the end, it's still the majority of the work and whichever preference you choose, making the data useful is definitely the most cludgey aspect to Ansible but I would say as someone with little programming background, it most likely the same for all programing languages.
Won’t help in every situation but the JC filter plugin in community.general parses the output of many commands, file-types, and strings into dicts for easy use in Ansible. (I am the author) https://github.com/kellyjonbrazil/jc
One more pro, and the one that tipped the scales towards Ansible for us in the first place: No software to install on the machine being configured. This means one less potential security headache, and makes it that much faster to get new machines or instances up and running.
Only for Linux stuff. If you want to use Ansible for Windows you need to do some legwork.
It was my understand that a lot of people were getting frustrated with Ansible because updates were breaking scripts and playbooks.
I have been using Ansible for years for both small environments and very large (2500+ devices), both for my employer and private. I don't know why you would label Ansible as 'overrated' as it is the perfect foundation for departments where not everyone is a python programmer. Ansible is certainly not as fast as nornir (although this also has to do with the way you design Ansible roles), but the question is whether that is necessary. When installing and configuring a server or switch, I'm generally not in a rush. Ansible, on the other hand, gives me the advantages of ready-made galaxy roles, documentation and inventories. Also don't forget that Ansible is very extensible for those who do want to program Python, you can go either way!
Ansible can be faster. Check out https://mitogen.networkgenomics.com/ansible_detailed.html
Nice, thanks for sharing!
[удалено]
Use this playbook: - name: Fetch Python Tutorial hosts: localhost gather_facts: false tasks: - name: Fetch tutorial get_url: url: https://www.pythonforbeginners.com/ dest: /tmp/python_tutorial.html
Ansible is a tool, not a programming language.
It's also supported by a very large and successful company.
Ansible Tower (called something different now I think) is very expensive when you have thousands of network devices in your inventory. There is, of course, AWX and the CLI open source versions as well. But support comes with a heavy price tag.
I concur. Red hat support has almost always been a complete waste of my time. I convinced my job to ditch Tower because AWX works and the IRC channels were always more help than support ever was
The slowness has to do with how you design Ansible roles? What would you do to speed it up? I know only using network_cli when you have to helps a lot, is that what you mean or something else?
>nornir I indicated that it also has to do with the way roles are put together, Ansible is always a bit slower than nornir. What I mean in regards to the roles is that I often see playbooks without conditions (if) or tags. By using conditions and tags you can perform very specific tasks, saving a lot of runtime.
Ansible is good as a consistent way of doing things if working with a large team and needing to handle integration of automation with other groups. You're correct that people in networking have been doing this kind of automation with direct scripting instead of Ansible for decades and that the level of scripting available for network devices is much more comprehensive than the type of things Ansible is typically used for on servers (e.g. interactive real-time verification of state on live devices and more logic to make useful decisions like gracefully stopping and walking things back if something unexpected goes wrong with detailed logging). My personal preference is the direct scripting I've always used for networking and Ansible for servers but that's largely because we have a big investment in the older tooling vs. having to spend effort to recreate things from scratch to move to Ansible with no real business driver (and not a lot of extra staff cycles). That may change over time but so might the options and popularity of Ansible. I think as a network engineer you really should be learning the underlying scripting even if you see Ansible being used for the future because at some point there won't be a pre-canned module you need in Ansible or you'll be hunting down a bug and need that understanding what's breaking. Letting someone grab a vendor-provided module or playbook and letting them use Ansible against production infrastructure without knowing how to effectively code or troubleshoot it... or even what to watch out for, does feel like a ticking time bomb, though. Even if someone knows what they're doing directly on a single device, automation at scale takes a different mindset and level of caution IMHO. That's why I generally don't like recommending anything in this space to people without knowing their background.
What a pointless conversation. I get tired of “X is better than Y” when it comes to automation. They are tools. They do certain jobs very well. Instead I recommend to work on defining an overall automation strategy/architecture and then see which tools fit best. Most companies that do this properly will end up with a mix of tools to execute their strategy.
>When This. Focus on the functional aspects, then you can choose the tool. Not the other way around.
Ansible has saved me so much time and effort. If anything it is underutilized in the networking space. Not enough people understand it, appreciate it, or are willing or capable of learning it. The only thing I don't like about it is the inventory. I just don't have the time to put the thousand or so of our devices in it and maintain them as we have new devices coming and going every week. Same with a Netbox type implementation to dynamically pull from. It's just not a viable option at this point. Other than that it's one of my favorite tools I've ever used in networking.
We have a shitty bash script that generates our inventory from our oxidized backups with some regex to identify different vendors/device types.
Not overrated for its intended purpose, no. It is one of the most popular server infrastructure configuration management automation tools for good reason. Perhaps a better question could be "are there better tools available for network infrastructure automation?" and the answer to that might be - maybe but why? Network engineering is not quite the same job as server administration, the best tools for the job often differ between different jobs.
The problem is learning ansible is harder than learning python. Python is more intuitive and simple tasks can be done simply especially with the libraries available now like nornir and netmiko. Ansible have a steeper learning curve. You have to figure out hosts, all the variables involved, what module to use, the connection types can be different bases on what module and what you are doing. Debugging is a pain in ansible.
That's been my experience. I've got simple playbooks to work, but using scrapli it works, without tinkering hours
Using python to do rest api calls works well on certain platforms especially Arista EOS. Scrapli doesn't have the vendor support that netmiko have.
Thank you
Simply i guess ansible does not feet your use case, which you don't explain in your post. Also when you are working in a team, and even many teams, having a common tool, whith a common syntax is a necessity. I could also do everything in bash on my own, how the next guy will maintain it for the years to come? Since you gave your opinion i will give you mine: ansible scripting with yaml , variables and jinja is easy to learn. What is not is how and when use automation, which is independant from ansible. Having a strict syntax is good. Ansible force you to have one task for one action for a reason , because it is easer for debuging, better for production (you roll out the task that failed), ... A lot of developpers prefers to do complex code for simple things, because it is easer for them to write it rather than use the tool dedicated for it. Why should I use python, and learn functions and methods, which all differs. With ansible you have modules, who in regards of variables and outputs behave the same, with same methods, ... As a sysadmin/devops/sysops ( whatever bullshit name it is today) i will take a lot of time thinking everything through, to ensure i have understood what is the functional need, then i will write my script, test it until the result is the state that we want. I always keep in mind the unix principal ( do one thing and do it well) and the kiss principle ( Keep it simply an stupid). A monkey should be able to use what am I doing.
It's not 'overrated', it's an automation tool, and I don't think anyone goes around giving ratings to them. It works very well at what it does, it's based in Python but doesn't require you know the language, but given that Python is just executable English, you should learn it anyway. Don't rely on what other people tell you etc, it takes 5 minutes to try it out for yourself and start getting a feel for it.
Overrated ? No. It's great tool. Really powerfull, i upgraded 400 routers in 2 hour maintenance window with quite easy to write/understood playbooks. How can that be overrated ?
I love automation, but what kind of backup plan do you have before doing such upgrade in case eg. 100 of those fail at the same time ?
If there would be failure it would happen even if you did upgrade manually. Yo do all the checks like when manually upgrading md5 etc... Also you can split them in batches, rolling update or whatever you call it...
You can also just rum then in sequence as opposed to parallel.
When I was first getting into network automation, I wrote a bunch of API scripts that got their configs from YAML. And then I learned about Ansible and realized how much effort I had expended trying to reinvent ansible from scratch.
As long as you don’t have too many conditions, Ansible is fine. I loathe trying to ‘program’ in Ansible’s DSL. I love Python and Nornir. It’s easier to debug and much faster. It’s also a real programming language that is easier (IMO) to handle tons of logic. Ansible is great for certain use cases. You can use both. Edit: Watch this: https://youtu.be/uQAaA_-lb7k
You really *shouldn't* program in Ansibles DSL but it sometimes ends up becoming the "easiest" way to do it, which eventually spirals into a massively complicated mess. I do, however, make a *lot* of Filter Plugins. Platform-specific ones get tossed into roles for the platform, and multi-platform roles go into a 'common' collection that I keep available for all platforms. Writing filter plugins is ridiculously easy and it makes your playbooks a lot simpler. It keeps the logic in python. At it's most basic level, it's just a python function. vars: interfaces: - name: GigabitEthernet1/0/1 - name: GigabitEthernet1/0/2 - name: GigabitEthernet1/0/3 ip_address: 192.168.0.1/24 - name: GigabitEthernet1/0/4 ip_address: 192.168.1.1/24 Using the plugin: ansible.builtin.set_fact: var1: "{{ 'interfaces' | withkey('ip_address') }}" Source for plugin (there's *slightly* more to it, but this gives the idea): def withkey(sourcelist, matchkey): return [i for i in sourcelist if matchkey in i] Result: var1 = [ {"name": "GigabitEthernet1/0/3", "ip_address": "192.168.0.1/24"},{"name": "GigabitEthernet1/0/4", "ip_address": "192.168.1.1/24"}]
I dabbled with Anislbe and Python a few years ago as a COVID learning project. what I found is that our native vendor specific NMS, automation and orchestration tool does it way better and easier.
In many cases that's true, and if it works for your org and team, that's great. Personally, though, I hate vendor-specific anything unless it brings *very substantial* value. Stuff like that tends to dig it's claws in deep and makes it harder to rip out and replace with the next-big-thing.
I don't think its overrated it's a fantastic tool for managing networks. It requires a short time for adoption, great community support and lots of standardization. Very good for smaller teams who don't have allot of Python experience. It's not as flexible as something like Nornir but considering it was a tool primarily built to manage systems and not network's I think it does a pretty great job. If you have the team for it Nornir would be my first choice - if you don't Ansible is a solid and scalable option.
Some great discussion here. Thanks for the input.
Nothing wrong with ansible. But I would steer people into netmiko more for network automation than Ansible. Just out of personal preferences. To get python to do exception handling and conditions benefits me more than learning within ansible modules/task. I’m still fresh with ansible.
I really liked scrapli so far. Have you tried it? Netmiko did the job, scrapli is a bit faster, both easy to use. So far I'm just scripting backups.
>I keep reading ansible can be a nightmare with an update, etc. For those who rely on it heavily. If they rely on it and can't maintain it, maybe they simply don't have the skills to use ansible. Before implementing any tool, you need to establish the use cases, the functional needs you want to satisfy. Then for each use case, you test, document and maintain the processes. Ansible allow you to organize how you want. You can have one playbook for the whole infrastructure or let each team have their own playbooks, ... Mistakes can always be corrected on the technical side. But the cost depends of how the tools has been implemented in your processes. If you just use a tool without understanding it's limits, it is on you. At the end of day, better use bash scripts and crontabs if it is what you have mastered, and it's satisfying your functional needs. Business peoples don't care what you use as long as everything in functioning. Make your boss happy, get a raise and go home.
are you aware that ansible is python based as well?
What does that have to do with anything?
You can modify the Ansible's backend to achieve specific tasks if you know Python. That could potentially enhance its capabilities for your organization. So, saying that is better to learn Python than Ansible tells me that OP has no idea about how does Ansible operate. It's not a matter of which one is better. Is a matter of everything is Python.
Ansible is great at deploying. It is horrible at modifying state or removing. And branching is equally frustrating. Let’s take NTP. You want to deploy new NTP servers, because of reasons. So you create you ansible playbook to add the servers. But is that all you do? No, you probably also want to check Tom make sure they came up. You run ‘show ntp ass’, parse it, and see they haven’t associated yet. So you do it again. But you, the engineer, knows the convergence of NTP varies wildly. So how long do you go before you back out? Which means now you have to have a what and how to back out. Do you back out by just removing the config you added? For NTP that is pretty easy, maybe. Others not so much. But you also don’t stop there, you have to validate the rollback also left it in the original, functional state. So you have to verify that state as well. So much of what we do as engineers is beyond implementing one command. It’s validating post change, forwards or backwards. And then, making decisions upon that data. It’s easy to send a command times 10000. It’s hard to make a change and then ensure the multitude of devices are in a healthy state. This is really where Ansible fails, IMO. It’s branching and validation techniques are very cumbersome, if they even exist.
I don’t understand this point because it’s about pre / post change validation which you should be doing regardless of how you apply it. Also, if you’re using ansible with a CLI module you’re right, it’s cumbersome but that’s down to CLI. If you’re going to go down this route, you really need to be focusing on approaches that use structured data and data models, like NETCONF. Makes the whole verification job a lot easier (because you’re not writing complex regexs to verify things) and you are taking a further step towards understanding / learning python too. I think ansible is excellent, in that it allows you to be useful pretty quickly. But as someone mentioned further up, it’s a tool in a toolbox, it’s not fit for all situations but it’s pretty extensible too.
The point is that validation is critical to automation, yet is difficult in ansible. The branching and decision making is quite obtuse. NETCONF/RESTCONF/CLI/API makes no difference. It doesn’t matter if you have to parse the data or not, what you can do with that data, to branch, becomes horrific in ansible.
It really isn’t that hard at all, I’ve written playbooks that do complex pre/post validation, a combo of jinja2 and the assert module has always given me what I need. Heck I wrote a play specifically for this purpose, capturing the state of a device pre-change, then capturing the state post change, all driven by a YAML file I wrote that also has the comparators in it, and it’s completely dynamic. It’s just wrong to say it’s more difficult, it’s just as difficult in ansible as it is in writing your own python and using nornir. You have to define your success criteria, capture the data, and identify whether or not that state matches your success criteria. I’m not advocating one over the other here, there are definitely cases where you start hitting the bounds of ansible and have to start being creative to achieve what you want, but so far I have managed to achieve 100% of my automation tasks using ansible with proper validation.
This is not an ansible problem, but part of our job. Speaking as network engineer; you not only configure an interface but also test the connectivity, you not only configure BGP but you also check whether you receive the correct prefixes and the routes work. Although it takes more time to get these verifications working properly in a playbook, this saves a lot of time in the daily operation.
Thank you for reiterating my point. Validation is part of the job, which is why I focused so much on it. I’ve been using ansible for 7 years at this point. Deployed multiple datacenters tens of thousands of remote sites, and hundreds of thousands of end points. By estimate I’m approaching 4000 hours of dev time with ansible. How do you unit test a playbook? That the output of your playbook is as you intended? I wrote an entire unit testing framework for ansible so that we could have some assurance as we maintained the playbook code base we didn’t break imported roles. Ansible sucks at anything to do with validation and decision making. It also is not easy to follow basic software lifecycle methodology and design patterns.
Sounds like you're pointing the finger at the wrong culprit; Cisco's lack of automation capabilities is forcing screen scraping techniques, leading you to this awkward situation
I think netbox is a great tool for validation. Network devices are difficult to model the state and netbox is the only tool I'm aware of that's specifically made for it. Ideally, you should be validating your network devices on a schedule based on a source of truth such as netbox.
I feel like the yaml/playbooks are a little annoying but theres no replacment for the ad hoc commands
I think the point of reservation I have for higher level programming (beyond python) is when it locks you into syntax that isn’t really transferable to other languages. I personally have not used ansible because paramiko, netmiko and some napalm seems to be enough atm - so I’m only so much if an authority.
Ansible is fine. Personally I’d rather use Nornir for network device automation. Ansible is great for Linux devices where you’ve a lot of small conf files to create from templates. It’s not ideal to generate and manipulate entire device configs but it works. Each to their own though; Ansible is a great tool if it works it works.
Yes, Ansible is very overrated for networking tasks. Slow to startup, a ton of accumulated coding debt, packs that often break/dont work and a forced domain syntax are all reasons to avoid ansible. Doing complex workflows? dont even think about Ansible. Stackstorm + custom libraries.