Rich Martin • 00:04

Hello, everyone. Thanks for tuning in. Today, we are going to be discussing a third and a final part in this series from scripts to services to ecosystems, really about how to scale your automation with Itential. My name is Rich Martin. I try to bring some sort of technical direction to marketing here at Itential. But I’m super excited to be joined, as always, for these sessions with the pre-check and the post-check to my execution, Peter Spragata. Peter, in 256 words or less, is going to be my moderator.

Rich Martin • 00:36

Say hello to the audience and give them a brief high five.

Peter Sprygada • 00:39

Thanks, Rich. It’s great to be back. And hi, everyone. First of all, thanks for joining. However, wherever you may be, we appreciate you taking the time to spend with us. But yeah, my name is Peter Spergata. I’m the chief architect here at Attention, which essentially means that I get the dubious honor of looking over our product strategy, our product roadmap, our product architecture.

Peter Sprygada • 01:03

Since you boil down means that I please absolutely nobody. So it’s just the nature of the job, but I love every minute of it. And I’m excited to have some more fun today as we continue on the series.

Rich Martin • 01:13

Awesome. Well, let’s jump right in. And let’s, at first, let’s set some stage and some context of where we’ve been. So kind of walk us through what we’re looking at here because that’ll give some insight and some context if folks haven’t been through the last, the previous two episodes here, or as a kind of refresher for some of us that kind of needs those hints because of our age. And I’m not talking about you, Peter, I’m talking about me. Give us some overview here, Peter. Yeah, absolutely.

Peter Sprygada • 01:43

So, you know, we started this journey, you know, you think back two sessions ago, we started this journey, you know, really looking at our newly announced Intentional Automation Gateway 5 and really kind of thinking about really what was it all about and how do we start to take, you know, this cornucopia of, you know, Python scripts and Ansible playbooks and Terraform plans and just all of the stuff that we’ve got and we really start to corral it and bring it, you know, bring some structure to it to allow us to, you know, provide a better way to introduce the stuff into our operational environment. We spent a lot of time talking about utilizing IAG 5 really from two different mindsets. One from that operations mindset, you’re rich from your team’s mindset, and then from more that automation engineer, that developer mindset. What does that new automation engineer look like in the world? That individual that’s just getting into network automation, that is starting to write code as much as they might be, punching out device CLI commands. We got into this idea of writing code, committing code, and publishing code being this new mantra of what that automation engineer is all about. Meaning that they don’t want to get overburdened with this idea of deploying operational systems and building up vertical stacks and having to build massive amounts of boilerplate code just simply so that they can write automations and make those automations available to the rest of the organization.

Peter Sprygada • 03:16

The operations team being a really good example of that. That’s really where we started this journey. We then moved on from that journey. While we enjoyed looking at Intentional Gateway from its CLI-based component, the ability to tie repos together with and build services against those repos and run them from the CLI. We recognize that that’s really more of looking at it through the lens of the developer. Then how do we take that and we bring that to the rest of the organization to that operations team that may or may not really want to spend as much time at that CLI level. They really are more focused on, hey, I’ve got a job to do.

Peter Sprygada • 03:54

I don’t want to get hung up on, here is 46 two commands that I need to run in order with a very specific syntax. How do I actually start to be able to consume all these things the automation engineers do? In that second session, we transitioned and we started talking about the attention automation service, WebUI. The WebUI really bringing more of that user interface, that graphical user interface through our SaaS-based platform to be able to consume all of these services that we’ve been publishing. In that way, we started to take a little bit of a different look at things. Because at that point in time, We no longer cared.

Peter Sprygada • 04:36

Is it an Ansible playbook? Is it a Python script? Don’t know, don’t care. I simply know I’ve got a job to do. I want to be able to run that job and I want to move on to the next thing. That was really what our second session was really focused on, and that was really driving this idea that we can now publish services from my potential gateway, and then the different teams, whether it be the NOC or the SOC, or yes, even you, Richard, can actually be able to execute these automation services and run them against production infrastructure. So that’s just kind of where we’ve been.

Rich Martin • 05:09

And so that’s a really relatable way to bring it. How do we get these automations that you are having a fabulous time running, or writing and testing, and how do we get them in a consumable format? for your operations team. I think the next step to this as we talk about scaling this out, so we’re allowing more folks on different teams to use them, is what we’re talking about today, which is exposing and allowing that automation service to be consumed in another way. Walk us through what we’re going to take a look at today.

Peter Sprygada • 05:43

Yeah, I’m excited about this part because this really rounds everything out. Because the reality is this, no tool, no operations team, no anything works in a vacuum. Nothing works in a bubble. Everything has to cohesively, hopefully, work together to actually deliver on something. While it’s fun to walk through the first two sessions that we did, in a lot of respects, we were just working within our own environment. We were working with the CLI tooling. We were then switching over and working with the SaaS-based platform to ultimately build, expose, and consume these services.

Peter Sprygada • 06:21

Now, today, we’re going to take that last step and maybe the biggest leap of all, and that is, how do we start to integrate this SaaS-based service into the ecosystem of tooling that organizations have to ultimately be able to build up automation solutions? Said another way, we’re going to start talking about this, not from the UI perspective. But now from the API perspective, being able to leverage that API so that we can plug it into our ecosystem of tools that we use for consumption. Whether that’s other platforms like potential platform, whether that’s pipelining tools, CICD style systems through things like GitHub, or GitLab, or Bitbucket, or Jenkins, or whatever that might be, or if it’s writing even bespoke applications where you want to consume it from an API perspective and not have to just simply rely on the UI. That’s really what we’re going to get into today, and I’m really excited to walk through this one.

Rich Martin • 07:18

Fantastic. Now, before we jump into demo, do you want to give us a brief overview of what you’ve cooked up for us to show us how this can be used in this way?

Peter Sprygada • 07:27

Yeah, I think that today we’re going to take a little bit of a divergent path in terms of, we spent the first two sessions really looking at how we build Python scripts and Ansible playbooks for talking directly to network devices. Today, we’re actually going to talk about something that’s near and dear to every network engineer’s heart, and that is how do I manage lab infrastructure? Looking at, again, different ways that we can do that. Today, we’re going to spend a little bit of time looking at how we use IES plus Itential Gateway to actually build, manage, and deploy a test infrastructure, namely using Container Lab, which everyone’s really excited about and should be in the community right now, and how we actually leverage that and tie that together in automation and do it in a very controlled way so that we don’t have to ultimately give teams full access to systems where they might otherwise inadvertently do something like remove RM space hyphen RF slash, which would be a very bad thing out of Linux system.

Rich Martin • 08:33

I’ve never done that before, Byron.

Peter Sprygada • 08:35

I know. No one ever has. My favorite story, I was working once on a project and it was I was going to say late at night, but it was actually very early in the morning. Anyway, I just had a complete brain meltdown and accidentally typed RM space RF tilde, which erased my entire home directory, which was not a lot of fun to recover from. But thankfully, my commitment to your source code control actually did salvage most of it.

Rich Martin • 09:03

Oh, fantastic. Well, I was going to say, the bright side is at least it wasn’t brute.

Peter Sprygada • 09:07

Hmm. Very, very true. Very true. Absolutely. That is true. But yeah, what do you say? Should we jump into this and see what we’ve got going on?

Rich Martin • 09:16

Yeah, let’s jump into it. Take over the screen and show us what we’ve got going on here. All right. Because it’s really exciting stuff.

Peter Sprygada • 09:23

All right. Fantastic. Let’s see. Obviously, step number one is, can I share? That’s always a good starting point. If everything has gone well, I’m actually now sharing my- All right. Excellent. It’s going to be a good day. It’s going to be a good day. Okay. So I’ve got two tabs here we’re going to look at. Obviously, we’re looking at a potential automation service here.

Peter Sprygada • 09:45

I’ve also got a tab over to GitHub. We’ll get to that in just a moment. But I really want to kind of start to talk about what we’ve got. Okay. So today, we’ve got a Linux host, or a number of Linux hosts, actually, in this environment. But one in particular that we’re going to work on is where we’ve got our test and validation infrastructure deployed on. So as we talked about last time in our call, I’m just going to use the web UI.

Peter Sprygada • 10:08

I’m going to go ahead and I’m going to run a automation called inspect topology. So let me go ahead and let’s get that kicked off and get that running. So what this is going to do is, again, I don’t know anything about this other than inspect topology, tells me it’s going to inspect my container lab topology. Well, sounds like what I really want. That’s great. So I’m going to jump over to my activities and I can see, wow, that ran pretty quick, 2.8 seconds. Fantastic. Now, I can go ahead and I can take a look and I can see, well, this is good. I’ve got a infrastructure built and I’ve got it running.

Peter Sprygada • 10:36

I can see that I’ve got it. I’ve got some nodes up here and actually some nodes up and running. So that’s wonderful. So now what we’re going to do is we want to go ahead and we want to make some adjustments to this. But in order to do that, we’re going to change the way we go about doing that. So instead of me going through and having to manually do things and then come back and run something, we really want to start to leverage integration into a pipeline. That’s what we’re going to do for this particular use case.

Peter Sprygada • 11:07

So if I switch back here to Git, we’re going to see that I actually keep all of this. This happened to be an Ansible playbook. You saw that from the output. I actually keep all of this in a GitHub repository. Obviously, that’s a good thing and I can do a lot of goodness by keeping it in a repository. Most notably, when I keep it in a repository, I get a nice change log of what has been changing over time. I can see we had an initial commit, and we’ve added some capability to it over time.

Peter Sprygada • 11:38

So I can start to manage things. If you remember back to our first session, we spent a lot of time talking about this, and that automation engineer, this is the world they want to live in. They don’t want to worry about the operational systems. They don’t want to have to know bespoke ways to have to build the code they have to build. They just simply want to write automations. I can do that here. I can just simply write Ansible playbooks or Python scripts, and I can just do it in a very natural way. I don’t have to be very prescriptive of the way I do it because my operational system or my automation system has a very specific way it needs to do things.

Peter Sprygada • 12:10

I can really just focus on creating the automation, and I can add the things that I need to add to ultimately deliver on the results that I’m trying to deliver on. That’s really the concept here. So what we’re going to do is, we’re actually going to make a change to the deployed infrastructure. So what we’re going to do is, we’re going to go ahead and we’re going to add a new topology file. So I’m going to very quickly here, I’ve actually pre-staged this, I just need to push some of this up. So we’re going to go ahead and go ahead and get that ready to go here. So let me go ahead and do that.

Peter Sprygada • 12:52

So we get that guy going and we’re going to go ahead and so we should now have a new commit into our repo. So if I go ahead and I take a look I can see yep sure enough I’ve got a new commit now I’ve updated the topology. So I want to be sure to get that ready to go and so now I’ve got the option. I’ve made the adjustment to my topology. Now, I haven’t done anything obviously yet. I’ve just simply made a change.

Peter Sprygada • 13:21

But now I can reach out to say, Rich, you and your team and you can log in and you can look at the commit that I’ve changed. This is pretty standard stuff for version control and you can look at it and say, yeah, that’s the change that we were looking for. Whatever that might be. This could be as much a config push to a network device or in this particular case, it could be the fact that we’re doing this to be able to push a topology change out to an environment. Now, if I want to actually though deploy this, I don’t want to have to manually log into things. I want to actually be able to just set this in my repository. What we’re going to do, I’m sorry, I’ve just lost the words here. My brain is gone. I’m old.

Peter Sprygada • 14:11

You have to bear with me sometimes these things happen. The way I’m going to do this is we actually have a pipeline that we’ve gone ahead and built. In this pipeline, we’re going to actually trigger based on just simply setting a new version. We can say I’ve got one tag already that’s currently deployed. If I look at that tag, it’s version 0.1.0 of this particular test and validation topology. I’ve gone ahead and I’ve made the change. Now, what I want to do is I really want to focus on seeing the change make a positive effect in my environments.

Peter Sprygada • 14:39

The way I do that is I’m going to go ahead and I’m going to create a new tag in Git. I’m going to just go ahead and push that up to the system. Go ahead and enter my information to push it. So now we go ahead and we pushed our new tag, 0.2.0, which would be the next version of our release. Then if I refresh my screen, we can see that our pipeline has kicked off.

Rich Martin • 15:06

Okay. So by updating that file. you’ve got something in GitHub, an action that’s kicking off another process in the back.

Peter Sprygada • 15:13

That’s right. What this is doing is this is just simply a standard GitHub action. This is running a workflow on the back-end, a GitHub workflow that’s actually going to go on. It’s going to talk to IIS through its APIs. Now, touching the UI at this point, I’ve done nothing on the IAG CLI side, other than I made that code commitment change. If you remember when we talked about this, is that gateway will actually pull in those changes because it’s going to clone the repository when it runs. We can see here that’s exactly what it’s doing. It’s starting by destroying the current topology.

Peter Sprygada • 15:48

Obviously, I got to kill it first before I can rebuild it. Then it’s going to go ahead and pull this in. These are all services that I’ve built and made available through IIS so that I’m controlling exactly what can be done within my environment. That’s what we’re looking at right now as this runs through. Okay.

Rich Martin • 16:10

How many API calls are being, so for this whole process, this action, how many API calls are being made into the automation service?

Peter Sprygada • 16:18

Yeah. Technically, we’re making one API call. We’re just using three different ways of making the call. I’m passing three different parameters. In the first case, we’re making an API call that essentially says run the service, and the service I want you to run is DestroyTopology, and then you can see it’s gone ahead and it’s done that. Once that was completed, we’re going to make the same API call, but now we’re going to run it with a DeployTopology. It’s going to deploy the new topology into the environment. Then last but not least, it’s going to rerun that InspectTopology, which we just saw me run, and it’s going to return to me the results.

Peter Sprygada • 16:52

I can see that sure enough that I’ve actually made a positive change and I now have my new environment up and running. What we’ve just seen happen is by simply making a change to an Ansible playbook to my ContainerLab topology file, committing that change into the repo, as we saw here in my commits, there we go. We can see that going over to my commits, I can see that my new commit got pushed, update the topology file. Then just simply tagging that with a new tag, in this case, version 0.2.0, that’s what my trigger point was to cause my workflow to run. At the end of that, I end up with a new newly deployed topology. Let’s go ahead and take a look at this and just confirm and see what’s going on from the potential IIS side. When I switch over to IIS, I’m going to go back and I’m going to look at the activities that have happened here.

Peter Sprygada • 17:48

When I look at that, I can see that when I started this, I first ran inspect topology. In fact, we started at that 1210 and that was actually run by me. We see that ran just fine. Now we can see the three different calls that were made from my pipeline, destroy topology, deploy topology, and inspect topology. Notice the user here, devil. That is my service account name. Effectively, what that’s telling me is this was actually run from my pipeline that got kicked off from github.com.

Peter Sprygada • 18:17

You put the whole thing together. I’ve got a pipeline that’s running in github.com. That pipeline based on a tag ran and it made calls into attention automation service. Then from that workflow, I selectively ran three different services, each one that I configured, which then in turn made the calls down to IAG5, which then made the changes to my infrastructure. Effectively, that’s what we’ve just done here.

Rich Martin • 18:42

Well, that’s fantastic. Again, this is exposing that same automation service, which was created. by a rule in the gateway that corresponds to a script you’ve written, in this case, an Ansible playbook, and then exposing it through an API, through the system, to an entirely different team, a DevOps team, that in their world, in their ecosystem of tooling, CICD pipeline through GitHub is their kind of preference and tools of choice. Talk to us a little bit about Because I think somebody could say, well, if you’re just deploying an Ansible playbook, I could have just run this directly on the server itself. Talk to us a little about the advantages of running it through Gateway and our attentional services and exposing it by API.

Peter Sprygada • 19:29

Yeah. This is the point right here. I’m glad you asked that question. Because the reality is you’re absolutely right. Obviously, with my background, I could have very easily just written this as an Ansible playbook and kicked it off and called it a day. However, there’s a couple of really important points to take away from this. In that, what I’ve done is I’ve focused on making this automation available through attention automation service, which means I’ve just taken what could have been a wide open world and I’ve now put those big guardrails around it. Which as you know from your operations background is super important.

Peter Sprygada • 20:09

You don’t want to just let people do whatever they want to do on the infrastructure. We want to make sure that they have the flexibility to be creative and do the things they need to do, but be able to do it in a controlled way so that we can continue to keep those guardrails up and actually protect the infrastructure. In this particular case, by building the playbook and committing it through IAG5 and through my Git repos, I was able to build the playbook the way I always have. No change there. But by exposing it through IAS, I now get all of that infrastructure allows me to actually consume that playbook through API calls and keep those guardrails in place. So for instance, what is not obvious when you run through the demo is that the host that’s actually the changes are being made to, in this particular case, the Linux server, that’s actually running my test and validation environment, I, as my username, have no access to that environment. But because I’ve built Gateway and because I’ve got IAS running, as we saw from the activities, the service account does have access to it, and therefore now I can control exactly what’s going on in terms of who can run what. The service account has access, but they only have access to do very certain things.

Peter Sprygada • 21:25

They can only run these playbooks, and therefore I’m creating a lot of control and a lot of auditing and logging capabilities, so that now I feel much more comfortable exposing all of this as APIs that now can be called from external systems. Again, it doesn’t have to be GitHub, it can be any pipeline-based tool, it can be any application. I can even write my own custom applications to make these API calls. These are just REST API calls that are being called from a service account. In fact, there’s my service account right there, devil, that’s the one that actually has it been running in the background this whole time. That’s really what I’m doing, is it’s all about giving control, validation to the operations team, but still creating that flexibility, so that developers and automation engineers can be able to build the services that they need to be able to service.

Rich Martin • 22:18

Yeah, this is great, Peter. That’s the common theme, and letting the builder leverage the tools of their choice, as they’re building and publishing, but even when we expose these automation services through the API, the same common theme is, what are the tools of choice to those folks working in programs, platforms, whatever it is they’re doing, pipelines, let them leverage the same tools of choice to actually consume it. And then of course, for the network operator like myself, I just need the GUI, which I still have access to. And I can get, given the access that you give to different gateways, different. your different automations, I get what I need. People and other teams get what they need as far as automation services. And now you still have the flexibility to go beyond that, to more of a DevOps, several DevOps teams and provide what they need all in a single platform with tools that are that are, you know, usable and applicable to all sides. And I love that. It almost seems like you thought this was thought out ahead of time.

Peter Sprygada • 23:28

Yeah, you might, you might think that, you might think that, but, but you know, the beauty of this is, you know, this is why I really kind of love what we’ve done with this is that, you know, so, so you’re absolutely right in everything you just said. And, you know, so now I can log into the web view, and I can kind of see what’s going on in the environment, you know, I’ve got access as an administrator into the SaaS platform. So I can see, you know, what I’m doing, I can see, you know, what, what the service accounts are doing. And I can create different service accounts for different reasons. But then as you know, more organizations start to see this and want to leverage this, you know, so for instance, you know, your peer group over in the security side, or maybe your peer group over on the cloud infrastructure side and operations, you know, perhaps they want to be able to leverage all that. It’s just simply about adding more gateways to the SaaS platform. You know, right now you’ve got this is your, you know, NetDev gateway, this is the one you’ve been working on. But, but the the cloud team could add their gateway and the security team could add their gateway, each with specific sets of permissions that they can expose these activities to. But in that way, we start to really unify how stuff is coming into the infrastructure. I’ve got that one conduit, which is through IIS where I can control and see what’s happening. Whether you’re coming in through the APIs, whether you’re coming in through the UI, it doesn’t matter. But I still have that control point that I need to allow me to sleep at night, or more importantly, probably for you to sleep at night, knowing that you’ve set up an appropriate gate or gateway to make sure that you’re only exposing what you need to.

Rich Martin • 25:01

That’s right. Well, I’m thankful that you’re worried about me getting a good night’s sleep But I still need to call you on Saturday just to say hi Well, you know that’s that’s always just fine you’re always welcome to call but but always be careful Make sure it’s not during the game because I don’t want to hear from you. I understand. Yeah. Well Peter. This was awesome I think this really opens up a lot of a lot of minds to not like not only what we’re providing with the Automation service, but what really what can be done and it’s not just for the network operations teams or the security operations teams There’s a lot of scalability in that because you have different teams building automations with different tools Now you have the ability within our solution to expose that to different teams unified in one platform but now Opening this whole wide world up to API integration to whatever it is in your ecosystem that you have today or tomorrow Right, and that’s really not science fiction Although that that is a little bit later in the journey for some But to know that that’s available now and they can go ahead and start leveraging it Just the way you you you cooked up the the github action CI CD pipeline It’s just as simple as that anything that that has the ability to integrate with API’s is now Something you can expose an automation to and leverage that as part of whatever it is that you’re doing in your organization

Peter Sprygada • 26:21

Yeah, I think that’s the point, exactly. If I think about being an automation engineer, or if I’m writing automation, or maybe I’m just a network engineer getting into automation, the last thing I want to do is, I’m focusing on trying to solve problems in the networking domain or in the Cloud domain or whatever domain it is that I work in. I’m writing things to solve those problems, whether I’m writing Ansible playbooks or Python scripts or whatever it is I’m writing, it doesn’t matter, but I’m writing things to solve use cases. What I don’t want to do is I don’t want to have to write copious amounts of boilerplate style code, if you will, just so I can simply expose my capabilities to the outside world via an API. Perfect example, case in point. I’ve written a Python script. We went through this in our last session.

Peter Sprygada • 27:03

If you remember, in our last session, we talked about show running, which was just a script that would go out and execute show running and return that. I want to focus on writing my Python script to just do that. I don’t want to have to get involved in writing an entire infrastructure that provides logging and securities and APIs and all the stuff I would need to do to be able to integrate the environment. That’s really where IIS brings to help fill out the puzzle. IIS brings all of that infrastructure so that I can stay focused on just simply writing that Python function, writing that Python script, writing that Ansible playbook, plug it into Gateway 5, and then IIS can expose that as an API, but then I can either leverage through the UI, through my CI-CD pipelines, through external tooling, through even other bespoke applications if I want. That’s really what we’re trying to deliver with this web service.

Rich Martin • 27:57

Well, thank you so much. I think that puts a very nice period at the end of the demo. We’ve exposed and we’ve shown all these features, but really this is just a springboard for anybody that wants to give it a shot and try. The good news is you can have a 30-day unlimited trial, no credit card required. Just go to itential.com slash free-trial. It’s itential.com slash free-trial. Any of the things that we’ve shown you today, or in the previous two sessions, are they available in this trial?

Peter Sprygada • 28:30

Everything is available in the stream. Everything. Everything is available.

Rich Martin • 28:35

We definitely encourage anybody who finds this interesting. We hope a lot of folks find this interesting because this is something we’ve run into many times talking to different organizations, different companies on their automation journey. We think this is something super valuable that’s going to save you time, that’s going to make all your teams more efficient. We want to make this available to you to use. Peter, it’s a poignant time. We’re ending this session. I’m going to say, do you have any last words?

Peter Sprygada • 29:06

Yeah, just, you know, for, you know, getting started, you know, if you have questions, if you have comments, you know, if you have thoughts, please reach out to me. You know, you can find me on the Twittersphere, at Private IP. You can find me on Mastodon, at PrivateIP, at Fostodon.org. You can reach out to me on LinkedIn, or you can reach out to me on the Network Automation Forum Slack channel. I’m in all of those places. I love talking with folks, so don’t be shy. Reach out to me.

Peter Sprygada • 29:34

I want to hear your thoughts, your comments, your questions, and always, and even if it’s, you know, to help you get started. You know, I’m here to help in any way I can.

Rich Martin • 29:44

Peter, thank you so much. It’s poignant because I’m sad to see these three sessions go so quickly. Working with you is always a pleasure, but I know there’s always more in store, whether it’s in front of the camera or behind it, so I really appreciate it. And what Peter just said is legit. He is somebody who definitely is always there to help out and lend a hand, so I appreciate that, Peter. Thank you, Peter. All right, thank you very much, everybody, and goodbye.