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.

Deployment - Done Right!

1,178 views

Published on

There are many different deployment options - package managers, tools like Chef or Puppet, PaaS and orchestration tools. This presentation give an overview of these tools and approaches like idempotent installation or immutable server.
Held at Continuous Lifecycle 2016

Published in: Software
  • Be the first to comment

Deployment - Done Right!

  1. 1. Deployment – Done Right! Eberhard Wolff @ewolff Fellow
  2. 2. http://continuous-delivery-buch.de/
  3. 3. http://microservices-buch.de/ http://microservices-book.com/
  4. 4. http://microservices-book.com/primer.html FREE!!!!
  5. 5. Why This Talk? > Numerous technologies > Deployment: pretty old problem > High productivity gains possible > Microservices: A lot more to deploy
  6. 6. Why This Talk? > Easier deployment = easier to change software > Goal of software architecture > Dev moving towards DevOps > Infrastructure as Code > i.e. deployment becomes part of software architecture
  7. 7. Package Manager Configuration Tools Docker PaaS Orchestration
  8. 8. Package Managers
  9. 9. Package Manager > Simple format > Easy to distribute to many servers > Packages software > Defines dependencies > Can also run scripts > Can also include configurations
  10. 10. Configuration (scripts?) Application Package (WAR) Tomcat Dependency Dependency
  11. 11. Package Manager: Challenges > Usually depend on OS and Linux distro > deb for Debian, msi for Windows etc. > What if the installation aborts? > What if the system is inconsistent? > Dependencies might cause problems
  12. 12. Package Manager: Challenges > No ideal tool for configuration > Manual changes might be needed > Systems might become inconsistent > What about wiring the hosts together?
  13. 13. Package Managers are widely used
  14. 14. Package Managers are widely used …and only a part of the full solution
  15. 15. Nix > Runs on Linux and Mac OS X > Declarative approach: Define desired state > Atomic upgrades and rollbacks > Rollbacks enable experiments > Fixes some issues
  16. 16. Ubuntu Snappy / Flatpak > Package application with all libraries > …instead of defining dependencies > Applications are portable across distros > Enables rollbacks… > ...independent updates of distro and app
  17. 17. Ubuntu Snappy / Flatpak > Packaging is all about dependencies > Basically no packages and dependencies any more > Self-contained like Docker images
  18. 18. What we still need…
  19. 19. > Configuration > Updates? Rollbacks? > Make sure installation was successful
  20. 20. Configuration > Templates > Configuration database catalogs servers > E.g. add web servers to load balancer
  21. 21. > Configuration > Updates? Rollbacks? > Make sure installation was successful
  22. 22. Idempotency > Idea: Start installation as often as you like > …result is the same > First run on fresh system: install everything > Run directly afterwards: Do nothing
  23. 23. Idempotency > Configuration describes desired state > Updates become trivial
  24. 24. Idempotency > Not: Install this package! > But: This package should be installed > Package already Installed do nothing > Package not installed install > Not: Create this file! > But: File should look like this.
  25. 25. > Configuration > Updates? Rollbacks? > Make sure installation was successful
  26. 26. Chef > Idempotent > Templates for configuration > Centralized server to store information
  27. 27. Similar Tools
  28. 28. Configuration (template) Recipe: Application Package (WAR) Recipe: Tomcat Dependency Dependency Package
  29. 29. Idempotency: Challenges > Configuration complex > No simple script > …but description of desired state
  30. 30. Idempotency: Challenges > Not described? Won’t be “repaired” > Servers are updated stepwise > …not from scratch > Not every starting point might work > Really reproducible?
  31. 31. Why Updates??
  32. 32. Checkout V1 Checkout V2
  33. 33. Checkout V1 Load Balancer Database Checkout V2
  34. 34. Pet or Cattle? Update Replace
  35. 35. No more updates!
  36. 36. Immutable Server > Never change a server > Never update a server > Always install from scratch > Fully and reliably reproducible > Very simple concept > i.e. no sophisticated tools
  37. 37. Immutable Server seem like a lot of overhead – how could they work?
  38. 38. Application Deployment > Install operating system > Install Tomcat > Change configuration files > Add application Volatile Stable Easy to write a script
  39. 39. Docker = Simple Deployment > Dockerfile > Just a shell script > Installation from scratch > Behind the scenes: Optimization > Every Dockerfile line = filesystem snapshot > Reuse snapshots for all other Dockerfiles
  40. 40. Docker Filesystem > Each installation steps creates a file system snapshot > Read go through all layers in order Ubuntu Tomcat Configuration Applicationread
  41. 41. Docker Filesystem > Rerun installation > Nothing happens > Everything is cached Ubuntu Tomcat Configuration Application
  42. 42. Docker Filesystem > Application changes > Just last layer recreated > …which is needed anyway Ubuntu Tomcat Configuration ApplicationApplication V2
  43. 43. You could use Chef + Docker
  44. 44. You could use Chef + Docker …but why?
  45. 45. Chef... might be useful to deploy Docker hosts.
  46. 46. You think you are creating a server from scratch…
  47. 47. You think you are creating a server from scratch… ...but everything is cached
  48. 48. Why care about servers?
  49. 49. Why Care About Server? > Applications are what provides value > Standardize environment > …and deploy application on the environment
  50. 50. Issues With PaaS > Standardized infrastructure > Not flexible > Hard to migrate existing applications > Installing PaaS on premise hard > Enterprise=On-Premise > Huge success for apps in the Public Cloud
  51. 51. On Premise Public Cloud Amazon Elastic Beanstalk
  52. 52. Orchestration
  53. 53. Checkout Search BrowsingInvoicing Load Balancer Database Individual Boxes Orchestration
  54. 54. Orchestration > Deploy many machines > Create network > Support many different offerings > E.g. PaaS, Docker, IaaS…
  55. 55. Terraform > Infrastructure e.g. cloud, virtualization > PaaS > Network > SaaS (DNS, CDN) > Similar: Amazon Cloud Formation
  56. 56. Docker Compose > Coordinate many containers > Define containers… > ...and networking > Might use Docker Swarm for cluster > Limited to Docker, though
  57. 57. Kubernetes > Pods: Wired Docker containers > Service discovery > Configuration > Load balancing > Limited to Docker
  58. 58. Conclusion
  59. 59. Package Managers Well established Can deploy large server farms Updates? Configuration? New approaches are self-contained and enable rollbacks
  60. 60. Idempotent Tools Updates Configuration / templates Book keeping of servers Truly reproducible? Complex? Updates = pets = anti-pattern
  61. 61. Docker Enable immutable server Simple scripts Tools for coordination New infrastructure (e.g. Kubernetes) Updates = pets = anti-pattern
  62. 62. Orchestration > Needed to create the rest of the environment > Terraform > …or a Docker tool
  63. 63. EMail conli2016@ewolff.com to get: Slides + Microservices Primer + Sample Microservices Book + Sample of Continuous Delivery Book Powered by Amazon Lambda & Microservices

×