In this DemoFriday, Cisco’s Shane Corban and Ansible’s Peter Sprygada demonstrate how to achieve greater DevOps collaboration through Day 0, 1, and 2 automation using Open NX-OS. During the live presentation, Cisco gave a brief introduction to Open NX-OS along with an overview of its application integration capabilities, the NX-API CLI, followed by a live demonstration of how Ansible is utilizing Open NX-OS. After the live presentation, the presenters took questions from the audience. Read the full Q&A below!
One of the things that you had mentioned was this open source project called Ignite. Do you think you could give a little bit more color into it, what it is, and maybe how people could get started with it.
Cisco: Ignite is a utility we provide on GitHub for essentially easing the provisioning and configuration of POAP on your switches. So if you think about POAP as a Day 0 automation provisioning solution, it relies on TFTP and DHCP servers within your infrastructure to essentially operationalize a given switch, but you’re doing it on a switch by switch basis, you config a given switch for POAP on a switch by switch basis across your entire fabric. What Ignite does is it up levels it to a fabric and enables you to build a fabric and a config template for your fabric and apply it and leverage POAP under the hood and configure POAP, the pieces required for POAP under the hood automatically for you. So it eases the configuration of POAP on a fabric wide basis.
Can AAA services be integrated within Ansible? Is there some notion of privilege management that could get in there so that the right person can make the right changes and not mess with something that they’re not supposed to be touching?
Ansible: With the Ansible product, which is the open source project, it’s what you see is what you get from an ability to deploy the application. Now what we built over the top of that is the Ansible Tower product and one of the key driving features behind this product is role-based access control. And that is such that when we build these playbooks and we have this catalogue, if you will, of playbooks available for operations teams to deploy, the role-based access controls of Tower, really focus on saying which individuals or which operators can actually execute which playbooks. So that’s why I made the distinction between Ansible core being the product for the engineering component, whereas Ansible Tower’s really then how you scale that up into your operations team.
This really allows us to take it to a point of not just simply saying, “Which roles can a given operator ultimately run in the network infrastructure?” but it allows us to create things like self-service IT portals that allows even individuals to come in and be presented with a list of things that they potentially could do as far as deploying applications and services, not only just in the network, but also in the compute and applications spaces.
Is Ansible really agentless? Is there anything that’s hidden that somebody may have to install later?
Ansible: Ansible is as agentless as agentless gets. There is absolutely nothing that gets done to the end system to make it ready for automation, short of enabling NX-API. So it really leverages the fact that when you look at the investment that Cisco’s made in making NX-API feature parity with what the CLI can do and really provide those programmable hooks, we’re really leveraging that to automate the end system. And then Ansible by its architecture itself, requires absolutely no agent on any system, whether it’s network, or computes, or storage, or application. It is 100 percent agentless.
Is Ansible and the Nexus API supported on all of the Nexus switches, or is somebody required to have a particular one?
Where would I go if I needed support from Ansible? What do I need to do to get started?
Ansible: One of the things that Ansible is very proud of is the fact that we have a very robust open source community, and one that is very inviting for folks to help them get started. In terms of just being able to pull down the Ansible core, getting up and running, everything is as easy as being able to do a PIP install all the way through. If you want to go the virtualization route, we have different ways that we can get folks started in using Ansible. And then as they start getting playing with it, as I always tell people, “Start simple, start easy.” Even as we went through today’s demo, right?
Start with some basic things and get an idea of what it’s like to work within the Ansible environment because I think you’ll find, for anyone who’s worked in an operations or an engineering environment, you’ll find that it becomes very addictive very quickly, even when you start to realize what you can do. When you scale that into looking at how do we get support from a deployment standpoint where we’ve got actual real applications and services that utilize Ansible, there’s a few different avenues there. Obviously, Ansible is fully supported by the commercial entity of Ansible, the organization of the company, and then we have all the support capabilities there from professional services to technical assistance in various flavors.
But we also have a tremendous working relationship with Cisco, and that will continue down the path such that when you start looking at specific modules that are integrating with the Nexus line, not only can we support it, but Cisco also. We work very closely with them to make sure that customers have all the support they need moving forward.
What other Cisco products does Ansible support today?
Ansible: Nexus was our first starting point and a lot of that really revolved around all the tremendous work done around NX-API, but certainly it’s not the first in the era, it was the first, but it’s definitely not the last. We actually are in the process right now of putting together a very comprehensive set of support for Cisco devices, specifically around any device that’s running iOS that will utilize more of a SSH transport. We’re working on support for iOS XR deployments, utilizing netconf as the API transport there. And then we’re also presently looking at how we’ll support ASA. So you’ll see a number of announcements coming from Ansible over the next few months really starting with the Ansible Fest in November in San Francisco.
Does Open NX-OS support Zenoss?
Cisco: Zenoss is not supported with Open NX-OS today. We’re currently evaluating extensions and going to add to this whole portfolio of solutions we’re offering around Open NX-OS, and as the quarters roll out, we’ll be adding some additions, but as of today, it isn’t supported.
Is there a library of playbooks that somebody could go to today and start to take what you demoed and use that on their own, or is this something that essentially everyone’s going to be cooking up their own playbooks?
Ansible: This really goes back to that vibrant Ansible community that I referenced a little bit earlier. So I would certainly encourage everybody to start at Ansible.com and from there, you can get the various links about how to get involved with the community. It’s an extremely helpful community in terms of information sharing, knowledge sharing, best practice sharing, all done through typical mailing list style.
However, it doesn’t end there. Ansible has a site called Galaxy which is a repository that allows any customer, any individual who’s working with Ansible in any form or capacity to be able to share the work that they’ve done, whether it’s networking, or computer, or application, or virtualization – it doesn’t really matter. End-users can upload work that they’ve done, they can get feedback, other users can download that work and utilize it in their own environments. That includes everything from playbooks, to roles, to modules, to really anything for orchestrating and automating solutions utilizing Ansible. From that point forward, we also have two additional repositories, our extras and our core repositories. These are really the areas where you find the Ansible fully supported module.