Running Containers in Production, no really!

LOPSA/UUASC Demos

* Triton install
** sdcadm post-setup
*** common-external-nics
*** cloudapi
*** dev-headnode-prov
*** dev-sample-data
** triton-update-all (https://gist.github.com/bahamat/b1f6511ebdaea510a0f9391c75e2362c)
* AdminUI Tour
** servers
** vms
** images
** packages
* SmartOS Basics
** imgadm
** vmadm
** zlogin
** smf
* json
* Using sdc-*api
** smf & bunyan
* pkgsrc basics
** pkgin avail
** pkg_info -e
** pkg_admin fetch-pkg-vulnerabilities
** pkg_admin audit
* triton to deploy
** profile
** images
** packages
** triton create base-64 g4-highcpu-1G
** ubuntu
** alpine
* docker to deploy
** docker run -it -e TERM=xterm alpine /bin/sh
*** ls /native/usr/sbin/dtrace
*** docker exec -it /native/usr/sbin/dtrace -n 'proc:::exec-success { trace(curpsinfo->pr_psargs); }'
*** ls
*** apk update
*** apk add nginx
** docker run -it -e TERM=xterm ubuntu /bin/sh
** docker run -d -p 80:80 bahamat/authenticated-proxy
*** docker inspect
*** http_proxy=http://:80/ curl -i -U jack:insecure http://www.google.com/
* CNS for service discovery
** triton account get | grep triton_cns_enabled
** triton inst tag list gloom
** triton inst get gloom | json dns_names
* Manta
** mls
** mget
** mput
** mlogin
** mjob

Transcript

1. © 2015 Joyent, Inc. Proprietary & Confidential Information of Joyent, Inc. ‹#›. Running Containers in Production
 No, really! brian.bennett@joyent.com @bahamat
2. • Containers are not a new idea, having originated with filesystem containers with chroot in 7th Edition and (later) FreeBSD jails • Seeing the potential for broader containers to provide workload consolidation, Sun introduced complete operating system virtualization with zones (née Project Kevlar) • These mechanisms were designed to be a security mechanism, not an application deployment mechanism A Brief History of Containers
3. • Joyent runs OS containers in the cloud via SmartOS — and we have run containers in multi-tenant production since ~2006 • Adding support for hardware-based virtualization circa 2011 strengthened our resolve with respect to OS-based virtualization • OS containers are lightweight and efficient — which is especially important as services become smaller and more numerous: overhead and latency become increasingly important! • We emphasized their operational characteristics — performance, elasticity, tenancy — and for many years, we were a lone voice Containers at Joyent
4. • Some saw the power of OS containers to facilitate up-stack platform-as- a-service abstractions • For example, dotCloud — a platform-as-a-service provider — built their PaaS on OS containers • Struggling as a PaaS, dotCloud pivoted — and open sourced their container-based orchestration layer... Containers as a PaaS Foundation?
5. …and Docker was born
6. • The Docker model has pointed to the future of containers • Docker’s challenges remain operational: network 
 virtualization, persistence, security, etc. • Security concerns are not due to Docker per se, but rather to the architectural limitations of the Linux “container” substrate • For multi-tenancy, state-of-the-art for Docker containers is to run in hardware virtual machines (!!) • Deploying OS containers in hardware virtual machines negates their economic advantage! Container Revolution
7. • SmartOS has been container-native since its inception — and running in multi-tenant, internet-facing production for many years • Could we achieve an ideal world that combines the development model of Docker with the container-native model of SmartOS? • This would be the best of all worlds: agility of Docker coupled with production-proven security and on-the-metal performance of SmartOS containers • We resurrected (and finished) a Sun technology for Linux system call emulation, LX-branded zones, and added a Docker API endpoint Container Native Infrastructure?
8. • SmartOS Platform Image (OS on 262MB RAM disk) • Instance Images • Zones (OS, KVM, LX) • Agents that report status to the API Stack (cn-agent, vm-agent, net- agent) • Data layer (manatee, moray) • API Stack (vmapi, cnapi, napi, etc.) • Front ends (cloudapi, sdc-docker, adminui) Triton, in a nutshell
9. • SmartOS Platform Image (OS on 262MB RAM disk) • Instance Images • Zones (OS, KVM, LX) • Agents that report status to the API Stack (cn-agent, vm-agent, net- agent) • Data layer (manatee, moray) • API Stack (vmapi, cnapi, napi, etc.) • Front ends (cloudapi, sdc-docker, adminui) • ContainerPilot (optional) Triton, in a nutshell
10. Triton vs. …
11. Triton: Architecture
12. Triton: Core Services
13. • SmartOS is a type 1, read-only hypervisor • Boots from USB or PXE • Uses pkgsrc, in collaboration with NetBSD, for third party packages • ZFS, Zones, Dtrace, oh my! • For when a container just won’t do, KVM runs qemu inside a zone • illumos derived, descended from OpenSolaris • Search Youtube for “Fork Yeah!” SmartOS, in 30 seconds
14. • https://www.joyent.com/ • #smartos on irc.freenode.net • https://github.com/joyent/triton • https://github.com/autopilotpattern • https://www.joyent.com/blog/spin-up-a-docker-dev-test-environment- in-60-minutes-or-less • https://www.joyent.com/blog/containerbuddy-is-now-containerpilot • https://www.joyent.com/blog/understanding-triton-containers • https://www.joyent.com/blog/docker-bake-off-aws-vs-joyent Resources