System Automation mit Puppet und Foreman

Toni Schmidbauer

9. Mai 2014

whoami

I SysAdmin@s-itsolutions

I toni@stderr.at

I http://stderr.at

I http://github.com/tosmi

I stderr@jabber.org

Agenda

I Kurze Umfrage

I Was ist Puppet?

I Was ist Foreman?

I Puppet@s-iTSolutions

I Was haben wir geplant?

Umfrage

Was ist Puppet?

I Declarative programming: telling the machine what you wouldlike to happen, and let the computer figure out how to do it.

I Imperative programming: telling the machine how to do something

1 c l a s s l i n u x w o c h e n 2 0 1 4 ($ e n s u r e = p r e s e n t

3 ) {u s e r { ’ t o n i ’ :

5 e n s u r e => $ensure ,u i d => 4711 ,

7 g i d => 100 ,}

9package { ’ emacs−nox ’ :

11 e n s u r e => i n s t a l l e d} −>

13 package { ’ vim−enhanced ’ :e n s u r e => absent ,

15 }}

Zuordnung von Klassen

I uber /etc/puppet/manifests/site.pp

node /ˆ( f o o | bar )\ . l i n u x w o c h e n \ . a t$ / {2 i n c l u d e l i n u x w o c h e n 2 0 1 4

}

I uber Hiera (hiera include(’classes’,[““]))

I uber einen External Node Classifier (Foreman)

Node classification

1 −−−c l a s s e s :

3 b l a c k :puppetmgmt :

5 m a n a g e c o n f i g : t r u epuppetmaste r : puppetd

7 p u p p e t v e r s i o n : 3 . 2 . 4sudo :

9 c o n f i g d i r : / e t c / s u d o e r s . d/c o n f i g f i l e : / e t c / s u d o e r s

11 c o n f i g f i l e r e p l a c e : f a l s epackage : sudo

13 p a c k a g e s o u r c e : ’ ’purge : f a l s e

Puppet Environments

I Environments sind unabhangige Puppet Umgebungen

I Ein Master kann mehrere Environments zur Verfugung stellen

/ e t c / puppet / modules / . . .2 / e t c / puppet / m a n i f e s t s / s i t e . pp

4 / e t c / puppet / e n v i r o n m e n t s / l i n u x w o c h e n / modules/ e t c / puppet / e n v i r o n m e n t s / l i n u x w o c h e n / m a n i f e s t s / s i t e . pp

Was ist Foreman?

Puppet run

Hiera

Puppet Master

Puppet Agent

Puppet CAPuppetDB REST API

Theforeman

2

3

4 1 5

4

5

6

6

3

2

1

Puppet

Facts / ReportsCatalog

Node classification

Facts / Reports

Upload reports to foreman

Upload reports to puppet master

Compile / send catalog

Node classifiction

Upload facts to foreman

Upload facts to puppet master

Und jetzt?

I Wie soll eine Entwicklungsumgebung aussehen?

I Wie testen wir den Puppet Code?

I Wie verwalten wir unseren Puppet Code?

I Wie soll unsere Puppet Umgebung aussehen?

I Wie erfolgt das Deployment des Codes?

I Wie verwalten wir Module von PuppetForge?

Wie soll eine Entwicklungsumgebungaussehen?

Vagrant

I http://vagrantup.com

I Ermoglicht virtuelle Entwicklungsumgebungen

I Vagrant Box ist ein vorkonfiguriertes Image

I Default VirtualBox andere Provider via Plugins (VMWare,KVM)

Demo

Wie testen wir den Puppet Code?

rspec-puppet

I Ruby RSpec Tests fur Puppet

I Jedes Module muss RSpec Tests mitbringen

1 r e q u i r e ’ s p e c h e l p e r ’d e s c r i b e ’ l inuxwochen2014 ’ do

3 l e t : f a c t s { { : o s f a m i l y => ’ RedHat ’ } }

5 c o n t e x t ’ e n s u r e i s s e t to absent ’ dol e t : params { { : e n s u r e => ’ absent ’} }

7i t do

9 s h o u l d c o n t a i n u s e r ( ’ t o n i ’ ) . w i t h ({’ en s ur e ’ => ’ absent ’ ,

11 ’ u id ’ => ’ 4 7 1 1 ’ ,’ g id ’ => ’ 1 0 0 ’ ,

13 })end

15i t { s h o u l d c o n t a i n p a c k a g e ( ’ emacs−nox ’ ) . w i t h e n s u r e ( ’ i n s t a l l e d ’ ) }

17 i t { s h o u l d c o n t a i n p a c k a g e ( ’ vim−enhanced ’ ) . w i t h e n s u r e ( ’ absent ’ ) }i t { s h o u l d c o n t a i n p a c k a g e ( ’ emacs−nox ) . t h a t c o m e s b e f o r e ( ’ Package [ vim−enhanced ] ’ ) }

19 endend

Demo

Wie verwalten wir unseren PuppetCode?

GIT

I Ein zentrales GIT RepositoryI 3 Hauptbranches

I MasterI TestingI Production

I Feature Branches fur neue Module

I Berechtigungssystem mit Gitolite

Wie soll unsere Puppet Umgebungaussehen?

Wie erfolgt das Deployment desCodes?

Umgebungen

I Development (Master)I Test auf 7 EntwicklungsserverI Push auf Remote Master Branch lost Deployment ausI RedHat 5,6 / Solaris sparc,i386 10,11 / AIX

I TestingI ca. 30 “Produktions” ServerI Annotated Tags werden automatisch deployed (test *)

I ProductionI ca 1000 HostsI Annotated Tags werden automatisch deployed (prod *)

Jenkins CI

I Continuous Integration Server

I Fuhrt Jobs aus (z.b. Shell Scripts)

I Monitored und liefert Status Jobs

I Es konnen Abhangigkeiten zwischen Jobs definiert werden

Puppet Umgebung und Deployment

Puppet developer

Development

Puppet Master

Testing

Puppet Master

Production

Puppet Master

Feature

Branch

Master

Branch

Testing

Branch

Production

Branch

4

3

2

1

Production Nodes

Testing Nodes (25−30)

Dev Nodes (7−8)

1

3

2

4

1 Features Branches get automatically created on Puppet Master (Dynamic Environments)

4

a normal commit to the Prodcution branch only runs tests

Production Branch gets deployed via GIT tag (prod_*)

3 Testing Branch gets deployed via GIT tag (test_*)

a normal commit to the Testing branch only runs tests

2 Master Branch gets deployed on commit via Jenkins

GIT

Jenkins

It’s all the same for Hiera yaml files, except dynamic environments!

Deployment

Monitoring

Wie verwalten wir Module vonPuppetForge?

Puppetforge Module

I Eigenes GIT Repository (puppetforge.git)

I Download der Module in der Enwicklungsumgebung viapuppet module install ...

I Staging GIT pull (bah!)

I Dies andert sich allerdings (dazu spater)

I Wie soll eine Entwicklungsumgebung aussehen? DONE

I Wie testen wir den Puppet Code? DONE

I Wie verwalten wir unseren Puppet Code? DONE

I Wie soll unsere Puppet Umgebung aussehen? DONE

I Wie erfolgt das Deployment des Codes? DONE

I Wie verwalten wir Module von PuppetForge? DONE

Probleme, Probleme, Probleme...

I Ein GIT Repo funktioniert nicht bei Anderungen vonUpstream Modulen

I Andere Abteilungen sollen ihre Module unabhangig testen

I Unittests sagen noch nichts aus, wie sich der Code amLive-System verhalt

I Wir sollten eigentlich das Zusammenspiel aller Module testen(Forge und eigene)

Was haben wir geplant?

I r10k fur Deployment(https://github.com/adrienthebo/r10k)

I Ein Repository pro Module

I Nur interne Module bleiben im Hauptrepo

I Acceptance Tests mit Beaker

Links und Bucher

I http://github.com/tosmi/linuxwochen2014

I http://github.com/tosmi/puppet-devel

I Puppet Learning VM: http://puppetlabs.com/download-learning-vm

I Foreman: http://theforeman.org

I Vagrant: http://vagrantup.com

I rspec-puppet: http://rspec-puppet.com/

I puppet-lint: http://puppet-lint.com/

I Gitolite: http://gitolite.com/

I r10k: https://github.com/adrienthebo/r10k

I Roles and Profiles: http://www.craigdunn.org/2012/05/239/

I Dynamische Puppet Umgebungen:http://puppetlabs.com/blog/git-workflow-and-puppet-environments

I puppet-sync: https://github.com/pdxcat/puppet-sync

I Instant Puppet 3 Starter

I Pro Puppet 2nd

I The RSpec Book

I Pulling Strings with Puppet

I Continuous Delivery

Danke fur die Aufmerksamkeithttp://stderr.at/foreman_puppet_development2014.pdf