4 hours 39 minutes
Welcome to the lesson 6.4, where we're going to do our Jenkins demo and add infrastructure is a code. This is another exciting module, and I would say that for all these, but I really like these interactive modules or sorry lessons.
So this will demonstrate Jenkins adding the infrastructures code and first explained Docker container deployment. And then within the demonstration, after it's the container is deployed, I'll run that zap security tool on it just toe,
as as part of the verification scan, that what we saw in our development and what we saw in production
is the same. And there's no new vulnerabilities.
So just just idea a doctor running on top of Bundu Lennox again, it doesn't really matter, but the way it's set up, the the Doctor room is I'm gonna create. As I took the default Tomcat image out of the doctor repository,
I have a docker file which does a copy of the war file
from our application we built and it would create our own custom image. So we took the Tomcat, put our war file, and then now we have this image running at that has our application wants get started up.
And so the way Dr Works is now I have this image that's out there. I'm gonna create a container and I, by default none of the ports of visible. So I'm gonna publish it with Port 80 82
affording into the internal 80 80 on the Tomcat within the Tomcat server
so that from the outside we can get this port and map into the running application.
And then I created container from that. And then what to do is run the container and that's we have are running container, our little service.
So here's the usual the Jenkins link.
And if you want to take a look at Docker has an ah explanation in this resource right here just to explain what a container is.
Right. So here are back in Jenkins, we're gonna take a look at the deployment phase. Here is our last phase in our pipeline.
Let me take a look here. Take a look at our pipeline like we normally do. I'm gonna scroll through all the ones we've done before. Fast see a deploying Dev. Last time we did the dynamic analysis that's the That was the last time we looked at. So here we are in a new stage deployment, and I mentioned already
showing you or explain exactly what we're doing. Docker get You don't have to understand completely what? The commands here that aren't kind of showing it, but just showing exactly what it needs to dio. I'm gonna skip this first step because what we're doing is tearing down what we had before, which we haven't actually explained yet.
here it is the were built, the credit, a docker file, as I mentioned. So I'm saying I want Tomcat. Nine is my default, and I'm gonna copy my or file, which we built into the user local web, APS. It's gonna could do that within the container. So when I say docker image build
here is I'm going to again create that
that our new custom image and I'm kind of call it def sec Ops prod, and it's gonna copy. It's gonna take the Tomcat base, copy the war file in there. I just do an ls here just to make sure in the output showing that it's available,
and in here we have the create container so saying, Doctor, I want to contain or create a container. And here, as I mentioned before, he saw mapping port 80 82 to 80 80 within the with running in the Tomcat on the inside.
And then I give it a name. I'm gonna call my container def sec ops Tomcat Container.
And it is based off of this image, def sec ops prod, which I just created in the previous,
command right before that.
And then So now I have a container that's ready. It's not actually running yet, so I say, container, start. And here's the name that I just created Death, psych ops, Tomcat container and again doing ls just to say so I see it running.
So I added a couple extra
steps in here just to verify some ring the curl command against see the local host port 80 82. And in looking for that job, a vulnerable lab, which is what I hope that I just deployed and I'm gonna check it. And we've seen this before. I do a try. Catch. So what I'm doing is let me actually run the curl command, see if it ran. If it didn't, If I can't connect to it
than that APP is not actually running.
And then I do the same loop Sleep five seconds. Curl tried again. I want to make sure the app is actually running before I pretty or going any farther in the step in the stages.
It's on this next stage. I'm just calling it monitor. What I'm gonna run here is the zap tool, which is thes and attack proxy from a loss which we've seen before.
There's actually a plug in force you going to say Start zap and it's very nice. You can just you can give it the home where it is and give us some other settings. I didn't have to give it very many here,
and it'll run this app tool and then you can give it thes thes high level command. Say I want to crawl because I don't want to manually go through it and spider my website. I wanted to crawl itself and then I'm gonna run attack against what? I've just crawled. And the one thing the note here is that
this is a verification scan. So as it's deployed, I want to make sure no new vulnerabilities in the dash tool previously rebrand Iraq. Me, he would obviously one run the same tool again. You don't want to different sets of results.
I just wanted to give an example, showing two different types of tools here. So this is what That's why I'm doing it here.
And then once that run and it completes, we have the same post step that pulls in all these artifacts that we've done from the desk. I've just added another post step here called Archives AP Tool. And then
so it'll take in everything that we have all these results.
Let's go back and take a look. And here's all the the artifacts that that were produced from the stage.
Uh, I think this one takes a little while to run, so I'm gonna is gonna take a look at it here, one that that's already run
and you can see that with these results have are seen before from our are assessed. We have a new one here for with a little lightning bolt from SAP, and it says, build failed due to zap skein, finding too many alerts. Click the Zap tool and we'll take a look at the report.
So the nice thing here is again. We don't have two runs that manually and look at it. We can have all these results pulled directly into our build. So this one that found seven highs, 22 mediums and all these quite a few lows. Another interesting idea here is that you can see it tracks across build.
So this one saw that there was one new high three were fixed on. You have the difference here,
and then you can in the same way as all all of these tools you can go through right hand and read. So it says this one has the high as an external redirect.
Looks like we got a cross site scripting issue here. Remote file inclusion. And some of these are ones we start. If we seen any other tools,
it's the idea here is again. We have this all built into our pipeline, and this one failed because I said it to fail. If I found any vulnerabilities. And then that's what that's what happened here.
They're just jump in, have ah question for you. Can you describe a container if somebody asked you to to describe it? Well, how would you explain it to them. And you can pause a video here and just think about it, uh, for a minute before I explain what it is.
So I figured, actually, I just take it directly from Doctor and explain what a container is there. So they say a container is a standard unit of software.
The application runs quickly reliable reliability for one computing environment to another
dr contains Images is a lightweight, standalone, executed, all package off software that includes everything needed to run the application code, runtime system, tool system, libraries and setting. So
it's like a VM, but it's the minimum version of it, and that's why it can spit up in seconds.
We talked about deploying, are apt to the custom docker container and had a demonstration of that and in the next lesson will take a look at maturing the deployment