Have you ever gotten lost in the APIC GUI while trying to configure a feature? Or maybe you are tired of going over the same steps again and again when changing an ACI filter or a contract? Or maybe you have always asked yourself how you can integrate APIC with other systems such as an IT ticketing or monitoring system to improve workflows and making your ACI fabric management life easier. Whatever the case may be, if you are interested in finding out how to create your own GUI for ACI, streamline and simplify APIC GUI configuration steps using smartsheets, and see how extensible and programmable an ACI fabric is, then read on.
Innovations that came with ACI
I have always been a fan of Cisco ACI (Application Centric Infrastructure). Coming from a routing and switching background, my mind was blown when I started learning about ACI. The SDN implementation for data centers from Cisco, ACI, took almost everything I thought I knew about networking and threw it out the window. I was in awe at the innovations that came with ACI: OpFlex, declarative control, End-Point Groups (EPGs), application policies, fabric auto discovery, and so many more.
The holy grail of networking
It felt to me like a natural evolution of classical networking from VLANs and mapped layer-3 subnets into bridge domains and subnets and VRFs. It took a bit of time to wrap my head around these concepts and building underlays and overlays but once you understand how all these technologies come together it almost feels like magic. The holy grail of networking is at this point within reach: centrally defining a set of generic rules and policies and letting the network do all the magic and enforce those policies all throughout the fabric at all times no matter where and how the clients and end points are connecting to the fabric. This is the premise that ACI was built on.
Automating common ACI management activities
So you can imagine when my colleague, Jason Davis (@snmpguy) came up with a proposal to migrate several ACI use cases from Action Orchestrator to full blown Python code I was up for the challenge. Jason and several AO folks have worked closely with Cisco customers to automate and simplify common ACI management workflows. We decided to focus on eight use cases for the first release of our application:
- Deploy an application
- Create static path bindings
- Configure filters
- Configure contracts
- Associate EPGs to contracts
- Configure policy groups
- Configure switch and interface profiles
- Associate interfaces to policy groups
Using the online smartsheet REST API
You might recognize these as being common ACI fabric management activities that a data center administrator would perform day in and day out. As the main user interface for gathering data we decided to use online smartsheets. Similar to ACI APIC, the online smartsheet platform provides an extensive REST API interface that is just ripe for integrations.
The plan was pretty straight forward:
- Use smartsheets with a bit of JavaScript and CSS as the front-end components of our application
- Develop a Python back end that would listen for smartsheet webhooks triggered whenever there are saved Smartsheet changes
- Process this input data based on this data create, and trigger Ansible playbooks that would perform the configuration changes corresponding to each use case
- Provide a pass/fail status back to the user.
The “ACI Provisioning Start Point” screen allows the ACI administrator to select the
Site or APIC controller that needs to be configured.
Once the APIC controller is selected, a drop down menu displays a list of all the use
cases supported. Select to which tenant the configuration changes will be applied,
and fill out the ACI configuration information in the smartsheet.
Selecting the checkbox for Ready to Deploy, and saving the smartsheet, will trigger a webhook event that will be intercepted by the backend code and the Ansible configuration playbook will be run.
A big advantage to using Smartsheets compared to the ACI APIC GUI is that several configuration changes can be performed in parallel. In this example, several static path bindings are created at the same time.
Find the details on DevNet Automation Exchange
You can find all the details and the public repository for this application on the DevNet Automation Exchange.
You can also find hundreds of similar use case examples in the DevNet Automation Exchange covering all Cisco technologies and verticals and all difficulty levels.
Drop me a message in the comments section if you have any questions or suggestions about this automation exchange use case.
Related resources
We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!
Twitter @CiscoDevNet | Facebook | LinkedIn
Visit the new Developer Video Channel
CONNECT WITH US