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.

1. Can you upgrade to
Puppet 4.x?
PuppetCamp London
Martin Alfke
<martin.alfke@buero20.org>

2. Agenda
• Why upgrading at all?
• Is your code still working?
• How to upgrading Puppet?
• What brings Puppet 4?

3. About me
• Martin Alfke
• Berlin/Germany
• Freelancer / Trainer
• PuppetLabs Training Partner
• Puppet User Group Berlin

4. Poll
!
!
• Using Puppet 2.x?

5. Poll
!
!
• Using Puppet 2.x?
• Using Puppet 3.x?

6. Why do I need to bother?
• Fast releases
• Best Practices
• Changing functionality
• Removing deprecated stuff
• Puppet 4 is coming

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. 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. What to look for?

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. 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. BAD
Best practice
Stop doing inheritance
!
class foo {
}
!
class foo::bar inherits foo {
}
!
class foo::baz inherits foo {
}
!
class foo::foobar inherits foo {
}

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. 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. 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. BAD
Best practice
Stop modifying remote modules
!
Take “remote modules” as a software
provided by others.
Are you also patching apache?

17. Best practice
Co-Work on remote
modules
!
Do a PR if you want
improvements.
!
Keep your remote modules
upgradeable.
BETTER

18. BAD
Best practice
Stop using non-local variables
without scope
!
class ssh (
$server = ‘baz’
) {
}
!
class ssh::server {
notify { $server: }
}

19. Best practice
Start using non-local variables with
scope
!
class ssh (
$server = true
) {
}
!
class ssh::server {
notify { $ssh::server: }
}
BETTER

20. BAD
Best practice
Stop using un-scoped variables
in templates
!!
key = <%= server %>
!
!
!

21. Best practice
Start using scoped variables in
templates
!!
BETTER
key = <%= @server %>
!
or
!
key = <%= scope.lookupvar(‘ssh::server’) %>
!
or
!
key = <%= scope[‘ssh::server’]

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. 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. BAD
Best practice
Stop not doing data validation
!
class ssh (
$server = hiera(‘server’, ‘localhost’)
){
notify { “We will use Server: ${server}”: }
}
!

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. 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. Remote modules
• Check Puppetfile /
metadata.json for
requirements
• Test prior upgrading in
production

28. How can I test my actual
Puppet DSL code?

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. Simple rspec upgrade check

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. Automatic rspec upgrade
check

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. Simple Puppet upgrade test

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. 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. Demo

38. Puppet 4
• Major update
• Removes deprecated
functionality
• New language features

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. 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. Puppet 4
• Further reading
• https://github.com/puppetlabs/puppet-specifications
• http://puppet-on-the-edge.blogspot.co.uk/

43. You can upgrade to
Puppet 4.x!
!
Thank you.
!
Martin Alfke
<martin.alfke@buero20.org>