Container Standards & Interfaces: An Update

Container Standards & Interfaces: An Update


Brandon Philips

April 15, 2016


  1. Brandon Philips @brandonphilips | Container Standards & Interfaces An

  2. None
  3. Build, Store and Distribute your Containers

  4. None
  5. Container Image Format Specification Requirements

  6. The "*app*" perspective is how the app processes inside the

    pod see the environment. This example pod will use a set of three apps: | Name | Version | Image hash |------------------------------------|---------|--------------------------------------------- | | 1.0.0 | sha512-277205b3ae3eb3a8e042a62ae46934b470e43 | | 1.0.0 | sha512-3e86b59982e49066c5d813af1c2e2579cbf57 | | 1.0.0 | sha512-86298e1fdb95ec9a45b5935504e26ec29b8fe #### Filesystem Setup Each app in a pod will start chrooted into its own unique read-write filesystem before execut An app's filesystem must be *rendered* in an empty directory by the following process (or equ - The `rootfs` contained in the ACI is extracted - If the ACI contains a non-empty `dependencies` field in its `ImageManifest`, the `rootfs` o is extracted, in the order in which they are listed - If the ACI contains a non-empty `pathWhitelist` field in its `ImageManifest`, *all* paths n must be removed Every execution of an app MUST start from a clean copy of this rendered filesystem. The simplest implementation will take an ACI (with no dependencies) and extract it into a new
  7. What we want? Image Format Storytime!

  8. you

  9. you as a sw engineer

  10. your with Ada.Text_IO; procedure Hello_World is use Ada.Text_IO; begin Put_Line("Hello,

    world!"); end; #include <stdio.h> int main() { printf("Hello, world!\n"); } package main import "fmt" func main() { fmt.Println("Hello, world!") }
  11. your container image

  12. your /bin/java /opt/app.jar /lib/libc

  13. your /bin/python /opt/ /lib/libc

  14. your d474e8c57737625c

  15. your d474e8c57737625c Signed By: Alice

  16. you as an ops engineer

  17. your

  18. your x3

  19. your x3

  20. your ??? x3

  21. None
  22. Towards a Standard Journey to OCI

  23. An image format A container runtime A log collection daemon

    An init system and process babysitter A container image build system
  24. An image format

  25. 17 Months Ago November 2014

  26. Docker Image Format Circa 2014 - Very fluid format and

    evolution - Not content-addressable - No name delegation/discovery - Like MX records - No mechanism for signing
  27. 16 Months Ago December 2014

  28. App Container (appc)

  29. appc image in a nutshell • Image Format (ACI) ◦

    what does an application consist of? • Image Discovery ◦ how can an image be located? • Content-addressing ◦ what is the cryptographic id of an image? • Signing ◦ how is an image signed?
  30. a modern, secure container runtime a simple, composable tool (CLI)

    an implementation of an open standard (appc)
  31. shell scripts docker2aci acbuild goaci deb2aci

  32. 12 Months Ago April 2015

  33. Docker v2.2 Image Format Circa 2014 - Versioned v2.0, v2.1,

    v2.2 schema - Content-addressable - No name delegation/discovery - Like MX records - Optional and non-prescribed signing
  34. 10 Months Ago December 1st, 2014

  35. Open Containers Initiative

  36. • Runtime ◦ start/stop verbs ◦ filesystem layout OCI Runtime

  37. • Runtime ◦ start/stop verbs ◦ filesystem layout OCI Spec

  38. Last Week April 2016 (blog post)

  39. • A serialized image format • Content-addressable Optional stuff ◦

    Signatures that are based on signing image content address ◦ Naming that is federated based on DNS and can be delegated OCI Image Format Spec Project
  40. Where are we going? • Goal: standard container ◦ Runtime

    ◦ Image ◦ Identity & Signing ◦ Discovery & Naming ◦ Distribution • Goal: Enable Innovation ◦ Build systems ◦ Runtimes
  41. Container Networking Connectivity and Beyond

  42. Container Networking Interface Initially designed for rkt, used lots of

  43. Connectivity for "pod" network model - IP per pod -

    Pods in the cluster can be addressed by their IP
  44. How to network containers together? linux-bridge macvlan ipvlan Open vSwitch

    Weave Project Calico flannel GCE networking AWS VPC
  45. How to allocate IP addresses? - From a fixed block

    on a host - DHCP - IPAM system backed by SQL database - SDN assigned: e.g. Weave
  46. Container Runtime (e.g. k8s) veth macvlan ipvlan OVS Container Networking

    Interface (CNI)
  47. CNI - Container can join multiple networks - Network described

    by JSON config - Plugin supports two commands - Add container to the network - Remove container from the network
  48. User configures a network $ cat /etc/cni/net.d/10-mynet.conf { "name": "mynet",

    "type": "bridge", "ipam": { "type": "host-local", "subnet": "" } }
  49. CNI: Step 1 Container runtime creates network namespace and gives

    it a named handle $ cd /var/lib/cni $ touch myns $ unshare -n mount --bind /proc/self/ns/net myns
  50. CNI: Step 2 Container runtime invokes the CNI plugin $

    export CNI_COMMAND=ADD $ export CNI_NETNS=/var/lib/cni/myns $ export CNI_CONTAINERID=5248e9f8-3c91-11e5-... $ export CNI_IFNAME=eth0 $ $CNI_PATH/bridge </etc/cni/net.d/10-mynet.conf
  51. CNI Flexibility - Plugins manage their own state - Essential

    for network vendors who often have complex control planes - Process model exposes full Linux network stack - External plugins implement the API and get out of the way - Metaswitch networks, Weaveworks
  52. CNI Community - Maintainers from CoreOS, Pivotal, and Weaveworks -

    Used by rkt, Kubernetes, Cloud Foundry, kurma, and usable with runC - External plugins from - Metaswitch networks, Weaveworks - Discussions around CNCF project
  53. Container Networking Model CNM is implemented in github. com/docker/libnetwork

  54. Defining a new network model - Network - A logical

    network (think vlan) - Endpoint - Connects a sandbox to a network - Sandbox - A container level network configuration for DNS, routes, etc
  55. CNM for Cluster and Local Networking

  56. "Battery Included Plugins" - Bridge - "Default Docker Networking" -

    Overlay - VXLAN and coordinated internally using libkv - Remote - Everyone else uses this
  57. Remote Plugins - Operate a long running plugin API service

    - Linux networking features restricted to API - External plugins - Difficult to integrate because of API model - Existing control planes don't get useful metadata
  58. - Maintainers from Docker, and Tencent - Used by docker

    engine - External plugins from - Metaswitch networks, Weaveworks libnetwork Community
  59. Container Networking Conclusions

  60. CNM creates a new interface to the network world -

    Hard to integrate into existing systems like Kubernetes - Exposes networking concepts through new API/model - Adopted by Docker Engine CNI is a simple model for container networking - Simple to integrate with process based workflow - Exposes full Linux network stack - Adopted by rkt, kurma, Kubernetes, Cloud Foundry, and easy integration with runC
  61. - @coreosfest May 9 & 10, 2016 - Berlin,

  62. Thank you! Brandon Philips @brandonphilips | | We’re

    hiring in all departments! Email: Positions: careers