Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Can you upgrade to Puppet 4.x?

1.748 Aufrufe

Veröffentlicht am

PuppetCamp London fall 2014
Martin Alfke - Can you upgrade to Puppet 4.x?

My talk at PuppetCamp London 2014 taking care on best practices and bad examples and an outlook to Puppet 4.

Veröffentlicht in: Internet
  • Als Erste(r) kommentieren

Can you upgrade to Puppet 4.x?

  1. 1. Can you upgrade to Puppet 4.x? PuppetCamp London Martin Alfke <martin.alfke@buero20.org>
  2. 2. Agenda • Why upgrading at all? • Is your code still working? • How to upgrading Puppet? • What brings Puppet 4?
  3. 3. About me • Martin Alfke • Berlin/Germany • Freelancer / Trainer • PuppetLabs Training Partner • Puppet User Group Berlin
  4. 4. Poll ! ! • Using Puppet 2.x?
  5. 5. Poll ! ! • Using Puppet 2.x? • Using Puppet 3.x?
  6. 6. Why do I need to bother? • Fast releases • Best Practices • Changing functionality • Removing deprecated stuff • Puppet 4 is coming
  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. Is my Puppet DSL code still working on new versions? • Your code was developed some years ago and is still running unmodified • Your code was written on old best practices and does not follow new style guide • You do not check your Puppet runs for deprecation warnings (or do you?)
  9. 9. What to look for?
  10. 10. BAD Best practice • Do you inherit from inherited classes? • Do you still use import? • Do you modify remote modules? • Do you access non-local variables without scope names?
  11. 11. BAD Best practice Stop doing multiple levels of inheritance ! class foo { } ! class foo::bar inherits foo { } ! class foo::baz inherits foo::bar { } ! class foo::foobar inherits foo::baz { }
  12. 12. BAD Best practice Stop doing inheritance ! class foo { } ! class foo::bar inherits foo { } ! class foo::baz inherits foo { } ! class foo::foobar inherits foo { }
  13. 13. Best practice Restrict Inheritance ! In most cases you can use parameterised classes instead. Only one kind of inheritance is proven good practice: inherit from module params.pp ! class ssh ( $server = $ssh::params::server, $client = $ssh::params::client, $x11fwd = false, ) inherits ssh::params { } ! class { ::ssh::params:: server => false, x11fwd => true, } BETTER
  14. 14. BAD Best practice Stop importing ! # ssh/manifests/init.pp class ssh { import ‘server.pp’ } ! # ssh/manifests/server.pp class ssh::secure { } ! # ssh/manifests/secure.pp class ssh::secure { } ! Which class ssh::secure will be used?
  15. 15. Best practice Use include ! In most cases you can make use of the puppet autoloader and you can use include. ! # ssh/manifests/init.pp class ssh { include ::ssh::server } BETTER ! # ssh/manifests/server.pp class ssh::server { } !
  16. 16. BAD Best practice Stop modifying remote modules ! Take “remote modules” as a software provided by others. Are you also patching apache?
  17. 17. Best practice Co-Work on remote modules ! Do a PR if you want improvements. ! Keep your remote modules upgradeable. BETTER
  18. 18. BAD Best practice Stop using non-local variables without scope ! class ssh ( $server = ‘baz’ ) { } ! class ssh::server { notify { $server: } }
  19. 19. Best practice Start using non-local variables with scope ! class ssh ( $server = true ) { } ! class ssh::server { notify { $ssh::server: } } BETTER
  20. 20. BAD Best practice Stop using un-scoped variables in templates !! key = <%= server %> ! ! !
  21. 21. Best practice Start using scoped variables in templates !! BETTER key = <%= @server %> ! or ! key = <%= scope.lookupvar(‘ssh::server’) %> ! or ! key = <%= scope[‘ssh::server’]
  22. 22. BAD Best practice Stop using factor variables without top-scope ! class ssh { notify { “We are on OS: $operatingsystem”: } } ! class ssh::server { if $is_virtual { notify { “We are running on $virtual virtualisation”: } } else { notify { “We are running on hardware: $productname”: } }
  23. 23. Best practice Start using factor variables with top-scope ! class ssh { notify { “We are on OS: ${::operatingsystem}”: } } ! class ssh::server { if $::is_virtual { notify { “We are running on ${::virtual} virtualisation”: } } else { notify { “We are running on hardware: ${::productname}”: } } BETTER
  24. 24. BAD Best practice Stop not doing data validation ! class ssh ( $server = hiera(‘server’, ‘localhost’) ){ notify { “We will use Server: ${server}”: } } !
  25. 25. Best practice BETTER Start doing data validation ! class ssh ( $server = hiera(‘server’, ‘localhost’) ){ # validate_string is a function from stdlib validate_string($server) notify { “We will use Server: ${server}”: } } !
  26. 26. Remote modules • Do foreign modules support your version? • Newer Puppet versions have new function attributes (arity) • New foreign module versions might need newer modules not supported by your Puppet version
  27. 27. Remote modules • Check Puppetfile / metadata.json for requirements • Test prior upgrading in production
  28. 28. How can I test my actual Puppet DSL code?
  29. 29. How can I test my actual Puppet DSL code? • Syntax/Semantic check • puppet parser validate / puppet-syntax / puppet-lint • Unit test • rspec-puppet • Integration test • beaker, vagrant, serverspec,…
  30. 30. Simple rspec upgrade check
  31. 31. Simple rspec upgrade check • Add rspec tests to all your modules and run them locally • Use rvm or rbenv to choose between ruby versions • Provide puppet version to verify in Gemfile • Run spec tests locally and verify results
  32. 32. Automatic rspec upgrade check
  33. 33. Automatic rspec upgrade check • Install a CI-Server (Jenkins, GO, Teamcity,…) and add build steps • Add git commit hooks to identify changes in repositories • Run rspec tests automatically
  34. 34. Simple Puppet upgrade test
  35. 35. Simple Puppet upgrade test • Install Puppet tarball in a separate directory on your master • Start puppet master manually using RUBYLIB or ruby -I on another port (—masterport 8141) • Test run from a single node with —noop against the new port
  36. 36. Simple Puppet upgrade test Example: additional Puppet Master process: ! 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 !! Example: Agent run against additional Puppet Master process: ! puppet agent —test —masterport 8150
  37. 37. Demo
  38. 38. Puppet 4 • Major update • Removes deprecated functionality • New language features
  39. 39. Puppet 4 • Deprecated in Puppet 4: • node inheritance - use roles/profiles instead • upper case variable names • variable with underscore in first position • references to classes using upper case name/title • hypens and periods in names • Ruby DSL
  40. 40. Puppet 4 • New in Puppet 4: • Strict variable naming and lookup (will become mandatory in Puppet 5) • Variable type validation • Boolean conversion (“” -> true instead of false) • Environmentpath • Functions in Puppet • New function API
  41. 41. Puppet 4 • Further reading • https://github.com/puppetlabs/puppet-specifications • http://puppet-on-the-edge.blogspot.co.uk/
  42. 42. You can upgrade to Puppet 4.x! ! Thank you. ! Martin Alfke <martin.alfke@buero20.org>

×