Puppet managed loadays

1,039 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,039
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Puppet managed loadays

  1. 1. login Puppetmanaged.org How to use it in your environment    
  2. 2. 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)    
  3. 3. 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    
  4. 4. elinks ● Puppet ● Zarafa ● Mysql ● Openldap ● Apache ● Openvpn ● Bind ● Postfix ● Cobbler ● Monit ● Yum ● Munin ● Samba ● Nagios    
  5. 5. elinks ● Authconfig ● Selinux ● Autofs ● Ssh ● Func ● Sudo ● Iptables ● Trac ● NFS ● Virt ● NTP ● Xen ● Rsync ● Pam    
  6. 6. elinks ● Each module contains ● A 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    
  7. 7. elinks ● pm.org is file based – just deliver the files and get out of the way ● There are five options for file locations ● Environment + Host ● Environment ● System Wide + Host ● System Wide ● PM.org default    
  8. 8. 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    
  9. 9. elinks node 'node1.example.org' { include webserver webserver::virtualhost { "www.example.org": enable => true } webserver::module::enable { "php": enable => true } }    
  10. 10. 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    
  11. 11. git clone All modules in a git repository    
  12. 12. 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    
  13. 13. make ● Some services require OS version specific files, then you get twenty options ● OS + minor version ● OS + major version ● OS ● Default ● For example: ● pam    
  14. 14. make install ● ah... um.....    
  15. 15. make install ● Actually this slide should be febootstrap/debootstrap    
  16. 16. git svn I can't talk about how to fix this in your environment...    
  17. 17. git svn Or can i? [Insert Shamless Hire Me Plug]    
  18. 18. git svn The UMC Utrecht DBG née Genomics Center is a public institution, so we can talk about how we solved the problem there    
  19. 19. git foo ● There are good gateways for git and other source control    
  20. 20. git svn ● We started with an old experimental version of pm.org ● conf/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    
  21. 21. 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    
  22. 22. 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    
  23. 23. 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    
  24. 24. 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    
  25. 25. publican ● Documentation is yet another git repo ● We store it at documentation/ ● We branch and merge like usual    
  26. 26. 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    
  27. 27. 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    
  28. 28. cat /dev/future ● Environments per working group ● Each group has write access to their own branch ● Porcelain – extensions on top of pm.org standard ● More modules ● Better integration with external nodes    
  29. 29. who ● ogd.nl ● rpmfusion.org ● kolabsys.com ● kanarip.com ● genomicscenter.nl ● op.umcutrecht.nl ● berica.nl ● fedoraunity.org ● puppetmanaged.org    
  30. 30. wget puppetmanaged.org ● http://www.puppetmanaged.org/ ● http://git.puppetmanaged.org/ ● http://www.puppetmanaged.org/mailman/listinfo ● Commits ● Devel ● Users    
  31. 31. questions? ● loupgaroublond@gmail.com ● loupgaroublond on practically every social network, especially freenode ● #ergo@freenode.net ● Or just annoy kanarip ● the one with the ugly haircut    

×