diff --git a/slides/containers/Docker_Overview.md b/slides/containers/Docker_Overview.md index cea7948c..34c2c6e8 100644 --- a/slides/containers/Docker_Overview.md +++ b/slides/containers/Docker_Overview.md @@ -1,136 +1,11 @@ -# Docker 30,000ft overview +# Why Docker? -In this lesson, we will learn about: +The original "Docker pitch" (back in 2013!) made a lot of comparisons +with the shipping industry, and its transformation thanks to +the *intermodal shipping container.* -* Why containers (non-technical elevator pitch) - -* Why containers (technical elevator pitch) - -* How Docker helps us to build, ship, and run - -* The history of containers - -We won't actually run Docker or containers in this chapter (yet!). - -Don't worry, we will get to that fast enough! - ---- - -## Elevator pitch - -### (for your manager, your boss...) - ---- - -## OK... Why the buzz around containers? - -* The software industry has changed - -* Before: - * monolithic applications - * long development cycles - * single environment - * slowly scaling up - -* Now: - * decoupled services - * fast, iterative improvements - * multiple environments - * quickly scaling out - ---- - -## Deployment becomes very complex - -* Many different stacks: - * languages - * frameworks - * databases - -* Many different targets: - * individual development environments - * pre-production, QA, staging... - * production: on prem, cloud, hybrid - ---- - -class: pic - -## The deployment problem - -![problem](images/shipping-software-problem.png) - ---- - -class: pic - -## The matrix from hell - -![matrix](images/shipping-matrix-from-hell.png) - ---- - -class: pic - -## The parallel with the shipping industry - -![history](images/shipping-industry-problem.png) - ---- - -class: pic - -## Intermodal shipping containers - -![shipping](images/shipping-industry-solution.png) - ---- - -class: pic - -## A new shipping ecosystem - -![shipeco](images/shipping-indsutry-results.png) - ---- - -class: pic - -## A shipping container system for applications - -![shipapp](images/shipping-software-solution.png) - ---- - -class: pic - -## Eliminate the matrix from hell - -![elimatrix](images/shipping-matrix-solved.png) - ---- - -## Results - -* [Dev-to-prod reduced from 9 months to 15 minutes (ING)]( - https://gallant-turing-d0d520.netlify.com/docker-case-studies/CS_ING_01.25.2015_1.pdf) - -* [Continuous integration job time reduced by more than 60% (BBC)]( - https://gallant-turing-d0d520.netlify.com/docker-case-studies/CS_BBCNews_01.25.2015_1.pdf) - -* [Deploy 100 times a day instead of once a week (GILT)]( - https://gallant-turing-d0d520.netlify.com/docker-case-studies/CS_Gilt_Groupe_03.18.2015_0.pdf) - -* [70% infrastructure consolidation (MetLife)]( - https://www.youtube.com/watch?v=Bwt3xigvlj0) - -* etc. - ---- - -## Elevator pitch - -### (for your fellow devs and ops) +More than a decade later... Why is Docker still relevant, and +what are we using it for? --- @@ -162,7 +37,7 @@ Never again "worked in dev - ops problem now!" ```bash git clone ... -docker-compose up +docker compose up ``` With this, you can create development, integration, QA environments in minutes! @@ -209,109 +84,6 @@ Images contain all the libraries, dependencies, etc. needed to run the app. class: extra-details -## Decouple "plumbing" from application logic - -1. Write your code to connect to named services ("db", "api"...) - -2. Use Compose to start your stack - -3. Docker will setup per-container DNS resolver for those names - -4. You can now scale, add load balancers, replication ... without changing your code - -Note: this is not covered in this intro level workshop! - ---- - -class: extra-details - -## What did Docker bring to the table? - -### Docker before/after - ---- - -class: extra-details - -## Formats and APIs, before Docker - -* No standardized exchange format. -
(No, a rootfs tarball is *not* a format!) - -* Containers are hard to use for developers. -
(Where's the equivalent of `docker run debian`?) - -* As a result, they are *hidden* from the end users. - -* No re-usable components, APIs, tools. -
(At best: VM abstractions, e.g. libvirt.) - -Analogy: - -* Shipping containers are not just steel boxes. -* They are steel boxes that are a standard size, with the same hooks and holes. - ---- - -class: extra-details - -## Formats and APIs, after Docker - -* Standardize the container format, because containers were not portable. - -* Make containers easy to use for developers. - -* Emphasis on re-usable components, APIs, ecosystem of standard tools. - -* Improvement over ad-hoc, in-house, specific tools. - ---- - -class: extra-details - -## Shipping, before Docker - -* Ship packages: deb, rpm, gem, jar, homebrew... - -* Dependency hell. - -* "Works on my machine." - -* Base deployment often done from scratch (debootstrap...) and unreliable. - ---- - -class: extra-details - -## Shipping, after Docker - -* Ship container images with all their dependencies. - -* Images are bigger, but they are broken down into layers. - -* Only ship layers that have changed. - -* Save disk, network, memory usage. - ---- - -class: extra-details - -## Example - -Layers: - -* CentOS -* JRE -* Tomcat -* Dependencies -* Application JAR -* Configuration - ---- - -class: extra-details - ## Devs vs Ops, before Docker * Drop a tarball (or a commit hash) with instructions. diff --git a/slides/docker.yml b/slides/docker.yml index fe21f821..84199c75 100644 --- a/slides/docker.yml +++ b/slides/docker.yml @@ -22,10 +22,10 @@ content: #- shared/chat-room-zoom-webinar.md - shared/toc.md - # MORNING - #- containers/Docker_Overview.md #- containers/Docker_History.md - containers/Training_Environment.md #- containers/Installing_Docker.md + - containers/Docker_Overview.md - containers/First_Containers.md - containers/Background_Containers.md - containers/Initial_Images.md