1. Use cases
1.1. protect computer
1.1.1. container jail
1.1.1.1. defense in depth
1.1.1.2. security thread limited to the scope of app
1.2. faster delivery of apps
1.2.1. improve portability
1.2.1.1. vs JVM
1.2.1.1.1. regardless of programming language
1.2.2. help with dev lifecycle
1.2.2.1. developers write code locally
1.2.2.2. push docker image to a test env
1.2.2.3. push docker images to prod
1.3. deploy and scale more easily
1.3.1. getting organized
1.3.1.1. Untitled
1.3.2. simplify deployment
1.3.2.1. before
1.3.2.1.1. Untitled
1.3.2.2. after
1.3.2.2.1. Untitled
1.4. achieve higher density and run more workloads
1.4.1. Improve efficiency
1.4.1.1. convergence on Linux
1.4.1.2. vs VM
1.4.1.2.1. complementary technologies
1.4.1.2.2. design
1.5. concrete examples
1.5.1. yes
1.5.1.1. web servers
1.5.1.2. word processors
1.5.1.3. email clients
1.5.2. not
1.5.2.1. Run an OS X or windows native app
2. why important
2.1. abstraction
2.1.1. install
2.1.2. remove
2.1.3. will change sysadmin/dev workflow
2.2. adoption
2.2.1. since 2013
2.2.2. Amazon, Google, Microsoft
2.3. Microservice architecture
2.3.1. lightweight nature
2.3.1.1. tasks less space
2.3.2. speed of containers
2.4. Immutable infrastructure
2.4.1. reduce size of configuration management code base
2.5. works best for stateless applications
2.6. externalizing state
2.6.1. storing things in container's filesystem limited
2.6.2. will not preserve state across lifecycle
2.7. disadvantages
2.7.1. Limited isolation
2.7.1.1. by default share CPU and memory
2.7.1.1.1. like colocated unix process
2.7.1.1.2. might compete for resources
2.7.1.2. many containers share one or more common filesystem layers
2.7.1.3. many containers use UID 0 to launch process
2.7.1.3.1. everything running on the same kernel
2.7.1.3.2. security vulnerabilities / simple misconfigurations
2.8. opinionated
2.8.1. particular workflow
2.8.1.1. revision control
2.8.1.1.1. filesystem layers
2.8.1.1.2. image tags
2.8.1.2. build
2.8.1.2.1. each command in dockerfile generates a new layer
2.8.1.2.2. build logic inside dockerfile
2.8.1.2.3. easy to create standard build jobs in systems like Jenkins
2.8.1.3. test
2.8.1.3.1. Docker ensures the consistency between dev and prod env
2.8.1.3.2. much better than java war
2.8.1.4. package
2.8.1.4.1. multi-layered image as build artifact
2.8.1.5. deploy
2.8.1.5.1. Untitled
3. history
3.1. Google develope CGroups for linux kernel
3.2. Linux Containers Project
3.2.1. brought together CGroups, kernel namespaces, and chroot technology
3.3. Docker platform
3.3.1. docker engine
3.3.2. docker hub
3.4. dotCloud
3.4.1. language agnostic Paas
3.4.2. Google App Engine support Java/Python
3.4.3. Heroku supported Ruby
4. eco system
4.1. surrounding technologies
4.1.1. swarm
4.1.2. docker engine
4.1.2.1. docker engine accepts docker commands from CLI
4.1.3. compose
4.1.4. machine
4.1.4.1. docker machine start
4.1.4.1.1. why start docker machine?
4.1.4.2. use cases
4.1.4.2.1. I have an older desktop and want to run docker on mac / windows
4.1.4.2.2. I want to provision docker hosts on remote systems
4.1.4.3. provisioning and managing dockerized hosts
4.1.4.3.1. Untitled
4.1.5. kitematic
4.1.6. docker trusted registry
4.2. emerging technologies
4.2.1. Networking
4.2.1.1. Weave
4.2.1.2. Calico
4.2.1.3. Overlay
4.2.2. service discovery
4.2.2.1. consul
4.2.2.2. registrator
4.2.2.3. skyDNS
4.2.2.4. etcd
4.2.3. orchestration/cluster mana
4.2.3.1. kubernetes
4.2.3.2. marathon
4.2.3.3. fleet
4.2.3.4. swarm
4.3. underlying technologies
4.3.1. namespaces
4.3.1.1. pid namespace
4.3.1.1.1. process isolation
4.3.1.2. net namespace
4.3.1.2.1. network interface
4.3.1.3. ipc namespace
4.3.1.3.1. access to IPC resources
4.3.1.4. mnt namespace
4.3.1.4.1. mounting points
4.3.1.5. uts namespace
4.3.1.5.1. isolating kernel and version identifiers
4.3.2. chroot
4.3.2.1. prevents anything running inside the container from referencing any other part of host file system
4.3.3. control groups
4.3.3.1. access control for resources
4.3.4. union file systems
4.3.5. container format
4.3.5.1. default format
4.3.5.1.1. libcontainer
5. architecture
5.1. Untitled
5.2. Daemon
5.2.1. commands
5.2.1.1. start using -d
5.2.2. daemon command is run on port 2375
5.2.3. restart policies
5.2.3.1. what happens to the service if it fails
5.2.3.2. what happens to the service when it terminates
5.2.3.3. what happens if the service keeps failing over and over
5.2.3.4. Untitled
5.3. server is integrated into same binary as client
5.4. Client
5.4.1. docker command is client
5.4.1.1. docker build
5.4.1.2. docker pull
5.4.1.3. docker run
5.4.1.3.1. Specify PID namespaces
5.4.2. Untitled
5.5. Registry
5.6. Images
5.7. Containers
5.7.1. state
5.7.1.1. Untitled
5.7.1.2. docker ps
5.7.1.3. docker ps -a
5.7.2. connect
5.7.2.1. host
5.7.2.1.1. use port mapping to map internal ports to host ports
5.7.2.1.2. docker run -d -p 10001:80 --name blog1 tutum/wordpress
5.7.2.1.3. -p host_port : container_port
5.7.2.2. links between containers
5.7.2.2.1. links won't wait for services to start
5.7.2.2.2. precond for links
5.7.2.2.3. Untitled
5.7.2.2.4. Untitled
6. the process of containerizing
6.1. move config state into env vars
6.2. always decreasing he size of containerized application
7. images
7.1. package software in images
7.1.1. packaging hello world
7.1.2. preparing packaging for git
7.1.3. reviewing file system changes
7.1.4. commit a new image
7.1.5. configurable image attributes
7.2. image identifier
7.2.1. image tags
7.2.2. UID
7.2.2.1. 65 bits
7.2.2.2. 12 bits for human users
7.3. build images
7.3.1. build context
7.3.1.1. .
7.3.1.2. http/https
7.3.1.3. git repo
7.3.2. cache
7.3.2.1. --no-cache flag for disable
7.3.3. base images
7.3.3.1. first instruction
7.3.3.1.1. FROM scratch
7.3.3.1.2. FROM ubuntu
7.3.4. dockerfile instructions
7.3.4.1. ONBUILD
7.3.4.1.1. defines instructions to execute if resulting image is used as a base for another build
7.3.4.1.2. inject downstream build-time behavior
7.3.4.2. Meta instruction
7.3.4.2.1. FROM
7.3.4.2.2. MAINTAINER
7.3.4.2.3. ENV
7.3.4.2.4. LABEL
7.3.4.2.5. WORKDIR
7.3.4.2.6. EXPOSE
7.3.4.2.7. USER
7.3.4.2.8. ENTRYPOINT
7.3.4.2.9. Untitled
7.3.4.3. file system instruction
7.3.4.3.1. COPY
7.3.4.3.2. VOLUME
7.3.4.3.3. ADD
7.3.4.3.4. Untitled
7.4. based on union file system
7.4.1. layers
7.4.1.1. def
7.4.1.1.1. Untitled
7.4.1.1.2. Untitled
7.4.1.2. upper bound
7.4.1.2.1. 42 layers for AUFS system
7.4.1.2.2. solve size problem with branches
7.4.1.3. attributes
7.4.1.3.1. env vars
7.4.1.3.2. working dir
7.4.1.3.3. set of exposed ports
7.4.1.3.4. volume defs
7.4.1.3.5. container entrypoint
7.4.1.3.6. commands and arguments
7.4.1.3.7. inheritance from parents if not specified
7.4.1.4. add a layer to an image: docker commit
7.4.1.4.1. what happens when docker run
7.4.1.4.2. Untitled
7.4.1.5. viewing changes added as a layer: docker diff
7.4.1.5.1. Untitled
7.4.1.6. view all historical changes as layers: docker history
7.4.1.6.1. Untitled
7.4.1.7. benefits of layers
7.4.1.7.1. common layers installed only once
7.4.1.7.2. coarse tool for managing dependencies
7.4.1.7.3. easy to create software specializations
7.4.1.8. weaknesses of ufs
7.4.1.8.1. make implementing memory-mapped files difficult
7.4.1.8.2. different file systems have different rules about file attributes, sizes, names and characters
7.4.1.8.3. backing file system
7.4.2. mechanism: copy-on-write
7.4.2.1. whole layer copied from read-only layer to writable layer before change made
7.4.2.1.1. Untitled
7.4.2.2. all layers below writable layers are immutable
7.4.2.2.1. common layers can be shared
7.4.2.2.2. when new change is made, a new layer is added and old layer is not removed
7.5. dockerfile
7.5.1. environmental precondition validation
7.5.2. use init process
7.6. versioning best practices
7.6.1. Untitled
7.7. image layering accomplished by union mounts
7.7.1. mount multiple file systems
7.7.2. combine into one file system
8. repos
8.1. Untitled
8.2. repo structure
8.3. create tags
8.3.1. applied to existing images
8.3.1.1. docker tag
8.3.2. applied to new images
8.3.2.1. docker commit
8.3.2.2. docker build
8.4. tagging principles
8.4.1. every repo contains multi tags
8.4.2. multi tags can reference same images
8.5. Untitled
8.6. Untitled
9. network
9.1. four archetypes
9.1.1. closed containers
9.1.2. joined containers
9.1.3. bridged containers
9.1.4. open containers
9.2. Untitled
10. volumes
10.1. position within the ecosystem
10.1.1. Untitled
10.2. when a volume is mounted on a container file system, it replaces the content that the image provides at that location
10.3. types
10.3.1. Untitled
10.3.2. bind mount volume
10.3.2.1. useful if want to share data with other processes
10.3.2.2. not limited to directories, can mount to individual files
10.3.2.3. creates potential for conflict
10.3.3. docker-managed volume
10.3.3.1. created when use -v option on docker run
10.4. sharing
10.4.1. host dependent sharing
10.4.1.1. two/more containers use bind mount volume for a single known location on the host
10.4.2. generalized sharing
10.4.2.1. --volumes-from
10.5. clean up volumes
10.5.1. Untitled
11. work with containers
11.1. create containers
11.2. start containers
11.3. stop containers
11.4. kill containers
11.5. pause/unpause containers
11.6. clean up containers
12. Commands
12.1. docker run
12.1.1. Untitled
12.1.2. -d
12.1.3. -i
12.1.4. -tty