Describing a network design as code can provide flexibility for design and deployment of cloud-based infrastructures. In this video, you’ll learn about playbooks, automation use cases, and source code control.
Infrastructure as Code, or IaC, is a concept where we can take a piece of networking technology and describe it in terms that are best described as code. This means that we could build a configuration file that could accurately describe everything in our infrastructure. Every server, all of the network devices, firewalls, switches, routers, and all of our applications can be configured as this code.
This means instead of manually building, installing, and then configuring all of these devices, we can do all of that work inside of this code and then simply tell the cloud to build out all of these systems to our specification. We can even use this to create versions of this infrastructure. So we can build out infrastructure as code configurations, deploy that configuration, and then make minor changes and redeploy the configuration. And all of those changes will take effect.
This also means that if we need to build another exact duplicate of this configuration in a separate data center, we simply take our code. We move it to the other data center. And we apply that infrastructure as code to build out a completely new application instance that is identical to the original. This is obviously one of the most powerful features of cloud-based technologies. And it allows us to have flexibility in where and how we deploy these systems.
This is a very simplified version of an infrastructure as code configuration file. You can see all of the definitions are in here to create a host that’s called mail.example.com. This infrastructure as code also includes children devices, such as web servers and database servers. And you can see the host names are included in there as well.
Inside of this same configuration file, we might want to include other details, such as the type of CPU, how much network configurations, IP addressing, the applications that need to be installed, and everything else we need to get these systems up and running. If we can automate the process of building out a series of devices, then we can also automate the process of responding to issues. This is done through a process known as a playbook. A playbook is a series of steps you would follow in order to be able to resolve or address a particular issue.
For example, if you needed to investigate a data breach, you could create a playbook that would step through that process. Or if you needed to recover from ransomware, there may be a set of very well-defined steps. And those steps would be contained within a playbook. This is obviously things that we do manually when we’re addressing issues one by one. But putting it into a playbook allows us to automate this process.
Perhaps you have a system that identifies the malware. It then references the playbook to know to remove that device from the network, delete everything on the storage drive, reimage the system, and then redeploy that system into your infrastructure. This can obviously be reused over and over again. So any time you run into that particular issue, you simply apply the appropriate playbook.
Playbooks are commonly implemented into SOAR platforms. That’s S-O-A-R. That stands for Security, Orchestration, Automation, and Response. This is a management console that allows you to centralize the operations of everything you’re doing with security in your environment. And if you want to implement playbooks, this would be a perfect console for a centralized deployment and monitoring of those playbooks.
This automation with playbooks and with infrastructure as code become very handy when you run into particular situations. For example, you may want to avoid instances of configuration drift, where there are minor changes to configurations between different application instances. Or perhaps you want to be sure that all of your systems remain in compliance with a set of standards. We can do that using infrastructure as code. We can make sure that every single one of those systems is created using the same infrastructure as code definitions. And therefore you would have identical systems wherever you deploy them.
Or perhaps you’re configuring a testing environment, and you want to be sure that that testing environment is identical when you deploy it into production. Infrastructure as code would be a perfect choice to be able to completely document what you have in the test environment and deploy that identically into your production environment. And if you want to be able to duplicate this same configuration across all of your data centers, wherever they might be in the world, you would obviously use infrastructure as code.
This would also be valuable if you needed to make a configuration change or an upgrade to an existing piece of software or system you may have already deployed. You simply make that definition change within your infrastructure as code definition file. And then you deploy that to those systems. It will note the difference and make those changes that you need to be able to upgrade those systems.
We can also use infrastructure as code to be able to document the configuration that’s been made to an existing system. So we may want to scan through a system that we would like to duplicate, have all of those configurations implemented within an infrastructure as code definition file. And then we’ll not only have documentation of that system. But we’ll be able to duplicate that system at will.
As you can imagine, in large environments, these definition files become extremely important. And you want to be sure that you’re running the latest version of that configuration file when you deploy these systems. To be able to ensure that level of control of the configurations, you need source control. This allows you to manage any type of change you may want to implement into those definition files. And then you’ll be able to test those configurations and then ultimately deploy those into a production state.
This prevents many different people from making their own minor changes to a configuration file. And instead you have one central repository where all of these changes are kept. And if somebody wants to make a change, they would need to make that change into your source control system. Sometimes we refer to this as a version control system for that very reason. A very popular type of a version control system is Git. We use that often on the internet to be able to maintain these source codes across multiple users wherever they might be in the world.
So you might have this central repository of a production system. You might want to make some changes. And those changes would be tracked and merged together into the final version. There could be many people making their own changes and merging all of those changes into the final config. This means that we can have many people working on these infrastructure as code definition files. They could be making changes to the area that’s specific to their part of the build. And then we can merge all of those changes together into one centralized configuration.
There might be occasions where one person makes a change to a line within the code, and another person makes a different change to the same line within the code. If you try to merge all of those together, there will obviously be a conflict. So your version control software not only needs to recognize these conflicts but also give you a way to manage what change you would really like to make into the final code.
This might be something that the version control software can do automatically. Or it may require manual intervention by one administrator who can decide which configuration is really the best one. This change control software also allows us to create branches of different types of code. So we can create a version of an infrastructure as code definition file.
We can branch that code off to do our own testing with, make some changes, and then later, we can merge that into the original code to create a new version. This allows us to have a production definition and then take that and configure it in a testing environment for upgrades, changes, and optimization. And then once we’ve tested that, we can then merge it back into the production environment.