DevOps for Infrastructure – Where’s the Automation?
Price:
Register
schedule
Default Schedule: 8 hours total over 4 weeks. 2-hour sessions each Friday. This schedule is intended to support the work week demands of participants, and allows time between sessions to apply the principals learned. This schedule can be adjusted as needed for the audience.
Workshop 2 | DevOps for Infrastructure – Where’s the Automation?
Workshop Series Description: Through the course of all three workshops, we tackle a common customer use case by making network management easier and eliminating single points of failure by providing an automated process. By starting with the basics and gradually building on the foundational concepts with interactive labs and content, we make it easy to learn a seemingly complex solution.
Workshop 2 Description: In Workshop 1, we discovered some pain points for our customer. Now that we have a well-documented plan to solve these pain points, we need to start working toward a solution so that the customer and their team can implement it.
Please note, this is workshop 2 in a 3-part series.
-
TARGET AUDIENCE -
Sales, PMs or Engineers responsible for selling or deploying network infrastructure, SEs -
TAKE-AWAYS -
To provide the audience an easier way to configure, manage, and ensure state on their devices with an automated approach and source of truth. -
SKILLS LEARNED -
Deploy a VM hosted in AWS
What is Ansible?
How to use Infrastructure as code
Make configuring infrastructure easier and more reproduceable using Ansible
Deploy a Cisco Modeling Lab using Ansible
Using GitHub as a Single Source of Truth
Branching in GitHub
Use GitHub actions to improve code quality
Make changes and push them to a shared repository
Build a CML lab
Working with Ansible playbooks
Use Ansible to push configuration changes to multiple devices at one time -
DESIGN GOALS -
• We must have a place to store and update configs so that we know what is on each machine. (Source of Truth)
• We must have a way to easily update the configs which provides a record of those changes. (Version Control)
• We need the ability to push changes directly from our Source of Truth to our devices. (Automation)
• We must have a way to test this process in a test environment modeled after our production environment, before using it in production.
• We must have a way to monitor the state of our devices to guard against accidental changes that could impact our network.
Workshop 2 Agenda
SESSION 0
Workshop Orientation
- Workshop schedule and topics covered
- Learner resources
- Learning environment access – test all tools we will use during the workshop
SESSION 1
Infrastructure as Code with Ansible
- Revisit deliverables from Workshop 1
- What is Ansible?
- Deploying a network in Cisco Modeling Labs (CML) with Ansible
In this session, we will deploy a small test network to a Cisco Modeling Labs instance hosted in dCloud by deploying from a virtual machine hosted in AWS. We will learn about Ansible and how to use Infrastructure as Code to make configuring infrastructure easier and reproducible. We will deploy a Test Lab using Ansible in CML, which will be used for future sessions to push configs at scale.
SESSION 2
Maintaining Source of Truth
- Using GitHub as a SoT
- Branching in GitHub
- GitHub actions
In this session, we will explore branching, pull requests, and merging in GitHub. We will also take a brief look at GitHub Actions. We will learn how to make changes and push them to our shared repository as a versioned Source of Truth, and how GitHub actions can help improve our code quality.
SESSION 3
Pushing Config Changes at Scale
- Build a CML lab
- Working with Ansible
In this session, we will explore how Ansible can be used to push configuration changes to multiple devices at one time. We will have two labs: In lab one we will be deploying our CML Lab from our AWS VMs that we set up. This will be a short lab to get our test network kicked off so once the playbook starts polling interfaces we will pull back to the main session. In lab two we will use the CML Lab we deployed to explore the network and push changes at scale.
