Introduction to Configuration Management
If you have been in operations team, then you must have spent most of your time in installing OS, Software, if not this, then in troubleshooting what has caused the outage. The remaining time, if left, then you must be filling in installing updates and Tuesday Patches. No wonder, you don’t get enough time or prioritization on patching as result attacks like wannacry play a great on you.
But you are not alone; it is a day in the life of any System Administrator. But then you have been smart to automated patching, daily checks and in some rare case even in deploying software. Unless you get time from your day, Automation of this scale needs a lot of time and dedicated effort. Automation or rather doing less with more is the most bliss thing for a System Administrator. When we see advanced automation adapted by companies, we miss on the know-how and documentation, Deployment tools training required to pass on to other team members. Software deployment tools might not even cater towards the different OS, OS Version, Flavors, Platforms. It might risk the investment made in the automation project if automation cannot address multi-platform, multi-OS requirement.
Imagine you and your team is managing thousands of servers and changes happening daily there? Yeah, this is a reality today due to cloud computing where you can deploy instance in seconds. Now every user has the luxury to provision more than one server. On the average end user has five servers. These are provisioned, de-provisioned frequently. Changes of these magnitudes will drive you mad.
Configuration Management (CM) is the solution to this problem. With configuration management software deployment, software configuration, software version control, user management, security, and permissions become an easy task. Apart from the above, CM implicitly solves documentation and change detection (drift) which is one of the key pain points. CM allows checking what had changed when it was changed and who has changed. It maintains the history of changes.
In case your server is corrupted, you can provision a new server, deploy CM agent, apply the desired configuration and you are back to the same state regarding software version, configuration, users, security, and permissions. It can be achieved using without any manual configuration or referring to any document or by using complex software deployment tools. It occurs so fast and effortlessly. We wonder how we could be spending so much time in only installing OS, software apart from troubleshooting.
CM and DevOps
DevOps played a critical part in pushing CM further on the list of must-haves in any organization. We know that Provision Server task is simplified due to virtualization and cloud computing. Therefore it is expected System Administrators start to focus on optimizing the rest of the part of their daily job. On the similar front, it is expected developers think on the same line. These roles will eventually overlap or in some cases has started overlapping.
Introduction to Puppet
Let’s discuss in the more pragmatic way how Puppet makes your life easy. Here is an example of deploying a typical application, user configuration, security and permissions.
Step: 01 Provision OS
Step: 02 Install software
Step: 03 configure software
Step: 04 Create user and provide him access to newly deployed software
Step: 05 set security for the deployed software
Now imagine doing it on hundreds of servers and the effort, time involved in deploying on different hardware, OS, and platforms. It is the humungous task. Human errors are likely to happen as well which will further slow down the deployment project. If you decide to do this in a puppet way, it might take two steps
- Install agent on the server/node
- Write following code
Ensure => installed,
}
File {‘/etc/mysql/mysql.cnf’:
Ensure => file,
Source =>’/puppet/manifest/file/mysql.cnf’,
Require => Package
notify => Service[‘mysql’],
}
Service{‘mysql’:
ensure => running,
enabled => true,
Require => [Package[‘mysql-server’],File[‘/etc/mysql/mysql.cnf’]],
}
First and foremost don’t try to understand this code. My intention is not to confuse you but to give you a glimpse of 12 lines of codes which do the magic. Secondly, you don’t need to have any knowledge about coding/language. Puppet is a declarative language, not imperative language. In a declarative language, you focus on describing end/desired state of the node. You never have to code on how to accomplish it, which is required in the imperative language. Third, which is most important you can re-run this code several times, and you will get the same result. The process of getting the same result is termed as idempotent. As I have already mentioned the term code, let me introduce manifest. In puppet, the above code is referred as manifest. Well, that is the first term I explained. And you already learned it.
Puppet Architecture
Before I describe the manifest, I would like to talk about puppet architecture. You can deploy puppet in one of the two supported architecture. What we have primarily seen in the industry is Client-Server. Nevertheless, we are also seen standalone architecture getting popular.
Agent Master Architecture
An agent which is also referred as Node is our traditional server. Master is referred as the Puppet master. In this architecture, agents are deployed on the nodes. All agents keep sending their state to Puppet Master, which puppet master reviews for any drift by comparing the manifests. You can delve more into this as I can guess you will start getting few key question like
“So all nodes keep checking with the master, and what about network traffic, security, and load on master and or Node.”
I will direct you to formal documentation about it here. Below is the simple schematic.
Standalone Puppet
Standalone as the name suggest do not need any master to get configuration from the centralized location. Instead, you have a choice of using online repository Git or You may also choose your own method to keep manifest on each node updated.
Puppet’s Domain Specific Language (DSL)
Now that we have learnt little bit about the architecture. Let’s go to the core of Puppet i.e. writing manifest. 90% of the time you as a System administrator will be writing manifest.
Domain Specific Language (DSL) which is commonly referred as DSL is used for expressing the desired state of the nodes. As shown above, DSL looks quite different. The reason being, it is declarative language. Here is very simple example
ensure => ‘installed’,
}
Above code in plain English states – Install VIM package.
Put the above code in your favorite editor. I love VIM editor. Save the file with any name as long as it ends with pp firstmanifest.pp
Now you need to execute this code or in puppet parlance, we have to apply this manifest. Below is the command
Puppet apply firstmanifest.pp
What happens when you execute this command?
- Checks the list of installed package on the node to review if vim package is installed?
- If not, puppet agent installs the vim package. If yes, nothing happens
Yeah, Step: 02 does nothing? Why? Because package is already installed. Did you notice we are not using any conditional statement (e.g. IF, Then). We are only stating VIM should be installed in “ensure => installed”. This line of code also forms a documentation that node x must have VIM installed. Now if we repeated run this command, result will be same which is called as Idempotent.
Let’s try one more example of creating users.
Step: 01 open VIM editor and type following code
ensure => present,
home => ‘/home/preetam/’,
groups => [‘adm’],
comment => ‘Preetam Zare’,
}
Let me explain the manifest before we go to next step. First line is user which is called as resource. What are resources? Well, resources are the critical part of manifest which aids you describing desired state. Yes you guess it correctly, package is also another resource. So, in the above example, user is a resource. We are declaring a desired state for the user by name preetam. So ‘preetam’ is Title of the resource. Title is must for the resource.
Anything after title is attribute value pair. Attributes are defined by puppet we just need to fill in the value. In my example preetam’s home directory is /home/preetam, preetam’s group is adm, preetam’s full name can be described under attribute by name comment.
Additional tips
You might wonder how to find the resource. Very simple, run following command to get full list of resource
Puppet describe –list
Run following command to get attributes defined for specific resource e.g. user
Puppet describe resource user
Similarly
Puppet describe resource service
Step: 02 save the file with any name e.g. user_preetam.pp and apply the manifest using the command
Puppet apply user_preetam.pp
What does the output means? Well before that let me show few more command. Below command validate
the syntax of .pp file
Puppet parser validate user_preetam.pp
If the syntax is fine, there is no output.
Below command does something called as dry run. Dry run is test before we apply the actual manifest to the node.
Puppet apply –noop user_preetam.pp
First line is compiling the manifest into catalog.
Second line checks if the user preetam is present and what should be the end state
Note, all lines start with the ‘Notice’
I’ve also shown you the message displayed by puppet resource user preetam command which also states that user preetam is absent
So when you apply the manifest the output will as below
Now again, if you run the same command.
Now when you again run the command puppet resource user preetam, you get desired state for the user preetam
Conclusion
We learned the importance of Configuration Management in System administration life. I have shown some use cases CM using puppet. I also gave a very short introduction to puppet architecture, Puppet DSL and few examples including how to apply manifest. We have scratched the surface. If you wish to learn CM, specifically puppet there is a long way to go but do remember this path is full of opportunities.
Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.
