Difference between revisions of "Infrastructure Team/Puppet"

From Sugar Labs
Jump to navigation Jump to search
Line 1: Line 1:
 
Sugar Labs Puppet infrastructure.
 
Sugar Labs Puppet infrastructure.
  
== Recipes ==
+
== Modules ==
  
There are two kinds of Puppet recipes:
+
Puppet modules configure particular services like [[Service/git|git.sugarlabs.org]] or MySQL but not tied to final configurations, they are being configured from [[#Master|puppetmaster]].
  
* Puppet modules that are abstracted from final usage on particular Sugar Labs sites,
+
All modules are collected as repositories in [http://git.sugarlabs.org/puppets puppets] Gitorious project. Modules might be created from scratch or mirrored from upstream, so, all modules that are used within Sugar Labs are stored in one place. Module repository might have followed branches:
* and recipes that composite modules and describe final configurations of Sugar Labs services.
 
 
 
=== Modules ===
 
 
 
Puppet modules configure particular services (e.g., mysqld) and are not tied to final configurations. All modules are collected as repositories in [http://git.sugarlabs.org/puppets puppets] Gitorious project. Modules might be created from scratch or mirrored from upstream, so, all modules that are used within Sugar Labs are stored in one place. Module repository might have followed branches:
 
  
 
* ''master'', development version (might be absent if project is mirrorred from upstream),
 
* ''master'', development version (might be absent if project is mirrorred from upstream),
Line 18: Line 13:
 
Auto generated [http://api.sugarlabs.org/puppets/ documentation].
 
Auto generated [http://api.sugarlabs.org/puppets/ documentation].
  
=== Final configuration ===
+
== Master ==
 +
 
 +
Only puppetmaster keeps final configuration for all Sugar Labs services. It is being started on [[Machine/lightwave|security machine]] in private git repository.
  
Final recipes are stored on [[Machine/lightwave|puppetmaster host]] in private git repository:
+
=== Private repository ===
  
 
* {{Code|/var/lib/puppet/etc/puppet.git}}
 
* {{Code|/var/lib/puppet/etc/puppet.git}}
Line 56: Line 53:
 
  sleep 3
 
  sleep 3
  
Git repository has submodules to all, used on all puppetized hosts, modules from [http://git.sugarlabs.org/puppets puppets] project. All submodules are checked out to ''production'' branch.
+
=== Repository hierarchy ===
 +
 
 +
Git repository consists of:
 +
 
 +
* {{Code|modules/}}, all used modules from [http://git.sugarlabs.org/puppets puppets] project in form of submodules.
 +
* {{Code|manifests/site.pp}}, main recipe which contain common settings and includes nodes.
 +
* {{Code|manifests/roles/}}, recipes that describes final configuration for particular service.
 +
* {{Code|manifests/nodes/}}, puppetized nodes, configuration for hosts that ask puppetmaster.
  
 
== Nodes ==
 
== Nodes ==
  
''In progress''
+
Hosts that fetch configuration from the [[#Master|puppetmast]] need <code>puppet >= 2.6</code> package.  If {{Code|puppet}} was installed from gems, it needs to be initially configured:
 +
 
 +
puppetmasterd --mkusers
 +
 
 +
Node's puppet agent might have optional configuration in {{Code|/etc/puppet/puppet.conf}}:
  
End-usage nodes. Configuration settings are tracked by local git repository only since contain private data.
+
[main]
 +
runinterval = <fetch-configuration-in-every-n-seconds>
  
=== jita.sugarlabs.org ===
+
Every puppetized host should have particular node file in {{Code|manifests/nodes/<host-name>.pp}} on [[#Master|puppetmaster]].

Revision as of 17:10, 14 November 2010

Sugar Labs Puppet infrastructure.

Modules

Puppet modules configure particular services like git.sugarlabs.org or MySQL but not tied to final configurations, they are being configured from puppetmaster.

All modules are collected as repositories in puppets Gitorious project. Modules might be created from scratch or mirrored from upstream, so, all modules that are used within Sugar Labs are stored in one place. Module repository might have followed branches:

  • master, development version (might be absent if project is mirrorred from upstream),
  • production, version is being used in production,
  • upstream, if it is mirrorred project.

Auto generated documentation.

Master

Only puppetmaster keeps final configuration for all Sugar Labs services. It is being started on security machine in private git repository.

Private repository

  • /var/lib/puppet/etc/puppet.git
  • /var/lib/puppet/etc/puppet detached working directory
  • /etc/puppet symlink to detached working directory
  • /var/lib/puppet/etc/puppet.git/config:
[core]
repositoryformatversion = 0
filemode = true
bare = false
sharedRepository = true
logallrefupdates = true
worktree = /etc/puppet

[receive]
denycurrentbranch = ignore

[hooks]
mailinglist = systems-logs@...
emailprefix = "[PUPPET] "
showrev = "git show -C %s; echo"
  • /var/lib/puppet/etc/puppet.git/description:
Sugar Labs Puppet configuration
  • /var/lib/puppet/etc/puppet.git/hooks/post-receive
#!/bin/bash
/bin/bash /usr/share/doc/git-core/contrib/hooks/post-receive-email
git checkout -f
tail -n0 -f /var/log/daemon.log &
puppet kick --all
sleep 3

Repository hierarchy

Git repository consists of:

  • modules/, all used modules from puppets project in form of submodules.
  • manifests/site.pp, main recipe which contain common settings and includes nodes.
  • manifests/roles/, recipes that describes final configuration for particular service.
  • manifests/nodes/, puppetized nodes, configuration for hosts that ask puppetmaster.

Nodes

Hosts that fetch configuration from the puppetmast need puppet >= 2.6 package. If puppet was installed from gems, it needs to be initially configured:

puppetmasterd --mkusers

Node's puppet agent might have optional configuration in /etc/puppet/puppet.conf:

[main]
runinterval = <fetch-configuration-in-every-n-seconds>

Every puppetized host should have particular node file in manifests/nodes/<host-name>.pp on puppetmaster.