beers with engineers uh we're really really excited we've got some great stuff to chat about with you guys today uh i am going to pour myself i don't know if you can see that very well but i've got an admiral abyss from odd 13 brewing it is a chocolate milk stout they're a little local colorado brewery that has awesome artwork on their cans and really good beer too so that's what i'm doing will what do you pour in there i have a joanne ipa from a local brewery called browns in the uh troy new york area nice well so we do have to start off with and i'll let you kind of run from there but we'll start off with you know the good old safe harbor notice right some of the stuff we're going to talk about here today is not yet released you know don't make any stock purchasing decisions around anything that we have to say so we'll why don't you run us through the agenda and then we'll talk through the rest of what we've got going on sounds good okay um welcome to our second installment of cloud native beers with engineers we don't stand on a lot of formality so we have a pretty minimalist agenda and it's certainly meant to be dynamic feel free to raise your hand throw questions in the q a or chat window as they come up or feel free to come off mute and just give a shout so why are we here so the goal is to try and um try and promote some exchange of information and knowledge and lessons learned between those of us at servicenow and our customers who are exploring the the cloud native world implementing various xaas services facilities platforms and to try and try and um discover ways that servicenow can make that journey easier who are we yeah so mike gallagher uh i'm an advisory solution architect on the uh america's west itx commercial team uh been in i.t for 25 plus years i've done everything on its own if it's got ones and zeros in it i've probably sort of had a hand in it at some point i love what i do i love talking about technology and using technology to solve business problems i love helping customers solve problems right and and just kind of siding out a little bit about me i've got a wonderful wife and four amazing kids so never a dull moment around my house i train brazilian jiu jitsu and i play a lot of board games not only with my family but also with my friends i'm will hallam i'm an advisory solution architect for itom in the commercial vertical i've been in technology for more years than i can count and working primarily in it infrastructure started as uh kind of an early on unix person and then just branched into all kinds of variations of i.t infrastructure systems engineering most recently doing a lot of things in the cloud especially automating a lot of repetitive cloud related tasks via via servicenow and in my spare time i like to hang out with my family play a little hockey now and again and probably way too much time on video games our first topic in the technical deep dive section of the program is just going to compare and contrast some of the methods that are available for discovering kubernetes clusters and there's three primary methods one is to use our out of the box discovery patterns which been available for several releases now and they can communicate with the api endpoint for any kubernetes control plane whether that's sitting in a cloud roll your own if it's a mini cube running on you know a raspberry pi under your desk we can talk to it with with the uh these discovery patterns the second option is something called cloud native operations cloud native operations is available in the innovation lab of our store it's going ga later this year and what that does is that actually creates a couple side car containers in your kubernetes cluster which contain our agent client collector and a mid server and those two containers push both visibility data the things you would typically get via discovery as well as various metrics that are available by querying things like prometheus and istio into your servicenow instance and then the the third method is the automated discovery pattern and what that is is a new functionality that started rolling out with the current store release of of patterns which discovers cloud-based kubernetes so if it's discovering a google cloud for example and there are gke clusters in that cloud account in that cloud project the automated discovery pattern will pull in the information about those clusters and automatically create a discovery schedule to discover that cluster for you which if you are looking to have a large scale deployment of a lot of kubernetes clusters in a cloud account this can save a lot of time in terms of setting up your discovery credentials and establishing your discovery schedules okay here are the uh pros and cons for manual discovery patterns uh the the big pro is it's our most mature solution it's completely you know fully supported whereas the other two solutions are newer the downside is the fact that it requires a one-to-one uh credential in many cases uh we we are hearing from customers who use a tool such as rancher to manage their clusters and have found that they can configure a credential at the rancher level which can then apply to multiple clusters but in general there's a need to have a credential defined for each cluster that you're going to discover it also requires two separate schedules the documentation for setting this up instructs you to create a cluster discovery schedule which runs the kubernetes cluster pattern that queries basically every single object inside your kubernetes cluster and because that can be um that can be not a short running operation in a cluster that's very large the recommendation is run that but daily perhaps twice a day and then we have a second pattern which is called the event pattern that just pulls in a set of recent kubernetes events based on you know basically it does a baseline the first time it runs it stores the date of the most recent event entry that it pulls and then when it runs subsequently it just pulls new events that occurred from that last run time and so that runs more quickly it parses through the events for pods that went away pods that were instantiated etc during that time window between um the current run and the previous run and then updates your cmdb accordingly but again it's a bit of a con because if you've got a lot of clusters you've got to establish those schedules for each cluster and the the out of the box pattern supports using a containerized mid a standard mid and as i mentioned it can point at any kubernetes endpoint so if you've got kubernetes clusters running in aks eks gke you can point these discovery patterns at those and the pattern will successfully inventory and update your cmdb against those clusters bottom line this will probably discover almost whatever you need to discover but it doesn't have a lot of bells and whistles it's you know kind of the baseline configuration and needs a bit of of management and hand holding great summary mike cloud native ops so the pros on this are it it's very easy to deploy it um you're provided with a standard manifest that you can apply to a kubernetes cluster and kubernetes just takes it from there it establishes a mid server and an each acc agent and those automatically phone home into your instance based on parameters that you pass into the uh into the deployment it includes metric ingestion so in addition to just updating your cmdb it's feeding metrics in which you can then use to alert responsible parties when something goes out of whack in your cluster it also enables things like traffic and tag-based service mapping so it kind of it can provide a leg up a shortcut to establishing service maps against what you've got running in kubernetes and another big plus there's no credentials management required because it's a push back into the um back into your instance the uh the sidecar mid server the the cons it it is coming ga is coming later this year it's not yet ga which just means that um if you know our recommendation is not to run it with you know mission critical workloads because if push comes to shove and you need support on it all the various underpinnings of full production level support are not quite there for it yet scaling can be scaling is a consideration if you have a hundred clusters running cloud native ops against those hundred clusters would mean you'd have a hundred mid servers showing up on your instance and so you'd wanna you know be cognizant of your current instance sizing and probably work with your uh account and support team to make sure that you're sized appropriately for the number of mid servers that you'd be looking to um stand up before you just blasted this out to you know a large large-scale deployment of kubernetes clusters and it does rely on you having things like prometheus and istio in order for it to get the full set of metrics back so you'd want to kind of look at your current design what the current kubernetes plug-in um standards within your organization are and make sure you kind of marry those up against what cloud native ops is looking for and and get an accurate picture of what the full value add would be again before you just kind of blast it out there to a lot of containers uh cloud native ops because of the way it functions it does require you know it only works with that containerized turnkey mid that it stands up as part of the deployment fully functional within aks eks gke or any kind of kubernetes cluster you can you can come up with really and a quick point um adam had asked about um in the q a about support for openshift uh for the manual patterns and i had just forgotten we we do currently support open shift and when we put the slide deck together i just totally forgot that so i wanted to make sure we called that out um as part of this as well so yeah great call mike there is uh specifically an open shift plug-in which does which is included as part of the out of the box regular kubernetes pattern which will look for open shift to be present on that cluster endpoint and if it's there it can pull in the openshift specific items automated discovery patterns so this is a new functionality we've started rolling out with the current store release of the discovery patterns app which is 1.0.89 and what this means is it's kind of a synergy between cloud discovery and kubernetes discovery and so starting with gke when a gke cluster is discovered this pattern will create a discovery schedule for that cluster and then when that schedule runs it will use cloud api commands to extract a an appropriate credential that it can use to perform the discovery and so this has a benefit of making scalability a lot easier you're no longer having to manually create schedules for individual clusters and um just kind of the the dynamic nature of the cloud marries up a lot a lot better with this type of approach as opposed to having to have some kind of process off to the side where you are constantly reconciling your discovery schedule against what uh cloud-based kubernetes clusters you have provisioned in your environment this will work with either a containerized mid or a standard plain old mid server current support is eks and gke currently available in the store release and the july store release is planned to have this functionality available for aks yeah and actually that's a good point this deck is wrong and we'll make sure to update that because they actually got it into the april store release before the may still release so this is this is now currently live for eks and gke as of the 1.0.89 discovery and service mapping patterns update and then this is just a really high level we don't need to walk through this but this is kind of a just real quick snapshot you know we'll provide this deck to everyone after we're done here but that way you can have a real quick snapshot to understand what the various methods are what the pros and cons are and and you know what what potentially would be the best you know um solution for you any any questions about the various methods before we shift on to the automated configuration and deployment portion you guys have been doing great throwing questions in the q a so keep doing that and don't you know don't hesitate if you'd like to come off mute raise your hand and you can ask your question that way as well hey mike while you're switching over to your uh your auto mid segment i'm just going to pop up the uh first poll okay just a quick uh poll just to garner some feedback from you folks about um what you're doing today for mid servers and what your initial thoughts would be on the concept of automatically deploying and retiring mid servers in your environment and then also just trying to get a flavor for what um what your most commonly deployed cloud resource is outside of vms so you should see a poll up on your screen if you can take a couple minutes to jam through those questions raise your hand if you don't see the poll yeah if you don't see the poll please oh we're starting to see answers come on in perfect so while you guys are looking through that i'll talk through a bit on uh so uh mike had a question around michael hunt had a question around the um the cloud native ops uh estimated ga what i'm hearing is q3 q4 but that's super fuzzy depending upon other road map things the automatic discovery capabilities gke and eks are actually live now and azure aks is expected to be july the other thing about cloud native ops is um as with a lot of you know enhancements on in service now a lot of it is driven on customer feedback so if for example cloud native ops the idea of cloud native ops really resonates with you feel free to drop us a note and we can kind of you know use that potentially to add fuel to the fire and let the business unit know you know we've got this level of interest in that um to potentially you know kind of get a more solid uh ga plan in in place for that functionality yeah agreed great point so this is this is the part where we talk about my background and why i have my background up here today so my background is from a video game called satisfactory which is all about building and making a completely automated factory floor that you know builds and deploys more stuff so it's a really kind of fun and interesting game be very careful it's easy to go down the rabbit hole but it it absolutely you know relates to what we're talking about today which is kind of automatically deploying and configuring more mid servers and the the whole like why we did this is let's say you're a customer that has a significant amount of infrastructure that you need to discover and you need to be able to discover it in a timely manner right you can't have a discovery process go for days and days and days and days and days and days and so as a result you may need a significant amount of mid servers in order to scale that capability up and your capacity up in order to be able to discover your components uh within a reasonable time frame however over time that could be incredibly costly if you're doing that in a uh you know an aws environment and you're running these all as ec2 instances you know having the 30 ec2 instances running full-time just so that you can discover stuff at night could be costly so the concept here is to automate the scale up and scale down of containerized mid servers so that you can dramatically increase or shrink your discovery capacity as needed so this is a quick kind of high level overview of the architecture and we'll kind of walk through the whole process as i kind of show you what it looks like and so the the first thing we need to do and i'm not going to cover this today but um i i just posted a blog article on how on on this entire process start to finish and what i did in order to get to this point so we'll make sure we send out the link to that blog article as part of the follow-up to this but the first thing you have to do is you have to prefer prepare your instance for tla tls based mutual auth right which is something that is a little bit of a tweak and the bottom line from a customer perspective you'll just open a support case and say hey we need to set up tls based mutual off and the support team will go through and do all the necessary components in order to ensure that's up and working for you once you've got that completed um you'll go through kind of the the preparation of the tls certificate chain and i'll dive into that and we'll get more into kind of the how in a minute but first i'm going to take a step back and talk about the architecture right so what you're seeing here on the screen is here are the components in the servicenow instance that sort of make up the capability to do this so we have to build out profiles for the mid server we have to build out the request record right and then we pass it over to what's called a deployment mid server deployment mid server is a mid server that's already on the kubernetes infrastructure that has the capability to deploy resources on that kubernetes infrastructure it then goes and deploys the rest of the mid servers automatically for you and then the same thing occurs when you delete them and it scales down so we'll kind of quickly review what it looks like so from a profile perspective this is hey this is what i want these mid servers to look like and be configured as once they're finally deployed so things like what what servicenow instance should they be connecting up to and you know on the wrapper configs you know it's you know java heap size and things like that if you want them to come up and be clustered together you can have that be configured you can configure their capabilities all of the normal mid server configuration options are there as part of these profiles so you can build that profile and then use that profile to instantiate your automatically deployed mid servers once you've got the profile built and you've got the other components built you've got this deployment request and i'll show you this live here on an instance here in just a minute but but basically you have to go in here and say hey here's how the deployment request looks here's how i want these mid servers deployed here's the container image to use and and then once you hit submit that um once you hit process now it's sending that off to the the deployment mid server to go get that those mid servers deployed in the kubernetes infrastructure it's very quick and it's a it's very fast so and once you've deployed that you can't make the any changes to the deployment request until it's completed and then i can show you you can actually make some tweaks after that and sync it back down to the running mid servers so we've actually created a new operation and i'll show you that in my in the logs as it's running but we've created a new operation called kubernetes operation probe which is where it's actually going out and deploying those resources right so it it accesses the kubernetes api using a service account that that pod is running as and then it accesses that api and runs and does the deploy of the rest of those mid servers on the container and then the same process happens in reverse when you delete those mid servers on your instance so when you go on to your instance and say oh hey i no longer need these mid servers it actually triggers the deployment mid server to go and actually delete those deployments on your kubernetes infrastructure so oh hang on i i'm jumping ahead so let's jump into an actual instance and i'll kind of show you the process and how i walked through and and did this so the first thing i did is i actually because mid servers when they come up you can't give them any commands or do really do anything with them until you validate them on the instance which is if you're deploying you know five or ten mid servers in the middle of the night so you can scale your discovery process that's not really all that terribly useful right hopefully your your you know your discovery managers are asleep so the idea was i used tls mutual tls authentication to be able to provide the tls certificate to those new deployment mid servers and have them automatically authenticate against the instance and when they do that they automatically come up validated and ready to start taking ecc requests essentially so this is my deployment mid server this cert mid here and i'll quickly show you on my terminal um kind of what the yaml file looks like that i used to deploy that so so it's really fairly straightforward right i say hey you know i'm here's the name i'm going to deploy it i'm going to make it part of the mid server management app right i give it what image i want to use and what um instance to connect to and where to get the pim file for tls authentication and it comes up in this particular case i'm i manually am using the azure key vault store but on the rest of them using the just native kubernetes secrets for the the pim certificate so once i've got that up and deployed now i've i've gone through and i'm gonna i'm gonna jump back a little bit and show you kind of the tls certificate preparation what i did in order to get tls certificate authentication set up was i added in you have to go in and you have to have the root certificate if there's an intermediate or an issuing certificate you have to have that and those go into this ca certificate chain records right so when you go in here the this was an interesting component and if you have to go and do this i want to call this out because it hopefully will help you kind of sidestep some problems i had you fill out these records and then you attach the pim file to the record and once it's attached then you submit the record and this is the important component here this publish status what happens is once you get the certificate loaded into the instance the instance is actually fronted by a load balancer that does the tls termination and it has to publish that's that root ca certificate into that load balancer so that that load balancer can actually handle those those tls requests so you have to wait you in my case because i have a a root certificate and i have an intermediate certificate and then i have my client certificates i had to wait for the root certificate to publish and become active and then i had to upload the intermediate certificate and wait for that to publish and after that i can go in and i create this user to certificates mapping so this is where i say hey the user that i want to have authenticated as the mid server right this is your mid server user that your mid server logs into the servicenow platform with and executes command as i need to map that user id to that client certificate that i'm providing so again here you go new record right you give it a name and you know kind of a nice mapping you you select which user to authenticate it to right and so in this particular case um i just i i called it cert mid just because i was or off just because i was messing with it but it's the my my kubernetes certificate authentication user and then again you attach the client certificate just the certificate not the key you attach the certificate here and then once that's done it's published appropriately and mapped to that user so once you've got that completed kind of the next step is to go and build a kubernetes certificate and the kubernetes certificate the way that you do that excuse me kubernetes secret the way that you do that is you say cube ctl secret create secret generic and i just said hey i want to call it mid-cert right so that is the name of the secret and then i want to ingest that from a file right from file equals and then the file name so that file needs to include both the certificate and the private key so that the mid server process can use the private key to ingest the certificate into the store within the the mid server container it's really really important as a lesson that i learned so once we've got both of those in the file and in the certificate you have to remember the name of this file right because the way that it gets mounted into the into the container that's running into the pod it actually gets mounted as your mount path slash the file name that you use to ingest it into that secret and i'll show you why that's important here in just a minute hey mike speaking of mount path adam put a question in the q a asking whether or not you had to pre-create the mount path that you put in the ammo file or if kubernetes was taking care of that for you based on what you put in there great question i did not have to pre-create that mount path that mount path does not exist in the um in the container image kubernetes handles that for you and presents that whole mount path appropriately into the pod so once i got that once i got the secret set up the next thing to do is uh to actually make sure that you have your container image built right which is what we talked about in last month's and and i have a blog post around how to do that uh but um so i won't go back over at today but needless to say i built a container image and made sure that it was ready to go and i published my deployment mid server using that container image and that um and that yaml file that i just showed you here momentarily moments ago once you've got the deployment mid server up now you need to go in and you need to define your profiles for how you want the mid servers to be deployed right and so you need to go into mid server profiles and deployments which is a new san diego functionality if you're not on san diego you won't see this yet but there's this mid server profiles and in here i've just gone and built out a manual profile that says hey this is the url i want to connect to and i want to just set it up for all applications all capabilities all ip ranges right i didn't want to restrict anything probably not the best solution of the best design just because you know you may want to actually restrict it down to discovery from an application standpoint but for this particular use case and for testing purposes i made it simple and straightforward as possible so once i've got that done right now you go in and create your deployment request so i've got these mid deployment requests and it keeps a record of these deployment requests this was one that i did earlier in testing but you can go in here and you can say i'm going to duplicate this deployment request so i'll do that just so you can see kind of how what the process looks like so you name the deployment request and you tell it hey this is the mid server profile that i want to deploy as part of this deployment request here is the image repository path and the image tag to use which you'll you'll notice matches what i had listed in my um in my yaml file for the deployment mid server and then there's three tabs down here on the bottom that really control how that those mid servers are deployed right so there's a the naming convention prefix and then how many of them you want right so it's going to actually do an auto naming configuration where it'll it'll iterate through you know it starts off with you know midcase001 and continues to increment so which you'll see here in a minute and then you add in the cluster info so in this particular case um the most important things that i changed here is the name of the secret that i created in my cube ctl create secret command so this is the name of the secret and then this is the path that i want it mounted as plus the file name that i used to ingest into kubernetes for that secret right super important if you don't get the file name on the tail end there then it won't actually know which component to ingest out of that secret because you could have multiple different files in that secret so once that's completed you know oh yeah the next one is you can specify which mid server to use for the deployment process right so in this particular case i've already built my deployment mid server and so i just said hey i'm going to specify that one deployment mid server to make sure there's no questions about mid selection process now because i copied this from another from another deployment request it's not going to deploy anything you'll notice the state is still at new right it's not going to deploy anything there's two options here one you can export to a yaml file so this is hey i want to actually deploy this but i want to make some tweaks to the yaml file first manually before i go and deploy these mid servers and so you can export it to a yaml file and then go to do the deploy yourself this is maybe you have a different secrets driver that you need to add in or you may have a private image repo that you need to add in authentication for so that it can actually download the images so you may want to do it that way the other option is hey i've got everything i need i'm just going to go ahead and hit process now so i'll go ahead and hit process now and that's going to actually go out and deploy three mid servers on my kubernetes cluster and so we'll go over to the logs for my mid server and you'll see that this is this new operation called kubernetes operation probe so let's kick that off and you'll also see that it's completed almost immediately right very very quickly and then we'll go and look at we now have three deployments with three new mid servers that are up and running and we'll go back to my instance you'll notice this has already set this field to complete if we reload that it's complete here's the total operations here's all the information around kind of how that all worked and then i'll go look over at the mid servers and you'll see that they've come up and they're already validated and ready to start taking eccq requests because they've got that tls certificate and they've got mutual off running already so they're all ready to go and then we can go through and and delete them from here or we could go in and we could change the profile and reconfigure the mid servers to say hey we're only going to do this or we're only going to do that and and so as a result then you can go back and you can resync that profile out to the already running mids and get that working so pretty quickly i went from just one deployment mid server to hey i've got you know three more mid servers ready to go and start discovering stuff we could probably scale that much larger the the recommendation in the documentation says we probably shouldn't do more than 10 mid servers at a time per request but given how quickly that ran i'm kind of surprised about that that 10 limitation so thoughts questions anything that's come up while i was running through that demo nothing in the chat or the q a is this something that might potentially be useful for folks on the call i saw something pop up yeah adam has a question about what it does under the covers i think it's creating a deployment you could probably take a look at the ammo file and see specifically yep i'll show you so it's thank you for that feedback darshan okay i appreciate that there you go so that's the yaml file so you can see what it's doing here right here's the configuration url here's its profile id and here's here's where it's mounting that pin file here's the deployment name so it's gone through and it's built out this yaml file it's deployed it all out into the infrastructure and it does it all automatically and if you want we can actually go look at good let's see here describe okay so a couple of questions coming up here so bob you asked can pdi's be set up to do the tls part um that's a really good question i've never tried to do that so we might that might be a support question honestly i can make a note we can kind of do some leg work and see i know you you've made friends with a couple of the uh the tls developers at this point so we might we might be able to get some insight there and then as far as hardware recommendations for setting up kubernetes clusters at home to test this out with um i can tell you what i'm running on right like i've got a three node intel nut cluster at home um that i am running vsphere on and then kubernetes on top of that that is purely because of my vmware background um you can probably go a lot leaner and a lot cheaper i mean i know i had no friends who are running clusters of raspberry pi's with multiple kubernetes nodes on them right so um it's really kind of a question of what works best for you and your budget will thoughts there yeah i've done a couple different things um if i just need to test something quick with kubernetes i do like mini cube just you know that can run basically anywhere whether it's uh like a virtual box linux vm on uh you know on a modest uh desktop or laptop computer um i like the uh i do like the cloud the the different cloud-based kubernetes offerings i found i actually did i did an exercise and wrote a a community article on spinning up a a windows based container mid and um those of you who have played with kubernetes probably know windows containers are not for the faint of heart so if you're gonna if you're gonna go windows i would say azure if if you have access to azure at all that's the best way to do kubernetes windows containers um you know we do still because um we don't use the cross platform power shell for any of our stuff yet if you want to run powershell stuff you have to have a windows mid so you can you can do a containerized windows mid um but there are a lot of caveats with doing that and i found that was most readily accomplished the uh via azure great question yeah mike's yeah mike was doing all linux mids but you can and basically everything mike did you can do with windows i mean it's really just a function of what uh image you're selecting and and i i have built windows mid images they are they're pretty big um windows windows because they you know they're based on the windows the base windows container image which is essentially you know us somewhat skinny down windows os image um i don't know of a way like with linux containers a lot of times you can strip like everything away and i don't know if that's feasible with windows but you can but you can do it and it i found it it worked fine so let's shift gears a little bit and talk about the mid profiler that um well made so one of the things that we came up with was hey we have to manually make these profiles so we'll want you kind of talk about what your goal was and how you went through that absolutely so when this uh capability was announced mike got all fired up he's like oh man i'm gonna dig into this i'm gonna you know set this up we'll do an article we'll do a session um i was looking at the instructions and and i realized that there's a lot of um there's a lot of tabs on that windows profile screen and if you've got to do that multiple times that that could get a little tedious and then because i you know if i have to do something more than two three times by hand i generally my mind just kind of gravitates towards hey can we automate this it turns out we can so the way i did it was um just went into studio i created a scoped app and then i built some stuff using flow designer and because i did it as a scoped app it was really easy to pop it out into a git repo and so the links to that as well as the community article that i wrote on um on how i put the the different flows together will be available in this deck there on this slide and as mike said we'll send out a copy of this deck to all the attendees today so you can you can go and check that out it's um you know it's it's meant to be an example but it's pretty solid um just kind of give you a little bit of a look at it here let me stop sharing and you can cheer yeah i'll grab the share here okay um so here's the git repo again if you have new studio it's a really great way to encapsulate you know a piece of work that you're doing in the platform and then as an added benefit you can pop it into a git repo and that get you know as long as you're um fastidious about pushing out your commits you can you know really kind of it gives you that ability to rewind in case you updated some stuff in studio that you didn't mean to update deleted a bunch of things or or what have you so i chose to do this using uh a fairly low code approach um i did a little bit of leg work so one of the things that i looked at was okay what's going on under the covers as we're managing these these mid profiles and it led me to this script include called mid server profile and this contains a bunch of javascript utility functions that are running under the behind the scenes and they are what does the work when you say hey i want to spin up a mid based on this profile they basically copy a bunch of records from the profile tables into the mid server tables and so what i did to create a mid profiler was i just kind of reverse that process and just kind of flipped the source and destination and created some sub flows that would take those tables say okay what you know give me all the records from this table for a given mid and then copy them over into the profile table so this was kind of this this was just a little bit of you know behind the scenes leg work that i did kind of get some insight into like table names that i needed to be looking at as well as down here was kind of uh interesting there are certain parameters that you know kind of individualize a mid server and so those are it actually won't let you put those parameters into a mid profile so that you don't inadvertently overwrite some mid server record for a mid that already exists and so armed with that i just went into studio and just created this little uh create this little app which is basically got a bunch of flows ah good old demo instances so responsive right so basically what i created was a flow that just takes an existing mid server reference as an input uh checks to see if it's windows or linux if it's when because there is one uh most of the information about mitzvot are stored in your instance but there's one piece that isn't which is the wrapper override config and that's where you put things like if you want to increase your java heap size you put those in the you put that kind of thing in the wrapper override config and i wanted to capture that as well so i just built a couple steps uh a couple actions one is the powershell action that pulls that file the contents of that override file from windows mid and then one is an ssh action that pulls the contents of that file from a linux mint and then pulls it into a flow variable then i fed that into another action that basically parses that and generates records inside the corresponding windows excuse me mid profile subtable if you will and then for each of those other tables i just created a subflow that queries all the records from each table that correspond to the mid that i select that i want to profile and just copies the records from the mid table into the mid profile table and again i kind of get into fair amount of detail in the community article and the git repo can be you want to clone that git repo and then you can create a scoped app within your own non-prod instance and pull in [Music] pull in all the code from your copy your clone of that git repo so an example of what that looks like and just put that um let's see i just kind of put a simple catalog item on the front end of it just for demonstration purposes so all i do is just select a mid and order it and so we can kind of see the flow running behind the scenes and so this kind of this simple flow is kicked off by the catalog item and then it runs the kind of the main subflow we can see that's already completed and then if i browse my mid profiles i just have it create a mid profile that's named after the mid that's used as the example and so what that flow did was it just kind of populated this profile based on a combination of the override wrapper settings that were in the wrapper file the wrapper override file on the actual server plus all of the different configuration property settings this one happens to be in a cluster so copies that information over as well and i did since i'm demonstrating this i did pick specific applications that the mid server would select would support specific capabilities and a specific ip range that i wanted to apply and it just copies all of that i mean at our heart we're a database and so it makes this kind of thing very easy and with um with flow designer it's all it can be done without having to write any code if you wanted to write code you could certainly i could have done this probably to be honest more quickly with javascript because i'm more of a kind of command line coder type person but i find it's a lot easier to kind of see what's going on by doing it within flow designer and exposing kind of those individual steps any questions so we did have one pop-up in the q a that i left for you because you've messed with the windows containers way more than i have any special requirements for log on as a service user and a windows containerized mid yeah my experience is it took care of that the docker recipe that they use to generate the image that includes the requisite i just took the default i let it create the default user um i didn't have to um i did not have to do anything special to kind of add that like when i i have experienced that when i'm doing a windows server uh windows mid by hand i've got to create the user and make sure it's got that logon as a service permission i did not have to do anything special to get the containerized windows mid to do that and if you haven't seen it if you look on a roam or later instance in the mid server downloads there is a a linux container recipe and a windows container recipe yeah that's been available since um rome so the once you get to once you get to at least rome you'll have access to those um docker recipes which basically just gives you a docker file and i'll include a i'll include the link to the article that i did on on pipelining the uh and mike has an article on kind of the build process i did an article on pipelining uh the mid server um container image built and we'll include both of those links in our follow-up email includes the slide deck yeah basically gives you an example of of how to actually kind of take this um kind of raw material and and turn it into a container image for a mid server i've already found the uh the pipelining to be an important process because as i was going through and building out this automated mid server deployment process we actually updated my instance so the images that i was building off of were now no longer valid for the instance and i had to go through the upgrade process and i didn't want to have to deal with that so i triggered off my pipeline and built out the the newer version of the mid server that matched my my new instance and that that helped significantly okay well we're bumping right up against the top of the hour and um mike and i i think can certainly hang out if there's any uh remaining questions also if you have any additional follow-up questions or uh suggestions for future sessions format etc different beers you want us to try whatever um feel free to to email us our contact information is um you know will definitely be available in the uh you know the follow-up email um i did put up a an exit poll if you'd be so kind as to give us some feedback that way as well that would be great and um yeah if there aren't any other questions will adjourn we'll give it a couple minutes in case anybody wants to raise their hand or put something in the chat for the qa bob's asking about the ga for cloud native ops we've heard a fairly fuzzy third fourth quarter it feels like if customers ask for it loudly that could accelerate so if you you know if you need assistance getting the right channel through which to ask for that vociferously feel free to reach out to us otherwise you can certainly uh consult your account team on how to um you know how how to make make servicenow aware that you're very interested in cloud native ops i'm going through now and allowing everyone to talk so if you would like to come off of mute and ask any questions you want anything related to kind of what we talked about today you know don't hesitate don't be shy and actually we can stop recording as well that way uh-oh going off the record that's always dangerous going off record guys