Robin discusses configuration management (CM) and why it has replaced manual scripting in most environments to enforce a desired state ensuring fast, reliable changes to infrastructure.
- [Instructor] Before we talk about Chef, it's important to understand where it fits in the overall context of configuration management. Configuration management, or CM, refers to the process of maintaining consistency over the course of a product's lifetime. In terms of software development, we're referring to server configuration management. This is where we can manage the integrity of the state of a computer system and the applications that run on it.
Programmatic techniques are applied to maintain consistency in an application throughout its lifecycle. Performance is usually evaluated through a testing framework of some kind that verifies deployments before they reach a production server. Typically, a CM tool allows for pre-configured and reusable code for infrastructure management, very similar to application development. The results of applying these techniques to infrastructure and application development have resulted in an enormous amount of cost avoidance, catastrophic event prevention, and time savings.
By the end of this course, I hope you'll be able to see why. A good CM tool allows for code reuse and templating amongst servers that share the same configuration. For example, a database configuration should be deployable on any server the code was designed for. A database template might provide instructions for provisioning the server using a Cloud provider of choice, installing the database and configuring it with details like usernames, passwords, and the proper permissions for accessibility to other infrastructure components like web servers.
To understand how much configuration management has changed the landscape of infrastructure, it's helpful to look at some examples such as deploying an Apache or an IIS web server. Here is an example of a generic template for a web server, Apache web server, written using Chef resources, which we'll discuss later. For now, don't worry if you've never seen or used Ruby before. Just take a look at the code and see if you can understand what it's doing.
You can see that the first block of code contains instructions for installing an Apache web server package called HTTPD. The second block then configures the HTTPD package to serve a basic Hello World application by creating an index.html page. This page will then be served to the web when the Apache service is started in the third block of code. Now, that code you just looked at is an example of a reusable template that could be deployed to one or thousands of servers.
A good CM tool will enforce the same configuration and ensure that there are no quote unquote snowflakes or unique servers that stray from the desired state that you defined in that block of code. Because these templates are written using languages that many developers are already familiar with, such as Ruby, there's a lot of programmatic flexibility that developers have with code reuse. This means that variables can be used inside of your infrastructure code to provide generic sets of instructions that any server can apply even though host specific details like differing IP addresses or host names will be present.
A practical use case for this might be storing the username and password for a database in a variable. This variable can then be called by your infrastructure template, which can easily be modified if, for example, the deployment environment were to change. Here, you see that variables are then referenced inside of our infrastructure code instead of those hard coded values, so that we only have to change the value of a template variable in one location.
The example you see here would involve rendering the username and password inside of the configuration file using a variable. Again, if you don't understand the code on the screen yet, don't worry. Just want you to get a sense of what you can plan to see throughout this course. Can you see how using templates instead of hard coding values will allow us to easily propagate changes throughout our code? This type of functionality is critical for a functional DevOps team and that's why configuration management has really taken the world by storm.
- Configuration management
- Using Chef
- Installing the Chef development kit (ChefDK)
- Provisioning a CentOS instance
- Using recipes and the Apache cookbook
- Working with nodes and node objects
- Using templates and embedded Ruby
- Hosting a Chef server
- Provisioning nodes with AWS
- Testing deployments with Kitchen
- Exploring the Chef Supermarket
- Resolving dependencies with Berkshelf
- Working with server roles, environments, and data bags