Difference between revisions of "Continuous Delivery with Puppet - what is missing?"

From CitconWiki
Jump to navigationJump to search
(Created page with "Andy: Who is using Continuous Deployment?")
 
(Initial adds from the session)
 
Line 1: Line 1:
Andy: Who is using Continuous Deployment?
+
We met in Meeting Room One (with standing room only!).
 +
 
 +
[[Andrew_Parker]] kicked off with  "Who is using Continuous Deployment"?
 +
 
 +
==Andy wrote on the chalkboard==
 +
* Drift from management config
 +
* Systems not designed for component management
 +
* Simplify
 +
* SE Practices
 +
* Clear vision
 +
* Case studies
 +
* Dist systems too hard
 +
 
 +
==Issues Discussed Related to Using Puppet for Continuous Deployment==
 +
* Just removing something from the manifest, doesn't mean that it will be removed from the server
 +
* Drift from management configuration
 +
* Keep all possible environments in one repository, don't use branches and cherry-pick.
 +
* The number one thing that PuppetLabs could do would be to be clear about how these tools should be used...Active Evangelism. The conversation [in the industry] today is dominated by people who see it as an alternative to scripting
 +
* Tools like Puppet are able to incorporate everything we have learned about answering difficult questions like "Has a service started?"
 +
* One problem that caused swearing, according to Squirrel, knowing which Puppet Modules are being deployed
 +
* Dry run is only partially good in Puppet, because the runtime behavior may change
 +
* Don't do multiple systems in one PuppetMaster
 +
* Do Puppet masterless, run Puppet apply
 +
* Consider packing everything up into an archive so that the Puppet scripts live with the application. Put all the scripts
 +
* 3 models with Puppet
 +
** Standalone
 +
** Multiple Puppet Masters - one for each environment
 +
** "Environments" in a Puppet Master - which DOESN'T work
 +
* When going headless, use Hiera to hold environment specific variables
 +
** Supports GPG encryption for "secret" stuff
 +
* How do you handle use cases like "Developers cannot have access to Production"
 +
** Sounds like a concern outside of puppet
 +
** Can use different repositories
 +
** Could use Hiera with different keys
 +
 
 +
==General Notes Not Related Specifically to Using Puppet==
 +
* Don't let your development team create software that requires OS installs
 +
* Some teams like to use another tool called [http://www.ansibleworks.com Ansible]
 +
* JTF likes starting from a clean VM every time
 +
* Companies like Netflix create a base AMI and then use that AMI across environments, like Staging, Development, Production
 +
* Simplify...use tools like Puppet for what they do well, but as soon as your pipeline becomes too complex, simplify
 +
* Infrastructure management comes from a different background than design/development. As soon as you start treating "infrastructure as code", design principles apply.
 +
* The Difference Between Scripting vs. State Propagation
 +
** In scripting, order is important
 +
** Scripts must check for themselves if a service is running
 +
** Tools like Puppet allow one to imply that a service is running, and the tool decides how to handle it.
 +
*** Similar to the way a version control system [GIT was used as the example] decides whether or not to pull anything down, or push anything up
 +
** State assertions make the system far more module
 +
* Distributed logic is hard. Why would you create autonomous distributed logic if you don't have to.
 +
* Look at [http://infrastructures.org] for a wealth of information
 +
* Software is not convergent any more
 +
* MCollective used for distributed system management
 +
 
 +
==Final Statements==
 +
* Look for ways to remove complexity!
 +
* Most big Puppet installs move to Masterless Puppet (using Ansible to control it because Ansible includes functionality like mCollective)

Latest revision as of 03:20, 28 September 2013

We met in Meeting Room One (with standing room only!).

Andrew_Parker kicked off with "Who is using Continuous Deployment"?

Andy wrote on the chalkboard

  • Drift from management config
  • Systems not designed for component management
  • Simplify
  • SE Practices
  • Clear vision
  • Case studies
  • Dist systems too hard

Issues Discussed Related to Using Puppet for Continuous Deployment

  • Just removing something from the manifest, doesn't mean that it will be removed from the server
  • Drift from management configuration
  • Keep all possible environments in one repository, don't use branches and cherry-pick.
  • The number one thing that PuppetLabs could do would be to be clear about how these tools should be used...Active Evangelism. The conversation [in the industry] today is dominated by people who see it as an alternative to scripting
  • Tools like Puppet are able to incorporate everything we have learned about answering difficult questions like "Has a service started?"
  • One problem that caused swearing, according to Squirrel, knowing which Puppet Modules are being deployed
  • Dry run is only partially good in Puppet, because the runtime behavior may change
  • Don't do multiple systems in one PuppetMaster
  • Do Puppet masterless, run Puppet apply
  • Consider packing everything up into an archive so that the Puppet scripts live with the application. Put all the scripts
  • 3 models with Puppet
    • Standalone
    • Multiple Puppet Masters - one for each environment
    • "Environments" in a Puppet Master - which DOESN'T work
  • When going headless, use Hiera to hold environment specific variables
    • Supports GPG encryption for "secret" stuff
  • How do you handle use cases like "Developers cannot have access to Production"
    • Sounds like a concern outside of puppet
    • Can use different repositories
    • Could use Hiera with different keys

General Notes Not Related Specifically to Using Puppet

  • Don't let your development team create software that requires OS installs
  • Some teams like to use another tool called Ansible
  • JTF likes starting from a clean VM every time
  • Companies like Netflix create a base AMI and then use that AMI across environments, like Staging, Development, Production
  • Simplify...use tools like Puppet for what they do well, but as soon as your pipeline becomes too complex, simplify
  • Infrastructure management comes from a different background than design/development. As soon as you start treating "infrastructure as code", design principles apply.
  • The Difference Between Scripting vs. State Propagation
    • In scripting, order is important
    • Scripts must check for themselves if a service is running
    • Tools like Puppet allow one to imply that a service is running, and the tool decides how to handle it.
      • Similar to the way a version control system [GIT was used as the example] decides whether or not to pull anything down, or push anything up
    • State assertions make the system far more module
  • Distributed logic is hard. Why would you create autonomous distributed logic if you don't have to.
  • Look at [1] for a wealth of information
  • Software is not convergent any more
  • MCollective used for distributed system management

Final Statements

  • Look for ways to remove complexity!
  • Most big Puppet installs move to Masterless Puppet (using Ansible to control it because Ansible includes functionality like mCollective)