How to Upgrading Puppet Best practices Testing new Puppet Master version

1. Upgrading Puppet
HowTo
PuppetCamp Düsseldorf
Martin Alfke
<martin.alfke@buero20.org>

2. Wer
• Martin Alfke
• Berlin
• Freelancer / Trainer
• Puppet @ Linuxhotel
• Puppet User Group Berlin

3. Poll
!
!
• Puppet 2.x?

4. Poll
!
!
• Puppet 2.x?
• Puppet 3.x?

5. Agenda
• Warum soll man Puppet
aktualisieren?
• Funktioniert der alte
Puppet DSL code noch?
• Wie führe ich das Upgrade
durch?
• Was kommt in Puppet 4?

6. Warum upgraden?
• Sehr schneller Release
Zyklus
• Best Practices
• Neue oder geänderte
Funktionalität
• Endlich fallen alte Sachen
raus
• Puppet 4 kommt!

7. Why should I upgrade
Puppet at all?
• Do you want security updates?
• Do you want to make use of new functionality?
(e.g. automatic data bindings, environmentpath,
future parser)
• Do you want to get support (community or
enterprise)?

8. Funktionieren meine
Module noch?
• Der eigene Puppet Code (Module)
wurde vor einiger Zeit entwickelt
und wird einfach benutzt.
• Der eigene Puppet Code basiert
noch auf alten Best Practices und
folgt nicht den neuen Style Guides
• Alle schauen immer in ihre Puppet
Logfiles und prüfen auf “deprecation
warnings”

9. Worauf muss man achten?

10. BAD
Best practice
• Multiple Vererbung (inherits)
• Verwendung von import
• Modifizieren von Remote Modules
• Benutzung von Variablen ohne
Angabe des Scopes

11. Best practice
Restriktive Benutzung von Vererbung
!
Anstelle von Vererbung kann man oft parametrisierte Klassen verwenden.
Aktuelle “Best Practice” ist nur noch Vererbung von params.pp
!!
BETTER
class ssh (
$server = $ssh::params::server,
$client = $ssh::params::client,
$x11fwd = false,
) inherits ssh::params {
}
!
class { ssh::params::
server => false,
x11fwd => true,
}

12. Best practice
Include verwenden
!
Nutzt den Puppet Autoloader.
!
# ssh/manifests/init.pp
class ssh {
include ssh::server
}
!
# ssh/manifests/server
class ssh::server {
}
!
BETTER

13. Best practice
“Remote Modules” sind
Open-Source -> helft beim
Besser machen.
!
Erstelle ein Issue oder PR wenn
eine Verbesserung rein soll.
!
Sorge dafür, dass die Remote
Modules upgradefähig bleiben.
BETTER

14. Best practice
Setze beim Verwenden von Variablen
den Scope.
!
class ssh (
$server
) {
}
!
class ssh::server {
notify { $ssh::server: }
}
BETTER

15. Best practice
Nutzt die Scope function in
Templates
!!
BETTER
key = <%= @ssh::server %>
!
oder
!
key = <%= scope.lookupvar(‘ssh::server’) %>
!
oder
!
key = <%= scope[‘ssh::server’]

16. Best practice
Setzt bei facter Variablen den Top Scope
!
class ssh {
notify { “OS: ${::operatingsystem}”: }
}
!
class ssh::server {
if $::is_virtual {
notify { “Virtuelle Maschine unter ${::virtual}”: }
} else {
notify { “Hardware: ${::productname}”: }
}
BETTER

17. Best practice
Ab sofort immer mit Daten
Validierung
!
class ssh (
$server = hiera(‘server’, ‘localhost’)
){
# validate_string is a function from stdlib
validate_string($server)
notify { “We will use Server: ${server}”: }
}
!
BETTER

18. Remote modules
• Welche Puppet Version unterstützen
“Remote Modules”?
• Neue Puppet Versionen habe neue
function Attribute (z.B. arity)
• Neue Remote Modules können
neuere Puppet Versionen
voraussetzen.
• Neue Remote Modules können
andere Module erfordern, die nicht
von der installierten Puppet Version
unterstützt werden.

19. Remote modules
• Prüft Puppetfile /
metadata.json in
Hinsicht auf Versionen
• Testet neue Module
vor dem Einsatz auf
Produktivsystemen

20. Wie kann ich meinen
Puppet DSL code testen?

21. Wie kann ich meinen
Puppet DSL code testen?
• Syntax/Semantische Prüfung
• puppet parser validate / puppet-syntax / puppet-lint
• Unit Tests
• rspec-puppet
• Integrations Tests
• beaker, vagrant, serverspec,…

22. Einfacher rspec upgrade
Test

23. Einfacher rspec upgrade
Test
• Fügt spec Tests zu den eigenen Modulen hinzu
• Nutzt rvm oder rbenv um zwischen verschiedenen
Ruby Versionen zu wechseln
• Setzt im Gemfile die zu verwendende Puppet
Version
• Führt spec lokal aus und prüft das Ergebnis

24. Einfacher Puppet upgrade
Test

25. Einfacher Puppet upgrade
Test
• Download des tar Archives, Auspacken
• manueller Start des Puppet Master wahlweise mit
RUBYLIB oder ruby -I auf einem anderen Port (—
masterport 8141)
• Testlauf von einem Node gegen den neuen
PuppetMaster

26. Einfacher Puppet upgrade
Test
Beispiel: zweiter Puppet Master Prozess:
!
tar zxf puppet-3.7.1.tar.gz -C /opt/puppet-3.7.1
!
ruby1.8 -I /opt/puppet-3.7.1/lib /opt/puppet-3.7.1/bin/puppet master
—nodaemonize —masterport=8150 —pidfile=/tmp/puppetmaster.pid
!!
Beispiel: Agent Lauf gegen den zusätzlichen Puppet Master Prozess:
!
puppet agent —test —masterport 8150

27. Demo

28. Puppet 4
• Major update
• Alte (deprecated)
Funktionalität fliegt raus
• Neue Features in Puppet
DSL

29. Puppet 4
• Deprecated in Puppet 4:
• node inheritance - statt dessen sollen roles/profiles verwendet
werden
• Variablen mit Großbuchstaben
• Variablen mit einem Unterstrich an erster Position
• Referenzen auf Klassen wobei die Klasse mit Großbuchstaben
angegeben wird
• Anführungszeichen und Punkte in Namen (Module, Klassen, …)
• Ruby DSL

30. Puppet 4
• Neu in Puppet 4:
• Striktes Namensschema für Variablen und Lookup
(wird in Puppet 5 zwingend)
• Typen Validierung von Variablen
• Boolsche Prüfung (“” -> true anstatt false)
• Environmentpath
• Funktionen in Puppet DSL
• Neue API für Ruby Funktionen

31. Upgrading Puppet
HowTo
!
Thank you.
!
Martin Alfke
<martin.alfke@buero20.org>