Customer and Environment Segregation using Puppet
This blog showcases the Customer and Environment segregation at the puppet-architecture-level for customized target deployments of the puppet modules. For instance, if one wants to deploy a puppet module to a specific customer and its specific environment type (Dev, Prod, Test), it is achievable by making the configuration changes in the puppet.
Puppet is a configuration management tool, designed for automating the administration tasks for the whole environment. System resources and their state is stored by user in Puppet’s Declarative language in a file called manifests. Puppet uses this system information via a utility known as Facter and compiles the manifests into a catalog containing resources and its dependencies.
Puppet deployment of modules is managed through two key configuration files :
- Node configuration file (Nodes.pp) : This file is used to determine which module (class) should get deployed to which server.
- Puppet manifests file (Site.pp) : It is the core configuration files of puppet. All the resources are stored in this file and its by default location is /etc/puppet/manifests/site.pp
Pre-requisite
Puppet master-agent architecture setup, with any number of agents. Please follow this post for installing-latest-puppet-master-and-agent.
Use Case
Deployment of puppet modules should be targeted to a specific customer or environment or both.
Present Puppet Architecture
Master-Agent Puppet Architecture is setup as shown in figure. Modules deployment is done through a central puppet master to all the systems (agents) in the infrastructure.
Segregated Environment Architecture
As shown in the above figure, the modules deployment is carried out on the basis of environment types and further segregation is done on the basis of customers.
Steps to achieve customer & environment segregation
By default, puppet configuration management is done using nodes.pp and site.pp file in puppet manifests folder. Customer and environment segregation is done using the puppet-agent certificate names, from which they are connected to the Puppet master server. The steps are as follows:
- Create a separate node file : <customer_name>.pp for every customer that consists of customer oriented puppet modules with the environment segregation.
[js]#customer.pp
node /customer.*\-.*\.ttn\.cloud inherits prod
{
include module-prd1
include module-prd2
}
node /customer.*\-.*\.ttn\.cloud inherits dev
{
include customer-module-dev1
include customer-module-dev2
}[/js]
2. Amend the default manifest file i.e.nodes.pp file of puppet and make the following changes.
[js]node default
{
#Modules listed here are targeted to whole environment
include global-module1
include global-module1
}
node prd inherits default
{
include prd-module1
include prd-module1
}
node dev inherits default
{
include dev-module1
include dev-module1
}[/js]
3. Restart the puppet-master service and use the targeted deployment of modules
By following the above steps one can achieve the segregation of the whole infrastructure environment at puppet architecture level on the basis of customers and their environment type. This approach is helpful for designing customer or environment specific modules in puppet.
