hardware abstraction layer • Complete OS • Slower startup • Dev is separate from Prod • Additional performance overhead • Containers • LXC has been around for a decade, OpenVZ • Can be full systems with init, persistent storage, • Can be shared read-only bins/libs with just the application • Lightweight and distributable • Packing density due to shared components
more like a shark, but that’s a different talk.) We give them names, hand feed them with private Chefs, and care about their wellbeing. • Containers are like cattle. They have numbers and are managed in herds. They are replaceable and no one will notice.
Docker) • Containers should be single-process, no durable storage, ephemeral little creatures • Filesystems are built of read-only layers using AuFS - only the top layer is read/write • It shares underlying libs/bins so the docker image can be tiny-ish. • Networking using an ethernet bridge - `docker0.` • By default each container is given an 172.17.xxx.xxx/16 inside the bridge and specific ports are mapped via NAT Docker
• AuFS • Layered filesystem is efficient and performant enough for most tasks • Better IO needed? Easy: • Data-only volume containers. Bypasses AuFS, just uses standard disk. • Need to share that data elsewhere? Spin NFS container process to share between hosts also mounts that container. • Each process can mount it separately.
Bridge Nat is/can be *terrible* • YMMV - up to 50% performance decrease (<1.7) • Even more important - inter-host communication is a no-no. • All containers are placed into a 172.17.xxx.xxx /16 address space - unreachable from network hosts • Solutions: Overlay networks • Current solutions: • Userspace Processing — options like Weave can drop throughput by 90% as all packets are sent through a userspace daemon on both sides. • Proposed solution: VXLANs in-kernel forwarding (Flannel-esque) or networking plugins. Seems reasonable. Isn’t standard yet. • You VM users - update your libvirt! Latency in test systems went from 20-30ms per hop to ~4ms on CentOS libvirt upgrades.
any RTC, you MUST use net=host networking • Exposes the native networking stack within the container • Side Affect: Horribly insecure - ordering a shutdown command will terminate the entire host. • https://github.com/docker/docker/issues/6401 • Requires setting physical host network appropriately (multiple virtual IPs) • Provides near native-level network throughput at high sustained PPS • For much further info, see this IBM Research Paper http://domino.research.ibm.com/library/cyberdig.nsf/papers/ 0929052195DD819C85257D2300681E7B/$File/rc25482.pdf
S3/NFS • A set of physical or virtual machines • FreeSWITCH/Kamailio aren’t blockers • Adhearsion & RTPProxy • Service Discovery to determine new components • Components can advertise services and announce locations, ports, etc.. • Orchestration layer can monitor cattle and restart where/when appropriate Service Discovery Kubernetes / etcd / Compose Examination of an RTC Container Stack API
packages (among many others) • curl -sSL https://get.docker.com/ | sh • Pull images from Docker Hub • https://hub.docker.com/ • Remember to not think in terms of a virtual machine, think in terms of shipping applications • Redo your Ansible / Chef / Puppet deploys. • Once you’ve got a grasp of container deployment, check out Google’s Kubernetes as an orchestration platform. • Provides a partial networking solution, scaleable deployment paradigm and ensures a cattle mentality.
that unnecessarily duplicate services or libraries • Containers are great if you’re in love density/performance/scaling ( do you also love NodeJS? ) • Containers are great at running in development exactly what runs on production • Containers are great if you love working with your network stack • Containers are great if you want to redo your deployment architecture • Containers are great if you love discovering something new
a lightweight VM to abstract away all hardware and then ship applications via containers inside? • If this is interesting, checkout out CoreOS and rkt. They dial containers up to 11. • https://www.digitalocean.com/community/tutorials/the-docker-ecosystem-an-introduction- to-common-components