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?") |
PaulJulius (talk | contribs) (Initial adds from the session) |
||
Line 1: | Line 1: | ||
− | + | 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)