Design & Technology March 08, 2018
Infrastructure as code - with Puppet
Using Puppet and Infrastructure as Code is important when you have to maintain a large amount of servers. Why is it important and how to use it? Gijs explains.
As an IT organization you have to manage the IT infrastructure. The infrastructure could be one server or a whole data center of servers. At some point you might be willing to automate things. At first you might manage these servers manually by logging in on them and running commands.
With a hand full of servers that is still feasible, but when your infrastructure starts to grow this will take too much time. That’s the point where you start writing scripts to automate some things, like for example an initial configuration of a new server, making sure the latest packages are installed.
But what if you have some servers that use package manager X to install packages and for some reason you need a server with a different kind of operating system that uses package manager Y? Now that your scripts do not work anymore, you could make a copy of the script and modify it so it works on both kind of servers but now you have two scripts.
The Solution: Puppet
Tomorrow a new colleague is starting and he also needs to maintain some servers. He could write his own scripts, but maybe he does things different then you do. You could send him your scripts but when he makes changes to it he needs to send them back to you so you can update your own scripts with them as well.
This quickly becomes a mess and needs a proper solution. This is where Puppet comes in. With Puppet you can create manifests and modules to maintain your infrastructure. These modules and manifests are operating system agnostic, so they will work on multiple different operating systems.
The way puppet works is that you describe how your server should look like in a manifest. In that manifest you use predefined service definitions that come from modules.
One such service definition could be a package that should be installed on the server. In your manifest you could describe that you need the Apache and PHP packages installed on the server. Then the module where that definition comes from contains everything Puppet needs to know how to install those packages on any operating system.
Standard Modules within Puppet
It will use Yum on Redhat servers for example and Apt on Debian servers. A lot things are already available by default with Puppet but if not you could make your own module. There are also a lot of modules available on the Puppet forge. Good chance the things you want to do are already done by someone else and you can re-use their module for your purposes.
The next step would be to put your manifests in a version control system like Git. That way you can keep track of all the changes that are being made to the infrastructure you are managing and you can collaborate with other people.
Because Puppet will run every 30 minutes by default any unauthorized changes to services that are being managed by Puppet will be effective for only a maximum of 30 minutes. This is because Puppet will see if something is different as described in the manifest and re-applies the manifest, so all changes to the infrastructure have to be done in the manifests which are in version control in order to see who made each change.
You can take this a step further by applying principles well known in the application development industry, like Continuous Integration and Continuous Delivery. This way you can even test your manifests and modules to make sure they work as intended. The modules are just classes which can be tested. And by using Beaker and a virtualized environment (local or in the cloud) it is easy to test your modules against different environments so you are sure the result is the same on for example Debian and Ubuntu.
By using Puppet and Infrastructure as Code you know for sure that each server is configured in the same way and you can also be sure they stay in the correct state. This is especially important when you have to maintain a large amount of servers.