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.

Can you upgrade to Puppet 4.x?

1 796 vues

Publié le

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.

Publié dans : Internet
  • Login to see the comments

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>

×