Your SlideShare is downloading. ×
0
Baking Wins
Baking Wins
Baking Wins
Baking Wins
Baking Wins
Baking Wins
Baking Wins
Baking Wins
Baking Wins
Baking Wins
Baking Wins
Baking Wins
Baking Wins
Baking Wins
Baking Wins
Baking Wins
Baking Wins
Baking Wins
Baking Wins
Baking Wins
Baking Wins
Baking Wins
Baking Wins
Baking Wins
Baking Wins
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Baking Wins

2,773

Published on

Do you take the time to bake your deployments from scratch to ensure they work reliably, or do you fry them at the risk of something breaking? Using Swipely's open source Docker projects, you can now …

Do you take the time to bake your deployments from scratch to ensure they work reliably, or do you fry them at the risk of something breaking? Using Swipely's open source Docker projects, you can now enjoy the best of both worlds by baking reliable Docker containers in less time than it takes to launch new instances.

Published in: Engineering, Technology
2 Comments
2 Likes
Statistics
Notes
  • Baking refers to statically composing the configuration of the docker image (that's then instantiated as a container). Therefore, one would install and configure all (as many as practical) dependencies needed by an application that's being deployed, as an image, within its own file system. For example, an application requiring secure access would potentially include a ssh server component (executable) within its docker image file system.

    Frying refers to dynamically wiring an application running within a container with the services (a.k.a dependencies) needed to support that application. So in contrast to the baked example mentioned above, an application requiring security services would be devoid of its own ssh server and would need to wire (docker 'link' API) to a running ssh server.

    The essential premise being that baked: statically compiled application images, are much more reliable, greatly improve performance and are much easier to manage than fried applications: dynamically linked containers.

    Of course there's an equilibrium between both approaches. Otherwise, composing solutions with only baking would result in the same fragile, inflexible monolithic mess that container approaches and VMs can be applied to solve. For example, if your applications relied on OpenSSL being baked into your docker image, the docker images statically including this component would have to be changed and recompiled. Also, deployment would necessitate the shutdown and restart of these applications. However, in a fried approach, a solution could be implemented such that only the OpenSSL container would require compilation and restarting, while the other dynamically connected containers would simply rebind to the new OpenSSL container (see docker ambassador pattern).

    One last observation to share: to me, docker is a distributed object orientated programming language where images are analogous to java/c++ classes and containers instantiated objects.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • What do you mean by frying here and what by baking?
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
2,773
On Slideshare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
10
Comments
2
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. B A K I N G W I N S @brightfulton 901 3320 29 03
  • 2. The bake vs. fry debate is over and baking wins
  • 3. THEORY RESOLUTIONPRACTICE
  • 4. THEORY RESOLUTIONPRACTICE Baking makes deployment better
  • 5. GOALS! reliability scalability availability
  • 6. GOALS! reliability scalability availability HURDLES! mutable state startup latency dependencies
  • 7. GOALS! reliability scalability availability HURDLES! mutable state startup latency dependencies SOLUTION! baking
  • 8. The bake vs. fry debate is over and baking wins * *! for some the debate was over long ago
  • 9. The bake vs. fry debate is over and baking wins * *! for some the debate was over long ago
  • 10. THEORY RESOLUTIONPRACTICE Baking improves deployment reliability, scalability, availability
  • 11. THEORY RESOLUTIONPRACTICE But, baking isn’t very fun
  • 12. http://techblog.netflix.com/2013/03/ami-creation-with-aminator.html BAKING TOOLS PRESUME AN ARCHITECTURE Bakery! Aminator! (Asgard)
  • 13. BAKING TOOLS ARE SLOW AND FRAGILE umount: /sysroot/proc: device is busy.
  • 14. THEORY RESOLUTIONPRACTICE Baking proved to be demanding, slow, messy
  • 15. THEORY RESOLUTIONPRACTICE We use Docker to make baking better
  • 16. D O C K E R R E D U C E S T H E O R Y T O P R A C T I C E • single dependency • isolated containers • improved dev / ops interface • fast
  • 17. SWIPELY’S ESSENTIAL INGREDIENTS docker-api: programmatic docker control dockly: declarative package definition aerosol: functional deployment orchestration
  • 18. swipely/docker-api Docker::Image.allGet all images Create an image Docker::Image.create( 'repo' => ‘ubuntu', 'tag' => ‘latest' ) Add file to existing image image.insert_local( 'localPath' => ‘/some/file', 'outputPath' => ‘/other/path' ) Ruby wrapper for Docker Remote API
  • 19. swipely/dockly deb :my_package do package_name 'my_app' ! docker do name 'my_image' import 's3://.../base-image.tar.gz' git_archive '/app' ! build <<-EOF run cd /app && ./configure && make EOF end ! foreman do name 'my_app' log_dir '/data/logs' user 'appuser' end end Declarative DSL for packaging
  • 20. Orchestrates instance-based-deploys swipely/aerosol deploy :production_myapp do ssh :production_myapp auto_scaling :production_myapp stop_command 'sudo stop myapp' live_check '/version' app_port 14000 post_deploy_command 'bundle exec rake honeybadger:deploy TO=production' end ! auto_scaling :production_myapp do availability_zones ['us-east-1a', 'us-east-1b'] min_size 2 max_size 2 launch_configuration :production_myapp tag 'Name' => 'prod-myapp' end
  • 21. D O C K E R R U N I S F A S T container
  • 22. docker do name :my_app import 's3://.../base-image.tar.gz' git_archive '/app' ! build_cache do s3_bucket "my-build-cache-bucket" s3_object_prefix "make/" hash_command "md5deep /app/src” build_command "cd /app && ./configure && make” output_dir "/app/build" use_latest true end end D O C K L Y I S F A S T Granular build caching
  • 23. A E R O S O L I S F A S T v1 v2
  • 24. THEORY RESOLUTIONPRACTICE Docker makes baking clean, simple, fast
  • 25. github.com/swipely! careers.swipely.com @swipelyeng 901 3320 29 03 T H A N K Y O U

×