Puppet managed loadays

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?

[email protected]

loupgaroublond on practically every social network, especially freenode

#[email protected]

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