Ok, I'll bite :) warning: this is going to be long and complicated, i think this is the part which was most challenging in setting up our puppet infrastructure.
some background and assumptions: - we have many sites / locations / data centers. - we have many different host types (e.g. server profiles) - we have site administrators (responseble only for their site) - we have global administrators, each one is responsible for a different topic globally. - we usually have a very short maintenance window on our servers (and its never on the same time across the different sites). - each host type might have a different maintenance window. we were looking for a way, of how we can have the same setup in all of our locations, but still managed by puppet so we came up with the following requirements: - every change should be done by puppet (unless really really critical and bla bla - never happened). - "global administrators" (or I don't know how else to call them, in contrast to site administrators) are the only one to control their respective parts in the manifest. - site administrators should have a way to rollout changes immediately and override global settings if something breaks (like they used to before puppet). - everything must be visible to every administrator - every change must be tracked etc. - must provide a release cycle. - must be easy to audit configuration database / repository - Consists of all Global (aka standard) configuration. - Consists of all Sites customizations (or global configuration overrides). - Access Control, Change Log - Using Version Control -Ticketing System, Milestone management (e.g. downtimes) etc puppet modules ( we defined 3 types of modules ) - Host Type - primary purpose of a host --- Each host is associated with one host type --- Always inherits the Host base class for common policy - Service modules - used (shared) by other modules, e.g. ssh, syslog, apache, x11 etc. ---Avoids repeating the same code again and again ---Breaks down the scope of each module, allowing different module owners per topic ---Changes requires more attention as many host types might use the same service module ---Should be plug-and-play - Sites Modules - sites customizations --- The only place a site can edit his settings (Sites can not change global modules) --- Each site can only change his own site module --- Site modules provide a mechanism to override the global modules in a visible and auditable way --- As Site modules are not tagged (versioned) any change in the site specific settings, will be rolled out immediately. on top of all that we tag the modules, and associate them with a version: Versioning – The ability to refer (tag) to a certain state/PiT Host Type and Service modules are associated with a version, e.g. ssh v1.0 Site Modules are not tagged in order to reduce complexity Why ? Allows each module owner to “release” testing and stable versions of his module Sites subscribes to modules in a certain version, allowing each site to select which and when changes will be applied Environments – The ability to select a group of modules in a certain version Each site is associated with at least two environments(usually more) – Production and Testing: Testing – an environment which refer to versioned modules under a test or productive tag. Production – A selection of modules in a certain version that has already been approved for Production usage. Development environment – The state where the modules are in the latest check-in version, but are not tagged (e.g. not a testing candidate yet). Development --> Testing --> Production (Per Host Type) Each module owner should review the local sites adaptation, to find out the reasons for change - Improve communications - Improve host-type / service module quality - Auditing ensures that our infrastructure remains harmonized on top of that, we also have global environments, this is needed for services which are identical across the sites but and not under the site control, for example puppetmasters, ldap servers etc. hope it helps :) Ohad On Sat, Jul 18, 2009 at 4:06 AM, Teyo Tyree <t...@reductivelabs.com> wrote: > In the course of training and consulting with Puppet, the question of > change management best practices has come up over and over again. On the > edges, we have small teams that can get away with simply version controlling > their code using an SCM as an incremental backups while rolling out change > in a fairly adhoc fashion and larger teams that need branches, QA, and DEV > environments, and perhaps even separate repositories for each module. There > is also the issues of roll back and testing. We are curious how the > community approaches these problems in hopes of developing some best > practices. So what do you guys/gals do? > -- > Teyo Tyree :: www.reductivelabs.com > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
