Slide 1

Slide 1 text

Docker Networking #dockerffm, 13.01.15 @aschmidt75

Slide 2

Slide 2 text

Host   Container   ~$ apt-get install

Slide 3

Slide 3 text

Host     Container   eth0 ~$ ip addr show eth0

Slide 4

Slide 4 text

Host     Container   eth0 vethY vethX Network Namespaces Veth   Pair   „namespaced“   interfaces   ethZ

Slide 5

Slide 5 text

Host       Container   eth0 docker0 Connecting to the host network Linux  Bridge,   created  by   dockerd   172.17.42.1/16   172.17.42.5/16   „IPAM“   by  dockerd  

Slide 6

Slide 6 text

Host       Container   eth0 docker0 Connecting to the outside world Address  TranslaJon   RouJng   Masquerading       # /sbin/iptables 
 -L -n -t nat  

Slide 7

Slide 7 text

Host       Container   eth0 docker0 Containers talk on docker0, secured by iptables     Container  

Slide 8

Slide 8 text

Host       Container   eth0 docker0 Across hosts via host ips + exposed port forwardings     Container   Host       Container   eth0 docker0     Container  

Slide 9

Slide 9 text

Host       Container   eth0 Multiple tenants, i.e. with tagged interfaces     Container   Host       Container   eth0     Container   eth4 eth4 eth5 eth5 Take   tagging   down  to     container   level?  

Slide 10

Slide 10 text

Multiple Hosts/DCs Host   Container   Container   Container   Container   DC   DC   Host   Container   Container   Container   Container   Host   Container   Container   Container   Container   Host   Container   Container   Container   Container  

Slide 11

Slide 11 text

Pluggable network architecture & multi-host networking

Slide 12

Slide 12 text

How to ? •  .. integrate containers into an existing system infrastructure, •  .. connect to existing networks, •  .. support vlans or vxlans etc.

Slide 13

Slide 13 text

pipework @jpetazzo github.com/jpetazzo/pipework à Not part of docker! 1

Slide 14

Slide 14 text

pipework 1 •  creates new linux bridges & works on existing Open vSwitch bridges •  injects a new interface into a container •  connects interfaces to bridges •  dhcp, vlan, ovs, ... supported •  independent of docker

Slide 15

Slide 15 text

Weave weave.works github.com/zettio/weave •  Overlay network •  Router / Switch functionality, ships as container •  Encryption •  wraps docker 2 Demos Docs

Slide 16

Slide 16 text

Flannel github.com/coreos/flannel •  Overlay network •  UDP-based (optional VxLAN-style) •  Uses etcd to store cluster/ip infos •  Does not wrap dockerd, but docker0! 3

Slide 17

Slide 17 text

(*)  hSps://github.com/coreos/flannel/raw/master/packet-­‐01.png   Docker-bridge, modified Flannel-bridge Overlay TEP/Router 3

Slide 18

Slide 18 text

Socketplane 4 socketplane.io github.com/socketplane/socketplane •  Open vSwitch-based Overlay •  Discovery w/ Multicast DNS •  Uses consul to store cluster info •  wraps docker •  ships as container + shell scripts hSps://www.youtube.com/watch?v=ukITRl58ntg   hSps://www.youtube.com/watch?v=5uzUSk3NjD0  

Slide 19

Slide 19 text

socketplane in a picture (*) Host       Container   eth0 docker0-ovs (*)  according  to  demo  Vagranaile  setup  on  github     eth1 docker0 vxlan  VTEP   port   vlan-­‐tagged   port   Host   4 eth0 eth1 docker0-ovs Privileged   socketplane   Container  

Slide 20

Slide 20 text

Overview Pipework •  Swiss army knife of container/namespace networking! •  Low-level, but high degree of freedom when integrating existing network infrastructure (i.e vlans) Weave •  cross-host overlay network magic, encrypted (!) •  Stays parallel to existing network infrastructure Flannel •  Good fit to CoreOS (O RLY?), etcd/systemd/.. •  Integration with VxLAN networks Socketplane •  Open vSwitch-based, integration with ovs-capable network infrastructure in the future •  Working close to Feature Proposals

Slide 21

Slide 21 text

Test-driven infrastructure & Repeatibility Green Field vs. Brown-Field

Slide 22

Slide 22 text

Commands are ad-hoc # pipework br1 28096eac487b 192.168.77.10/24 # weave launch # weave run 10.0.1.1/24 -t -i ubuntu # socketplane network create web 10.2.0.0/16 # socketplane run -n web -itd ubuntu

Slide 23

Slide 23 text

... in contrast to model-based approaches •  Packer -> pckr.json •  Vagrant -> Vagrantfile •  Fig -> fig.yaml •  ... ⇒ packer validate ⇒ vagrant destroy ⇒ fig up && fig ps

Slide 24

Slide 24 text

~# wire up https://github.com/de-wiring/wire

Slide 25

Slide 25 text

How it works Model files ~# wire

Slide 26

Slide 26 text

How it works Model files ~# wire validate Check consistency of model

Slide 27

Slide 27 text

How it works Model files ~# wire validate Check consistency of model up ovs à Bridges, dnsmasq à DHCP, fig à containers, then wiring, etc.

Slide 28

Slide 28 text

How it works Model files ~# wire validate Check consistency of model up ovs à Bridges, dnsmasq à DHCP, fig à containers, then wiring, etc. verify Check eveything using linux commands

Slide 29

Slide 29 text

How it works Model files ~# wire validate Check consistency of model up ovs à Bridges, dnsmasq à DHCP, fig à containers, then wiring, etc. verify Check eveything using linux commands spec Generate a #serverspec and run it

Slide 30

Slide 30 text

How it works Model files ~# wire validate Check consistency of model up ovs à Bridges, dnsmasq à DHCP, fig à containers, then wiring, etc. verify Check eveything using linux commands spec Generate a #serverspec and run it down Take it down in reverse order (detach, stop containers, remove dhcp, bridges)

Slide 31

Slide 31 text

Model Zones •  Separate Components •  i.e. „DMZ is untrusted“ •  Policy in mind „DMZ à Application, Application à Backend, but not DMZ à Backend“ DMZ   Applica8on   Backend  

Slide 32

Slide 32 text

Model Networks •  Equals Open vSwitch bridge •  Have names network ranges •  Host may have an ip on that network •  May be attached to host interfaces •  May serve dhcp using dnsmasq DMZ   Applica8on   Backend   dmz-ext 10.0.1.0/24 dmz-int 10.0.2.0/24 App-int 10.1.0.0/16 be-int 10.37.15.0/24 (dhcp 10.37.15.[20..29]) 10.1.1.15 10.37.15.1

Slide 33

Slide 33 text

Model Application Groups •  That‘s where containers are in. •  Containers are attached to networks of zone. •  Currently managed using fig (1 fig file per app group) DMZ   Applica8on   Backend   Web  group   App  #1   App  #2   DB   NoSQL  

Slide 34

Slide 34 text

Demo

Slide 35

Slide 35 text

Demo

Slide 36

Slide 36 text

Demo

Slide 37

Slide 37 text

Demo

Slide 38

Slide 38 text

Demo

Slide 39

Slide 39 text

Goals •  System & Network Architecture specification. •  Manage a working application environment, identically between dev, stage and prod. •  Connect multiple docker hosts: using VLANs, VxLANs •  Be pluggable, integrate what‘s coming

Slide 40

Slide 40 text

Test Driven Infrastructure? github.com/
 de-wiring/containerspec

Slide 41

Slide 41 text

Thanks! @aschmidt75 github.com/de-wiring [email protected] [email protected] Pipework  is  (C)  @jpetazzo,  .  Licensed  under  the  Apache  License,  Version  2.0     Weave  is  (C)  2014  Zego  Ltd.  Licensed  under  the  Apache  License,  Version  2.0     Socketplane  is  (C)  2014  SocketPlane,  Inc.  Licensed  under  the  Apache  License,  Version  2.0     Flannel  is  (C)  CoreOS,  Licensed  under  the  Apache  License,  Version  2.0     Wire:  The  MIT  License  (MIT)  Copyright  (c)  2014  Andreas  Schmidt,  DusJn  Huptas