Itential Platform Dev Stack: Lab Demo Series

Elliot Conner • 00:01

Hey everyone, my name is Elliot Connor, and I am a solutions engineer here with Itential. And today I want to welcome you to a new series that I’m starting where I’m going to help you set up your own Ittential developer stack and be able to automate and orchestrate against your own networking devices. So before I get into anything though, I want to just take a moment to level set about who this course is for. It’s for everybody. Even if you’ve never touched itential before, you’ve never heard of us.

this course is designed for you. It’s designed for people who’ve never seen it and all you have is a laptop and who want to be able to get up and running quickly. So that is my goal. That is what we are striving to do here. So let’s get into it and take a look at what we’ll be covering today.

So let’s meet your platform, okay? The first thing that we’re gonna, or the overall platform consists of two pieces for Itential: the Itential platform itself as well as the Ittential gateway. Both of those two pieces are what allow the lab to talk to our devices. In our case, we have two four devices, two FRR routers down here and running OSPF, as well as two Arista switches.

down here running OSPF. Now the entire platform and gateway as you see, we’re going to go over it in in five different steps. The first thing that we’re going to do is we’re going to prove that our lab even works. I’ve done some behind the scenes work to set it up and you’ll get some of this too if you or you’ll see this too if you download the GitHub repo and go through the steps. You’ll see the ways that you can verify your lab. I’m not going to go through that in this video here. We’re just going to focus on the

Actual platform itself. But we will just I’ll show you how we verify that everything’s up and running so you can just make sure yourself. Then we’re going to sign our way or sign into the platform itself and then just kind of look around and see some of the pieces that make up the platform. Then we’re going to follow a command from the platform to a device so you can just see how that flow works and what it really entails when we say using a workflow.

that workflow is actually going to then allow us to read live. Well, I’m sorry, not the workflow, but then we’re going to read live configs from a device using our configuration manager so that you can see how you can gain access to device information directly from the platform. And then finally, we’re gonna run a job so that you can see the whole process in work. So just bear with me and sit back. We’re about to have a lot of fun. So let’s go here.

Sorry about that.

All right. So this is our Tinchal login screen. But you know what? I did tell you I owe you a verification. So let me verify that real quick. We’re gonna go to our terminal here.

And I’ll share that with you. And the only thing that I’m gonna do from this terminal is run one command, make verify. And this is going, like I said, some stuff that I’ve done behind the scenes, some tests, some checks just to make sure the platform is up and in good condition for us. So the main ones we want to focus on here are V6. that shows that our platform is connected and our platform name is Lab. V8 here, this is the OSPF checks.

for our FRR routers to make sure that everything is up and that they both routers see each other. And the same with V13 here for our Airsta switches, just to make sure that they are reachable via the gateway and that the routers themselves or the switches themselves can see each other. So with that, we’re gonna go back to our platform here.

Okay. And now I’m going to go ahead and log in. We have the super secret password. It’s admin admin. I already have it saved here.

All right. So this is the platform’s UI. Okay. This is, you know, from one login, you get to see every application on the app on the in the platform. And I’ll show you those here if you go to our administration essentials, our admin essentials, and you just look at the applications. These are all the applications here that are are listed on my platform and on my in my platform. Okay. So

The home page and the menu, they use the same kind of three groups to kind of help us work within the platform. So that’s going to be the administer group, the build group, and the operate group. And they all have their individual applications from within them that will allow us to automate using Itential. So the first thing we’re going to do here, we looked at the admin essentials, but now let’s look at the gateway manager. That’s how we’re going to administer our gateway. So

The platform, you know, itself never logs into a device. What it does is it hands work to a gateway. And then that gateway is what will do the SSH into a device for us to read or configure whatever we need. And it’s because of that split that the platform can even reach networks that it’s not even connected to, that it has no idea about. Because as long as the gateway can reach it, then the platform knows about it. So

Let’s take a look at some of these things that we have in inside our gateway manager here. Just starting from the top, we could add a gateway if we wanted to, but we’re not gonna do that here. but you see for our lab, it’s our cluster ideas lab. We are running a physical gateway. We also have virtual gateways. so if you don’t want to have an actual appliance or on-prem setup, you can run it virtually. And we have a description of this lab’s gateway, our last connection, when it was enabled.

And the connection status, which if you hover over, it shows connected. But if we click into our lab, this is where we see all the all the specifics about our potential specific gateway. So as you can see here, it’s enabled, it’s connected, tells you when, when it was last updated, all the good stuff there, what groups it belongs to, and the access information here. and then you could verify the certificates if you wanted to.

you can see which service groups and like I said, for us the default service group is the admin group and the admins, which you’re showing right there. That’s what they have basically have access to everything. And then we have access to these services also. But let’s take a look at the services tab because these are actually just Python. Well, these the send config and the send command are Python tasks. And then these are Python tasks that we can run through a broker. So I’ll get into that later on with later lessons in the lab, but I just kind of wanted you to see.

Right here. And this is where our workflows are coming in. This will come later on in this lesson. But we have one workflow right now on our gateway to pull a running config. And the type of task that it is, it’s a send command task. Okay. So that’s just a little quick look at our gateway manager and the things that our gateway manager does there. Next, I’m gonna go into our inventory manager. And the inventory manager is the platform’s list of devices and how

To reach them. Okay. If you look here, we’ve got one total inventory that consists of four nodes. This is our inventory right here, lab, same with here, descriptions, and it has groups. Now, if we click into it, this is where you actually see your devices. So remember from our diagram, we had FRR1 and FRR2. We have the tags here about them of what type of routers they are and where they’re located, the gateway. Same with CEO S1 and C E O S two.

All right. And if we wanted to look into the actions here, again, these are all of our actions that our lab devices can have, and they are IAG5 services. Again, we’re not going to get into the definitions and what all that means in this video, but we will get into that a little bit later. And the next thing after the end inventory is our configuration manager. And the configuration manager.

it sees the exact four all the devices that the inventory manager saw saw. So if you look on the left here, you see your CEOS one, two, fr one and two. So it sees the exact same devices. the only difference is if we click on CEO S1, as you see here, the status says offline, but it quickly goes to online. It is up and running. The difference is we can actually pull a running device or running configuration from our devices here just to view them. So let’s take a look at CEO S1’s.

configuration and this is making a live call to the device. So imagine I hit that button in the platform, it sends a call to our gateway, then the gateway forwards that call to the device and pulls everything back. And what we get back is a running configuration for CEO S1. Okay. And again, it’s a lab device. So you know normally you wouldn’t show all your Shaw hashes and all that stuff. But I want you to understand and see exactly what I see. So I’m not really worried about it in this video.

Let’s do the same thing for our FRR1 router, just so you can see that it’s a little bit different. Make the same call. It takes a couple of seconds for it to pull it, but here we go. We have our FRR1 configuration here. And so, you know, as you see, we’ve got two vendors basically operating them and looking at them both from one screen. And I, as an operator, never had to SSH or open a terminal to access and pull this information myself.

So that’s one of the real advantages of being able to orchestrate your devices and be able to have them all under one location for you. Now, the next thing that we’re gonna do is we’re gonna build our first job. And we’re not, well, we’re actually not gonna build it here. Let me let me take a step back. I’ve already done this for you in this video. We’ll build it ourselves in the next video. But I want you to see where we build our jobs, and that is in our studio here. So if I click in my studio,

As you can see, I already have one job or workflow in the in the studio. So I’m gonna click in it here, and this is a workflow. Starting from the top where it begins, we’re going to send a command and then we’re gonna send the command of show running config on both routers. Now I’ve already configured this. If we go in there and take a look into it, I’m not gonna go into this like I said, because it this isn’t the video for that.

But I’ve gone in here and set up some parameters to pull from these nodes, FRR1 and FRR2. If I wanted to do all four, I could. But just so you can see, I want to just do an example. This is what we’re going to pull here. So, and another quick thing, this red line here, this is our our failure path or our failure transition. So if for whatever reason we sent a call to FRR1 and the device is down or

It’s not able to the gateways down. Something’s wrong. Instead of stopping the entire job for all the devices that work, we’re just gonna send some data to tell which job failed. But again, we’re not gonna go into all that. These should pass. So what we’re gonna do here is we’re gonna go ahead and run this. Okay. Now I don’t need to enter in any access groups because again, this gateway has access permissions to both the admin group and the admin, both the admin underscore group.

Session and the admin. So I’m just going to go ahead and run this here. And what you see shortly, I have to zoom in. I’m sorry. But this is our workflow having been completed. Okay. So our workflow, our send command here. And let me go and run and go to another screen because it opens up another screen. And we’re going to our operations manager. And you can see it here now.

So again, if we start here at the bottom, this is when the workflow started. It goes through and shows you and says that it ran the show running config command on both routers, and then it gives us our workflow in. And the way that we verify that is we come here to our job variables after we’ve highlighted send command and we come to our job variables. Let me scroll this over. And this is the information that we got from the job. So starting from top to bottom.

The admin account is the one that initiated it. It has our job ID here, IDs here. We’re using JSON 2.0, RBC 2.0 here. And then our results. This is what we really want to focus on. So it ran the show running config command. It took 2.552 seconds. The host that it ran for this particular one was FRR1. And then as you can see here, it pulls all of the running config. It pulls it in this one long line here.

And the same if we go down to the bottom for FRR2, it did the same thing in 2.552 seconds. And those are actually the same time. So the whole job took about five seconds to do. And then at the bottom here, we have our status complete. And then it tells you which execution gateway it performed this against. And that was our lab gateway. So as you can see here, from our one workflow, it produced all of this information, the pool running config.

Which we can now see. So that is just a little preview of a way that we can interact with devices. Now, going forward, let’s take a look at our work center. Okay. These are two rooms that are two places on the the platform right now that are empty, but they’re just empty for now. We’re definitely going to be using these later on. the work center, which is under our operate section here, this is where approvals land. So

imagine I’m an operator and I get a config change ticket and that I need to approve. This is where it will show up. And you’ll get a good picture of this in lesson seven because we use it to actually make changes from in with inside the platform use via an agent to the devices. So cool things coming up there. And speaking of agents, the last place we’re gonna look today is our agent project.

Tab here under the build tab right under the studio. This is one of the new things and the most exciting part to me of the platform. We can come in here and build agents, AI agents for almost anything that we need to automate or orchestrate on our platform. So get excited. I’m not going to go into it. We were going to get into that into lesson three. So just, you know, though those are just the basics there that I wanted you to get to look into and to get excited about.

So, you know, that is going to really cover today’s lesson and today’s opener for us. And I hope you understood kind of what we were doing, what we’re building towards, seeing how the lab works in some of the different portions of the lab. Okay. So let’s recap kind of what we’ve done. We’ve proven that the lab works via the terminal. you all know the three parts of the platform: the administer, the operate, and the build.

portions and you also will you should all i’m sorry you should also understand how we get real information from real devices and how it all works in the platform so that’s a a good recap i think that’s a good stopping point for today in our next lesson we’re gonna build our own workflow from a blank canvas so

What we’ll do is we’ll back up a device into the configuration manager and then we’ll introduce clawed code in MCP. It’s a little teaser, so that we can start doing some of these things using our AI assistance. So I hope you enjoyed this video. I hope you found it informative, and I hope you come back and go along with me on this journey. It’s gonna be fun. again, have a good one. My name is Elliot, and I’ll see you down the road.