1. Background on Virtualization
1.1. Full virtualization
1.2. Para virtualization
1.3. Kernel or container based virtualization
2. Why containers?
2.1. Why containers over full/para?
2.2. When containers over full/para?
3. Evolution of containers
3.1. Solid tech. since 1982
3.2. 1982 - chroot
3.3. 1998 - FreeBSD Jails
3.4. 2004 - Solaris Zones
3.5. 2005 - OpenVZ
3.6. 2008 - LXC
3.7. 2013 - Docker
4. Properties of container
4.1. Isolation
4.1.1. File system
4.1.2. I/O
4.1.3. Network
4.1.4. CPU
4.1.5. Memory
4.2. Privileges
4.2.1. Can I give someone root?
4.3. Speed
4.3.1. How close to bare metal?
4.4. Efficiency
4.4.1. Copy on write
4.4.2. Resource pooling
5. ...Enter Snap CI
5.1. Hosted continuous integration platform
5.2. Running untrusted code thousands of times a day
5.3. Users demand extreme speed
5.3.1. Must be faster than my build box
5.3.2. Builds must start-up in a flash
5.4. Needs isolation
5.4.1. Builds cannot see each other
5.4.2. Builds cannot affect each other
5.4.2.1. Network
5.4.2.2. Memory
5.4.2.3. Disk
5.4.2.4. I/O
5.4.2.5. CPU
5.5. Users need privilege
5.5.1. I want to test my Chef code. Need root.
5.5.2. I want to install latest gcc. Need root.
5.5.3. I want to start a service without changing init scripts. Need root.
6. We chose OpenVZ
6.1. Circa mid 2012
6.2. Why OpenVZ over LXC?
6.3. Why OpenVZ over Docker?
6.4. Linux kernel namespaces vs OpenVZ namespacing
6.5. Full isolation
7. App code to manage OpenVZ
7.1. vzctl
7.2. shell
7.3. Unix pipes and signals
7.4. Caching
7.5. Storing parts of the container file system safely
7.6. Artifacts
7.7. Fast dispatch
8. LXC
8.1. Better upstream support.
8.2. Namespaces baked into Kernel
8.3. Unprivileged containers can help with escalated privileges inside container
9. Docker
9.1. Much more efficient - Copy-on-write
9.2. Abstraction over container tech. via libcontainer
9.3. No user namespace support
9.4. Docker daemon runs as root
9.5. Better suited to be application containers
10. What's next with container tech.
10.1. When are user namespaces landing
10.2. When can we have full isolation with Docker?
11. Takeaway
11.1. Container based virtualization is fast and efficient
11.2. Containers are useful in production. Not just limited to testing.
11.3. Speed, efficiency and security are all possible if you choose the right container tech. for your problem.
11.4. Essentially problem/container tech. fit.
12. First cut: dedicated on-demand containers
12.1. Good
12.1.1. Isolated
12.1.2. Users can scale to n-containers
12.1.3. Bespoke containers. Can create per user demand.
12.2. Bad
12.2.1. Very slow build startup
12.2.2. Very poor utilization
12.2.3. Complex orchestration
12.2.4. Very large inventory of containers with poor utilization