Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Upgrading Puppet CommitterConf Essen 2014

621 views

Published on

How to Upgrading Puppet
Best practices
Testing new Puppet Master version

Published in: Internet
  • Be the first to comment

  • Be the first to like this

Upgrading Puppet CommitterConf Essen 2014

  1. 1. Upgrading Puppet HowTo PuppetCamp Düsseldorf Martin Alfke <martin.alfke@buero20.org>
  2. 2. Wer • Martin Alfke • Berlin • Freelancer / Trainer • Puppet @ Linuxhotel • Puppet User Group Berlin
  3. 3. Poll ! ! • Puppet 2.x?
  4. 4. Poll ! ! • Puppet 2.x? • Puppet 3.x?
  5. 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. 6. Warum upgraden? • Sehr schneller Release Zyklus • Best Practices • Neue oder geänderte Funktionalität • Endlich fallen alte Sachen raus • Puppet 4 kommt!
  7. 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. 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. 9. Worauf muss man achten?
  10. 10. BAD Best practice • Multiple Vererbung (inherits) • Verwendung von import • Modifizieren von Remote Modules • Benutzung von Variablen ohne Angabe des Scopes
  11. 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. 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. 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. 14. Best practice Setze beim Verwenden von Variablen den Scope. ! class ssh ( $server ) { } ! class ssh::server { notify { $ssh::server: } } BETTER
  15. 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. 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. 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. 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. 19. Remote modules • Prüft Puppetfile / metadata.json in Hinsicht auf Versionen • Testet neue Module vor dem Einsatz auf Produktivsystemen
  20. 20. Wie kann ich meinen Puppet DSL code testen?
  21. 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. 22. Einfacher rspec upgrade Test
  23. 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. 24. Einfacher Puppet upgrade Test
  25. 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. 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. 27. Demo
  28. 28. Puppet 4 • Major update • Alte (deprecated) Funktionalität fliegt raus • Neue Features in Puppet DSL
  29. 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. 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. 31. Upgrading Puppet HowTo ! Thank you. ! Martin Alfke <martin.alfke@buero20.org>

×