Die Präsentation von Martin Alfke bei PuppetCamp in Düsseldorf thematisiert die Notwendigkeit und die Vorgehensweise beim Upgrade von Puppet, einschließlich der Vorteile neuer Funktionen, Sicherheitsupdates und Best Practices. Besondere Aufmerksamkeit gilt der Kompatibilität des alten Puppet DSL Codes mit der neuen Version und der Notwendigkeit, Best Practices zu befolgen, um die Upgradefähigkeit von Modulen zu gewährleisten. Zukünftige Änderungen in Puppet 4 werden ebenfalls angesprochen, darunter die Abschaffung veralteter Funktionen und die Einführung neuer Features.

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>