Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Dev to Delivery with Puppet - PuppetConf 2014

1,087 views

Published on

Dev to Delivery with Puppet - Sam Bashton, Bashton Ltd.

Published in: Technology
  • Be the first to comment

Dev to Delivery with Puppet - PuppetConf 2014

  1. 1. DEV TO DELIVERY WITH PUPPET SAM BASHTON, BASHTON LTD
  2. 2. HOW DID WE GET HERE? Previously: Devs built stuff Later, Ops came and built production infrastructure This caused many IT problems The solution?
  3. 3. OPSVELOPMENT
  4. 4. DEVOPS
  5. 5. WHAT IS DEVOPS REALLY? Devs doing Ops? Ops 'coding' infrastructure? Automating things? Word that recruiters use without understanding anything about it?
  6. 6. WHAT IS DEVOPS? BE EXCELLENT TO EACH OTHER
  7. 7. WHAT DOES THAT MEAN IN PRACTICE?
  8. 8. WHAT IS OPS? Working as part of a team to build a reliable environment
  9. 9. WHAT IS DEV? Working as part of a team to build a reliable environment
  10. 10. BEING GOOD AT DEV Follow 'The Twelve Factor App' - http://12factor.net/
  11. 11. BEING GOOD AT OPS Provide consistency across all environments - including local dev Provide developers the means to understand what is happening Provide as much visibility of everything to everybody
  12. 12. PEP20 'Simple is better than complex' 'Complex is better than complicated' http://legacy.python.org/dev/peps/pep-0020/
  13. 13. PROVIDING VISIBILITY All infrastructure work (Puppet, CloudFormation, etc) should be checked in to a repository available to the whole team (Devs + Ops) Make it easy to see and search logs from all environments Give as many people as possible access to these logs
  14. 14. DEVELOPMENT
  15. 15. WHAT AND WHY? Development environments need to match production as closely as possible Builds confidence that something working in dev will work in production
  16. 16. PUPPET EVERYWHERE Puppet should be used everywhere in the dev and deployment process Production Staging Integration environments Test environments Local dev machines
  17. 17. PUPPET CONFIG DOGMA The same Puppet manifests and modules should be deployable to all environments without any modification
  18. 18. PUPPET CONFIG DOGMA if statements in manifests are a 'bad smell' and should be avoided as much as possible
  19. 19. PUPPET APPLICATION CONFIG DOGMA Separate config files per environment are a 'bad smell' too Avoid manifests that look like below: file { '/etc/nginx/nginx.conf': source => "puppet:///localmodules/data/nginx/${hostname}.conf", } Make it easy to 'miss' replicating things between environments, or make mistakes
  20. 20. VAGRANT Builds virtual machines from Puppet manifests Makes it easy to spin up short-lived dev instances Quick to get working Avoid ops being a blocker for dev
  21. 21. VAGRANT + DOCKER Reduce dev environment spin-up time Docker makes it easier to create more realistic environments Docker images for drop-in use with Vagrant available: https://github.com/BashtonLtd/docker-vagrant-images
  22. 22. BETTER MATCH LIVE ENVIRONMENTS
  23. 23. ONE SET OF MANIFESTS, MANY ENVIRONMENTS Different environments need different config Resource locations Settings
  24. 24. DEALING WITH DIFFERING ENVIRONMENTS Hiera Allows separation of logic from data Put anything that differers by environment in a separate file Combine with custom facts
  25. 25. HIERA.YAML :hierarchy: - env/%{envname} - services/%{service} - common
  26. 26. CUSTOM FACTS IN VAGRANT config.vm.provision :puppet do |puppet| puppet.manifests_path = "puppet/manifests" puppet.manifest_file = "site.pp" puppet.module_path = ["puppet/localmodules","puppet/modules"] puppet.hiera_config_path = "puppet/hiera.yaml" puppet.facter = { "envname" => "vagrant", "service" => "web", } end
  27. 27. CUSTOM FACTS ON MACHINES Drop a file into /etc/facter/facts.d service=web envname=stage
  28. 28. HIERA IN ACTION env/vagrant.yaml: web::hostname: vagrantdev.local env/stage.yaml: web::hostname: stage.example.com
  29. 29. HIERA IN ACTION common.yaml: postfix::server::relayhost: '[mailtrap.io]:2525' env/live.yaml: postfix::server::relayhost: 'email-smtp.eu-west-1.amazonaws.com:587'
  30. 30. PRODUCTION
  31. 31. 'WORKED IN DEV' Devs and ops need the right data to be able to debug If only ops have access the the data, how much can devs really help?
  32. 32. PROVIDING VISIBILITY Metrics and Service Health Logging Dashboards
  33. 33. METRICS AND SERVICE HEALTH Sensu Health checks Collection of statistics and export to Graphite
  34. 34. CENTRALISED LOGGING Variety of approaches available Logstash Graylog2
  35. 35. GRAYLOG2 Simple to get up and running Puppet module available: https://forge.puppetlabs.com/graylog2/graylog2
  36. 36. VISIBILITY Dashboards show (near) realtime metrics let everyone see the current state of the system Don't just include system data - business metrics add context

×