Learn Infrastructure as Code Concepts

0:00[AUDIO LOGO]

0:11Hi, guys.

0:12My name is Trevor Sullivan, and welcome back

0:14to another CBT Nugget skill.

0:17In this skill, we are going to be introducing the concept

0:20of infrastructure as code.

0:23Before we get too far ahead and start

0:25talking about the specific tenets of infrastructure

0:27as code, I wanted to take a few steps backwards in time

0:31and discuss some of the challenges or pain points

0:35that we used to experience in the IT world

0:38before infrastructure as code tooling became mainstream.

0:43So for starters, let's say that we've got

0:45as a software developer here.

0:48Typically, as a software developer,

0:50you're going to have a variety of objectives, which ultimately

0:53ends with your application that you're building being deployed

0:57to some kind of server.

0:59So typically, the process that you're going to have is going

1:02to look something like this, where you deploy a virtual

1:04machine, you maybe install some software packages like runtimes

1:09that are required for your application,

1:11like maybe a Java runtime or a .NET runtime, a Python runtime,

1:16something like that, whatever language that your code is

1:19being built in.

1:21Next, you might have to copy some configuration files.

1:24Maybe you've got a special configuration file

1:26that you've got for a dev environment versus a production

1:29environment.

1:30Maybe you want to run some containers,

1:32maybe you've containerize your application.

1:36You might need to restart some services as well after you

1:39have deployed your application.

1:40Maybe you need to restart your database server,

1:42maybe you need to restart some other application that's

1:45running some background jobs.

1:46And then you also want to run some health monitors, right?

1:49So you've got metrics agents, you've got logging agents,

1:52and you need to make sure that all those agents are

1:55up and running and healthy to ensure that it is properly

1:59monitoring your application that you're actually building.

2:02So there's a bunch of different tasks that you have here.

2:05And in a traditional environment where

2:08you have to provision hardware and take care of all that,

2:11it's going to look something like this.

2:13So you're going to start off by ordering a physical server.

2:16So you're going to go to maybe or dell.com

2:18or hp.com or whatever provider it is that you're using

2:22to purchase physical hardware.

2:24You're going to purchase that physical server,

2:27and then you're going to have to install it into a rack.

2:30So you'll need to, of course, have

2:32a rack that you will have to physically install servers

2:34into and networking equipment.

2:36And then once you've got it physically installed

2:38into that rack, you're going to need

2:40to run a power and networking to that server

2:43so that you can remotely log into it

2:45and configure the operating system,

2:48install your applications, use VNC or remote desktop

2:51protocol or SSH or whatever remote protocol it

2:54is that you're using to access that server

2:57and make sure that it can power up

2:59and have network connectivity.

3:01Next, your servers are typically going

3:03to have what's known as a remote access controller.

3:05So Dell servers and HP servers and Cisco servers, they all

3:09have these remote access controllers,

3:11which is basically a piece of hardware that

3:13allows you to remotely access that server in case

3:17the operating system is not properly

3:20booting up for whatever reason.

3:22In case something happens to the operating system,

3:24maybe during an update process, where the operating system gets

3:27corrupted, the remote access controller

3:30will ensure that you have the ability

3:32to remotely access that hardware even in case of an operating

3:36system failure.

3:38And then once you've got your remote access controller

3:40configured, the next thing you'll want to do

3:42is to install some kind of operating system.

3:45So if you're a Windows shop, then you're

3:47probably going to install Windows server.

3:49If you're using Linux servers, you

3:51might use a Linux distribution like Ubuntu Linux or Red Hat

3:55Linux or SUSE Enterprise Linux or something like that.

3:58But you're going to get your operating system installed

4:00onto your physical server that you've installed into the rack.

4:05Once you've got that physical operating system installed

4:08onto the server, then you can install a hypervisor,

4:11and you can start to create virtual machines

4:14on top of that hypervisor.

4:16And then once you've got that virtual machine provisioned,

4:20then you can actually come back over here, to your core

4:23objectives here, and then you can install those software

4:26packages that are dependencies, you

4:28can copy your configuration files, run your containers,

4:31install other logging and metrics agents and things

4:34like that.

4:34But as you can see, the process, the traditional process,

4:37I should say, of provisioning physical infrastructure

4:41is pretty involved.

4:43There's a lot of different manual steps

4:45to making that happen.

4:47And that's where the cloud came into play.

4:50So there's lots of different cloud providers out there

4:52that provide virtual infrastructure on demand

4:56so that you don't have to worry about all

4:58of these different aspects of the physical provisioning

5:01process.

5:02They take care of all that for you

5:04so that you can focus on only the end of it, which

5:07is to deploy the virtual machine,

5:09get your dependencies in installed, and then ultimately,

5:12run your application.

5:15So in a cloud provider world, we have the ability

5:18to log into our web browser and basically provision

5:23Cloud Infrastructure by using a web console

5:26rather than having to physically provision all of our servers.

5:31There's lots of different cloud providers

5:33out there such as DigitalOcean and Linode and Vultr

5:37and Amazon Web Services, Microsoft Azure, Google Cloud.

5:41Those are just some of the larger names in the industry,

5:43but there's also lots of smaller cloud providers out there

5:46as well.

5:47Once you sign up for an account with one of those cloud

5:50providers, you can typically just open up your web browser,

5:53log in to your account for that cloud provider,

5:57and then you can start to create virtual machines.

6:00Now, that's just the kind of infrastructure side of things.

6:03A lot of these cloud providers have actually

6:05moved to more of a platform as a service model, where

6:09it's somewhere in the middle of providing serverless functions

6:12and infrastructure where in the middle,

6:15you have the ability to do things like run containerized

6:18applications without actually having to deploy

6:21any infrastructure servers.

6:23But typically, this is just a really straightforward process

6:26where you can manually log in and create virtual machine

6:29infrastructure, and then you're good to go.

6:31But that's still not ideal because we still are performing

6:35a lot of manual steps here.

6:37So instead of just logging into the web console,

6:40we can actually plug into the APIs that are provided

6:43by these cloud vendors.

6:44We can write automation scripts using a variety

6:47of different languages.

6:49You could use PowerShell, you could use Python,

6:51you could use a bash script if you really

6:53wanted to with some kernel commands

6:55perhaps to call into different APIs endpoints.

6:58And then you can deploy virtual machines.

7:01Once you've automated that process,

7:03it gives you the ability to scale.

7:05So if you need to deploy more than one virtual machine

7:08with the same configuration, then you

7:10can start to automate that process

7:11and just increase the number of servers that you're deploying,

7:14maybe change some configuration options like give them

7:17different names or choose different software

7:19packages that you need to install on each of those.

7:21But you can automate that process just using

7:24some simple scripting.

7:25But now, introduce some additional developers

7:28into play.

7:28So now, instead of just having you,

7:30we've got a team of software developers.

7:33Think of like a two pizza box team, where maybe you've

7:35got seven or eight people that you could feed with two pizzas.

7:40That's what Amazon typically uses

7:41as their kind of model for internal software development,

7:44is having seven or eight people teams that are building

7:47some specific tool or project.

7:50But in this case, we've got a few other devs here

7:52like Sally, Joe, and Jane in addition to yourself

7:55on your development team.

7:57Now, with these additional developers,

7:59we have some additional pain points

8:00that we need to be aware of.

8:02If we have a cloud account perhaps with,

8:05let's say Amazon Web Services or maybe Microsoft Azure,

8:09we've got multiple developers that

8:10are going to be logging in to our web console for that cloud

8:14provider.

8:14And each of those developers is going

8:16to have a different perspective of what needs to change inside

8:20of that account.

8:20And so they're going to go into that account,

8:22into the web console, and they're

8:24going to start making tweaks and changes.

8:26And they're going to log in to different virtual machines,

8:28they're going to install software packages,

8:30maybe remove some software packages,

8:32apply some updates to software packages.

8:34And very, very quickly within a matter of hours or days,

8:38you're going to start to see drift

8:40in your infrastructure, where you're

8:42going to have inconsistencies in that infrastructure

8:45because maybe Joe decides to go update virtual machine number

8:48one, but he forgets to update virtual machine

8:50number two because he's not doing anything

8:52with that virtual machine.

8:54And so he just doesn't think to go and update

8:56all of the virtual machines that are inside

8:58of that cloud account.

9:00Now, once again, you can use automation tools

9:02to help improve some of that, but we still

9:05don't have visibility kind of centralized across

9:08the entire development team here, across all four

9:11of our developers to understand what's going

9:14on inside of that environment.

9:16And that's where infrastructure as code really comes into play.

9:19So let's introduce the tenets of infrastructure as code.

9:23And these are just a few--

9:24this isn't necessarily a comprehensive list,

9:26but these are a few tenets that I came up with.

9:28And so in order to solve for some of these challenges

9:31that we've introduced, we want to make sure

9:33that our environment is consistent,

9:36we want to make sure that every time we run some automation

9:38tool, that we're getting a consistent output.

9:40We want to make sure that it's repeatable,

9:42so we want to make sure that we can take our automation tasks

9:45and repeat it across multiple cloud accounts

9:48or across multiple different cloud vendors.

9:50We need to make sure that our environment is auditable,

9:54and that kind ties into being version

9:56controlled down here as well, where we can actually

9:58see the changes that are happening over a period of time

10:01on a timeline.

10:02And we also want to make sure that it's collaborative.

10:05So as we have multiple developers that

10:07are accessing a single environment,

10:09we need to make sure that those developers can collaborate

10:12on that environment.

10:13We also need to make sure that it's automated,

10:15so we need to basically have a schedule where

10:18we can set things up to automatically roll out

10:21changes to our infrastructure.

10:22And then we also need it to be scalable, right?

10:25So our manual processes, whether we're

10:27talking about physical infrastructure

10:29that we're deploying or even if we're using a cloud vendor,

10:32if we don't have automation in place,

10:34then we can't scale our infrastructure provisioning.

10:38So now, let's talk about these tenets in a little bit

10:41more depth, and we'll do that in the upcoming videos.

10:44I hope this has been informative for you,

10:46and I'd like to thank you for viewing.

0:00[AUDIO LOGO]

0:11Hey, guys, and welcome back.

0:12One of the concepts or tenets that we introduced

0:15with infrastructure as code in the last video

0:18was the notion of consistency across infrastructure

0:23provisioning.

0:24Now, the pain point here is that once you've

0:26got a team of developers here, each of those developers

0:30can make different changes to infrastructure

0:33at different times.

0:35So one developer might initially provision a physical server

0:39with a particular IP address on it's network interface,

0:42and another developer might come along and be troubleshooting

0:45some kind of network issue, and they

0:47might decide to change the IP address of that network

0:51interface to something different.

0:54That kind of inconsistency is going

0:56to lead to intra team problems because each of the team

1:00members is going out and manually making changes

1:03to the infrastructure, and they're not necessarily

1:06communicating what those changes are,

1:08and they're not necessarily able to inventory exactly

1:12what those changes are either.

1:14So over time, as manual changes are

1:17being made to infrastructure resources

1:20by different developers on your team,

1:23that's going to lead to a kind of just mess of infrastructure

1:27configuration, a lot of inconsistency,

1:30and that's just going to lead to communication issues

1:33and development delays and all sorts of time

1:36spent troubleshooting and debugging code

1:39when it could be simplified a lot more if things were more

1:43consistent and more visible.

1:45Now, in order to gain consistency of infrastructure

1:49provisioning, one of the things that we can do

1:51is to store our infrastructure configurations inside

1:55of a version controlled repository.

1:57Now, there's lots of different version controlling tools

2:00out there.

2:01Some traditional ones are things like SVN, for example,

2:04or subversion.

2:05But over the years, more recent decentralized version

2:09controlling tools have come out such as Git or Mercurial

2:14are a couple of decentralized version control tools

2:17that are very similar to each other.

2:19But most of the world has standardized

2:21on Git for whatever reason.

2:23I'm not exactly sure what has kind of led to that.

2:26But the existence of services out there like GitHub

2:29have really made Git a much more mainstream protocol

2:33for version control.

2:35So by storing our infrastructure configurations inside

2:39of a shared Git repository here, we

2:42can gain consistency from our entire team

2:45because all the different team members on our team

2:49are storing the version controlled changes

2:53to our infrastructure configurations inside of a Git

2:56repository.

2:57And there's a lot of different tools

2:58that we'll talk about later on, that

3:00allow us to store these different infrastructure

3:03resources inside of a Git repository.

3:06But for the time being, let's just

3:07kind of think of these things in an abstract mechanism here.

3:13So basically we've got a few different files

3:15that we are going to store inside of our Git repository

3:18here, and these files are going to kind of map

3:21to a particular cloud provider.

3:24So we're not going to be talking about physical infrastructure

3:26here, we're going to be talking more

3:28about using a cloud-based model here,

3:30where we sign up for a cloud account with,

3:33let's say maybe DigitalOcean or Linode or Amazon Web Services,

3:37and then we basically create these configuration files

3:41that allow us to provision and configure different types

3:44of cloud resources.

3:46Typically at the base layer of your Cloud Infrastructure,

3:51you're going to have a virtual network.

3:53And the network is just going to provide that software defined

3:56cloud networking layer that you can connect different cloud

4:00resources to such as virtual machines.

4:03So you might define a virtual network

4:06inside of an infrastructure code file, and then that way,

4:09everybody knows, everybody who has access to this Git

4:13repository is going to know exactly

4:15what the configuration of that virtual network looks like.

4:19In addition, if anybody wants to make changes

4:22to the configuration of that virtual network,

4:25instead of going out to the cloud provider

4:27and manually making that change leading to inconsistency

4:31and a lack of communication about what that change was,

4:34everybody's going to basically agree

4:36that they're going to make changes to that virtual network

4:39configuration inside of this code file,

4:42inside of this shared Git repository.

4:44And that way, everybody has visibility into those changes

4:47that are being made.

4:49For example, at a virtual network layer,

4:51maybe somebody wants to change the CIDR block that's

4:54being used for the virtual network

4:56or maybe they want to create additional subnets.

5:00Subnet that CIDR block into smaller blocks of IP

5:04addresses across different cloud regions

5:07or maybe they want to change something about a firewall

5:10invigoration, maybe they want to allow a port or block a port.

5:14And those kind of firewall configurations

5:16can also be expressed as code inside of these configuration

5:21files and then stored inside of a Git repository.

5:24Once you've got that virtual network layer defined,

5:27the next thing you'll probably want to do

5:28is to provision some servers or just some virtual machines,

5:32basically.

5:33So maybe you've got a database server,

5:35and maybe you've got an application server.

5:37Of course, this could be scaled up as well.

5:40But maybe in our database server configuration

5:43here, we define something like a virtual machine size.

5:47So maybe our database server needs more compute capacity

5:50than our application server because it's

5:52doing database heavy tasks like queries,

5:55and it needs high disk resources,

5:58it needs high CPU resources, as well as high memory resources.

6:02So maybe we choose a virtual machine

6:03that's got eight CPUs and 128 gigabytes of memory

6:08and some really high performance storage for the database

6:12server.

6:13On the other hand, maybe on our application server here,

6:16it's kind of a lightweight web server that's

6:17just sending some queries off to the database

6:19and returning some data back to the end user.

6:22So maybe we could get away with a four CPU machine

6:25with 32 gigabytes of memory.

6:27And maybe it doesn't really need as much disk access,

6:30though we could reduce the disk to a lower performance

6:33tier that costs less, and we can declare

6:37all of that configuration right here inside

6:39of these configuration files for our virtual machines

6:42that are stored inside of this shared Git repository.

6:45And so that way, our entire team of developers right up here,

6:49is going to have the consistency of knowing that they can always

6:52go to this Git repository right here

6:54and any of the configuration files

6:57that declare infrastructure resources like virtual networks

7:00and firewall rules and virtual machine configurations

7:04is all going to be defined inside of separate files

7:07within this Git repository.

7:09By having that confidence, that this

7:11is our single source of truth inside this Git repository,

7:15our team of developers knows that the consistency

7:20between this Git repository and the actual cloud

7:23account that you've signed up for are going to be enforced so

7:27that we know that if we make a change to this Git repository

7:30here, that change will ultimately be reflected inside

7:34of our cloud provider right here.

7:36So that's the idea of consistency,

7:39is that using a version control tool like Git

7:43is going to help us ensure that that's

7:46going to be our single source of truth,

7:47and therefore, we're going to have

7:49that enforced level of consistency between our Git

7:53repository configuration and whatever

7:55cloud providers we're using.

7:57I hope this has been informative for you

7:59and I'd like to thank you for viewing.

0:00[AUDIO LOGO]

0:11Hi, guys, and welcome back.

0:13In the last video, we discussed the tenet of consistency right

0:16here for infrastructure as code.

0:19And we also discussed how using a Git repository or really

0:23any kind of version control system

0:25to store our infrastructure configurations

0:27can help us achieve consistency and visibility across all

0:32of the team members that are contributing changes

0:34to our infrastructure configs.

0:37In fact, it even helps us to communicate outside of our core

0:40team so that if anybody else needs to at least have

0:43kind of read-only access to know what our infrastructure

0:46configuration looks like, maybe they

0:48need to an IP address of a database server, for example,

0:52or maybe they need to an IP address of an application

0:55server so that they can register that name in DNS

0:58on a separate team, then they can

1:00have that visibility into a Git repository

1:03with read-only access.

1:06But something else that we need to ensure

1:07that we have as part of infrastructure as code

1:10is the ability to repeat processes and ensure

1:14that not only do we have consistency,

1:16but we need to make sure that those processes are easily

1:19repeatable across different environments.

1:22So imagine that your dev team here

1:24has chosen to use a particular cloud provider,

1:28maybe you've chosen to use DigitalOcean.

1:30But then as a backup, maybe you want

1:32to have a secondary disaster recovery site using

1:36a different cloud provider.

1:39So you've got multiple accounts, where

1:40you've got maybe a couple of accounts over at Linode,

1:43maybe you've got a couple of accounts over a DigitalOcean,

1:46maybe you've got accounts over at Amazon Web Services as well.

1:49And you need to ensure that your automated processes are

1:53repeatable regardless of which account

1:56or which cloud provider you are provisioning into.

2:00In order to ensure that we have that level of repeatability,

2:04having our code, our infrastructure as code

2:07stored inside of a Git repository

2:09also helps with that.

2:11So let's take a look at a couple of accounts

2:14that we have down here.

2:15For example, maybe we have a dev test account

2:18that we have with the Linode cloud provider,

2:21whereas we have a production account

2:23that we have with the DigitalOcean cloud provider.

2:26Well, if we have a template for a virtual network resource

2:31that we want to provision into our dev test account,

2:34we might want that virtual network

2:36to have a different set of parameters

2:39than the production account has.

2:42For example, maybe we want to give our virtual network

2:44a name like dev01, whereas the name of our production

2:49virtual network is going to be prod01.

2:52Or maybe you call it prodwest or prodeast

2:55based on cloud regions.

2:57Or maybe you call it prod-finance or prod-hr

3:02if you want to name things based on the department

3:06that the resource belongs to.

3:08So you've got a lot of different choices

3:10in terms of what your naming convention is.

3:12But the idea here is that we want

3:14to have different names for different resources depending

3:17on whether it's a dev test account, a production

3:20account, or who the resource belongs to,

3:22who's responsible for managing that particular resource,

3:25and other types of inputs like that.

3:28Additionally, maybe another parameter that we have

3:30for our virtual network configuration is that for dev

3:34test accounts, we want to have a CIDR block of 10.0.0.0/16.

3:39Whereas for production accounts, maybe we have a totally

3:42different CIDR block of 10.5.0.0/16.

3:48Well, by having our infrastructure declared

3:51as code, we can actually put in input parameters

3:54into these templates, and we're ensuring

3:58that not only do we have consistency

4:00across provisioning, but we also have that repeatability where

4:04we can take those templates, we can pipe in different input

4:07parameters like the name of a virtual network

4:10resource or the CIDR block that we want to declare

4:13for a virtual network resource, and then we can basically

4:17pipe those input parameters into the exact same template

4:20and, boom, we've got the repeatability across our dev

4:24test accounts as well as our production

4:27accounts and any additional accounts

4:29that we want to create.

4:31So most templating tools out there

4:33that allow us to provision infrastructure as code

4:36will allow us to provide input parameters to those templates

4:41and then reference those input parameters somewhere inside

4:44of our templates, such as the resource

4:46name, the CIDR block that we want

4:47to use for virtual networks.

4:49Or in the case of database servers or application servers,

4:53we can choose different virtual machine sizes.

4:55We can also pipe in things like user data for cloud

4:59initialization scripts so that we can automatically

5:02configure the servers and install certain software

5:05packages and apply configuration files to those servers.

5:09And we can have different configurations

5:11for different accounts that we have

5:14across our cloud providers.

5:16So again, consistency is very important.

5:19And we have that by using Git here.

5:21But also having that level of repeatability,

5:23where we can take a single template for a resource

5:26and then repeat that across multiple accounts

5:29here is another important tenet of infrastructure as code.

5:33I hope this has been informative for you,

5:34and I'd like to thank you for viewing.

0:00[MUSIC PLAYING]

0:11Hi, guys, and welcome back.

0:12In the last couple of videos, we've

0:14looked at infrastructure as code tenets of consistency

0:18as well as repeatability.

0:20And we've discussed how using a Git repository

0:24as our single source of truth helps

0:26to enable consistency and repeatability

0:30with parameterized templates.

0:32Now, another important tenet of infrastructure as code

0:35is having auditability.

0:37Now in a traditional environment where

0:40you don't have your infrastructure

0:42being defined as code files and basically

0:46your entire development team here is just going out

0:49and manually logging into servers,

0:51making changes to those servers, or logging into cloud accounts

0:55using their web browser and making changes to those cloud

0:57accounts manually.

0:59We don't have the ability to go back and see

1:02what our infrastructure looked like maybe five days ago

1:06or five months ago or five years ago.

1:09But we have the ability to audit our infrastructure when

1:14we declare our infrastructure as code files

1:17inside of a version controlled repository here.

1:21Because every single time that one of our dev team members

1:24here needs to make a change to our infrastructure,

1:27all they need to do is go out to this version controlled

1:31repository, find the file that they want to make a change to,

1:35make the change to that file, and then perform

1:38what's known as a "commit," which is basically

1:41just committing those changes to the repository.

1:45And it's creating a new version.

1:47It's incrementing the version of that repository overall.

1:51And it's incrementing the version

1:52of the entire infrastructure configuration.

1:55Now, granted not every resource is necessarily

1:58going to change in every "commit," maybe

2:00we just want to make a change to our virtual network

2:02and maybe change our dev test account to have

2:06our virtual network instead of being named dev01,

2:09we could name it dev-test-hr instead.

2:15So that would be just a change that we

2:16make to the virtual network resource.

2:18But we haven't made any changes to other resources

2:21like our database server or our application server.

2:24But over time, we're going to be making these micro changes

2:28to different resources in our infrastructure configuration.

2:31We might be adding new resources.

2:33Maybe we add a second app server,

2:36or maybe we make a change to our database server config.

2:40Or maybe we actually delete resources.

2:42Maybe we say, eh, you know what?

2:43Maybe we actually don't need to have that application server.

2:46So maybe we provision it for a couple of weeks,

2:48and then we decide that we don't need it anymore.

2:50So we actually delete that second app server

2:52from our infrastructure configuration.

2:55And all of those different changes,

2:56whether it's adding things, changing things, or removing

3:00things, all of those are going to be

3:02versions of our infrastructure.

3:04And it's important for our security team over here.

3:08Maybe we've got our core dev team

3:10up here that's got Sally, Joe, Jane, and you as the members.

3:13But then maybe we've got a separate security team here

3:16that needs to be able to inspect our live production

3:20infrastructure.

3:20But they also need the ability to go back in time

3:24and actually look at what our infrastructure configuration

3:27looked like maybe a couple of months ago,

3:30maybe six months ago, maybe a year ago.

3:32And so the security team needs to be

3:34able to have that level of audit access to our infrastructure

3:38so that they can see what our actual live infrastructure

3:41looks like.

3:42Like, what does it look like right now inside

3:45of our cloud accounts?

3:46But then they can also go back to our Git repository.

3:50They can go through that timeline, that history of all

3:53the changes that have been made over time by different team

3:56members on our core dev team right up here.

3:59And then that gives them the information

4:01to see who made changes, when exactly was that change made,

4:07and what exactly did the change consist of?

4:09Did maybe Sally here make a change

4:12to the virtual network resource on June 1?

4:15And then maybe Jane made a change to the database server

4:20configuration on September 5.

4:23These types of changes that are being

4:25made to our infrastructure over time

4:27can be audited by an external team

4:31by simply giving them read access to our Git repository

4:34that contains our infrastructure as code configuration files.

4:38And then they can go back, figure out

4:40what information they need from that Git repository,

4:44and then figure out kind of the path of what

4:47happened in history, and then formulate response

4:50to some kind of security incident if that were to occur.

4:54Now, having the ability to go back in history,

4:57inspect your infrastructure at any point in history,

5:00as well as being able to inspect the live configuration of what

5:04it looks like right at this moment,

5:07is going to be really important for external security teams.

5:10Whether they're internal to your company,

5:12or whether it's an external auditing agency that

5:15comes in and is consulted, you do some investigative work

5:19on your infrastructure and IT environment.

5:22It gives them the information that they

5:23need in order to do that investigative work

5:26on a thorough basis.

5:28So having your infrastructure as code stored inside

5:32of a version controlled repository

5:34is ultimately what's going to enable that ability

5:37to audit your infrastructure configuration.

5:40And once again, if you don't use infrastructure as code tools,

5:44then this security team here is going

5:46to be limited to only being able to snapshot things

5:50at a given point in time.

5:51So they'll be able to go out to your cloud account,

5:53and they'll be able to see what things look like right now,

5:56but they won't be able to go back in time

5:57and actually see what the infrastructure looked

6:00like maybe six months ago or three months ago.

6:04And so by making manual changes to your infrastructure

6:07without using infrastructure as code tools,

6:10you lose all of that visibility, and you ultimately

6:13lose a lot of information that could

6:15be very useful if a security team is doing

6:18investigative work in incident response,

6:21or they just want to prove that the team of developers

6:25is actually improving over time and making

6:28more secure and more intentional changes

6:30to their infrastructure.

6:32I hope this has been informative for you.

6:34And I'd like to thank you for viewing.

0:00[MUSIC PLAYING]

0:11Hi, guys and welcome back.

0:13So in the last video, we discussed the element

0:15of having auditable infrastructure configurations

0:19by having the infrastructure stored as code files

0:23inside of a version controlled repository such as Git.

0:28Now, another important tenet of the infrastructure

0:32as code paradigm shift is the ability

0:35to automate changes to your infrastructure.

0:39In the traditional days before infrastructure as code tools

0:43were available and before APIs were

0:46commonplace amongst different cloud providers

0:48as they are today, making changes to infrastructure

0:52could be a very manual process.

0:54So our dev team members right up here,

0:56if they wanted to change something

0:58about a physical server's configuration,

1:01such as installing some software packages,

1:04or maybe making a change to a configuration file,

1:07or if they wanted to go out to a cloud account

1:10and maybe make a change to one of the virtual machines

1:13or virtual networks or firewall rules

1:15inside of their cloud account, they

1:17would actually have to physically make

1:19that change on a manual basis.

1:21They'd have to be in the office from 9:00 to 5:00.

1:25And they'd have to log in to their web browser

1:27or log in to that virtual machine.

1:29They would have to make whatever change

1:31it is that they wanted to.

1:33And then, they would have to document

1:35that they made that change, what time they made that change,

1:38and then communicate that, all of that information,

1:41back to their team members, so that the entire team had

1:45visibility.

1:45Now, if any step was forgotten that

1:48would lead to inconsistency in the infrastructure

1:51as we had previously discussed.

1:53Or at the very least, the other team members

1:56may simply not be aware that a particular change was made

2:00or when that change was made.

2:02So maybe if Joe makes a change right here

2:05and he doesn't communicate that to the rest of the team,

2:08then maybe Jane gets a call from somebody saying,

2:11hey, I'm having problems accessing this application.

2:14So I need you to investigate this.

2:17And then, Jane goes out and she spends

2:18a bunch of time doing some investigative work on why

2:22that application isn't working.

2:23Not realizing that Joe had actually

2:26made a change that had accidentally

2:29caused that application to stop working.

2:31So that's why that element of visibility,

2:34and consistency, and auditability is just

2:37so important, so that everybody knows

2:39exactly what the infrastructure looks like,

2:42and who's been making changes, and what

2:44those changes have been.

2:45But another important concept of infrastructure as code

2:49is having the ability to automate changes as well.

2:52So you may not want to always make changes on demand

2:56to your infrastructure.

2:58So even if Joe comes along and makes a change to,

3:01let's say, the database server configuration,

3:04Joe may not want that change to take effect immediately.

3:08You might want that change to actually

3:10be batch rolled out along with some other changes

3:13within the team.

3:15So maybe, Joe makes a change.

3:17And maybe, Jane comes along and makes a change

3:20to the application server.

3:22And maybe, Sally comes along and makes a change

3:24to the virtual network configuration.

3:26Well, rather than doing all of those changes

3:29on an individual basis, we could choose as a team

3:32to batch those changes together and roll out

3:35all of those changes during a standard rollout cycle.

3:39And typically, those schedules are

3:41going to differ from dev test accounts

3:43to production accounts.

3:45Because dev test accounts can have changes

3:48happen to them much more frequently

3:50because we don't have the risk of breaking access

3:53to a production application.

3:54On the other hand, in a production account

3:57with production resources like virtual networks, and database

4:00servers, and application web front ends, then

4:02we want to make sure that we're doing those

4:04on a scheduled basis that everybody

4:06has kind of visibility into when that's going to happen.

4:09And that, they're ready for those changes

4:11to happen to the production account.

4:13So that if something of some kind of problem occurs,

4:16that the team is able to go back and rectify that situation

4:20relatively easily.

4:21So we can actually automate things

4:24to be rolled out by using an infrastructure as code

4:27approach.

4:28In the traditional environment, we

4:29don't have that ability to do that because we're manually

4:32going in and making those changes.

4:34Whereas, using infrastructure as code,

4:36we have the ability to batch things together and actually

4:39roll it out based on a schedule.

4:41So for example, in our dev test account

4:43here, maybe, we as a team, work together

4:46and choose to roll out changes to that dev test

4:49account on an hourly basis.

4:52So that we know that every single hour that goes by,

4:54we're going to have new changes being rolled out

4:57to our dev test accounts.

4:59On the other hand, maybe on a production account,

5:01we want to roll out much less frequently just

5:04to reduce the risk of breaking our production application,

5:08that we have real end users accessing.

5:10So maybe, as a team, we decide that we

5:13are going to open a maintenance window at 2 o'clock

5:15in the morning on a daily basis.

5:18And that any changes that we are making to our dev test accounts

5:22are going to get ultimately rolled out

5:24to our production infrastructure at 2:00 AM every day.

5:28By having our infrastructure stored as code files

5:32inside of a version controlled repository,

5:35we can use automation tools like the standard Unix Cron utility

5:40to schedule changes to happen on a periodic basis,

5:44using whatever kind of scheduling

5:46our team actually comes up with.

5:48So we could use something like a Cron schedule

5:50to set up an hourly automation task to roll out changes

5:54to our dev test account.

5:56And we could also use a scheduled task with Cron

5:59to roll out infrastructure changes,

6:01anything that's stored in these code

6:02files right up here to roll out changes

6:04to our production environment at 2 o'clock on a daily basis.

6:09So having the ability to automate those tasks so that we

6:12don't necessarily have to be awake and actually

6:14actively physically making those changes to our infrastructure

6:18resources makes things a lot easier,

6:21because we don't have to worry about manually making

6:25those changes, manually logging into servers,

6:27manually logging into multiple servers,

6:29even logging into cloud accounts to make changes

6:32to virtual networks and firewall rules.

6:34Instead, we can just set up an automated schedule

6:38for those tasks to occur.

6:40And our infrastructure changes defined in these code files

6:43will automatically get rolled out to each of those accounts

6:47respectively.

6:48So it's up to you as a team to figure out

6:50what kind of schedule works best for you

6:52across different accounts, across different environments.

6:55And you guys can work together to make sure

6:58that you have a schedule that works well for the team

7:00and is also fully automated, so that you don't have to be

7:03manually making those changes.

7:05And open up that time, so that you

7:06can have meetings, or sleep, or eat dinner,

7:09or whatever it is that you need to worry about in daily life.

7:13And just let those automated infrastructure tasks

7:15happen in the background.

7:17I hope this has been informative for you.

7:19And I'd like to thank you for viewing.

0:00[AUDIO LOGO]

0:11Hi, guys, and welcome back.

0:13In the last several videos, we've

0:14discussed some of the tenets of infrastructure

0:17as code, and the importance of having consistency,

0:21automatability, and having auditability,

0:25as well as collaboration in your infrastructure configuration.

0:30Now one of the central tools that we

0:32talked about that is going to enable many

0:36of those infrastructure as code tenets

0:38is the Git version control tool.

0:41Now you don't have to use Git if your team decides

0:43to use a different version control tool.

0:46That is totally fine.

0:47You can use Mercurial, which is very similar to Git.

0:52It's decentralized version control

0:54versus some of the traditional tools that are more centralized

0:58and have kind of a server backend to them.

1:01But there are lots of different version control tools

1:03out there.

1:04And so I would encourage you to do some investigative work,

1:06and determine which version control tool is going

1:10to work the best for your team.

1:12But there's lots of other services out there

1:15and tools that you can use to enable infrastructure as code.

1:19And, of course, HashiCorp's Terraform

1:21is an open source utility that allows you to achieve that.

1:25But there's many others that I wanted to talk about as well.

1:28So for starters, you'll want to be

1:30familiar with Git fundamentals.

1:32And we do have some other training here

1:34at CBT Nuggets that covers really basics around Git

1:38and how to use Git as a version control tool,

1:42whether it's for infrastructure or developing

1:44actual application projects as well.

1:47So Git is a really great version control tool,

1:50and is kind of a de facto standard

1:52across the entire world as far as version

1:55controlled tooling goes.

1:57Now Git by itself works pretty well for doing version control.

2:01But when it comes to the collaboration aspect,

2:04Git by itself generally is not going

2:07to be enough because your team is

2:09going to need to have a centralized place

2:12to store the Git repository.

2:14And there's a couple of really great services for that.

2:17One of those is, of course, known as GitHub.

2:20This is arguably the most popular Git hosting service out

2:24there that allows you to basically just create

2:27Git repositories, store them directly on the GitHub service,

2:31and then grant access to each of your different team members

2:34to that Git repository, so that everybody

2:37can collaborate and have access to commit changes

2:41to that Git repository.

2:43Another big benefit of using the Git hub service

2:48is that not only do you have the ability

2:50to store code files here, you also

2:52have the ability to create this issue tracker here.

2:55So if you need to file an issue to say

2:59I need to fix this bug in my infrastructure configuration,

3:02or we need to add this new resource to our infrastructure

3:05configuration, or maybe we need to remove a resource,

3:08you can track all of your work by using this built-in issue

3:11tracker in GitHub.

3:13And that allows you to see what work needs to be done.

3:17You can assign ownership of specific pieces of work

3:20to different users in your team.

3:23And you can basically just collaborate and kind of

3:25centralize all of your work with this issue tracker.

3:28Also GitHub has the ability to create what

3:31are known as pull requests.

3:32And so rather than just directly committing changes

3:35back to your Git repository here,

3:38your team can actually use these pull requests

3:41as a workflow mechanism to ensure

3:43that any proposed changes to your infrastructure as code

3:47files are going to actually be submitted as proposals,

3:51rather than being directly committed

3:53to the Git repository.

3:54And what that enables your team to do

3:56is to actually peer review these pull requests before the pull

4:00requests are merged back into the code base,

4:03so that anybody who wants to comment or propose

4:07some additional changes on top of the initial changes that

4:10were proposed by one of your team members

4:12can be sent through this pull request process.

4:15And that adds to the element of auditability,

4:18where different team members just within the same dev team,

4:21can actually audit each other's code

4:23to make sure that everybody agrees that that's

4:25a change that actually does need to be made to the project.

4:29Another great thing about using GitHub as a managed Git hosting

4:33service is that there is an Actions Service, which

4:36is basically an automated pipeline where you can set up

4:39things to run on a schedule, as we had previously discussed.

4:43Maybe you want to have a separate schedule for your dev

4:46test environment and a separate schedule for your production

4:49environment right here.

4:50Regardless of what that schedule is,

4:52you can set up those automated actions inside of the GitHub

4:55Actions Service to automatically roll out changes

4:59to your Cloud infrastructure based on a particular schedule

5:03that your team agrees to.

5:05So having all that functionality built into GitHub

5:08is really nice.

5:08It also has a project management tool, a wiki for documentation,

5:12and things like that.

5:14Now there is a competitor to GitHub.

5:15So if, for some reason you say, we

5:17don't want to use GitHub as a team,

5:19there's also another service called GitLab over

5:22at GitLab.com.

5:24And this is very similar to GitHub,

5:26because it does allow you to store your Git source code.

5:30It has built-in issue tracking.

5:32It has a built-in CI/CD service.

5:34They don't call it the same thing.

5:35They don't call it GitHub actions.

5:36They call it GitLab CI/CD.

5:38But it's essentially the same concept,

5:40where you can set up these automated pipelines

5:42to roll out changes to your infrastructure on a schedule.

5:46Now from a version control tooling perspective,

5:49using Git with GitHub or GitLab or something similar to that

5:54is going to provide a lot of additional value.

5:57Now when it comes to infrastructure templating

5:59tools, of course, HashiCorp's Terraform

6:01is kind of a really great tool which

6:04is open source that allows you to version

6:07control your infrastructure.

6:08The great thing about using Terraform to do version control

6:12for your infrastructure is that Terraform actually works

6:15across multiple cloud vendors.

6:18And this is one of the most powerful things about Terraform

6:20is that it doesn't care which cloud vendor you're using.

6:23You can declare all of your infrastructure resources,

6:26regardless of which cloud vendor you select.

6:29So if you decide to use Azure, you

6:31can still use Terraform to do templating

6:33for your infrastructure.

6:35If your team chooses to use Amazon Web Services,

6:37or if your entire organization is

6:39just standardized on AWS for infrastructure,

6:42you can still use Terraform.

6:44If you choose to use Google Cloud or other cloud

6:46providers out there, you can still

6:48continue to use Terraform.

6:50So once you learn and understand Terraform,

6:53you'll actually be able to use that concept

6:55and actually leverage multiple cloud vendors or infrastructure

7:00provisioning.

7:01Now lots of cloud vendors will actually

7:03provide their own automated tooling

7:05to roll out templated infrastructure as well.

7:09So for example, Amazon Web Services

7:10has a managed service that just is included with the Amazon Web

7:15Services account when you sign up called CloudFormation.

7:18And CloudFormation is just a templating service

7:20that allows you to create a code-based stack of resources.

7:25For example, this stack right here,

7:28I know that this is a lot of code to read through.

7:30But essentially, this is a very minimal template

7:33for CloudFormation that allows you

7:35to provision a virtual machine, also known

7:38as an EC2 instance in AWS parlance,

7:41as well as a security group, which basically is just

7:44another term for a firewall rule that allows certain network

7:48traffic to be allowed inbound to this particular Amazon EC2

7:53instance or virtual machine.

7:54So this is, for example, just enabling

7:56SSH access via TCP port 22.

8:00And you can see that because this is just a plain text file,

8:03this is a template file that we can store inside

8:06of a Git repository.

8:07We can apply that change to our cloud environment

8:11by using the CloudFormation service.

8:13And we can achieve that version controlled infrastructure,

8:15because we're using this template service.

8:17Now one of the limitations of using something

8:20like CloudFormation, though, is that it

8:22is proprietary to Amazon Web Services.

8:25So any improvements to CloudFormation

8:27have to be made by AWS, because it is a managed service.

8:31And the same is true for the Microsoft Azure

8:35templating service, as well, which

8:37is known as Microsoft Azure Resource Manager.

8:40And they provide a bunch of prebuilt templates for Azure

8:43Resource Manager as well.

8:44So you can kind of search through their template library

8:47here and find different templates.

8:48But once again, Azure Resource Manager, as the name implies,

8:52is proprietary to the Microsoft Azure service.

8:55So that's why it's a really good idea

8:57to learn more generic tools like Terraform that you can actually

9:01use to provision infrastructure across multiple cloud vendors,

9:06such as Azure, AWS, Google, Cloud, DigitalOcean.

9:09Whatever it is that you want to provision,

9:11you can use Terraform to accomplish that.

9:14So in future skills in this course,

9:16we're actually going to be taking a deeper

9:17look at Terraform, and specifically

9:19how to use Terraform to provision infrastructure

9:22on various cloud vendors.

9:24I hope this has been informative for you.

9:26And I'd like to thank you for viewing.