I presented these slides at Puppet Camp in London on November 17th and then at our local DevOps meetup in Bristol on November 19th 2014.

1. Puppet & Small
Infrastructures
Rachel Andrew
@rachelandrew

2. edgeofmyseat.com

3. grabaperch.com

4. Why would a small business use
Puppet?

5. • My background
• Learning Puppet and initial challenges
• Our current use of Puppet
• Why Puppet for small businesses with a
handful of servers?

6. This is my job.
• writer
• tech support person
• bookkeeper
• HR
• filler in of baffling
forms from the
government
• PHP developer
• front-end web
developer
• marketer
• sales person
• public speaker
• … ops person.

7. Back in my day …

8. Pre-Puppet
• Infrastructure consisted of a bunch of VPS
boxes hosted at Memset
• Configured at different times
• Some set up by me, some by Drew
• Neither of us understood the setups done by
the other
• No real handle on what was installed where

9. Initial setup would be documented
but configuration would drift over
time as we updated, installed and
fixed things.

10. “If it ain’t broke, don’t fix it”

12. Getting Started with Puppet

13. Puppet or Chef?

14. https://docs.puppetlabs.com/learning/

15. https://puppetlabs.com/learn

16. “By starting small and getting good at
automating one discrete task, you can
establish a foundation for bigger
automation projects.”
http://puppetlabs.com/blog/get-more-agile-learn-how-to-automate-one-small-
thing-with-puppet-enterprise

17. Ideas for small tasks
• cron jobs
• users
• ssh keys
• vhosts
• specific config files -
for example a
common php.ini
• packages or settings
you configure on all
servers as standard

18. Installing
packages
package { "sudo":
ensure => "installed"
}

19. Using Puppet to
create cron jobs.
cron {‘my_cron_job’:
command => "php /home/sites/mysite/public_html/
perch/core/scheduled/run.php secret",
user => root,
minute => [1,31],
}

20. Adding standard
files.
file {'/etc/php5/apache2/php.ini':
ensure => file,
source => 'puppet:///modules/hosting/php.ini',
notify => Service["apache2"],
}

21. Don’t wait until you have time to
rebuild everything. Who ever has
time to rebuild everything?

22. Not Invented Here.

23. Is there an existing, well supported
module that does this job?

24. https://forge.puppetlabs.com/supported

25. Managing Third Party Modules

26. Dependencies will bite you.

27. “Puppet describes the end-state of the
machine, and NOT the order that it’s
(Puppet) going to take you to that
state”
http://garylarizza.com/blog/2014/10/19/on-dependencies-and-order/

28. Where we are now.

29. • A Puppet Master, PuppetDB is on the same
box
• Three webservers
• The “demo server”, also a webserver but of
interesting configuration
• PuppetBoard and Scout to see what is
happening in Puppet and for monitoring

30. Webservers
• Puppetlabs Apache, MySQL
• modules/hosting = a module I’ve written than
wraps up standard things used on webservers
• make use of hiera for site, database and user
values

31. Discovering Hiera made Puppet
make sense to me.

32. A common.yaml
file holds
information
common to all
servers. For
example user
accounts.
---
users:
rachel:
comment: "Rachel Andrew"
shell: "/bin/bash"
home: "/home/rachel"
managehome: "true"
groups: ['admin','www-admin']
drew:
comment: "Drew McLellan"
shell: "/bin/bash"
home: "/home/drew"
managehome: "true"
groups: ['admin','www-admin']
ssh_keys:
rachel_ssh:
user: "rachel"
type: "rsa"
key: "AAAABB[...]"
drew_ssh:
user: "drew"
type: "rsa"
key: "AAAABB[...]"

33. Information
specific to one
server is held in
node specific
YAML files.
eg: vhosts and
MySQL
databases.
---
apache_vhosts:
example.co.uk:
port: '8080'
docroot: '/home/sites/example/public_html'
docroot_group: 'www-admin'
servername: 'example.co.uk'
serveraliases: ['example.com']
test.co.uk:
port: '8080'
docroot: '/home/sites/test/public_html'
docroot_group: 'www-admin'
servername: 'test.co.uk'
serveraliases: ['test.com']
mysql_db:
db_a:
user: 'user_a'
password: 'xxxxx'
grant: ['all']
db_b:
user: 'user_b'
password: 'xxxxx'
grant: ['all']

34. The hiera.yaml
file.
---
:backends:
- yaml
:logger: console
:yaml:
:datadir: /etc/puppet/hiera
:hierarchy:
- "%{::fqdn}"
- common

35. hiera_hash gives
an array of users,
hosts and
databases from
the node specific
YAML.
I can use that in
create_resources
within manifests.
$sites = hiera_hash('apache_vhosts')
create_resources('apache::vhost',$sites)
$db = hiera_hash('mysql_db')
create_resources('mysql::db',$db)

36. “When you come up with a solution
using create_resources(), I challenge
you to draw up another solution using
Puppet code in a Puppet manifest”
http://garylarizza.com/blog/2014/10/24/puppet-workflows-4-using-hiera-in-anger/

37. Hiera and the demo server.

38. Standard CMS demos allow
everyone access to one install
which is “refreshed” periodically.

39. We wanted to give everyone a clean
demo all of their own.

41. Hiera can have
multiple
backends
defined.
Hiera can use
json as well as
YAML.
---
:backends:
- yaml
- json
:logger: console
:yaml:
:datadir: /etc/puppet/hiera
:json:
:datadir: /etc/puppet/hiera
:hierarchy:
- '%{fqdn}'
- common

42. deploy.pp
• create a home directory
• grab the site files tarball and untar into the home directory
• get the relevant SQL dump
• grab the config file and replace out db details
• create a database using the import file
• create a vhost
• execute a script to notify Air Traffic Control the site is
ready

43. • json Hiera backend is the source of truth for
Puppet as to what sites should be running
• could deploy to multiple servers by writing
multiple json files one for each node
• can deploy different versions of Perch - for
example to allow someone to try out a beta
• currently deploying and tearing down 50 or 60
sites per day. It just works.

44. Start small with Puppet, but be
aware of non-obvious problems
that Puppet can help solve.

45. I use Vagrant and Puppet to test
and build the site packages locally.

46. Why should small business and
small infrastructures consider
Puppet?

47. Disaster Recovery

48. Small companies
• often don’t need hugely redundant
infrastructures
• having sites offline for a few hours not critical
• … as long as everything can be restored.

49. Before Puppet
• Rebuilding our infrastructure would have
involved us “trying to remember” what went
where.
• Just getting servers reinstalled would have
taken a long time.
• Then we would have had to reconfigure every
site, every SSH key, one at a time.

50. With Puppet
• Configuration for each server is held in code,
and in an external git repo
• Checkout the modules onto a new Puppet
Master
• Spin up new servers and run Puppet which
would create all resources - sites, keys etc.
• We could then import any data such as MySQL
backups

51. A good test - can you restore any
of your servers into a local VM?

52. How do we do that thing again?

53. Puppet allows us to document
processes by way of manifests.

54. The git commit history gives me
additional information as to why
something is configured that way.

55. Please look after this server.

56. Get an expert up to speed quickly

57. Ensure knowledge isn’t lost when
someone leaves the company

58. Small businesses are often far
more exposed than large ones to
losing knowledge when a key
person leaves.

59. Easier audits and compliance

60. “It is generally acceptable to show the
Puppet modules to the auditor to
demonstrate what settings are
applied to the PCI servers.”
http://blog.bluemalkin.net/pci-compliance-tips-for-sys-admins/

61. Speed of setting up new servers

62. Puppet means I don’t need to spend
time and energy remembering how
to do things on our servers.

63. Moving hosting or to new servers
within a hosting company

64. Getting “stuck” on terrible hosting
is a real issue for small businesses

65. Being Puppetized makes moving
the entire infrastructure seem far
less scary.

66. Modules from the Forge

67. Modules show best practice ways
of achieving tasks.

68. The Puppet Community

69. “We like nice people way better than
mean ones!”
https://docs.puppetlabs.com/community/community_guidelines.html

70. Thank you
http://rachelandrew.co.uk/presentations/puppet
@rachelandrew