Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Cloud Foundry Summit 2015: 12 Factor Apps For Operations

1.175 Aufrufe

Veröffentlicht am

Speakers: Rags Srini­vas, EMC; Matt Cowger, EMC

To learn more about Pivotal Cloud Foundry, visit http:///www.pivotal.io/platform-a-as-a-service/pivotal-cloud-foundry.

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

Cloud Foundry Summit 2015: 12 Factor Apps For Operations

  1. 1. 12 Factor Apps for Operations rags srinivas (@ragss) matt cowger (@mcowger)
  2. 2. #1: Codebase • Everything in revision control • Including environment configuration
  3. 3. I didn't change anything! — every. developer. ever.
  4. 4. Well the environment didn't change! — every. ops. person. ever.
  5. 5. Revision Control -> git blame (svn blame if you must)
  6. 6. #2: Dependencies • Dependencies must be explicitly declared • They should be declared with the rest of the code, and tracked the same way • Dependencies tracking should contain version numbers of dependencies
  7. 7. #3: Config • Config belongs in the environment if possible - it varies between deploys, but the code doesn't • Includes access credentials, logging config, etc. • Should be read at runtime, not preprocessed into code.
  8. 8. • Only people with access to host & account can see creds • Creds can be specific (maybe avoid shared accounts!) • Now everyone knows the live config, all the time, and be sure code is using it. • Less danger of having critical file stolen/checked in
  9. 9. #4: Backing Services • Anything your application uses as a resource (database, queueing system, email, cache) should be referenced with 'bindings' to these services. • All applications deployed with explicit declarative references ( as in manifest.yml) • Avoid implicit references (User Provided Services)
  10. 10. #5: Build Release Run • Build, Release and Run are separate stages for the application life cycle. • Version everything • Use profiles • Blue/Green Deployments are a rule, not an exception.
  11. 11. #6: Processes • Seperation of concerns - each microservice is a single process • Instances of running code to be stateless - certain exceptions apply • This makes apps more resilient, and easier to recover • Categorize processes into Stateful and Stateless
  12. 12. #7: Port Binding • Export services via port binding • For instance HTTP is exported as a service via port binding and not injected at run time. • The ultimate goal is to be able to horizontally scale.
  13. 13. #8: Concurrency • An extension of # 6 above. • An implication to scale out. • Not necessarily required for certain aspects (single process workers, etc)
  14. 14. #9: Disposability • Losing a process should be a normal event • No loss of state for user if we lose a process • Startup times should be low • Platforms can adapt to errant processes and self heal if required.
  15. 15. #10: Dev / Prod Parity • Dev MUST == Production in config, but not performance • Following the above helps do this
  16. 16. #11: Logs • Log everything • Storage is cheap • Searching is cheap • Logs help fix problems after they happen • Use tokens for specific flows
  17. 17. Measure/Monitor Everything
  18. 18. #12: Admin Processes • Use your app/framework for these... build in the tools as needed. • Don’t run updates directly against a database • Don’t run them from a local terminal window • ChatOps can help here Importances: Moderate. Helps prevent mistakes
  19. 19. 6 Laws of Systems that never stop • Isolation • Concurrency • Failure Detection • Fault Identification • Live Code Upgrade • Stable Storage http://www.infoq.com/presentations/Systems-that-Never-Stop-
  20. 20. More Resources • Pivotal Podcasts: Episode 23 (Operational transformation) • You Build it, you run it - an interview with Werner Vogels • This presentation

×