Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Upgrading Puppet CommitterConf Essen 2014

760 vues

Publié le

How to Upgrading Puppet
Best practices
Testing new Puppet Master version

Publié dans : Internet
  • Login to see the comments

  • Soyez le premier à aimer ceci

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>

×