Transcript
Welcome to the NSYNC and Secure Building IDN and IIQ Pipelines with Service Containers panel here at Dev Days 2024. My name is Zach Adams, and I'm a senior IAM architect specializing in DevOps and SRE with instrumental identity. So today, I'm going to talk to you about how you can build CICD pipelines using service containers, both for identity IQ and identity now, and kind of explain to you a little bit of our experience building those pipelines for a variety of our clients here. So who are we and our experience in building CICD pipelines? Well, we at instrumental identity are an independent consulting company offering a wide range of services in the identity and access management space and are a SailPoint partner for a long time now specializing in both new and existing implementations of identity IQ and identity now for a pretty diverse set of clients. So with our clients being so diverse, we get a unique opportunity to work with many different infrastructure stacks. Some of our clients may be all in on the Azure stack where they're going through and handling their source control using Azure DevOps. They're doing their project management using Azure DevOps. Their computing infrastructure is located in Azure as well, but we also have clients that are using more of a trail mix of different technologies, GitLab for their source control, Jenkins for their CICD pipeline platform, Jira for their product management. With all of this, we start to see a couple of commonalities between all these different clients though, even if they have very different environments that they're working with. One of these commonalities is that everybody wants a pipeline. Everybody has a dream state, either in their leadership's head or actually in their project management board, maybe scoped out a little bit further on down the line and they continue to kick the can down the line, but basically they have this idea that they would like to have their deployments fully automated with at least a very bare minimum of being able to deploy to dev, QA and prod with little to no human input during that process. Maybe they want to have a little bit of validation checks beforehand or after the deployment, but generally speaking, these are common things that we see across everyone. Another thing that we see that's this next section here is a little bit more of the shortcomings or explanations as why people haven't built a CICD pipeline yet. One of those commonalities that we see is that everyone thinks that it costs a lot of money to go through and actually stand something like this up or they don't have the hardware resources currently available to actually dedicate to a dedicated build server. The thing about this is that with build servers and containerization, as you'll see here today, you don't need to have large data centers of IaaS hardware in order to run a build server. In fact, you can use ambient resources, but we'll talk to that or we'll talk on that here in just a second. Another thing that you'll see is that even if they do have those resources available, they may think that the hardware may change here in the next year or so. By that, I mean, maybe you're going through and evaluating different cloud providers and you haven't decided on if you're going to stick with AWS in exchange for, say, GCP or Azure. You kind of have a fear of how do I build something that's going to be cross-supported with future organizational direction. Another commonality that we see is that you may not have a lot of human resources available to you to manage this pipeline, or you may not have somebody who's specialized in building CICD pipelines. The thing about pipelines and CICD pipelines in general is that they're all written in YAML. It doesn't matter if you're using Jenkins or GitLab or GitHub, it's all YAML underneath the hood, which is a simple configuration language. Although some of the syntax may differ, so for example, GitLab requires declaration of different stages to run multiple computing jobs, and Azure can allow multiple jobs to run within a same stage. It still overall is similar in its syntax. You just need to know what's available to you. And then finally, with all of this here, we can kind of get around a lot of these problems using both a tiered approach when implementing our CICD pipelines, as well as whenever we design the container in which that they're going to run. So let's start by taking a look at how would we build a CICD pipeline. So a pipeline should serve three basic functions. First off, it's gonna be pre-deployment testing. So whenever I say pre-deployment testing, we're talking about linting, syntax checks, connectivity testing, unit testing before your code ever reaches the environment. This is something that you should catch issues before it even touches your dev environment. Second part of a CICD pipeline is gonna be your automated deployments. Of course, this is where you're actually doing the build of your application itself in the old ways of, you know, I did the IQ space, but identity now, going through and actually doing the deployment of your JSON files or XML files to your identity now tenants. And then phase three, which is post-deployment QA and regression testing. This is a more open-ended kind of phase here. And with this, we are doing similar checks that we do in our pre-deployment phase with a couple of extras like UI testing that's included. So this is using things like Selenium or Cucumber to go through and actually click through the environment to collect evidence during your deployment that you might need for closing out your change management ticket or to automate usability tests. So these three phases are to be implemented within sequential order. And the reason why you should do it this way is because it handles a lot of your dependency or it handles accomplishing a lot of your dependencies that you need when building your CICD pipeline. So phase one, you're going through and actually deciding on where your build server is going to live. And whenever I say build server, this doesn't have to be a permanent structure, but you're figuring out what will this infrastructure look like later on down the road. You're also setting up your firewall exceptions to communicate from that build server over to your source control management software. In phase two, whenever you're going through and building that out, that's where you're actually working on connectivity dependencies related to connecting to your application servers directly. So from your build server up to your IdentityNow tenant, making sure that you have those exceptions in place from your firewall team, setting up connectivity exceptions for your vault storage. So if you're using Vault, HashiCorp, everything like that. And then also this is where you will do some organic load balancing. So as soon as you start doing deployments, you'll really start to figure out and get a feel of if I need to scale this up or down. And with containers, it's very easy to do. It's one setting that you change, but this is where you start figuring that out. And then of course, phase three, since this is more open-ended, you never truly finish phase three. You're always going to find something that's a pain point that makes you stay up late after deployment, after hours, that could easily be automated using either those UI tools that we were talking about or by using some other scripting language. All of my tools I'm going to be showing you today are written in Python, but that doesn't mean you have to use it in your own implementation. You can use Bash, you can use PowerShell, whatever you're comfortable with. But this is where you try to find needs and fill them with automation. So now to talk a little bit about what this infrastructure looks like for the build server and kind of a more high-level overview. So you have the three phases of the pipeline, but whenever you're actually doing deployments and running these tests, you have two approaches that you can kind of take, two methodologies, a pull and a push methodology, right? So whenever we talk about a pull methodology, we're talking about pulling code from your source control management up to your server, building and deploying that way. This was something that was a little bit more common with on-prem applications as your build server was essentially your application server. And what you would do is actually clone it onto your machine, build the war file, and then deploy it that way. It was a really simple setup because you didn't have to have a separate build server in order to run this. You also didn't have to worry about a lot of the firewall exceptions that you needed because the build may have happened directly on the actual build or the application server or the built artifacts were attached via like an NFS or some kind of shared storage. Another plus of the pull structure was that it was that minimal build architecture. So you didn't necessarily need to have many dependencies installed when using a pull approach because your application server generally will have any dependencies that you need to actually even build that application. But there was a lot of cons that came with this too. So this is great for phase two, pull is, but for phase one and three, you're gonna experience resource drag whenever you're trying to run those pre-deployment tests or those post-deployment tests. If you're going through and linting every single file existing in your repository, you're taking away from what could be used for aggregations. And the same thing goes for UI testing as well as those are a little bit more resource heavy trying to run that. You also had resiliency issues. So if your application server went down, say due to like a botched deployment, there's a chance your application server would go down too. And even worse, if your application server also handed DR, or not your application server, your build server handled DR deployments. Say if your actual main production environment went down and you needed to fall back to a DR environment, well, that build server that was living on that production instance is no longer able to handle that deployment over to DR. You are basically dead in the water at this point. And then finally, in the biggest one, and the reason why we're all here is that with a pull strategy, it's not compatible with SAS. The thing is, is that you're not gonna be able to load a build server into your identity now tenant. For this reason, it's just out the window. So we come and take a look at the push methodology instead. So with a push methodology, we're going through and we are building the files, running the tests in a separate location, and then pushing all of that to the application server or storing those unit tests that you're actually running the pre and post deployment test into your source control. So you're pushing everything back at that point. What's great about this push methodology is that it's highly resilient. Since this is running from a separate build server, you're not gonna have to worry about, oh, I had a bad deployment to my application server and as such, my runner is down. No, it's gonna be able to stay up and actually report back even whenever your application server is down. So you can get real time feedback as well on kind of a push model here. A push model is also gonna be much more open to different build architecture designs. So basically by this, what I mean is you can go through and run this from either a full fledged IaaS VM or something as small as a Raspberry Pi or a developer workstation. As long as the firewall exceptions are in place, you're always able to do a build from whatever your build hardware is. Of course, push methodology is compatible with SaaS. I mean, in this case of identity now, we're making different API calls to upload configuration files and run our pre and post deployment tests. There's no resource drag because the thing is, is we are running separately from our main application server. But there is one con, it's that it's slightly more complex when setting it up. You're having to manage basically two locations, your application server and your build server if you wanna think of it that way. But I'm here to tell you it can be made much easier through the use of containers. So in order to get around this complexity, we use containerization. So if you're not familiar with containerization, containerization is OS level virtualization that's light enough to basically run on, like I said, from a Raspberry Pi up to your large scale enterprise IaaS environment. They are highly scalable. So using Kubernetes clusters, you can create more service containers that can handle your build tasks for you. And whenever I say service containers, we're not talking about the application itself living within the container. A service container has a unique specialized purpose that's for providing auxiliary services to your main application server. So for your dev test prod, this is going through and only handling those testing and deployment needs for you. And as such, like I said, you can scale them up and down depending on how many tests you're running and basically finish a lot of these deployment and testing functionalities in the same amount of time that it would usually take to run them in sequential order just by scaling up the number of service containers available to you. So taking a look at some of the pros with the service container model, again, infrastructure independent. So containers are small little OS bubbles if you wanna think of it that way. So you can run them on a Windows server or on a Linux server, on a MacBook, it doesn't matter. It's gonna be infrastructure independent. They're gonna be scalable. Like I said, they can scale up and down depending on what your needs are during your deployment process as you identify them through implementing the three phases. You'll have enhanced security. So during the runtime of a pipeline, containers are spun up dynamically at that runtime. So secrets and other things of that nature are injected during that runtime. And once a particular stage has completed or a job is completed within a CICD pipeline, the container is then shut down and then can be cleared completely from memory. So no bad actors can actually hijack that old container and use it for nefarious purposes. And then the final thing, and this is gonna be a little bit of a bonus feature here. These service containers are multipurpose. So over the last couple of years, there have been new methods that you can go through and leverage these containers outside of a CICD pipeline environment, allowing you to kind of run these tools in an ad hoc manner and make your development experience just a lot better. So getting into our journey. So this is something that we've been working on for a very long time now. And as I said before, we started doing this with IdentityIQ. And what we did was we started with a phase two deployments, doing our automated deployment strategy because that was what was wanted. And I hit a lot of roadblocks when I was building it. when I was building that out, those dependencies for connecting up to my different application environments. I was kind of rushing ahead. I wasn't able to look for my dependencies needed for my source control to actually even upload some of my test results. But as time went on, we started building out a more fleshed out phase one to go ahead and handle those dependency maps and as well as to kind of organically grew on its own. So we were doing a lot of remediation efforts that would typically be checking for syntax errors for long lived objects within an object repository that may not get deployed every deployment that may have things like misspellings here and there, or maybe they forgot a bracket. Basically, we would build up scripts and tools to go ahead and evaluate this here and found that, you know, if it's already being ran in a scalable CICD pipeline environment, might as well run it every single time. This became our phase one as we know it here today. And then finally, we implemented out phase three, which was that post deployment functionality. This kind of came from the idea that there are a certain number of regression tests that need to take place during a upgrade, whether that be for your actual application server or to service IQ service host or to VAs. We were basically able to take all of these scripts that we were writing. At this point, it was using Ansible playbooks to manage a lot of this and put those inside of our service container. So our service container then housed Ansible and we can run it directly from there too. Developers didn't need to go through and download Ansible on their machine and configure everything. It was just ready to go. And then from there, we started adding more generic playbook functionality. So things like needing to clear cache on a particular VA, or if you needed to grab logs off of a VA, or if you just wanted to bounce them, we started adding more generalized playbooks for that reason. And then finally, we went into doing a UI addition for our service container. Making the container, instead of a standalone kind of OS bubble and making it more like an executable that could run actually on your local workstation. So that way developers had access to this without having to necessarily push their code up right away. And this would later expand out to the use of dev containers, which is a new feature in Visual Studio Code that we'll touch on. And then, of course, we're always going and looking at trying to optimize and reduce the size of the container image. So with service containers, you don't, or containerization in general, you don't have to load all of the dependencies that would generally be required with the standard OS installation. You can get much, much more lightweight base images from places like Docker Hub that allow you to reduce the size dramatically. Ours was reduced to 41% of its original size, so in a magnitude of about like 1.1 gigabytes. And whenever you do this to the container, your pipelines run faster because it's not having to spin up this larger image. And as such, your deployments go faster. So what I'm gonna be doing here today is actually building a CICD pipeline for you guys. And we're gonna use my more mature image, but I'll also show you how to build your own image from scratch. But what this pipeline will do is validate the rules. This is gonna leverage the SailPoint rule validator tool. It'll utilize some of my helper scripts written in Python to go ahead and format the results into something that's source control friendly. So most source control platforms have a unit testing view where you can actually view, say like JUnit test in a meaningful manner directly from the UI. And then we also automate the process of submitting cloud rule verification emails. This is something that I won't necessarily show you right now just because we don't have an email system set up for this demo, but you can go as far as doing automated opening of say tickets to actually reach out to SailPoint to upload something or even send it from directly within the pipeline. We'll also implement a transform tester. So what this is doing is going through and utilizing in-house tooling to test transforms using dummy data. So I will be able to feed it in a kind of unit test JSON that has expected values as well as given values. And then in this particular test, it will dynamically create our source for us and give us a pass or fail, depending on what I've declared within my unit test JSON. This is more familiar with like, if you do full stack engineering, this is unit driven or unit test driven development. So, and then finally a test connection. So we want to double check and make sure that all of our sources are currently connecting up to their end environments without any issues. This is leveraging in-house tooling, again, Python tooling and the IDN API. So you can do this directly in a pipeline if you wanted to, if you wanted to loop through and call every single source and do test connection that way. But this is meant to act as kind of like a sanity check. Your litmus test pre and post deployment. We're gonna call test connection in our post deployment phase and compare the results between the two. And this can act as a red flag for if maybe a configuration got messed up or if maybe some configurations on the end application have changed and you're not aware of it. Then moving on to phase two, we're gonna do an export object. So one of the things that we like to do that we kind of found from our identity IQ days was we want to make sure that we export all of the objects in the UI before deploying to them. There's a lot of times whenever you make changes in the UI and then whenever you do a deployment, they get blown away. And this can be a day's worth of work or week's worth of work. By exporting objects and keeping a local snapshot of just the raw objects themselves, not the entire application, you can always roll back and make sure that you're not actually losing anything. And whenever we first built this pipeline, this was all using internal tooling, but as of recent time, there's been the release of configuration. I'll also show you how you can use configuration hubs APIs to accomplish the exact same task. And then of course, the automated deployment, we want to make sure that we're going through and handling our reverse tokenization of configuration objects before it goes to identity now and provide an auditable trail for the deployments that are occurring. So showing what config objects went out to identity now, whenever we deployed on this particular night. And I'll also show you how you can accomplish the same thing in configuration hub. And then finally, our open-ended phase, phase three, we're going to do that test connection again. So that other side of our sanity check there will compare those results within the source controls testing web UI. And then we're also going to run a UI test. So leveraging that selenium or cucumber, in this case, we're going to use selenium to go ahead and gather screenshots needed for us to close our change management ticket. So this can be expanded though, to go ahead and click through and actually trigger first aggregations or provisioning, say a new user, but just to kind of give you an idea that you can run your UI test directly inside of this service container here. But let's go ahead and see what this pipeline looks like. So over here on my screen, you'll see, this is my current identity now project repository. So pretty simple set up here. There's not necessarily an SSB for identity now, but we've kind of developed our own here, just a directory structure that contains a list of the JSON files that come directly from identity now that are then able to be uploaded back to the environment. And then we have our declaration of our CICD pipeline file here. So again, just a YAML file with different code in there. And then also a token file here to basically contain certain passwords needed to reach out to our IQ service or our different sources. We have an ignore validate properties is similar to kind of like your ignore files properties back in the old identity IQ days. But this basically allows you to skip certain objects from being validated by the rule validator tool. And then we have our transform tester unit test here, giving us our given and expected values. So, but we'll go ahead and show you what this pipeline looks like on our side here. So first off, go ahead and get our environment open. Okay. So this right here is that exact same repository. Right now we're starting with a blank GitLab CI YAML file. And what I'm gonna start by doing is declaring the base settings needed to build this pipeline. So this is gonna be setting up your base image that you're going to be using as well as the stages for the pipeline itself. So this is directly related to your different pipeline phases. So in this case, we'll start by declaring our stages here. And then we'll go ahead and declare our pre deploy and post deploy steps. Then we'll go ahead and declare our container image here. So this is going to direct to our container registry located on our source control platform being GitLab. We have a container registry that comes with that. And most source control platforms have container registries built into them. So that's something that you'd wanna leverage whenever you start building your own container. Then we'll start declaring our different jobs. So the first thing that I'm gonna go ahead and build is our test connection job right here. So we have test connections, the job name, we've declared that the stage where this is gonna be happening is the pre deployment stage. We're gonna allow failure during this because maybe sometimes the application goes down. We're calling the actual script for that tool. So in this case, it's a Python tool, but I've made it a single line command here. We have our artifacts being published. So in our pipeline, we like to use badging to go ahead and easily show visitors to the project repository, what's failing, what's the health of the repository overall. And then we also publish the JUnit test that I was talking about. So that way it can be displayed in a meaningful manner there. We also define an environment name here. So this environment name corresponds to an environment that I have declared within my CICD pipe or within my repository here. So if we go to our operate flag and underneath environments, you'll see that I have three environments stood up. So here's our IID partner demo. Same name is defined here. And inside of this, I'm going through and I'm declaring the URL for my identity now tenant here. So this is just the base URL, not the API URL. But once I define that environment in my source control platform, I can go over to the CICD section in my settings here, go to variables. So these are the variables that will be consumed by your container image whenever the pipeline runs. And it's then used by our different tools that we have inside of that container image. You'll see that they're separated out by their environment name. So I'll have an ID and password for my IID partner demo, as well as an ID and password for my ambassador demo, which will be our second tenant that we work with here today. But this allows you to basically have multiple definitions of an environment variable that corresponds to each independent environment. So that's our test connection phase. I'm gonna go ahead and move forward with our validate rules test here or validate rules stage. So grab this right here and put it in right here. So kind of a similar thing here, we're going through and we are defining again, which stage this belongs to. We are defining exactly where that script is being called. We're not allowing failure during this run because during rule validations, we're also evaluating whether or not a rule can be submitted to SailPoint, if it's a cloud rule. So if this fails and we don't want to go through forward with our deployment here. And then for artifacts, we are once again, displaying the badge that's associated with the rule validation test. We are sharing the JUnit test, our validation log from that rule validator tool. And then of course, our environment again. We'll do the same thing here with test transform. So this one right here is gonna do that unit test, consume that transform test.json file there. Same exact thing, calling the tool here, exporting the same files. Then we'll also do the same thing here with another new rule that we added in, which is going to be our test workflows rule. And I'm showing you this one right here because you don't always have to have JUnit tests defined for your tools. You can obviously just use log output that is produced whenever you actually run the pipeline. It's just, if you want something a little bit prettier and easier to read, you might wanna look into building your tool to produce a JUnit test or a similar testing report that can be consumed by your source control platform. So then we'll move on to phase two, deploy objects. So in this phase here, we're doing two separate script runs. So like I said, this is internal tooling. We do our export first. So this is gonna go in and grab a copy of all of our objects within the environment. And then we also do our import here. This will take all the objects within this folder here and import that into identity now. Whenever it goes through and does the export, it will show those exported files as artifacts affiliated with this job right here. Define our environment. Once again, we define our validate rules. And then there's a secondary rule down here. So this is something that's a little bit more interesting that you get with identity now. With identity now, you get event triggers, which allow you to fire off API calls whenever an event happens within the IdentityNow platform. whenever an event happens within. What I'll show you here is how you can actually trigger export events to occur whenever say like a source has changed, but we'll touch on that here in a second. Now, finally, I'm gonna go ahead and define the last of my phase three here, just real quick. So moving down over here, we have our phase three rules here. Like I said, we're going through and basically doing a kind of a second run of phase one. So our post deploy test connection, so we can compare the results between the two. Our test workflow, so we can compare whether or not a workflow stopped working after deployment. And then our collect evidence step. So this is where we're using that UI testing tool, Selenium in this case, to go ahead and grab screenshots and then export those screenshots as PNG files that are then attached as artifacts to the job here. So we'll go ahead and save our pipeline file and then push it up to our repository. So once this is committed here, your source control generally already know that a pipeline has been added to the environment and kick off immediately. So since I defined three different jobs or four different jobs during that pre-deployment phase, you'll see that all four of them are running in tandem. This is because it detected that there were four jobs that were within this phase here. And I had my runner configured to allow for multiple containers, service containers, to be created if it detected that it needed a little bit of extra horsepower there. So these are all running at once and completing up ultra fast. So we've already gone through our entire repository here and we are basically good to go with our deployment. But to take a look at what these jobs actually look like, you'll see that it creates a nice log output of what was happening inside of the container here. So you'll see where it's going through and actually doing all of the different tests for each one of the applications in our environment, our transform tester, our badging tracks WS, and showing success and failures for each and every one of them. But these are also being exported as those J unit tests as well. And formatted specifically for our pipeline platform. So I can view that exact same result directly from the test section here in our GitLab UI. And you have the exact same results just in a little bit cleaner format. We also like to include where it's located at on the identity now server. So I can go ahead and go directly to that source definition and view what the configuration settings are directly in the environment if there was an issue. But for our test workflow, so like I said, this one is not producing a J unit test. But you can certainly just use your log output on the pipeline to get the results of whenever a test is run. So like here we have workflow mover campaign was inconclusive. Workflow mover access history passed, you know, inconclusive pass. You don't necessarily need to spend all your time setting up J unit reporting right out the gate. It's totally fine to go ahead and just look for the results within the log output, but make sure that you're exiting with an error so that way it flags this as a failure if there is a particular failure that you're looking for. But we'll go ahead and do our deploy next. So we'll kick off our deployment here. And this time, since it's a single job, I'll show you what happens live in the environment here. So right now, it's told our runner pool that, hey, I have a job that needs to be run. Once one of the runners say, hey, I can go ahead and pick up that job, it starts by checking out the Git repository, checking out the Docker image for your service container, and then spinning up that service container here. And it happens live in real time for basically every pipeline platform out there that I've worked with. You do get live output from it. While that's running too, we'll go ahead and take a look at those artifacts that were being produced by these previous jobs here. So we were talking about artifacts are being produced by many of these jobs. In order to view them, you can view them directly in the browser here. So for example, here's where my badging was happening. Here's where my JUnit test was created. You can download them directly from here. You can download the entire archive and you can see them by job. So each job will have a different set of artifacts available to you. In this case, since it was pre-deployment, most of those are going to be just JUnit tests and log files. For the deploy object step, this one is where we're producing our exported objects. So you can see here, it exported all the objects, categorized them for us in something that's already ready to be pushed back to the repository. And you can grab them if you need them, just in a one-off manner. They're downloadable directly from here. But with that, I'm also gonna go ahead and take a look at the root of my repository before I let the phase three finish here. So because that phase one has run and we have badges being published from phase one, you'll see that it automatically updated the repository here with a nice set of badges showing if there's any obvious failures within the environment. We have our rule error count, our rule warning count and test connection failures, transform test failures, and then our analyze rule count. Like I said, we have a ignore file here for validation. We have one file declared in there. So it's not validating all the rules, but this lets you know whether or not you're hiding too many objects from your linting test, which that's something that we see pretty common too. You still want your objects to be linted even if you're not deploying them every single time. But going back over to our pipeline here, we'll see that our pipeline's completed successfully. And we'll take a look at the full view here. And you'll see that there's already a different number of tests here. So like I said, this is kind of like a copy of phase one. We have our test connection, our post deploy test connection here. We can see that nine passed before, nine passed after. So no obvious errors there. Same for our test transforms here. It's basically, like I said, a way for you to sanity check if it was your deployment that caused the issue or if it was always that way. Now for our collect evidence step, right? This is where we're getting those screenshots of our IDN environment to show that sources were deployed, roles were deployed, other things like that. You'll see that it spun up a container and then it took a bunch of screenshots for each one of those Selenium tests that I'd written up for it. And then much like the other artifacts within the pipeline, you can view those screenshots directly from the web UI here Now, you can also set up your tools to actually make API calls to your change management and automatically push this up there. But the possibilities are really limitless. And this is why I always say that phase three is an open-ended phase. As you find needs, you'll go through and build out, you know, scripts that meet those needs. So this is really great and all. I know you're thinking, Zach, you know, it's something where I can go out to your repository and, you know, see your pipeline, but I can't actually use this because I don't have a lot of these tools available to me right now. You said you're using a lot of in-house tooling. I'm here to tell you that I also have a pipeline that's using only IDN APIs as well that you can go ahead and try for yourself here today. What we're gonna go ahead and do is we're gonna try this build again, but from scratch. And I'm gonna show you how you can build your Dockerfile as well. So I switched over to my configuration hub run of this pipeline. So an empty GitLab YAML file again. We have a Dockerfile over here that basically is pulling from a location in our repository here. Now this container file, this Dockerfile, looks like this here. So this Dockerfile is really, really simple. I'm basically only starting from a Python slim image here. I'm loading in some dependencies. Now it looks like that there's a lot of dependencies on here. It doesn't have to be this complex. The only reason why there's so many dependencies is because Selenium generally requires a full Chrome web browser in order for it to run. But you really only need a couple of dependencies for identity now. It's going to be the request library if you're trying to build your tools in Python. Any badge if you wanna have badging available to you. JUnit XML if you wanna create JUnit XMLs that can then be displayed within the environment. And then of course, the Selenium Python module if you'd like to go ahead and build out a Selenium UI tester here. So we use the Dockerfile to go ahead and create our base service container that's going to be used by the pipeline. Now for those Python scripts that are actually running these different tests, we have, for example, our backups. Instead of using our object exporter that we built in-house, we can use the configuration hub backup endpoint to go ahead and basically build a backup that's based upon your day month timestamp, as well as giving it a name of pipeline backups. That way you know where it came from. And like I said, this is literally using just the request library. The rest of these are out of box libraries for Python. So nothing really fancy there. Same thing for the deploy. What we're doing here is we're leveraging that requests module again, as well as a couple other file management libraries just to go ahead and make sure that we're able to read all the files that exist within your repository. But again, we're just making a lot of API calls. Same thing for our export here. So export, we're using the export endpoint. And this is gonna just basically give us all of those JSON files locally. So that way we can actually access them from our source control platform. Backup is gonna only make the backup in configuration hub, but this right here is gonna give us the actual solid artifacts. So now to go ahead and build this pipeline here, and this pipeline will be available on our repository after the presentation. So you can play with it yourself. This pipeline is gonna look pretty similar to our original pipeline. We're still gonna go through and define all the stages that we had before. So pre-deploy, deploy, post-deploy. We're gonna have, instead of a single line call, I have to extrapolate the actual path to the pipeline scripts here. But besides that, there's not really anything different here. We're still only needing to do one line of script for it. And we're still exporting the same artifacts during each one of these jobs here. And then instead of using our partner environment, we're using our ambassador environment here. So I'm using a different environment, but since I declared CICD variables for both of them, I shouldn't have to make any changes to my Python scripts themselves. And then something that you'll notice as well too is that with that Dockerfile that I had declared, I didn't actually include any of those Python scripts within the Dockerfile. And the reason why is that I want you guys to know that you can totally have all of your tools that you're trying to build out for a CICD pipeline located in the same repository as your IDN project. So in this case, they're being stored within pipeline scripts. And so whenever it's cloned down to that container, you're just basically calling it from the cloned repository. And this can actually make your pipeline a little bit faster because you're not having to include those in your final build image. But we'll just go ahead and leave it like this for right now and go ahead and kick off our deployment here. So I've saved the file. We'll push that up. And then same as before, it's gonna detect the changes on our source control platform and kick off a new pipeline build for that branch. So you'll see over here, this is running. I have a couple less tools and that's just because a couple of our tools are using a little bit more advanced internal tooling. And I wanna make sure that you guys can use this day one here, but you'll see here as it finishes running through, we can go ahead and kick off our deploy since that finished up testing successfully. And you can see how fast that is too. I mean, like it loads so fast that you have to manually trigger a refresh within the GitLab UI in order for it to actually show the completed status within this kind of overview. And now while this is running here, you'll see that the deployment completed. It's showing an error right now. And the only reason why it's showing an error is because we're using Configuration Hub to actually go through and move between two tenants being our partner tenant and our developer tenant. In this particular environment, we don't have an exact match between the two, but this would be similar to if you actually were set up with an identity now dev in production environment. So that would be how you would move between the two. And then of course, we have our post deployment steps taking place. Still have everything pushing back up. So we'll go ahead and take a look at our dev tenant now. So then our identity now dev tenant, go ahead and log in real quick. And we'll take a look at Configuration Hub to make sure that those changes took place. So come over here, Configuration Hub. And then under here, you'll see pipeline backups that have taken place. And we have one that is taking place for basically every single run that has happened. And it's been categorized by its date timestamp. And then you'll see that it'll create an automated for draft backup as well as you move between the different environments. But if you're familiar with Configuration Hub, this is something that's probably not strange to you. But like I said, this is something where I'm just calling API endpoints. But like I said, this is something where I'm just calling API in. This doesn't necessarily require you to build anything from scratch. You just need to go through and explore the postman collection on your own to find what you're looking for. Now, this is the extent of the pipeline and like I said, this is a very, very expandable process that is based upon what your organization's needs are. As time goes on, you're going to find new things that are pain points for you that you'd like to automate. And the key is to make sure that you're going through and building it as you see fit. I mean, if you have to do something, you know, every single deployment, maybe take the time to figure out, hey, maybe I can write a Python script for this. And then it's as simple as just importing it into your repository along with your project and then calling it from your service container. So our base value that we've provided here with this pipeline. So if you're wondering, you know, how do I get the okay to implement this here at my organization? We are already pretty stretched in our velocities. We don't really have very much manpower to actually go through and build this out. Well, you've already seen that it can prevent errors from reaching production environments by using pre-deployment testing. Since you can do all the testing from within the container itself, you don't have to worry about messing up with somebody else's code, whether that be in production whenever it's actually going live or even in dev whenever somebody is building with the exact same configuration files, whenever you have multiple developers touching the same thing. You have accelerated build and deployment processes. So now, you know, you don't actually have to go to your IDN tenant and actually kick off that migration from one tenant to another. You can do it directly from the IdentityNow environment whenever or from within the source control platform. It's as simple as just clicking a play button. You can automate those QA tasks and streamline those operations. So instead of having to have a dedicated resource clicking through that IdentityNow environment, you can go through and have it done in an automated fashion. And a lot of times, you know, we spend a lot of time having to go through and close down the change management tickets that we have open for those production releases. Well, the pipeline can do that for you. If you call the API endpoint, similar to what you're doing with IdentityNow, you can accomplish the same task and not have to spend extra time navigating through your web browser here. And then finally, we're centralizing our change control and deployment records for easy auditing. So you know exactly when something is going out, who made the changes to that file, because with source control, you can see the contributor to a particular file and its file history throughout time. You finally have the access to that just all directly from your source control platform. So one other thing I wanted to show you real quick, too, was the ability to do exports with IdentityNow's event triggers. So this is something that is really, really unique. And what's really great about IdentityNow being a SaaS application, you have these kind of event triggers that allow you to call back to the CICD pipeline and basically do your Git management for you without actually having to know how to use Git, if that makes sense. So basically, whenever a change happens to a source, what we're going to see here is that we'll kick off a pipeline that then calls that export job. And then we'll make it to where you can actually push it directly back into the repository for you. So basically, IdentityNow is managing its own project at this point. You're just making changes within the UI. So we'll go on over to our admin section here, go underneath event triggers, and you'll see underneath our subscriptions, we have one defined for updating the objects in the Git. And this happens whenever the source is updated. So I'm going to go ahead and kick this off, and we'll go back over to the repository here. So this is that extra step that was hidden up here at the very top. So whenever it listens for an API call to its pipeline endpoint, that has the export trigger set to it, then it will kick off just particularly that export job there. So we'll go ahead and take a look at our pipeline here and back at our root folder. You'll see that it kicked off a two-stage process here showing a trigger token. This was a export operation using Configuration Hub, and you can see all of those objects were updated here. So that way, if somebody's only doing changes in the UI, you're capturing them both in your source control platform. So you're kind of doing both. You're doing an export before you do a deployment from your source control, and you're doing an export whenever you do changes within the UI. So they're always in sync with one another. Just a really cool feature and a unique thing that I found with Identity now, and there's a lot of other things that I haven't found yet that you might be able to find. But there's one last little thing that I wanted to show you here today. One other bonus feature that comes with service containers is that you can expand the functionality beyond the pipeline. So like I said before, in our very last stages of our build-out for this service container, we started including a text user interface. So that way, developers could run these tools in an ad hoc manner, in a one-off manner. This was really great, and it acted as an executable, but we found an even better way to make all of these tools usable, and it was through Visual Studio Code's new dev containers feature. So basically, what this allows you to do is to actually take your project folder in Visual Studio Code and reopen it inside of a container image. And in this case, it'll be our service container image. And that allows you to do all of your development from inside of there and be able to call the embedded tools from your local IDE. So to show you what that looks like here, we'll go ahead and go back over to our demo IDN project here. Okay. And then underneath here, I'm going to switch back over to my main branch. You'll see that there was a Docker file defined right here that was reaching out to our service container image URL here, and it's running an entrypoint.sh script whenever it spins up. Well, Visual Studio Code knows to look for this, and as such, it will actually create a dynamic dev container folder that then takes this container and then puts your project folder inside there, like how I'd said. And it also allows you to embed different plugins that you would like to have or extensions available to your IDE once it's actually opened up this dev container. So I'm a huge fan of Yannick's Visual Studio Code extension here, as well as Anchin's JSON Visual Studio Code extension as well. But you'll see, I don't have that actually installed in my environment at all. What we'll go ahead and do is we will open this project up inside of a dev container. So a little button right here, it says reopening container. It'll read from that Docker file, start up a container on your local workstation, and then you can access and run all of your development tools and tests in here. So whenever I go ahead and I spin this up here, I can actually kick off the Tui application and run every single one of my tools directly from a nice little user interface. Or if I wanted to call those Python scripts directly, you can do that fine. Like I said, this is like a little OS bubble. So you have a full OS workspace that's clean, that's shareable between your developers that you can then do development from. And this is the thing, you can embed different secrets in here so that way you're not having to share secrets over email. You can share how everybody's development environment should look. So if you wanted to include, like I said, everybody should have the identity now extension with the tenants already pre-configured in. As you can see here, I didn't even have to set anything up. I went from not having the extension at all to having the extension in my environment with my tenants already set and connected up to their respective environments. So if you had a new developer onboarding, it's literally a two-minute setup time and they can get going. And this really brings us back to a really awesome feature of service containers. One of the things that we've had to do as time goes on, and something that I touched on at the very start, is not everybody wants to have a dedicated IaaS build server to run this from. We've started doing creations of pipelines that utilize kind of an edge computing model using ambient computing resources. So developer workstations, those little boxes that live underneath your desk, they use as a test environment. Using those to run these service containers as well too, and this gives you that high availability because developers are located geographically usually pretty far away from one another. And by having the pipeline runner pool consist of your developer workstations, you can have high availability with your pipeline. So really having this kind of developer container paradigm really opens our eyes to a lot of the great resources that you have available to you, even if you don't have a dedicated, like I said, build server. But there's a lot of things that are still coming out. Service containers were a new term as of, I would say, last year. They talked about it during DockerCon, and people are finding new tools and new tricks that they can build into these service containers. And really, it just takes a little bit of curiosity and a little bit of an annoyance from a constant pain point to explore and find these new things. We'd really like to see what you guys have to develop, and if you have any questions about what you've seen here today, please feel free to reach out to me directly. These scripts, again, will be located on our repository if you'd like to try it yourself. I'd also say I can't show the Ansible build process that I talked about at the very beginning, but our colleague, Jeff, will be talking about it during his later panel here today about how to spin up VAs using Ansible. And this is a playbook that we've run within some of these service containers here too. But like I said, possibilities are really endless with this, and we'd really love to see what you guys come up with on your own. Again, my name is Zach Adams. Thank you guys so much for attending this panel here today.
