Introduction
DevOps
As we measure our end-to-end pipeline and begin to improve it, we address the fundamental DevOps goal, which is to increase an organization’s ability to deliver applications and services at high velocity. DevOps is the combination of cultural philosophies, practices, and tools, which can even be applied to organizations that are using traditional software development and infrastructure management processes. The resulting speed increase enables organizations to better serve their customers and compete more effectively in the market.
DevOps has multiple stages. The four basic stages are:
NetDevOPS
NetDevOps combines toolsets, concepts, and methodologies to automate deployment, testing and manual networking processes. It treats the network as code to allow for version control, and reliably tests changes to make sure of quality and stability.
Four stages for NetDevOps
There are so many tools available and we need to select the specified tools which we want to use for our organization's purpose.
Tools
- Jenkins
- Ansible
- Docker
- GitHub
- Nexus Dashboard Insights
Jenkins is an open-source continuous integration tool that helps bring everything together regarding DevOps strategy to push code.
Ansible allows us to develop reusable automation components by grouping and encapsulating related automation artifacts, like configuration files, templates, tasks, and handlers. It natively supports Cisco ACI.
Ansible provides seamless application configuration, while Docker provides a containerized environment for building and deploying applications.
GitHub is a code hosting platform for version control and collaboration. It lets us and others work together on projects from anywhere like [repositories, branches, commits, and pull requests]
Cisco Nexus Dashboard Insights (Nexus Dashboard Insights) is a real-time monitoring and analytics service.
How to use NetDevOps practices for ACI?
- The discovery process for an ACI fabric - Once the ACI hardware installation and basic configuration setup are done, it auto-detects and connect all names of Spines and Leaves.
- The current environmental compliance check is an extra level of security and confirms we’re operating up to standard.
- Firmware can be updated in those devices by bulk execution and feedback mechanisms. It can be performed on demand, or they can be scheduled for execution at any future point in time.
- Deploy ACI fabrics to allow applications to be gradually migrated from one infrastructure to another.
- Configure management connectivity to the ACI fabric. It is easieror security analysts to detect and respond to potential threats.
- Troubleshoot can assist us with monitoring traffic, debugging, and detecting issues such as traffic drops, misrouting, blocked paths, and uplink failures.
Identify Ansible modules
Ansible ACI modules can provide a user-friendly interface to managing our ACI environment. We can find the modules and code to be run in Ansible. It shows detailed infrastructure.
- The Payload of an API Module is the body of our request and response message. It contains the data that we send to the server when we make an API request. We can send and receive Payload in different formats, for instance JSON.
- The next one is Visore; it relates to the object browser, which we can use to perform the data filter and analysis on our API.
- We can use the dev tools in the browser to interpreter our API. We can click something on our browser, and see the payload of the click.
API Inspector contains the inspection codes and standards:
API Inspector - It provides the interception of our API calls. It is used to provide a REST API payload, and is a most convenient method to consume the REST API.
Visore - This is like an object browser, with which we can perform more filtration, more Analysis on our API.
Browser - Can use dev tools on our browser to intercept what is happening on our ACR. If we click something, it shows the payload equivalent of that click.
Next, we must use GitHub for our Version Control System. So, we should not have to keep anything or any files locally.
Here are some concepts of branches in GitHub:
- Release branch - access/responsible for Administration task
- Feature branch - Administrator who have access for network side like creating access policy
- Main branch - Admin on main branch. Main branch is our source code.
Nexus Dashboard Insights. Automate, monitor, and analyze our data center fabric in real time. Nexus looks inside to explore the product for data analytics and is a tool used to multi-task.
From a validation perspective, it is one of the key functions called pre-change analysis, which takes input of our current confirmation. It impacts at delta time and it basically takes snapshots automatically.
Nexus Dashboard insights
Easy to understand and proactively assures performance on our ACI fabric.
The base architecture needs some infrastructure to execute these lines of code with Jenkins. We must set up authentication to secure our projects.
From the nodes and cloud, inspect Agents and On-demand Agents. These are the difficult virtual machines that would always be powered on it, and are the connectors to Jenkins to run our code. On-demand Agents run any code found in Docker, once done, it will automatically delete.
Pre change Analysis
It is one of the key functions. It takes input of our current configuration and matches it with delta time period. It will take snapshot automatically and, when we need, will compare with existing change and with our current changes. It will provide the before and after configuration of our state.
We can create a Webex bot as a self-service experience for relaying the information automatically. For example, build or failure of anything can be tracked.
Demo:
Demo environment use depends on the Base session to run for the local desktop. The docket contains a lightweight process, and we can download it from GitHub:
Demo Code: https://github.com/saurabhkothari/CiscoLive-BRKDEV2291
Open to the Jenkins dashboard and see it has shown the stage view and difficult view of history.
Next, check out the GitHub code and open the ‘fabric _switch_discovery’ file.
From GitHub, we can find the leaf ID and spine ID once we have opened the leaf.CSV file.
See below…
if want or need to merge, it is possible with leaf and spine ID 101 and 102
With the IP address, we can check the project at the top and it will open the stage view; choose the Fabric discovery
It needs some infrastructure to execute these lines of code with Jenkins, and must use authentication.
Choose the option to build with parameters and change the IP address and username credentials.
Next, we need to check overall credentials for the local desktop. Go to the Jenkins dashboard option and choose to ‘Manage Jenkins’.
Open and scroll down, then choose the ‘Manage Credentials’.
Check the configuration for GitHub code, upload, and select the ‘Configure’ option. Scroll down, then fill the pipeline repository box.
Open the GitHub repository to check the clone URL in Jenkins file.
For the next step, we can check out the code from GitHub and pass to Ansible and check the number of switches present.
Switches are identified with the DOCKER container.
Create a Webex bot. It is used to identify the error messages and builds a history.
Failure and success view in Jenkins dashboard
Sample of running the Pipeline PreChange-Analysis
In the Console Output, we can verify the runtime changes.
Manage PreChange-Analysis to view the history of changes and verify the content changes; it will show the output, windows stage-wise.
An error is identified and reported to the Webex chat room
Once the process has been completed, we need to check the view Epoch Delta analysis. It shows on error stage critical, major, etc., error thrown by the event management page.
Resources:
GitHub url : https://github.com/saurabhkothari/CiscoLive-BRKDEV2291
- https://developer.cisco.com/docs/aci/
- https://developer.cisco.com/docs/aci/#!sandbox
- https://developer.cisco.com/netdevops/live/
