4 hours 39 minutes

Video Transcription

Welcome to the lesson 6.3, where we're gonna talk about infrastructure as code.
So in this lesson will praise the benefits of infrastructure code. Take a look at the types of configurations the different types of Parisian software compare them and then also describe a need for ah hardening framework or compliance as a code and also specific. Look at chef inspect for deployment verification.
So if you're not familiar with infrastructure, is a code or I see it's used in conduct conjunction with continuous delivery. And if you really want embrace it, you would do the idea of there being no manual changes in production. So
the I C creates the infra Critz, the infrastructure deploys the application and nobody makes any changes. A production. If you find any issues, you go back and it's changed in the I A. C B and and you have it requires a new deployment.
So the deployment rebuilds everything. Network segmentation, load balancers, instances.
So why would you do this? It
well, first it makes for easier deployments.
You always have. You know the structure is gonna be built and you test that that code as that infrastructure is a code you tested to make sure it works correctly. It doesn't get deployed unless it works.
Improved resilience to disaster. You don't have these changes in production. You have these notes like, Oh, after deploy. You have to do this, that you can always deployed directly from this code,
and it reduces the need for system, administration and production. Again. It's
there's no changes in production if says something doesn't work, it goes into the development pace and has to go through the full pipeline.
And then you can associate infrastructure with version. So the application version and the infrastructure can be easily be tied together and you don't have any drift.
The first word or the idea is as
ID evidence is, which means actions always produce the same result. Eso that it's good for when you deploy in the development pays, uses infrastructure code, you know it's gonna work, so when you go to production, you should use that same exact code. You don't have any drift. You know it's going to work with that because you already tested
the production.
It's also again, if you want to embrace it this way, is immutable dark. The architecture and production can't be changed because you only make the changes in the code
and then it gives you the ability to have production development, have multiple production environment so that you can you will have this drift. They're all the same. You always know what's gonna work.
It assisted delivery for you make it rapid, reliable and do it at scale. Whether you have multiple environments or ah, availability zones, you can always do it in all these places. You know, it's gonna end up the same.
Here's a question for you. Do use infrastructures code in your organization.
If so, is it for operations? If is it for security purposes? How is it? How is it deployed?
If not, what do you see value in it? Or maybe should go ask Maybe that you are using it and you're not. You have not aware of it. And so maybe you might look at a problem that you've had. You have
applications that get deployed into Devon. You test them and then I'll stand. Go to production and you find new errors. And like oh, well, that version is different in this. To win the production,
we have some drift there
and maybe might be interested in using it for compliance to make sure that every time the infrastructures deployed, it's always correct. And in compliance with the whatever standard you need to follow for your organization, even in the operating systems, the applications are they always compliant.
So for software, comparacion, uh, we're just gonna take a look at a couple different products out there. I use this blood from grunt work Daio that that compared some of the available tools out there. So for configuration management, there's quite a few answerable puppet chef salt stack heat You've heard of heard of several of these?
Where if you're looking at provisioning, there's cloud formacion. Terra form
procedural ones are are grouped into, say, chef and, um, a little more suitable for for procedural based.
Whereas if you look in that declarative, that terra form cloud formacion salt stack puppet fit into that category
and there's there's some differences between the tools, like Puppet Chef Salt Stack need master a server with an agent, but they also support an Agent lis mode. So it depending what again, if you what you're using already, you might stick with it, but if you're If you're trying to compare somebody's, you might look at the
the pros and the cons of
having that agent master structure.
Some of the benefits are just looking at the strengths and the weaknesses of each one of these tools and using them together. So if you're doing more the clarity of work
versus actually creating the environment, might might see which one suits you better.
There's also interesting tools out there from inspect io, which is death set card inning framework. So this is that idea I talked about before was compliance as a code. So if you're using, if you're in a credit card industry and you're doing PC I D. S s or if your health care and you doing HIPAA Sox anything like that
you can use thes thes infrastructure are outside that this compliance as a code
to maintain that that compliance and it is actually a missed a CF requirement PW nine for this.
So the hardening framework actually offers quite a few options out there. So if spending what database you're using with this my sequel Post Chris, they have recipes for that. Recipes for the different Web servers, even components down to secure shell. What? How us Sl's configured
in your containers and docker or the orchestration with kubernetes
and even at the operating system level for Lennox windows. So they people have created these recipes over these
that the framework has them and then they have available. So you pick which what you're looking for, and I say I'm using inspect, answerable, whatever it is, and then the recipe is available for you to copy.
So here's an example. Just one quick ones ship for a chef. Inspect is to test on, and infrastructure is a code deployment.
This is if you're familiar with Ruby, you would kind understand the structure. So this is an example of testing to make sure the Ssh Protocol is set to version two.
So this would be a recipe that would look through the configuration file and say,
What's the protocol? Is it set the number two OK, it passes this so this would be just one of the steps, so they obviously be quite a few here, but it's just be all be part of your compliance verification and then the test define whether it failed past skipped, whether it's an unexpected or observe state,
and you can also run these locally so you could war. I'm sorry you could run them as over Ssh! If you're running clinics or win RM. If you're running windows, think are they could be set out with cloud formation Terra form anyway, these if you're running them in the cloud. So there's a lot of options to run this
compliance as a code,
not just the setting up or creating it, but also verifying that once it's in place that it is correct, or maybe a part of your continuous monitoring
in this model. We talked about infrastructures, a code around the idea of having stood bail stability and for the repeatability of your environment. And next will take a look at we're gonna deploy infrastructure of the code in our Jenkins pipeline and use it for deploying are setting up images
and containers and docker and then deploying them and then actually testing environment

Up Next

DevSecOps Fundamentals

DevSecOps certification training helps students learn to incorporate security features in every step of the development process and navigate distinct security challenges in custom software and web applications.

Instructed By

Instructor Profile Image
Philip Kulp