Keeping You Honest

Puppet Roles and Profiles with a Simple Module Structure (part 2)

by on Jan.12, 2013, under Puppet

In part 1 I discuss the inspiration for this series and also the overall goals. If you haven’t read it, it would be beneficial to read it before reading this article.

I will be using a top down approach for the design, but will build the modules bottom up.

Node List

In this environment we will have:

  • 1 database cluster
  • 3 app server clusters
  • 1 web server cluster
  • 1 ldap server cluster
  • 1 load balancer cluster
  • 1 content server.

Each cluster, other than the app and web server clusters, each cluster will consist of two nodes, in either a Master/slave or “hot standby” type configuration. The web and app servers will each have three nodes.

Role List

For this environment we will have 19 nodes that we will be managing. Of these 19, there are only 6 distinct roles, so we can go ahead and define them here.

  • Database Role
  • App Server Role
  • Web Server Role
  • LDAP Role
  • Load Balancer Role
  • Content Server Role

These roles will become the top level classes that will be assigned by either our ENC or in the site.pp based node defs. Which one doesn’t really matter and is more a matter of personal taste and company policy and what works for you and your team. For simplicity’s sake, I will assume we are using the site.pp method.

Profile List

Now we can define our profiles. Each role has a few different variants, or profiles that will be needed. We shall list these now.

  • Database
    • Master
    • Slave
  • App Server
    • Cluster 1
    • Cluster 2
    • Cluster 3
  • Web Server
  • LDAP
    • Master
    • Replica
  • Load Balancer
    • Master
    • Backup
  • Content Server

You may notice that the content server and the web server roles do not actually have any defined profiles. These will be using the “default” profile for their roles, as each node in the web server cluster should be configured the same, with the host name as the exception. And the content server is a singleton. Not a true snowflake, but not clustered at this point in time.

 Module List

At this point, we have worked our way down to the point where we can start talking about application stacks and specific configurations and environments. For the purpose of this article, everything will be in a single environment, but it’d be trivial to do this with additional environments. Instead of Database -> Master profile,  you’d use something like Database -> Master -> Test or Database -> Master_test for the profile, and just create additional Master and Slave profiles per environment.

There are certain things that are common to all nodes, this would be things like puppet, ssh, 7zip, unzip, ntp, admin users, package manager repo sources (apt/yum/whatever), etc.. These common, shared items will all go into a base module. The exact name doesn’t matter, but I would I would avoid ‘default’ or ‘common’ to avoid conflicts. Names like ‘base’ or ‘basenode’ are fairly common.

Even though each role has a couple different profiles, the core application stack is the same. The only difference is how they are configured.

  • Database Server
    • PostgreSQL
  • App Server
    • Tomcat
    • Java
  • Web Server
    • Apache
  • LDAP
    • OpenLDAP
  • Load Balancer
    • Keepalived
  • Content Server
    • Alfresco

You may have noticed, but at this point, we still don’t say anything about versions or such. That will be a parametrized option that will be discussed in part 3, as long as the other code level details for much of this.

 

:, ,

3 Comments for this entry

Leave a Reply

Looking for something?
You can search for it here.

Custom Search

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!