Go, link statically, package app solo in ACI More complex, dynamic linking required: Reduce the base. Alpine vs Ubuntu (Docker hub recently) See also: buildroot, Brian Harrington’s talk
what does an application consist of? - Image Discovery and Verification - how can an image be located? signed/validated? - Pods - how can applications be grouped and executed? - Executor (runtime) - what does the execution environment look like?
with Docker This work has always been in pursuit of a community standard specification for a container image Docker v2.2 implements some aci concepts; convergence? Spur innovation between friendly rivals until shakes out
for image name coreos.com/rkt/stage1-coreos:0.15.0 rkt: using image from local store for image name quay.io/josh_wood/caddy [ 1161.330635] caddy[4]: Activating privacy features... done. [ 1161.333482] caddy[4]: :2015 $ rkt run
features of rkt/appc • Reduced isolation for privileged components • chroot file system isolation only • Has access to host-level mount, network, PID name spaces • Method for shipping k8s kubelet in CoreOS
from local store for image name coreos.com/rkt/stage1-fly:0.15.0 rkt: using image from local store for image name quay.io/josh_wood/caddy [ 1161.333482] caddy[4]: :2015 $ rkt run stage1=fly
kubelet: packaging and distribution of containers, ns at host level • rkt is container execution engine, runs cluster work • Pod :: Pod • CNI: Native k8s network plugin model • Write containers, pods, and CNI plugins!
and application runtime components - Hashes must match to boot and/or join cluster - rkt logs pod executions to tamper-resistant TPM facility - Chain of trust from TPM hardware up through the cluster application stack