Learn Infrastructure as Code Concepts

0:00[AUDIO LOGO] Hi, guys. My name is Trevor Sullivan, and welcome back to another CBT Nugget skill. In this skill, we are going to be introducing the concept of infrastructure as code. Before we get too far ahead and start talking about the specific tenets of infrastructure as code, I wanted to take a few steps backwards in time and discuss some of the challenges or pain points that we used to experience in the IT world before infrastructure as code tooling became mainstream.

0:43So for starters, let's say that we've got as a software developer here. Typically, as a software developer, you're going to have a variety of objectives, which ultimately ends with your application that you're building being deployed to some kind of server. So typically, the process that you're going to have is going to look something like this, where you deploy a virtual machine, you maybe install some software packages like runtimes that are required for your application, like maybe a Java runtime or a .NET runtime, a Python runtime, something like that, whatever language that your code is being built in.

1:21Next, you might have to copy some configuration files. Maybe you've got a special configuration file that you've got for a dev environment versus a production environment. Maybe you want to run some containers, maybe you've containerize your application. You might need to restart some services as well after you have deployed your application. Maybe you need to restart your database server, maybe you need to restart some other application that's running some background jobs. And then you also want to run some health monitors, right? So you've got metrics agents, you've got logging agents, and you need to make sure that all those agents are up and running and healthy to ensure that it is properly monitoring your application that you're actually building.

2:02So there's a bunch of different tasks that you have here. And in a traditional environment where you have to provision hardware and take care of all that, it's going to look something like this. So you're going to start off by ordering a physical server. So you're going to go to maybe or dell.com or hp.com or whatever provider it is that you're using to purchase physical hardware. You're going to purchase that physical server, and then you're going to have to install it into a rack. So you'll need to, of course, have a rack that you will have to physically install servers into and networking equipment.

2:36And then once you've got it physically installed into that rack, you're going to need to run a power and networking to that server so that you can remotely log into it and configure the operating system, install your applications, use VNC or remote desktop protocol or SSH or whatever remote protocol it is that you're using to access that server and make sure that it can power up and have network connectivity. Next, your servers are typically going to have what's known as a remote access controller. So Dell servers and HP servers and Cisco servers, they all have these remote access controllers, which is basically a piece of hardware that allows you to remotely access that server in case the operating system is not properly booting up for whatever reason.

3:22In case something happens to the operating system, maybe during an update process, where the operating system gets corrupted, the remote access controller will ensure that you have the ability to remotely access that hardware even in case of an operating system failure. And then once you've got your remote access controller configured, the next thing you'll want to do is to install some kind of operating system. So if you're a Windows shop, then you're probably going to install Windows server. If you're using Linux servers, you might use a Linux distribution like Ubuntu Linux or Red Hat Linux or SUSE Enterprise Linux or something like that.

3:58But you're going to get your operating system installed onto your physical server that you've installed into the rack. Once you've got that physical operating system installed onto the server, then you can install a hypervisor, and you can start to create virtual machines on top of that hypervisor. And then once you've got that virtual machine provisioned, then you can actually come back over here, to your core objectives here, and then you can install those software packages that are dependencies, you can copy your configuration files, run your containers, install other logging and metrics agents and things like that.

4:34But as you can see, the process, the traditional process, I should say, of provisioning physical infrastructure is pretty involved. There's a lot of different manual steps to making that happen. And that's where the cloud came into play. So there's lots of different cloud providers out there that provide virtual infrastructure on demand so that you don't have to worry about all of these different aspects of the physical provisioning process. They take care of all that for you so that you can focus on only the end of it, which is to deploy the virtual machine, get your dependencies in installed, and then ultimately, run your application.

5:15So in a cloud provider world, we have the ability to log into our web browser and basically provision Cloud Infrastructure by using a web console rather than having to physically provision all of our servers. There's lots of different cloud providers out there such as DigitalOcean and Linode and Vultr and Amazon Web Services, Microsoft Azure, Google Cloud. Those are just some of the larger names in the industry, but there's also lots of smaller cloud providers out there as well.

5:47Once you sign up for an account with one of those cloud providers, you can typically just open up your web browser, log in to your account for that cloud provider, and then you can start to create virtual machines. Now, that's just the kind of infrastructure side of things. A lot of these cloud providers have actually moved to more of a platform as a service model, where it's somewhere in the middle of providing serverless functions and infrastructure where in the middle, you have the ability to do things like run containerized applications without actually having to deploy any infrastructure servers.

6:23But typically, this is just a really straightforward process where you can manually log in and create virtual machine infrastructure, and then you're good to go. But that's still not ideal because we still are performing a lot of manual steps here. So instead of just logging into the web console, we can actually plug into the APIs that are provided by these cloud vendors. We can write automation scripts using a variety of different languages. You could use PowerShell, you could use Python, you could use a bash script if you really wanted to with some kernel commands perhaps to call into different APIs endpoints.

6:58And then you can deploy virtual machines. Once you've automated that process, it gives you the ability to scale. So if you need to deploy more than one virtual machine with the same configuration, then you can start to automate that process and just increase the number of servers that you're deploying, maybe change some configuration options like give them different names or choose different software packages that you need to install on each of those. But you can automate that process just using some simple scripting. But now, introduce some additional developers into play. So now, instead of just having you, we've got a team of software developers.

7:33Think of like a two pizza box team, where maybe you've got seven or eight people that you could feed with two pizzas. That's what Amazon typically uses as their kind of model for internal software development, is having seven or eight people teams that are building some specific tool or project. But in this case, we've got a few other devs here like Sally, Joe, and Jane in addition to yourself on your development team. Now, with these additional developers, we have some additional pain points that we need to be aware of. If we have a cloud account perhaps with, let's say Amazon Web Services or maybe Microsoft Azure, we've got multiple developers that are going to be logging in to our web console for that cloud provider.

8:14And each of those developers is going to have a different perspective of what needs to change inside of that account. And so they're going to go into that account, into the web console, and they're going to start making tweaks and changes. And they're going to log in to different virtual machines, they're going to install software packages, maybe remove some software packages, apply some updates to software packages. And very, very quickly within a matter of hours or days, you're going to start to see drift in your infrastructure, where you're going to have inconsistencies in that infrastructure because maybe Joe decides to go update virtual machine number one, but he forgets to update virtual machine number two because he's not doing anything with that virtual machine.

8:54And so he just doesn't think to go and update all of the virtual machines that are inside of that cloud account. Now, once again, you can use automation tools to help improve some of that, but we still don't have visibility kind of centralized across the entire development team here, across all four of our developers to understand what's going on inside of that environment. And that's where infrastructure as code really comes into play. So let's introduce the tenets of infrastructure as code. And these are just a few-- this isn't necessarily a comprehensive list, but these are a few tenets that I came up with.

9:28And so in order to solve for some of these challenges that we've introduced, we want to make sure that our environment is consistent, we want to make sure that every time we run some automation tool, that we're getting a consistent output. We want to make sure that it's repeatable, so we want to make sure that we can take our automation tasks and repeat it across multiple cloud accounts or across multiple different cloud vendors. We need to make sure that our environment is auditable, and that kind ties into being version controlled down here as well, where we can actually see the changes that are happening over a period of time on a timeline.

10:02And we also want to make sure that it's collaborative. So as we have multiple developers that are accessing a single environment, we need to make sure that those developers can collaborate on that environment. We also need to make sure that it's automated, so we need to basically have a schedule where we can set things up to automatically roll out changes to our infrastructure. And then we also need it to be scalable, right? So our manual processes, whether we're talking about physical infrastructure that we're deploying or even if we're using a cloud vendor, if we don't have automation in place, then we can't scale our infrastructure provisioning.

10:38So now, let's talk about these tenets in a little bit more depth, and we'll do that in the upcoming videos. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] Hey, guys, and welcome back. One of the concepts or tenets that we introduced with infrastructure as code in the last video was the notion of consistency across infrastructure provisioning. Now, the pain point here is that once you've got a team of developers here, each of those developers can make different changes to infrastructure at different times.

0:35So one developer might initially provision a physical server with a particular IP address on it's network interface, and another developer might come along and be troubleshooting some kind of network issue, and they might decide to change the IP address of that network interface to something different. That kind of inconsistency is going to lead to intra team problems because each of the team members is going out and manually making changes to the infrastructure, and they're not necessarily communicating what those changes are, and they're not necessarily able to inventory exactly what those changes are either.

1:14So over time, as manual changes are being made to infrastructure resources by different developers on your team, that's going to lead to a kind of just mess of infrastructure configuration, a lot of inconsistency, and that's just going to lead to communication issues and development delays and all sorts of time spent troubleshooting and debugging code when it could be simplified a lot more if things were more consistent and more visible.

1:45Now, in order to gain consistency of infrastructure provisioning, one of the things that we can do is to store our infrastructure configurations inside of a version controlled repository. Now, there's lots of different version controlling tools out there. Some traditional ones are things like SVN, for example, or subversion. But over the years, more recent decentralized version controlling tools have come out such as Git or Mercurial are a couple of decentralized version control tools that are very similar to each other.

2:19But most of the world has standardized on Git for whatever reason. I'm not exactly sure what has kind of led to that. But the existence of services out there like GitHub have really made Git a much more mainstream protocol for version control. So by storing our infrastructure configurations inside of a shared Git repository here, we can gain consistency from our entire team because all the different team members on our team are storing the version controlled changes to our infrastructure configurations inside of a Git repository.

2:57And there's a lot of different tools that we'll talk about later on, that allow us to store these different infrastructure resources inside of a Git repository. But for the time being, let's just kind of think of these things in an abstract mechanism here. So basically we've got a few different files that we are going to store inside of our Git repository here, and these files are going to kind of map to a particular cloud provider. So we're not going to be talking about physical infrastructure here, we're going to be talking more about using a cloud-based model here, where we sign up for a cloud account with, let's say maybe DigitalOcean or Linode or Amazon Web Services, and then we basically create these configuration files that allow us to provision and configure different types of cloud resources.

3:46Typically at the base layer of your Cloud Infrastructure, you're going to have a virtual network. And the network is just going to provide that software defined cloud networking layer that you can connect different cloud resources to such as virtual machines. So you might define a virtual network inside of an infrastructure code file, and then that way, everybody knows, everybody who has access to this Git repository is going to know exactly what the configuration of that virtual network looks like.

4:19In addition, if anybody wants to make changes to the configuration of that virtual network, instead of going out to the cloud provider and manually making that change leading to inconsistency and a lack of communication about what that change was, everybody's going to basically agree that they're going to make changes to that virtual network configuration inside of this code file, inside of this shared Git repository. And that way, everybody has visibility into those changes that are being made. For example, at a virtual network layer, maybe somebody wants to change the CIDR block that's being used for the virtual network or maybe they want to create additional subnets.

5:00Subnet that CIDR block into smaller blocks of IP addresses across different cloud regions or maybe they want to change something about a firewall invigoration, maybe they want to allow a port or block a port. And those kind of firewall configurations can also be expressed as code inside of these configuration files and then stored inside of a Git repository. Once you've got that virtual network layer defined, the next thing you'll probably want to do is to provision some servers or just some virtual machines, basically.

5:33So maybe you've got a database server, and maybe you've got an application server. Of course, this could be scaled up as well. But maybe in our database server configuration here, we define something like a virtual machine size. So maybe our database server needs more compute capacity than our application server because it's doing database heavy tasks like queries, and it needs high disk resources, it needs high CPU resources, as well as high memory resources. So maybe we choose a virtual machine that's got eight CPUs and 128 gigabytes of memory and some really high performance storage for the database server.

6:13On the other hand, maybe on our application server here, it's kind of a lightweight web server that's just sending some queries off to the database and returning some data back to the end user. So maybe we could get away with a four CPU machine with 32 gigabytes of memory. And maybe it doesn't really need as much disk access, though we could reduce the disk to a lower performance tier that costs less, and we can declare all of that configuration right here inside of these configuration files for our virtual machines that are stored inside of this shared Git repository.

6:45And so that way, our entire team of developers right up here, is going to have the consistency of knowing that they can always go to this Git repository right here and any of the configuration files that declare infrastructure resources like virtual networks and firewall rules and virtual machine configurations is all going to be defined inside of separate files within this Git repository. By having that confidence, that this is our single source of truth inside this Git repository, our team of developers knows that the consistency between this Git repository and the actual cloud account that you've signed up for are going to be enforced so that we know that if we make a change to this Git repository here, that change will ultimately be reflected inside of our cloud provider right here.

7:36So that's the idea of consistency, is that using a version control tool like Git is going to help us ensure that that's going to be our single source of truth, and therefore, we're going to have that enforced level of consistency between our Git repository configuration and whatever cloud providers we're using. I hope this has been informative for you and I'd like to thank you for viewing.

0:00[AUDIO LOGO] Hi, guys, and welcome back. In the last video, we discussed the tenet of consistency right here for infrastructure as code. And we also discussed how using a Git repository or really any kind of version control system to store our infrastructure configurations can help us achieve consistency and visibility across all of the team members that are contributing changes to our infrastructure configs.

0:37In fact, it even helps us to communicate outside of our core team so that if anybody else needs to at least have kind of read-only access to know what our infrastructure configuration looks like, maybe they need to an IP address of a database server, for example, or maybe they need to an IP address of an application server so that they can register that name in DNS on a separate team, then they can have that visibility into a Git repository with read-only access. But something else that we need to ensure that we have as part of infrastructure as code is the ability to repeat processes and ensure that not only do we have consistency, but we need to make sure that those processes are easily repeatable across different environments.

1:22So imagine that your dev team here has chosen to use a particular cloud provider, maybe you've chosen to use DigitalOcean. But then as a backup, maybe you want to have a secondary disaster recovery site using a different cloud provider. So you've got multiple accounts, where you've got maybe a couple of accounts over at Linode, maybe you've got a couple of accounts over a DigitalOcean, maybe you've got accounts over at Amazon Web Services as well. And you need to ensure that your automated processes are repeatable regardless of which account or which cloud provider you are provisioning into.

2:00In order to ensure that we have that level of repeatability, having our code, our infrastructure as code stored inside of a Git repository also helps with that. So let's take a look at a couple of accounts that we have down here. For example, maybe we have a dev test account that we have with the Linode cloud provider, whereas we have a production account that we have with the DigitalOcean cloud provider. Well, if we have a template for a virtual network resource that we want to provision into our dev test account, we might want that virtual network to have a different set of parameters than the production account has.

2:42For example, maybe we want to give our virtual network a name like dev01, whereas the name of our production virtual network is going to be prod01. Or maybe you call it prodwest or prodeast based on cloud regions. Or maybe you call it prod-finance or prod-hr if you want to name things based on the department that the resource belongs to. So you've got a lot of different choices in terms of what your naming convention is.

3:12But the idea here is that we want to have different names for different resources depending on whether it's a dev test account, a production account, or who the resource belongs to, who's responsible for managing that particular resource, and other types of inputs like that. Additionally, maybe another parameter that we have for our virtual network configuration is that for dev test accounts, we want to have a CIDR block of 10.0.0.0/16. Whereas for production accounts, maybe we have a totally different CIDR block of 10.5.0.0/16.

3:48Well, by having our infrastructure declared as code, we can actually put in input parameters into these templates, and we're ensuring that not only do we have consistency across provisioning, but we also have that repeatability where we can take those templates, we can pipe in different input parameters like the name of a virtual network resource or the CIDR block that we want to declare for a virtual network resource, and then we can basically pipe those input parameters into the exact same template and, boom, we've got the repeatability across our dev test accounts as well as our production accounts and any additional accounts that we want to create.

4:31So most templating tools out there that allow us to provision infrastructure as code will allow us to provide input parameters to those templates and then reference those input parameters somewhere inside of our templates, such as the resource name, the CIDR block that we want to use for virtual networks. Or in the case of database servers or application servers, we can choose different virtual machine sizes. We can also pipe in things like user data for cloud initialization scripts so that we can automatically configure the servers and install certain software packages and apply configuration files to those servers.

5:09And we can have different configurations for different accounts that we have across our cloud providers. So again, consistency is very important. And we have that by using Git here. But also having that level of repeatability, where we can take a single template for a resource and then repeat that across multiple accounts here is another important tenet of infrastructure as code. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[MUSIC PLAYING] Hi, guys, and welcome back. In the last couple of videos, we've looked at infrastructure as code tenets of consistency as well as repeatability. And we've discussed how using a Git repository as our single source of truth helps to enable consistency and repeatability with parameterized templates.

0:32Now, another important tenet of infrastructure as code is having auditability. Now in a traditional environment where you don't have your infrastructure being defined as code files and basically your entire development team here is just going out and manually logging into servers, making changes to those servers, or logging into cloud accounts using their web browser and making changes to those cloud accounts manually. We don't have the ability to go back and see what our infrastructure looked like maybe five days ago or five months ago or five years ago.

1:09But we have the ability to audit our infrastructure when we declare our infrastructure as code files inside of a version controlled repository here. Because every single time that one of our dev team members here needs to make a change to our infrastructure, all they need to do is go out to this version controlled repository, find the file that they want to make a change to, make the change to that file, and then perform what's known as a "commit," which is basically just committing those changes to the repository.

1:45And it's creating a new version. It's incrementing the version of that repository overall. And it's incrementing the version of the entire infrastructure configuration. Now, granted not every resource is necessarily going to change in every "commit," maybe we just want to make a change to our virtual network and maybe change our dev test account to have our virtual network instead of being named dev01, we could name it dev-test-hr instead. So that would be just a change that we make to the virtual network resource.

2:18But we haven't made any changes to other resources like our database server or our application server. But over time, we're going to be making these micro changes to different resources in our infrastructure configuration. We might be adding new resources. Maybe we add a second app server, or maybe we make a change to our database server config. Or maybe we actually delete resources. Maybe we say, eh, you know what? Maybe we actually don't need to have that application server. So maybe we provision it for a couple of weeks, and then we decide that we don't need it anymore.

2:50So we actually delete that second app server from our infrastructure configuration. And all of those different changes, whether it's adding things, changing things, or removing things, all of those are going to be versions of our infrastructure. And it's important for our security team over here. Maybe we've got our core dev team up here that's got Sally, Joe, Jane, and you as the members. But then maybe we've got a separate security team here that needs to be able to inspect our live production infrastructure.

3:20But they also need the ability to go back in time and actually look at what our infrastructure configuration looked like maybe a couple of months ago, maybe six months ago, maybe a year ago. And so the security team needs to be able to have that level of audit access to our infrastructure so that they can see what our actual live infrastructure looks like. Like, what does it look like right now inside of our cloud accounts? But then they can also go back to our Git repository. They can go through that timeline, that history of all the changes that have been made over time by different team members on our core dev team right up here.

3:59And then that gives them the information to see who made changes, when exactly was that change made, and what exactly did the change consist of? Did maybe Sally here make a change to the virtual network resource on June 1? And then maybe Jane made a change to the database server configuration on September 5. These types of changes that are being made to our infrastructure over time can be audited by an external team by simply giving them read access to our Git repository that contains our infrastructure as code configuration files.

4:38And then they can go back, figure out what information they need from that Git repository, and then figure out kind of the path of what happened in history, and then formulate response to some kind of security incident if that were to occur. Now, having the ability to go back in history, inspect your infrastructure at any point in history, as well as being able to inspect the live configuration of what it looks like right at this moment, is going to be really important for external security teams.

5:10Whether they're internal to your company, or whether it's an external auditing agency that comes in and is consulted, you do some investigative work on your infrastructure and IT environment. It gives them the information that they need in order to do that investigative work on a thorough basis. So having your infrastructure as code stored inside of a version controlled repository is ultimately what's going to enable that ability to audit your infrastructure configuration.

5:40And once again, if you don't use infrastructure as code tools, then this security team here is going to be limited to only being able to snapshot things at a given point in time. So they'll be able to go out to your cloud account, and they'll be able to see what things look like right now, but they won't be able to go back in time and actually see what the infrastructure looked like maybe six months ago or three months ago. And so by making manual changes to your infrastructure without using infrastructure as code tools, you lose all of that visibility, and you ultimately lose a lot of information that could be very useful if a security team is doing investigative work in incident response, or they just want to prove that the team of developers is actually improving over time and making more secure and more intentional changes to their infrastructure.

6:32I hope this has been informative for you. And I'd like to thank you for viewing.

0:00[MUSIC PLAYING] Hi, guys and welcome back. So in the last video, we discussed the element of having auditable infrastructure configurations by having the infrastructure stored as code files inside of a version controlled repository such as Git. Now, another important tenet of the infrastructure as code paradigm shift is the ability to automate changes to your infrastructure.

0:39In the traditional days before infrastructure as code tools were available and before APIs were commonplace amongst different cloud providers as they are today, making changes to infrastructure could be a very manual process. So our dev team members right up here, if they wanted to change something about a physical server's configuration, such as installing some software packages, or maybe making a change to a configuration file, or if they wanted to go out to a cloud account and maybe make a change to one of the virtual machines or virtual networks or firewall rules inside of their cloud account, they would actually have to physically make that change on a manual basis.

1:21They'd have to be in the office from 9:00 to 5:00. And they'd have to log in to their web browser or log in to that virtual machine. They would have to make whatever change it is that they wanted to. And then, they would have to document that they made that change, what time they made that change, and then communicate that, all of that information, back to their team members, so that the entire team had visibility. Now, if any step was forgotten that would lead to inconsistency in the infrastructure as we had previously discussed.

1:53Or at the very least, the other team members may simply not be aware that a particular change was made or when that change was made. So maybe if Joe makes a change right here and he doesn't communicate that to the rest of the team, then maybe Jane gets a call from somebody saying, hey, I'm having problems accessing this application. So I need you to investigate this. And then, Jane goes out and she spends a bunch of time doing some investigative work on why that application isn't working.

2:23Not realizing that Joe had actually made a change that had accidentally caused that application to stop working. So that's why that element of visibility, and consistency, and auditability is just so important, so that everybody knows exactly what the infrastructure looks like, and who's been making changes, and what those changes have been. But another important concept of infrastructure as code is having the ability to automate changes as well. So you may not want to always make changes on demand to your infrastructure.

2:58So even if Joe comes along and makes a change to, let's say, the database server configuration, Joe may not want that change to take effect immediately. You might want that change to actually be batch rolled out along with some other changes within the team. So maybe, Joe makes a change. And maybe, Jane comes along and makes a change to the application server. And maybe, Sally comes along and makes a change to the virtual network configuration. Well, rather than doing all of those changes on an individual basis, we could choose as a team to batch those changes together and roll out all of those changes during a standard rollout cycle.

3:39And typically, those schedules are going to differ from dev test accounts to production accounts. Because dev test accounts can have changes happen to them much more frequently because we don't have the risk of breaking access to a production application. On the other hand, in a production account with production resources like virtual networks, and database servers, and application web front ends, then we want to make sure that we're doing those on a scheduled basis that everybody has kind of visibility into when that's going to happen. And that, they're ready for those changes to happen to the production account.

4:13So that if something of some kind of problem occurs, that the team is able to go back and rectify that situation relatively easily. So we can actually automate things to be rolled out by using an infrastructure as code approach. In the traditional environment, we don't have that ability to do that because we're manually going in and making those changes. Whereas, using infrastructure as code, we have the ability to batch things together and actually roll it out based on a schedule. So for example, in our dev test account here, maybe, we as a team, work together and choose to roll out changes to that dev test account on an hourly basis.

4:52So that we know that every single hour that goes by, we're going to have new changes being rolled out to our dev test accounts. On the other hand, maybe on a production account, we want to roll out much less frequently just to reduce the risk of breaking our production application, that we have real end users accessing. So maybe, as a team, we decide that we are going to open a maintenance window at 2 o'clock in the morning on a daily basis. And that any changes that we are making to our dev test accounts are going to get ultimately rolled out to our production infrastructure at 2:00 AM every day.

5:28By having our infrastructure stored as code files inside of a version controlled repository, we can use automation tools like the standard Unix Cron utility to schedule changes to happen on a periodic basis, using whatever kind of scheduling our team actually comes up with. So we could use something like a Cron schedule to set up an hourly automation task to roll out changes to our dev test account. And we could also use a scheduled task with Cron to roll out infrastructure changes, anything that's stored in these code files right up here to roll out changes to our production environment at 2 o'clock on a daily basis.

6:09So having the ability to automate those tasks so that we don't necessarily have to be awake and actually actively physically making those changes to our infrastructure resources makes things a lot easier, because we don't have to worry about manually making those changes, manually logging into servers, manually logging into multiple servers, even logging into cloud accounts to make changes to virtual networks and firewall rules. Instead, we can just set up an automated schedule for those tasks to occur.

6:40And our infrastructure changes defined in these code files will automatically get rolled out to each of those accounts respectively. So it's up to you as a team to figure out what kind of schedule works best for you across different accounts, across different environments. And you guys can work together to make sure that you have a schedule that works well for the team and is also fully automated, so that you don't have to be manually making those changes. And open up that time, so that you can have meetings, or sleep, or eat dinner, or whatever it is that you need to worry about in daily life.

7:13And just let those automated infrastructure tasks happen in the background. I hope this has been informative for you. And I'd like to thank you for viewing.

0:00[AUDIO LOGO] Hi, guys, and welcome back. In the last several videos, we've discussed some of the tenets of infrastructure as code, and the importance of having consistency, automatability, and having auditability, as well as collaboration in your infrastructure configuration.

0:30Now one of the central tools that we talked about that is going to enable many of those infrastructure as code tenets is the Git version control tool. Now you don't have to use Git if your team decides to use a different version control tool. That is totally fine. You can use Mercurial, which is very similar to Git. It's decentralized version control versus some of the traditional tools that are more centralized and have kind of a server backend to them.

1:01But there are lots of different version control tools out there. And so I would encourage you to do some investigative work, and determine which version control tool is going to work the best for your team. But there's lots of other services out there and tools that you can use to enable infrastructure as code. And, of course, HashiCorp's Terraform is an open source utility that allows you to achieve that. But there's many others that I wanted to talk about as well. So for starters, you'll want to be familiar with Git fundamentals.

1:32And we do have some other training here at CBT Nuggets that covers really basics around Git and how to use Git as a version control tool, whether it's for infrastructure or developing actual application projects as well. So Git is a really great version control tool, and is kind of a de facto standard across the entire world as far as version controlled tooling goes. Now Git by itself works pretty well for doing version control. But when it comes to the collaboration aspect, Git by itself generally is not going to be enough because your team is going to need to have a centralized place to store the Git repository.

2:14And there's a couple of really great services for that. One of those is, of course, known as GitHub. This is arguably the most popular Git hosting service out there that allows you to basically just create Git repositories, store them directly on the GitHub service, and then grant access to each of your different team members to that Git repository, so that everybody can collaborate and have access to commit changes to that Git repository. Another big benefit of using the Git hub service is that not only do you have the ability to store code files here, you also have the ability to create this issue tracker here.

2:55So if you need to file an issue to say I need to fix this bug in my infrastructure configuration, or we need to add this new resource to our infrastructure configuration, or maybe we need to remove a resource, you can track all of your work by using this built-in issue tracker in GitHub. And that allows you to see what work needs to be done. You can assign ownership of specific pieces of work to different users in your team. And you can basically just collaborate and kind of centralize all of your work with this issue tracker.

3:28Also GitHub has the ability to create what are known as pull requests. And so rather than just directly committing changes back to your Git repository here, your team can actually use these pull requests as a workflow mechanism to ensure that any proposed changes to your infrastructure as code files are going to actually be submitted as proposals, rather than being directly committed to the Git repository. And what that enables your team to do is to actually peer review these pull requests before the pull requests are merged back into the code base, so that anybody who wants to comment or propose some additional changes on top of the initial changes that were proposed by one of your team members can be sent through this pull request process.

4:15And that adds to the element of auditability, where different team members just within the same dev team, can actually audit each other's code to make sure that everybody agrees that that's a change that actually does need to be made to the project. Another great thing about using GitHub as a managed Git hosting service is that there is an Actions Service, which is basically an automated pipeline where you can set up things to run on a schedule, as we had previously discussed. Maybe you want to have a separate schedule for your dev test environment and a separate schedule for your production environment right here.

4:50Regardless of what that schedule is, you can set up those automated actions inside of the GitHub Actions Service to automatically roll out changes to your Cloud infrastructure based on a particular schedule that your team agrees to. So having all that functionality built into GitHub is really nice. It also has a project management tool, a wiki for documentation, and things like that. Now there is a competitor to GitHub. So if, for some reason you say, we don't want to use GitHub as a team, there's also another service called GitLab over at GitLab.com.

5:24And this is very similar to GitHub, because it does allow you to store your Git source code. It has built-in issue tracking. It has a built-in CI/CD service. They don't call it the same thing. They don't call it GitHub actions. They call it GitLab CI/CD. But it's essentially the same concept, where you can set up these automated pipelines to roll out changes to your infrastructure on a schedule. Now from a version control tooling perspective, using Git with GitHub or GitLab or something similar to that is going to provide a lot of additional value.

5:57Now when it comes to infrastructure templating tools, of course, HashiCorp's Terraform is kind of a really great tool which is open source that allows you to version control your infrastructure. The great thing about using Terraform to do version control for your infrastructure is that Terraform actually works across multiple cloud vendors. And this is one of the most powerful things about Terraform is that it doesn't care which cloud vendor you're using. You can declare all of your infrastructure resources, regardless of which cloud vendor you select.

6:29So if you decide to use Azure, you can still use Terraform to do templating for your infrastructure. If your team chooses to use Amazon Web Services, or if your entire organization is just standardized on AWS for infrastructure, you can still use Terraform. If you choose to use Google Cloud or other cloud providers out there, you can still continue to use Terraform. So once you learn and understand Terraform, you'll actually be able to use that concept and actually leverage multiple cloud vendors or infrastructure provisioning.

7:01Now lots of cloud vendors will actually provide their own automated tooling to roll out templated infrastructure as well. So for example, Amazon Web Services has a managed service that just is included with the Amazon Web Services account when you sign up called CloudFormation. And CloudFormation is just a templating service that allows you to create a code-based stack of resources. For example, this stack right here, I know that this is a lot of code to read through. But essentially, this is a very minimal template for CloudFormation that allows you to provision a virtual machine, also known as an EC2 instance in AWS parlance, as well as a security group, which basically is just another term for a firewall rule that allows certain network traffic to be allowed inbound to this particular Amazon EC2 instance or virtual machine.

7:54So this is, for example, just enabling SSH access via TCP port 22. And you can see that because this is just a plain text file, this is a template file that we can store inside of a Git repository. We can apply that change to our cloud environment by using the CloudFormation service. And we can achieve that version controlled infrastructure, because we're using this template service. Now one of the limitations of using something like CloudFormation, though, is that it is proprietary to Amazon Web Services.

8:25So any improvements to CloudFormation have to be made by AWS, because it is a managed service. And the same is true for the Microsoft Azure templating service, as well, which is known as Microsoft Azure Resource Manager. And they provide a bunch of prebuilt templates for Azure Resource Manager as well. So you can kind of search through their template library here and find different templates. But once again, Azure Resource Manager, as the name implies, is proprietary to the Microsoft Azure service.

8:55So that's why it's a really good idea to learn more generic tools like Terraform that you can actually use to provision infrastructure across multiple cloud vendors, such as Azure, AWS, Google, Cloud, DigitalOcean. Whatever it is that you want to provision, you can use Terraform to accomplish that. So in future skills in this course, we're actually going to be taking a deeper look at Terraform, and specifically how to use Terraform to provision infrastructure on various cloud vendors. I hope this has been informative for you.

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