Bryan Cantrill, CTO of Joyent. My god did he talk stupidly fast. People mentioned that he apparently beat some record.
Bryan did an excellent recap of how LXC containers, and eventually Docker came to be. Also brought us up to speed with what Joyent has been doing to basically allow inherently Linux based LXC containers to run under "Solaris."
Red Hat is doing a thing. They are forking Docker, in stereotypical RHEL fashion. Things won't work like normal Docker, but it'll get RHEL uses an enterprise "Docker," cuz buzzwords.
swarm seemed super super interesting. This is Docker's solution to container orchestration. It included features like affinity and anti-affinities. Example case, an anti-affinity for a redis-slave to be scheduled on the same host machine as a redis-master. You could also basically merge multiple providers and Linux distros to be in a swarm and still run your containers.
Also talked about scheduling based on network port and container linking availability.
Overall, the project seems super promising but still leaves out a management component. Example, what if a container dies, no process to maintain transitioning of container.
How to Build a Docker PaaS: a from-the-trenches case study of multi-host Docker networking - Luke Bond
Confirmation: Docker networking is still a nightmare. Solutions have been DNS based SDN (Weave, Flannel, Calico). Disappointed to not see anything using native Linux routing.
Super promising framework on creating Docker plugins and building ontop of Docker. The project sadly is being phased out since it encouraged the Docker team to create a finalized standard for plugins (see earlier Swarm and Compose projects)
Google has been using containers for the past 10 years, and have applied their learnings from Borg (their early internal container management) and created a public project Kubernetes, to handle container orchestration. This is the platform that is currently used for Google Cluster Compute.
Lots of work has been done to handle stateful and stateless containers, shared general purpose resources (like load balancing). However, this is definitely a thing that would be more suited at scale (when you need 300+ services running)
Proposal for a specification on containers to have more metadata. Basically making containers analogous to apt.
This was a super useful talk. Discussed the need for 12-factor application design to really leverage the power of Docker containers. The need for applications to be able to dynamically handle config/state changes rather than requiring a restart.
Lessons learned from migrating away from Chef to Docker. Basically used Chef to manage what containers run on a host, and using containers mostly for isolation and deployable units. Tried using Packer+Chef to create Docker images, but abandoned using Chef to build the images.
This was an awesomely hilarious presentation. Jessie basically Docker-ized her entire desktop workstation. LibraOffice, OpenGL and Steam all demoed as containerized.
There seems to be two general use cases for Docker. Compartmentalization/isolation, and at-scale scheduling. A lot fo the at-scale scheduling use cases seem to be based around having bare-metal infrastructure as opposed to cloud based.
The compartmentalization/isolation aspects still seem to be fraught with debate. General methods still seems to be Dockerfile filled with all the commands you'd run to make the container. Nothing handling in-container lifecycle management.
Networking solutions have been innovative, but still greatly revolve around DNS. Route based solutions also don't seem to be cloud-friendly and rely upon bare-metal rollouts.
The concensus from a lot of people I've talked to is that they've abandoned a majority of their Chef management to deal with Docker, but their perceived "convenience" of Docker containers outweighed not having config management. The push seems to be on lowering entry-level of people doing changes.
Another thing that seemed to be missing was any sort of testing frameworks or patterns that made sense. Not much mention of testing built container images.