If you can't read please download the document
Upload
yankee-nemoy
View
1.414
Download
0
Embed Size (px)
Citation preview
login
Puppetmanaged.orgHow to use it inyourenvironment
id
uid=500(Yaakov M. Nemoy) gid=500(Human) groups=10(wheel),501(Fedora Project Ambassador),502(Puppetmanaged.org Developer),503(RHCE),666(UMC Utrecht BOFH)
elinks
Puppetmanaged.org is a collection of (mostly) standalone common puppet modules for per service deployment of your infrastructure
It's designed around principles of good configuration management
Reliability and longevitiy of your organisation
Going to scale via code as well as being flexible for those one offs
elinks
Puppet
Mysql
Apache
Bind
Cobbler
Yum
Samba
Zarafa
Openldap
Openvpn
Postfix
Monit
Munin
Nagios
elinks
Authconfig
Autofs
Func
Iptables
NFS
NTP
Rsync
Selinux
Ssh
Sudo
Trac
Virt
Xen
Pam
We're looking for your modules
elinks
Each module containsA bunch of file declarations
Gets your service up and running
RHEL default configurations
Well defined classes with logical meaning
Every class has a disabled subclass for cleanup
A pony development, testing, and production branches
elinks
pm.org is file based just deliver the files and get out of the way
There are five options for file locationsEnvironment + Host
Environment
System Wide + Host
System Wide
PM.org default
elinks
puppet://$server/private/$environment/webserver/httpd.conf.$hostname
puppet://$server/private/$environment/webserver/httpd.conf
puppet://$server/files/webserver/httpd.conf.$hostname
puppet://$server/files/webserver/httpd.conf
puppet://$server/webserver/httpd.conf
You have to know how to setup apache anywaysYou can group with symlinks
elinks
node 'node1.example.org' { include webserver
webserver::virtualhost { "www.example.org": enable => true }
webserver::module::enable { "php": enable => true }}
Can also be virtual and external resources
Note use of sites enabled and modules enabled
elinks
Uses definitions to create pseudo resources
Makes these modules very easy to adopt
Easy to deploy in your current infrastructure, one module at a time
Easy to collaborate with upstream on
Comment about virtual host, pam, ldap, git
The goal is to get common interfaces
The design is meant to scale too
git clone
All modules in a git repository
make
All you need is a git repo with a directory per module
Each branch is a seperate environment
The master branch is the site-wide configuration
The pm.org puppet module handles the rest
make
Some services require OS version specific files, then you get twenty optionsOS + minor version
OS + major version
OS
Default
For example:pam
make install
ah... um.....
make install
Actually this slide should be febootstrap/debootstrap
git svn
I can't talk about how to fix this in your environment...
git svn
Or can i?
[Insert Shamless Hire Me Plug]
git svn
The UMC Utrecht DBG ne Genomics Center is a public institution, so we can talk about how we solved the problem there
git foo
There are good gateways for git and other source control
Fill me in more
git svn
We started with an old experimental version of pm.orgconf/manifests this is our site manifest
distr/modules one git repo per module
distr/files legacy files
distr/files/private file domain structure
We only have one environment currently
git branch
Each repo is cloned into the svn, then branched to a umc specific branch
Since we're using svn, i freely use git rebase, so it's obvious which patches are not yet upstream
The diff between development and umc is meant to be as short as possible
emacs
Our umc branches normally just edit file locations and comment out code defined in legacy
UMC specific classes are in conf/manifests/classes/*pp
git rebase
Every time i commit to git, i can also commit it to our SVN
Everytime someone else commits to svn, i can rebase the git on top
git push
Commiting is then very easy, just switch to the right branch and push
git format patch is great
There is a devel mailing list open for patches
Frequent patchers can probably get commit access
publican
Documentation is yet another git repo
We store it at documentation/
We branch and merge like usual
Rather than using our internal wiki
make install
Move all code into modules or classes
Migrate to pm.org's puppet module managing site.pp
Sort all files into distr/files/private
Ensure every module we have is pm.org quality
make install
Move each git repo to its own toplevel in svn (except maybe distr/modules)
git-svn handles mapping svn branches
Fix the puppet module to do svn too
cat /dev/future
Environments per working groupEach group has write access to their own branch
Porcelain extensions on top of pm.org standard
More modules
Better integration with external nodes
who
ogd.nl
kolabsys.com
genomicscenter.nl
op.umcutrecht.nl
berica.nl
fedoraunity.org
puppetmanaged.org
rpmfusion.org
kanarip.com
wget puppetmanaged.org
http://www.puppetmanaged.org/
http://git.puppetmanaged.org/
http://www.puppetmanaged.org/mailman/listinfoCommits
Devel
Users
questions?
loupgaroublond on practically every social network, especially freenode
Or just annoy kanaripthe one with the ugly haircut
Click to edit the title text format
Click to edit the outline text formatSecond Outline LevelThird Outline LevelFourth Outline LevelFifth Outline LevelSixth Outline LevelSeventh Outline LevelEighth Outline LevelNinth Outline Level