SlideShare a Scribd company logo
1 of 28
Download to read offline
1
Tél : +33 (0)1 58 56 10 00
Fax : +33 (0)1 58 56 10 01
www.octo.com© OCTO 2013
50, avenue des Champs-Elysées
75008 Paris - FRANCE
Follow us on Twitter!
@AdrienBlind
@ArnaudMazin
2
REMINDER: DOCKER NETWORKING
Agenda
INTRODUCTION TO SOFTWARE DEFINED NETWORKS
MIX UP
1
TAKE AWAY
2
4
3
3
Reminder: Docker networking
4
Host
Natively, each container runs isolated from the outside world
A bridge network (an internal, virtual switch) is provided with Docker but
does not allow containerized processes to communicate together
without further config (see next slides)
Isolation by design
Container ‘app’
Bridge docker0
Container ‘db’
Tomcat
(port 8080)
MySQL
(port 3306)
5
Exposing ports allows containers services to talk together through the
bridge network
Dockerfile: add line “EXPOSE <port>” (several ports can be appended)
Command line switch: “docker run ... –expose <port>”
Example for the ‘app’ container: “docker run ... –expose 8080”
Exposing ports
Host
Container ‘app’
Bridge docker0
Container ‘db’
Tomcat
(port 8080)
MySQL
(port 3306)
TCP 3306
exposed
TCP 8080
exposed
« The app is able to talk to its database »
6
Linking enables a client container to get information related to a
resource container (also known as the linked container)
Command line switch: “docker run -link <containername:alias>”
Example on ‘app’ container: “docker –run … –link db:dbalias”
Linking containers
Host
Container ‘app’
Bridge docker0
Container ‘db’
Tomcat
(port 8080)
MySQL
(port 3306)
Env variables
DBALIAS_PORT_3306_TCP=tcp://1.2.3.4:3306
DBALIAS_PORT_3306_TCP_PROTO=tcp
DBALIAS_PORT_3306_TCP_ADDR=1.2.3.4
DBALIAS_PORT_3306_TCP_PORT=3306
« The app knows where to join its database »
7
Mapping ports enable to publish container’s ports on “external
interfaces”. Ports may be translated.
Command line switch: “docker run -p <externalport:insideport>”
Example for ‘app’ container: “docker –run … –p 80:8080”
Mapping ports
Host
Container ‘app’
Bridge docker0
Container ‘db’
Tomcat
(port 8080)
MySQL
(port 3306)
« The app is reachable from the external network at port 80 of the host,
while the database container only remains reachable to other containers »
IP_interface
TCP 80 map Tomcat’s 8080 port
External network
8
These characteristics enables containers:
To either remain fully isolated or talk to all other containers of the same
host having their services exposed
To map one-by-one services on the hosts interface
Hmm… What if I want to isolate groups of containers?
Conclusion
9
Introduction to Software Defined Networks
10
Traditional datacenter management
VM
VM
VM
VM
VM
VM
VM
VM
VM
Internet
Internet
DMZ
Physical overview
Logical overview
Tenant #1
Tenant #3
Tenant #2
LAN
DMZ
LAN
DMZ1
DMZ2
Logical topologies
are quite different
from physical ones
These designs
traditionally relies a
lot on low network
layers (L2, etc.)
11
Multi datacenter perspective
VM
VM
VM
VM
VM
VM
VM
VM
VM
Physical overview
VM
VM
VM VM
VM
VM
VM
VM
VM
• Limited to 2048 VLANs
• Lack of dynamic provisioning
• Involves subnetting or encapsulation to
flow over L3 networks
Internet
12
SDNs proposes network solutions embracing cloud paradigms
Massively multi-tenant
Thousands tenants, massively scalable
Easy & fast (de)provisioning
Infra as code, API centric
Infrastructure agnostic
L3, does not stick with lower levels (physical designs, vlans & co)
Decouple infrastructure & tenants lifecycles
Cross technology, vendor agnostic
SDNs value proposal
13
Enables to abstract
networking topologies &
services from wiring and
equipments
Centralize network
intelligence
Standardized management
APIs: ex. OpenFlow for both
physical & virtual network
equipments
SDNs overview
(Source Wikipedia)
14
On hosts (hypervisors, Docker hosts…), SDNs mostly rely on:
Allocating network bridges (virtual and internal switches)
Setting ACLs to decide which flow to allow or deny
Connecting these bridges to external world through real host’s
interfaces
Host perspective
15
Network perspective – Low level isolation
Host #3
SDN
network #1
SDN
network #1
Host #1
SDN
network #1
SDN
network #1
Host #2
SDN
network #1
L2-Network focused
Keep traditional paradigms but use API/centralize intelligence
Requires VLANs, VPLS… to spread same virtual networks accross several hosts
Enforces low-level isolation
Consider API-based network configuration (ie. OpenFlow) to centralize and facilitates
network management, making it more dynamic
VPLS Router
Physical net.
VPLS network
The link tags both
virtual network trafics in
vlans
The VPLS ensure providing L2
networks at all ends – strong req.!
16
Full-mesh, network agnostic and encapsulated approach
Relies on L3 networks and GRE, VXLAN… tunnels for inter-hosts communication (avoid using L2)
Network agnostic, til hosts can route trafic
SDN Routers must route traffic between an inner virtual net and the ext. world
Network perspective – Full mesh
Host #3
Host #1
Host #2
SDN
network #1
SDN
network #1
SDN
network #1
SDN
network #1
SDN
network #1
Router
Physical net.
Flow encapsulation
L3 network
17
Mix up
18
How to support several containers related to a same tenant, accross multiple hosts
(or even multiple datacenters or providers), and avoid them to talk to other containers
in the same time ?
Answer to this question enables several usecases
Isolate containers of a same app without having to face limits of a single Docker host
Resilience (ex. spread an app server farm over multiple hosts)
Multi providers (ex. spread containers over several clouds/hosters, overflow mgmt…)
…
Usecases – Back to Docker
Internet
LAN
DMZ
DMZ
DMZ 1
DMZ 2
LAN
Container
Tenant #1
Tenant #3
Tenant #2
19
Host #1 Host #3Host #2
0. From where we start
Container ‘app’
Container ‘db’
Bridgedocker0
Container ‘app’
Container ‘db’
Bridgedocker0
Container ‘app’
Container ‘db’
Container ‘app’
Bridgedocker0
Container ‘app’
TCP ports of
services running
in containers are
mapped
Get rid of actual Docker bridges implementation !
If not, all containers will talk together across a same host
20
Use OpenVSwitch to create bridges on each host, for each tenant’s subnet. For
instance, on host #1:
» ovs-vsctl add-br tech-br
» ovs-vsctl add-port tech-br tep0 -- set interface tep0 type=internal
» ifconfig tep0 192.168.1.1 netmask 255.255.255.0
» ovs-vsctl add-br sdn-br0
» ovs-vsctl set bridge sdn-br0 stp_enable=true
1. Create SDN compliant bridges
Host #1
sdn-br0
Host #3
sdn-br0
sdn-br1
Host #2
sdn-br0
sdn-br1
Simplified view. Detailed insight exposed in later slides
Once per host: common plumbing
(detailed slide 24)
For each bridge: create and protect
against ethernet loops using
Spanning Tree Protocol (beware, in
complex/large deployments, it may
consumes a lot of CPU!)
21
2. Link SDN bridges
Host #1
sdn-br0
Host #3
sdn-br0
sdn-br1
Host #2
sdn-br0
sdn-br1
Use OpenVSwitch to link corresponding bridges accross hosts
In this example, we decided to use the full-mesh approach. On host #1:
ovs-vsctl add-port sdn-br0 gre0 --set interface gre0 type=gre options:remote_ip:1.2.3.2
ovs-vsctl add-port sdn-br0 gre1 --set interface gre1 type=gre options:remote_ip:1.2.3.3
1.2.3.1 1.2.3.2 1.2.3.3
Simplified view. Detailed insight exposed in later slides
22
U
3. Instanciate VMs and map them to the bridges
Host #1
sdn-br0
Host #3
sdn-br0
sdn-br1
Host #2
sdn-br0
sdn-br1
Container ‘app’
Container ‘db’
Container ‘app’
Container ‘db’
Container ‘app’
Container ‘app’
Container ‘db’
Container ‘app’
Container ‘db’
Instanciate containers without pre-built interfaces to avoid
plugging containers to native docker0 bridge
Use “docker run … -n=false” switch in “docker run” calls
23
U
4. Connect containers to the appropriate bridge
Host #1
sdn-br0
Host #3
sdn-br0
sdn-br1
Host #2
sdn-br0
sdn-br1
Container ‘app’
Container ‘db’
Container ‘app’
Container ‘db’
Container ‘app’
Container ‘app’
Container ‘db’
Container ‘app’
Container ‘db’
Use pipework.sh from J. Petazzoni to easily plug containers to a chosen bridge
https://github.com/jpetazzo/pipework
Creates network adapter in each containers, allocate them an IP (manually/static vs DHCP), and
plug it to the bridge.
Per container: “pipework bridge_name $container_id container_ip/24”
24
Switch
Insight - Detailed view between two hosts
Previous drawings were simplified to ease overall understanding
Following schema details more deeply what happened inside a single host
Host #1
sdn-br0
Container
Host #2
Container
gre
0
tech-br
tep0
eth0
sdn-br0
Container Container
gre
0
tech-br
tep0
eth0
Switch
ovs-vsctl add-br tech-br
ovs-vsctl add-port tech-br
tep0 -- set interface tep0
type=internal
ovs-vsctl add-port sdn-br0
gre0 --set interface gre0
type=gre
options:remote_ip:1.1.1.1
GRE tunnel in which the traffic really flows
Ethernet link between an adapter and a switch
L2 switch
Network adapter
pipework sdn-br0
$container_id
192.168.0.3/24
eth1 eth1ovs-vsctl add-br sdn-br0eth1 eth1
1.1.1.1/24 2.2.2.2/24
192.168.1.2/24
192.168.0.3/24192.168.0.2/24192.168.0.1/24 192.168.0.4/24
4
7
6
1
2
ifconfig tep0 192.168.1.1
netmask 255.255.255.0
3
L3 routed
network
Docker container
Docker host
pipework sdn-br0
$container_id
192.168.0.4/24
8
192.168.1.1/24
Repeat step #6 to create additional tunnels in order to reach other hosts
ovs-vsctl set bridge
sdn-br0 stp_enable=true
5Virtual, direct link established
through the GRE tunnel
25
Bonus: Alternate design - OpenStack Neutron paradigms
Alternate design, based on OpenStack Neutron paradigms – notice that use of VLAN limits to 2048 tenant networks on each hosts
All VMs/containers of a same tenant network are segregated inside a dedicated, local VLAN of a shared unique bridge
Full-mesh of GRE tunnels between all hosts
On each host, local mapping between a local tenant network VLAN and its GRE identifier shared across all hosts
Full story from VM A to B (tenant #1): traffic outgoing A is tagged with VLAN 20 entering br-int, flows to br-tun, is untagged entering GRE tunnel while the
GRE identifier 11111 is set on transmitted packets. At the other end of the GRE tunnel, the traffic having the GRE id 11111 is assigned to VLAN 40, then
flow outside br-tun, to br-int, and is finally untagged before entering B.
Full story from A to C (tenant #1): traffic is tagged with VLAN 20 entering br-int, then flows to br-eth1 which finally untag inbound trafic (or assign a different
VLAN corresponding to the external world)
Switch
Host #1
br-int
br-eth0
eth0
Switch
GRE tunnel in which the traffic really flows
Ethernet link between an adapter and a switch
L2 switch
Network adapter
L3 routed
network
VM or container
Host/server
br-eth1
eth1
br-tun
Tenant #2
Local VLAN 30
Tenant #1
Local VLAN 20
A single bridge is used for
all VMs/containers ; VMs of
different tenants isolated
using local VLANs (not
exposed externally !)
A single bridge is used as
end-points for all GRE
tunnels used for full-mesh
One bridge is
created for
each physical
interface
Host #2
br-int
br-eth0
eth0
br-tun
Tenant #2
Local VLAN 50
Tenant #1
Local VLAN 40
Switch or VLAN
(not related to
internal VLANs)
gre
0
gre
0
A B
Server
C
Flow rules:
Tenant #1: VLAN 20  GRE ID 11111
Tenant #2: VLAN 30  GRE ID 11112
Single patch link between the
two bridges supporting all
traffic from/to full-mesh
Flow rules:
Tenant #1: VLAN 40  GRE ID 11111
Tenant #2: VLAN 50  GRE ID 11112
26
Take away
27
Use Docker for containers hosting, externalize SDN management
Disable bridges management features in Docker, use OpenVSwitch
Abstract from low level network considerations whenever possible, between
hosts (L2 VLANs for instances): consider tunneling
Get further
Use OpenStack Neutron to centralize & automatize the whole network conf.
You definitively use VLANs ? Consider encapsulating several VLANs in your own
tenant network
Other (dirty) options:
Docker in VMs nesting
Multiple Docker instances on the same host
ebtables/iptables/openvswitch acls on flat network
Take away
28

More Related Content

What's hot

Room 1 - 7 - Lê Quốc Đạt - Upgrading network of Openstack to SDN with Tungste...
Room 1 - 7 - Lê Quốc Đạt - Upgrading network of Openstack to SDN with Tungste...Room 1 - 7 - Lê Quốc Đạt - Upgrading network of Openstack to SDN with Tungste...
Room 1 - 7 - Lê Quốc Đạt - Upgrading network of Openstack to SDN with Tungste...Vietnam Open Infrastructure User Group
 
Understanding Open vSwitch
Understanding Open vSwitch Understanding Open vSwitch
Understanding Open vSwitch YongKi Kim
 
How VXLAN works on Linux
How VXLAN works on LinuxHow VXLAN works on Linux
How VXLAN works on LinuxEtsuji Nakai
 
VXLAN and FRRouting
VXLAN and FRRoutingVXLAN and FRRouting
VXLAN and FRRoutingFaisal Reza
 
netconf, restconf, grpc_basic
netconf, restconf, grpc_basicnetconf, restconf, grpc_basic
netconf, restconf, grpc_basicGyewan An
 
Linux Network Administration (LPI-1,LPI-2)
Linux Network Administration (LPI-1,LPI-2)Linux Network Administration (LPI-1,LPI-2)
Linux Network Administration (LPI-1,LPI-2)laonap166
 
Vxlan deep dive session rev0.5 final
Vxlan deep dive session rev0.5   finalVxlan deep dive session rev0.5   final
Vxlan deep dive session rev0.5 finalKwonSun Bae
 
Understand the iptables step by step
Understand the iptables step by stepUnderstand the iptables step by step
Understand the iptables step by stepHungWei Chiu
 
Docker Networking: Control plane and Data plane
Docker Networking: Control plane and Data planeDocker Networking: Control plane and Data plane
Docker Networking: Control plane and Data planeDocker, Inc.
 
Linux Networking Explained
Linux Networking ExplainedLinux Networking Explained
Linux Networking ExplainedThomas Graf
 
VXLAN BGP EVPN: Technology Building Blocks
VXLAN BGP EVPN: Technology Building BlocksVXLAN BGP EVPN: Technology Building Blocks
VXLAN BGP EVPN: Technology Building BlocksAPNIC
 
Linux fundamentals
Linux fundamentalsLinux fundamentals
Linux fundamentalschakrikolla
 
Deploying CloudStack and Ceph with flexible VXLAN and BGP networking
Deploying CloudStack and Ceph with flexible VXLAN and BGP networking Deploying CloudStack and Ceph with flexible VXLAN and BGP networking
Deploying CloudStack and Ceph with flexible VXLAN and BGP networking ShapeBlue
 
OVN - Basics and deep dive
OVN - Basics and deep diveOVN - Basics and deep dive
OVN - Basics and deep diveTrinath Somanchi
 

What's hot (20)

Room 1 - 7 - Lê Quốc Đạt - Upgrading network of Openstack to SDN with Tungste...
Room 1 - 7 - Lê Quốc Đạt - Upgrading network of Openstack to SDN with Tungste...Room 1 - 7 - Lê Quốc Đạt - Upgrading network of Openstack to SDN with Tungste...
Room 1 - 7 - Lê Quốc Đạt - Upgrading network of Openstack to SDN with Tungste...
 
Understanding Open vSwitch
Understanding Open vSwitch Understanding Open vSwitch
Understanding Open vSwitch
 
How VXLAN works on Linux
How VXLAN works on LinuxHow VXLAN works on Linux
How VXLAN works on Linux
 
VXLAN and FRRouting
VXLAN and FRRoutingVXLAN and FRRouting
VXLAN and FRRouting
 
netconf, restconf, grpc_basic
netconf, restconf, grpc_basicnetconf, restconf, grpc_basic
netconf, restconf, grpc_basic
 
HSRP ccna
HSRP ccna HSRP ccna
HSRP ccna
 
Demystifying openvswitch
Demystifying openvswitchDemystifying openvswitch
Demystifying openvswitch
 
Linux Network Administration (LPI-1,LPI-2)
Linux Network Administration (LPI-1,LPI-2)Linux Network Administration (LPI-1,LPI-2)
Linux Network Administration (LPI-1,LPI-2)
 
Vxlan deep dive session rev0.5 final
Vxlan deep dive session rev0.5   finalVxlan deep dive session rev0.5   final
Vxlan deep dive session rev0.5 final
 
Understand the iptables step by step
Understand the iptables step by stepUnderstand the iptables step by step
Understand the iptables step by step
 
Docker Networking: Control plane and Data plane
Docker Networking: Control plane and Data planeDocker Networking: Control plane and Data plane
Docker Networking: Control plane and Data plane
 
Adapting to evolving user, security, and business needs with aruba clear pass
Adapting to evolving user, security, and business needs with aruba clear passAdapting to evolving user, security, and business needs with aruba clear pass
Adapting to evolving user, security, and business needs with aruba clear pass
 
Aruba ClearPass Guest 6.3 User Guide
Aruba ClearPass Guest 6.3 User GuideAruba ClearPass Guest 6.3 User Guide
Aruba ClearPass Guest 6.3 User Guide
 
Linux Networking Explained
Linux Networking ExplainedLinux Networking Explained
Linux Networking Explained
 
VXLAN BGP EVPN: Technology Building Blocks
VXLAN BGP EVPN: Technology Building BlocksVXLAN BGP EVPN: Technology Building Blocks
VXLAN BGP EVPN: Technology Building Blocks
 
VLAN vs VXLAN
VLAN vs VXLANVLAN vs VXLAN
VLAN vs VXLAN
 
Linux fundamentals
Linux fundamentalsLinux fundamentals
Linux fundamentals
 
Deploying CloudStack and Ceph with flexible VXLAN and BGP networking
Deploying CloudStack and Ceph with flexible VXLAN and BGP networking Deploying CloudStack and Ceph with flexible VXLAN and BGP networking
Deploying CloudStack and Ceph with flexible VXLAN and BGP networking
 
Optimizing Aruba WLANs for Roaming Devices
Optimizing Aruba WLANs for Roaming DevicesOptimizing Aruba WLANs for Roaming Devices
Optimizing Aruba WLANs for Roaming Devices
 
OVN - Basics and deep dive
OVN - Basics and deep diveOVN - Basics and deep dive
OVN - Basics and deep dive
 

Viewers also liked

THETA S + Raspberry pi 2でライブストリーミングしてみた(続)
THETA S + Raspberry pi 2でライブストリーミングしてみた(続)THETA S + Raspberry pi 2でライブストリーミングしてみた(続)
THETA S + Raspberry pi 2でライブストリーミングしてみた(続)Shuichiro Fukuoka
 
DevOps à l'échelle: ce que l'on a fait, ce que l'on a appris chez Societe Gen...
DevOps à l'échelle: ce que l'on a fait, ce que l'on a appris chez Societe Gen...DevOps à l'échelle: ce que l'on a fait, ce que l'on a appris chez Societe Gen...
DevOps à l'échelle: ce que l'on a fait, ce que l'on a appris chez Societe Gen...Adrien Blind
 
Docker cloud hybridation & orchestration
Docker cloud hybridation & orchestrationDocker cloud hybridation & orchestration
Docker cloud hybridation & orchestrationAdrien Blind
 
When Docker Engine 1.12 features unleashes software architecture
When Docker Engine 1.12 features unleashes software architectureWhen Docker Engine 1.12 features unleashes software architecture
When Docker Engine 1.12 features unleashes software architecture Adrien Blind
 
Petit déjeuner Octo - L'infra au service de ses projets
Petit déjeuner Octo - L'infra au service de ses projetsPetit déjeuner Octo - L'infra au service de ses projets
Petit déjeuner Octo - L'infra au service de ses projetsAdrien Blind
 
Introduction to Unikernels at first Paris Unikernels meetup
Introduction to Unikernels at first Paris Unikernels meetupIntroduction to Unikernels at first Paris Unikernels meetup
Introduction to Unikernels at first Paris Unikernels meetupAdrien Blind
 
DevOps at scale: what we did, what we learned at Societe Generale
DevOps at scale: what we did, what we learned at Societe GeneraleDevOps at scale: what we did, what we learned at Societe Generale
DevOps at scale: what we did, what we learned at Societe GeneraleAdrien Blind
 
Continous delivery at docker age
Continous delivery at docker ageContinous delivery at docker age
Continous delivery at docker ageAdrien Blind
 
DevOps, NoOps, everything-as-code, commoditisation… Quel futur pour les ops ?
DevOps, NoOps, everything-as-code, commoditisation… Quel futur pour les ops ?DevOps, NoOps, everything-as-code, commoditisation… Quel futur pour les ops ?
DevOps, NoOps, everything-as-code, commoditisation… Quel futur pour les ops ?Adrien Blind
 
Skynet vs planet of apes
Skynet vs planet of apesSkynet vs planet of apes
Skynet vs planet of apesAdrien Blind
 
Dockercon Europe 2014 - Continuous Delivery leveraging on Docker CaaS
Dockercon Europe 2014 - Continuous Delivery leveraging on Docker CaaSDockercon Europe 2014 - Continuous Delivery leveraging on Docker CaaS
Dockercon Europe 2014 - Continuous Delivery leveraging on Docker CaaSAdrien Blind
 
Identity & Access Management in the cloud
Identity & Access Management in the cloudIdentity & Access Management in the cloud
Identity & Access Management in the cloudAdrien Blind
 
Monitoring de conteneurs en production - Jonathan Raffre & Jean-Pascal Thiery
Monitoring de conteneurs en production - Jonathan Raffre & Jean-Pascal ThieryMonitoring de conteneurs en production - Jonathan Raffre & Jean-Pascal Thiery
Monitoring de conteneurs en production - Jonathan Raffre & Jean-Pascal ThieryParis Container Day
 
Docker: Redistributing DevOps cards, on the way to PaaS
Docker: Redistributing DevOps cards, on the way to PaaSDocker: Redistributing DevOps cards, on the way to PaaS
Docker: Redistributing DevOps cards, on the way to PaaSAdrien Blind
 
Living the Nomadic life - Nic Jackson
Living the Nomadic life - Nic JacksonLiving the Nomadic life - Nic Jackson
Living the Nomadic life - Nic JacksonParis Container Day
 
The missing piece : when Docker networking and services finally unleashes so...
 The missing piece : when Docker networking and services finally unleashes so... The missing piece : when Docker networking and services finally unleashes so...
The missing piece : when Docker networking and services finally unleashes so...Adrien Blind
 
Docker, Pierre angulaire du continuous delivery ?
Docker, Pierre angulaire du continuous delivery ?Docker, Pierre angulaire du continuous delivery ?
Docker, Pierre angulaire du continuous delivery ?Adrien Blind
 
Full stack automation - TIAD 2015
Full stack automation - TIAD 2015Full stack automation - TIAD 2015
Full stack automation - TIAD 2015Adrien Blind
 
There is no container - Ori Pekelman
There is no container - Ori PekelmanThere is no container - Ori Pekelman
There is no container - Ori PekelmanParis Container Day
 

Viewers also liked (20)

Webpacker 3 on Docker
Webpacker 3 on DockerWebpacker 3 on Docker
Webpacker 3 on Docker
 
THETA S + Raspberry pi 2でライブストリーミングしてみた(続)
THETA S + Raspberry pi 2でライブストリーミングしてみた(続)THETA S + Raspberry pi 2でライブストリーミングしてみた(続)
THETA S + Raspberry pi 2でライブストリーミングしてみた(続)
 
DevOps à l'échelle: ce que l'on a fait, ce que l'on a appris chez Societe Gen...
DevOps à l'échelle: ce que l'on a fait, ce que l'on a appris chez Societe Gen...DevOps à l'échelle: ce que l'on a fait, ce que l'on a appris chez Societe Gen...
DevOps à l'échelle: ce que l'on a fait, ce que l'on a appris chez Societe Gen...
 
Docker cloud hybridation & orchestration
Docker cloud hybridation & orchestrationDocker cloud hybridation & orchestration
Docker cloud hybridation & orchestration
 
When Docker Engine 1.12 features unleashes software architecture
When Docker Engine 1.12 features unleashes software architectureWhen Docker Engine 1.12 features unleashes software architecture
When Docker Engine 1.12 features unleashes software architecture
 
Petit déjeuner Octo - L'infra au service de ses projets
Petit déjeuner Octo - L'infra au service de ses projetsPetit déjeuner Octo - L'infra au service de ses projets
Petit déjeuner Octo - L'infra au service de ses projets
 
Introduction to Unikernels at first Paris Unikernels meetup
Introduction to Unikernels at first Paris Unikernels meetupIntroduction to Unikernels at first Paris Unikernels meetup
Introduction to Unikernels at first Paris Unikernels meetup
 
DevOps at scale: what we did, what we learned at Societe Generale
DevOps at scale: what we did, what we learned at Societe GeneraleDevOps at scale: what we did, what we learned at Societe Generale
DevOps at scale: what we did, what we learned at Societe Generale
 
Continous delivery at docker age
Continous delivery at docker ageContinous delivery at docker age
Continous delivery at docker age
 
DevOps, NoOps, everything-as-code, commoditisation… Quel futur pour les ops ?
DevOps, NoOps, everything-as-code, commoditisation… Quel futur pour les ops ?DevOps, NoOps, everything-as-code, commoditisation… Quel futur pour les ops ?
DevOps, NoOps, everything-as-code, commoditisation… Quel futur pour les ops ?
 
Skynet vs planet of apes
Skynet vs planet of apesSkynet vs planet of apes
Skynet vs planet of apes
 
Dockercon Europe 2014 - Continuous Delivery leveraging on Docker CaaS
Dockercon Europe 2014 - Continuous Delivery leveraging on Docker CaaSDockercon Europe 2014 - Continuous Delivery leveraging on Docker CaaS
Dockercon Europe 2014 - Continuous Delivery leveraging on Docker CaaS
 
Identity & Access Management in the cloud
Identity & Access Management in the cloudIdentity & Access Management in the cloud
Identity & Access Management in the cloud
 
Monitoring de conteneurs en production - Jonathan Raffre & Jean-Pascal Thiery
Monitoring de conteneurs en production - Jonathan Raffre & Jean-Pascal ThieryMonitoring de conteneurs en production - Jonathan Raffre & Jean-Pascal Thiery
Monitoring de conteneurs en production - Jonathan Raffre & Jean-Pascal Thiery
 
Docker: Redistributing DevOps cards, on the way to PaaS
Docker: Redistributing DevOps cards, on the way to PaaSDocker: Redistributing DevOps cards, on the way to PaaS
Docker: Redistributing DevOps cards, on the way to PaaS
 
Living the Nomadic life - Nic Jackson
Living the Nomadic life - Nic JacksonLiving the Nomadic life - Nic Jackson
Living the Nomadic life - Nic Jackson
 
The missing piece : when Docker networking and services finally unleashes so...
 The missing piece : when Docker networking and services finally unleashes so... The missing piece : when Docker networking and services finally unleashes so...
The missing piece : when Docker networking and services finally unleashes so...
 
Docker, Pierre angulaire du continuous delivery ?
Docker, Pierre angulaire du continuous delivery ?Docker, Pierre angulaire du continuous delivery ?
Docker, Pierre angulaire du continuous delivery ?
 
Full stack automation - TIAD 2015
Full stack automation - TIAD 2015Full stack automation - TIAD 2015
Full stack automation - TIAD 2015
 
There is no container - Ori Pekelman
There is no container - Ori PekelmanThere is no container - Ori Pekelman
There is no container - Ori Pekelman
 

Similar to Docker networking basics & coupling with Software Defined Networks

Docker Multihost Networking
Docker Multihost Networking Docker Multihost Networking
Docker Multihost Networking Nicola Kabar
 
How to build a Kubernetes networking solution from scratch
How to build a Kubernetes networking solution from scratchHow to build a Kubernetes networking solution from scratch
How to build a Kubernetes networking solution from scratchAll Things Open
 
Tungsten Fabric Overview
Tungsten Fabric OverviewTungsten Fabric Overview
Tungsten Fabric OverviewMichelle Holley
 
SDN: an introduction
SDN: an introductionSDN: an introduction
SDN: an introductionLuca Profico
 
Single Host Docker Networking
Single Host Docker NetworkingSingle Host Docker Networking
Single Host Docker Networkingallingeek
 
"One network to rule them all" - OpenStack Summit Austin 2016
"One network to rule them all" - OpenStack Summit Austin 2016"One network to rule them all" - OpenStack Summit Austin 2016
"One network to rule them all" - OpenStack Summit Austin 2016Phil Estes
 
Building a sdn solution for the deployment of web application stacks in docker
Building a sdn solution for the deployment of web application stacks in dockerBuilding a sdn solution for the deployment of web application stacks in docker
Building a sdn solution for the deployment of web application stacks in dockerJorge Juan Mendoza
 
Network Design patters with Docker
Network Design patters with DockerNetwork Design patters with Docker
Network Design patters with DockerDaniel Finneran
 
Sdn dell lab report v2
Sdn dell lab report v2Sdn dell lab report v2
Sdn dell lab report v2Oded Rotter
 
Deep Dive in Docker Overlay Networks - Laurent Bernaille - Architect, D2SI
Deep Dive in Docker Overlay Networks - Laurent Bernaille - Architect, D2SIDeep Dive in Docker Overlay Networks - Laurent Bernaille - Architect, D2SI
Deep Dive in Docker Overlay Networks - Laurent Bernaille - Architect, D2SIDocker, Inc.
 
Pushing Packets - How do the ML2 Mechanism Drivers Stack Up
Pushing Packets - How do the ML2 Mechanism Drivers Stack UpPushing Packets - How do the ML2 Mechanism Drivers Stack Up
Pushing Packets - How do the ML2 Mechanism Drivers Stack UpJames Denton
 
vPC techonology for full ha from dc core to baremetel server.
vPC techonology for full ha from dc core to baremetel server.vPC techonology for full ha from dc core to baremetel server.
vPC techonology for full ha from dc core to baremetel server.Ajeet Singh
 
Openstack openswitch basics
Openstack openswitch basicsOpenstack openswitch basics
Openstack openswitch basicsnshah061
 
Octo talk : docker multi-host networking
Octo talk : docker multi-host networking Octo talk : docker multi-host networking
Octo talk : docker multi-host networking Hervé Leclerc
 
Docker 1.11 Meetup: Networking Showcase
Docker 1.11 Meetup: Networking ShowcaseDocker 1.11 Meetup: Networking Showcase
Docker 1.11 Meetup: Networking ShowcaseDocker, Inc.
 
Docker Meetup: Docker Networking 1.11, by Madhu Venugopal
Docker Meetup: Docker Networking 1.11, by Madhu VenugopalDocker Meetup: Docker Networking 1.11, by Madhu Venugopal
Docker Meetup: Docker Networking 1.11, by Madhu VenugopalMichelle Antebi
 
Docker Meetup: Docker Networking 1.11 with Madhu Venugopal
Docker Meetup: Docker Networking 1.11 with Madhu VenugopalDocker Meetup: Docker Networking 1.11 with Madhu Venugopal
Docker Meetup: Docker Networking 1.11 with Madhu VenugopalDocker, Inc.
 

Similar to Docker networking basics & coupling with Software Defined Networks (20)

Docker Multihost Networking
Docker Multihost Networking Docker Multihost Networking
Docker Multihost Networking
 
How to build a Kubernetes networking solution from scratch
How to build a Kubernetes networking solution from scratchHow to build a Kubernetes networking solution from scratch
How to build a Kubernetes networking solution from scratch
 
OpenStack sdn
OpenStack sdnOpenStack sdn
OpenStack sdn
 
Tungsten Fabric Overview
Tungsten Fabric OverviewTungsten Fabric Overview
Tungsten Fabric Overview
 
Docker networking
Docker networkingDocker networking
Docker networking
 
SDN: an introduction
SDN: an introductionSDN: an introduction
SDN: an introduction
 
Single Host Docker Networking
Single Host Docker NetworkingSingle Host Docker Networking
Single Host Docker Networking
 
"One network to rule them all" - OpenStack Summit Austin 2016
"One network to rule them all" - OpenStack Summit Austin 2016"One network to rule them all" - OpenStack Summit Austin 2016
"One network to rule them all" - OpenStack Summit Austin 2016
 
Building a sdn solution for the deployment of web application stacks in docker
Building a sdn solution for the deployment of web application stacks in dockerBuilding a sdn solution for the deployment of web application stacks in docker
Building a sdn solution for the deployment of web application stacks in docker
 
Network Design patters with Docker
Network Design patters with DockerNetwork Design patters with Docker
Network Design patters with Docker
 
Sdn dell lab report v2
Sdn dell lab report v2Sdn dell lab report v2
Sdn dell lab report v2
 
Simplify Networking for Containers
Simplify Networking for ContainersSimplify Networking for Containers
Simplify Networking for Containers
 
Deep Dive in Docker Overlay Networks - Laurent Bernaille - Architect, D2SI
Deep Dive in Docker Overlay Networks - Laurent Bernaille - Architect, D2SIDeep Dive in Docker Overlay Networks - Laurent Bernaille - Architect, D2SI
Deep Dive in Docker Overlay Networks - Laurent Bernaille - Architect, D2SI
 
Pushing Packets - How do the ML2 Mechanism Drivers Stack Up
Pushing Packets - How do the ML2 Mechanism Drivers Stack UpPushing Packets - How do the ML2 Mechanism Drivers Stack Up
Pushing Packets - How do the ML2 Mechanism Drivers Stack Up
 
vPC techonology for full ha from dc core to baremetel server.
vPC techonology for full ha from dc core to baremetel server.vPC techonology for full ha from dc core to baremetel server.
vPC techonology for full ha from dc core to baremetel server.
 
Openstack openswitch basics
Openstack openswitch basicsOpenstack openswitch basics
Openstack openswitch basics
 
Octo talk : docker multi-host networking
Octo talk : docker multi-host networking Octo talk : docker multi-host networking
Octo talk : docker multi-host networking
 
Docker 1.11 Meetup: Networking Showcase
Docker 1.11 Meetup: Networking ShowcaseDocker 1.11 Meetup: Networking Showcase
Docker 1.11 Meetup: Networking Showcase
 
Docker Meetup: Docker Networking 1.11, by Madhu Venugopal
Docker Meetup: Docker Networking 1.11, by Madhu VenugopalDocker Meetup: Docker Networking 1.11, by Madhu Venugopal
Docker Meetup: Docker Networking 1.11, by Madhu Venugopal
 
Docker Meetup: Docker Networking 1.11 with Madhu Venugopal
Docker Meetup: Docker Networking 1.11 with Madhu VenugopalDocker Meetup: Docker Networking 1.11 with Madhu Venugopal
Docker Meetup: Docker Networking 1.11 with Madhu Venugopal
 

More from Adrien Blind

Introdution to Dataops and AIOps (or MLOps)
Introdution to Dataops and AIOps (or MLOps)Introdution to Dataops and AIOps (or MLOps)
Introdution to Dataops and AIOps (or MLOps)Adrien Blind
 
DataOps introduction : DataOps is not only DevOps applied to data!
DataOps introduction : DataOps is not only DevOps applied to data!DataOps introduction : DataOps is not only DevOps applied to data!
DataOps introduction : DataOps is not only DevOps applied to data!Adrien Blind
 
An introduction to Serverless
An introduction to ServerlessAn introduction to Serverless
An introduction to ServerlessAdrien Blind
 
Unleash software architecture leveraging on docker
Unleash software architecture leveraging on dockerUnleash software architecture leveraging on docker
Unleash software architecture leveraging on dockerAdrien Blind
 
Docker, cornerstone of cloud hybridation ? [Cloud Expo Europe 2016]
Docker, cornerstone of cloud hybridation ? [Cloud Expo Europe 2016]Docker, cornerstone of cloud hybridation ? [Cloud Expo Europe 2016]
Docker, cornerstone of cloud hybridation ? [Cloud Expo Europe 2016]Adrien Blind
 
Docker, cornerstone of an hybrid cloud?
Docker, cornerstone of an hybrid cloud?Docker, cornerstone of an hybrid cloud?
Docker, cornerstone of an hybrid cloud?Adrien Blind
 

More from Adrien Blind (6)

Introdution to Dataops and AIOps (or MLOps)
Introdution to Dataops and AIOps (or MLOps)Introdution to Dataops and AIOps (or MLOps)
Introdution to Dataops and AIOps (or MLOps)
 
DataOps introduction : DataOps is not only DevOps applied to data!
DataOps introduction : DataOps is not only DevOps applied to data!DataOps introduction : DataOps is not only DevOps applied to data!
DataOps introduction : DataOps is not only DevOps applied to data!
 
An introduction to Serverless
An introduction to ServerlessAn introduction to Serverless
An introduction to Serverless
 
Unleash software architecture leveraging on docker
Unleash software architecture leveraging on dockerUnleash software architecture leveraging on docker
Unleash software architecture leveraging on docker
 
Docker, cornerstone of cloud hybridation ? [Cloud Expo Europe 2016]
Docker, cornerstone of cloud hybridation ? [Cloud Expo Europe 2016]Docker, cornerstone of cloud hybridation ? [Cloud Expo Europe 2016]
Docker, cornerstone of cloud hybridation ? [Cloud Expo Europe 2016]
 
Docker, cornerstone of an hybrid cloud?
Docker, cornerstone of an hybrid cloud?Docker, cornerstone of an hybrid cloud?
Docker, cornerstone of an hybrid cloud?
 

Recently uploaded

EMEA What is ThousandEyes? Webinar
EMEA What is ThousandEyes? WebinarEMEA What is ThousandEyes? Webinar
EMEA What is ThousandEyes? WebinarThousandEyes
 
CyberSecurity - Computers In Libraries 2024
CyberSecurity - Computers In Libraries 2024CyberSecurity - Computers In Libraries 2024
CyberSecurity - Computers In Libraries 2024Brian Pichman
 
The Zero-ETL Approach: Enhancing Data Agility and Insight
The Zero-ETL Approach: Enhancing Data Agility and InsightThe Zero-ETL Approach: Enhancing Data Agility and Insight
The Zero-ETL Approach: Enhancing Data Agility and InsightSafe Software
 
2024.03.12 Cost drivers of cultivated meat production.pdf
2024.03.12 Cost drivers of cultivated meat production.pdf2024.03.12 Cost drivers of cultivated meat production.pdf
2024.03.12 Cost drivers of cultivated meat production.pdfThe Good Food Institute
 
Where developers are challenged, what developers want and where DevEx is going
Where developers are challenged, what developers want and where DevEx is goingWhere developers are challenged, what developers want and where DevEx is going
Where developers are challenged, what developers want and where DevEx is goingFrancesco Corti
 
Graphene Quantum Dots-Based Composites for Biomedical Applications
Graphene Quantum Dots-Based Composites for  Biomedical ApplicationsGraphene Quantum Dots-Based Composites for  Biomedical Applications
Graphene Quantum Dots-Based Composites for Biomedical Applicationsnooralam814309
 
From the origin to the future of Open Source model and business
From the origin to the future of  Open Source model and businessFrom the origin to the future of  Open Source model and business
From the origin to the future of Open Source model and businessFrancesco Corti
 
TrustArc Webinar - How to Live in a Post Third-Party Cookie World
TrustArc Webinar - How to Live in a Post Third-Party Cookie WorldTrustArc Webinar - How to Live in a Post Third-Party Cookie World
TrustArc Webinar - How to Live in a Post Third-Party Cookie WorldTrustArc
 
UiPath Studio Web workshop series - Day 2
UiPath Studio Web workshop series - Day 2UiPath Studio Web workshop series - Day 2
UiPath Studio Web workshop series - Day 2DianaGray10
 
UiPath Studio Web workshop series - Day 4
UiPath Studio Web workshop series - Day 4UiPath Studio Web workshop series - Day 4
UiPath Studio Web workshop series - Day 4DianaGray10
 
Novo Nordisk's journey in developing an open-source application on Neo4j
Novo Nordisk's journey in developing an open-source application on Neo4jNovo Nordisk's journey in developing an open-source application on Neo4j
Novo Nordisk's journey in developing an open-source application on Neo4jNeo4j
 
IT Service Management (ITSM) Best Practices for Advanced Computing
IT Service Management (ITSM) Best Practices for Advanced ComputingIT Service Management (ITSM) Best Practices for Advanced Computing
IT Service Management (ITSM) Best Practices for Advanced ComputingMAGNIntelligence
 
Stobox 4: Revolutionizing Investment in Real-World Assets Through Tokenization
Stobox 4: Revolutionizing Investment in Real-World Assets Through TokenizationStobox 4: Revolutionizing Investment in Real-World Assets Through Tokenization
Stobox 4: Revolutionizing Investment in Real-World Assets Through TokenizationStobox
 
Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024
Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024
Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024Alkin Tezuysal
 
Flow Control | Block Size | ST Min | First Frame
Flow Control | Block Size | ST Min | First FrameFlow Control | Block Size | ST Min | First Frame
Flow Control | Block Size | ST Min | First FrameKapil Thakar
 
Q4 2023 Quarterly Investor Presentation - FINAL - v1.pdf
Q4 2023 Quarterly Investor Presentation - FINAL - v1.pdfQ4 2023 Quarterly Investor Presentation - FINAL - v1.pdf
Q4 2023 Quarterly Investor Presentation - FINAL - v1.pdfTejal81
 
Extra-120324-Visite-Entreprise-icare.pdf
Extra-120324-Visite-Entreprise-icare.pdfExtra-120324-Visite-Entreprise-icare.pdf
Extra-120324-Visite-Entreprise-icare.pdfInfopole1
 
GraphSummit Copenhagen 2024 - Neo4j Vision and Roadmap.pptx
GraphSummit Copenhagen 2024 - Neo4j Vision and Roadmap.pptxGraphSummit Copenhagen 2024 - Neo4j Vision and Roadmap.pptx
GraphSummit Copenhagen 2024 - Neo4j Vision and Roadmap.pptxNeo4j
 
3 Pitfalls Everyone Should Avoid with Cloud Data
3 Pitfalls Everyone Should Avoid with Cloud Data3 Pitfalls Everyone Should Avoid with Cloud Data
3 Pitfalls Everyone Should Avoid with Cloud DataEric D. Schabell
 
Introduction to RAG (Retrieval Augmented Generation) and its application
Introduction to RAG (Retrieval Augmented Generation) and its applicationIntroduction to RAG (Retrieval Augmented Generation) and its application
Introduction to RAG (Retrieval Augmented Generation) and its applicationKnoldus Inc.
 

Recently uploaded (20)

EMEA What is ThousandEyes? Webinar
EMEA What is ThousandEyes? WebinarEMEA What is ThousandEyes? Webinar
EMEA What is ThousandEyes? Webinar
 
CyberSecurity - Computers In Libraries 2024
CyberSecurity - Computers In Libraries 2024CyberSecurity - Computers In Libraries 2024
CyberSecurity - Computers In Libraries 2024
 
The Zero-ETL Approach: Enhancing Data Agility and Insight
The Zero-ETL Approach: Enhancing Data Agility and InsightThe Zero-ETL Approach: Enhancing Data Agility and Insight
The Zero-ETL Approach: Enhancing Data Agility and Insight
 
2024.03.12 Cost drivers of cultivated meat production.pdf
2024.03.12 Cost drivers of cultivated meat production.pdf2024.03.12 Cost drivers of cultivated meat production.pdf
2024.03.12 Cost drivers of cultivated meat production.pdf
 
Where developers are challenged, what developers want and where DevEx is going
Where developers are challenged, what developers want and where DevEx is goingWhere developers are challenged, what developers want and where DevEx is going
Where developers are challenged, what developers want and where DevEx is going
 
Graphene Quantum Dots-Based Composites for Biomedical Applications
Graphene Quantum Dots-Based Composites for  Biomedical ApplicationsGraphene Quantum Dots-Based Composites for  Biomedical Applications
Graphene Quantum Dots-Based Composites for Biomedical Applications
 
From the origin to the future of Open Source model and business
From the origin to the future of  Open Source model and businessFrom the origin to the future of  Open Source model and business
From the origin to the future of Open Source model and business
 
TrustArc Webinar - How to Live in a Post Third-Party Cookie World
TrustArc Webinar - How to Live in a Post Third-Party Cookie WorldTrustArc Webinar - How to Live in a Post Third-Party Cookie World
TrustArc Webinar - How to Live in a Post Third-Party Cookie World
 
UiPath Studio Web workshop series - Day 2
UiPath Studio Web workshop series - Day 2UiPath Studio Web workshop series - Day 2
UiPath Studio Web workshop series - Day 2
 
UiPath Studio Web workshop series - Day 4
UiPath Studio Web workshop series - Day 4UiPath Studio Web workshop series - Day 4
UiPath Studio Web workshop series - Day 4
 
Novo Nordisk's journey in developing an open-source application on Neo4j
Novo Nordisk's journey in developing an open-source application on Neo4jNovo Nordisk's journey in developing an open-source application on Neo4j
Novo Nordisk's journey in developing an open-source application on Neo4j
 
IT Service Management (ITSM) Best Practices for Advanced Computing
IT Service Management (ITSM) Best Practices for Advanced ComputingIT Service Management (ITSM) Best Practices for Advanced Computing
IT Service Management (ITSM) Best Practices for Advanced Computing
 
Stobox 4: Revolutionizing Investment in Real-World Assets Through Tokenization
Stobox 4: Revolutionizing Investment in Real-World Assets Through TokenizationStobox 4: Revolutionizing Investment in Real-World Assets Through Tokenization
Stobox 4: Revolutionizing Investment in Real-World Assets Through Tokenization
 
Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024
Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024
Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024
 
Flow Control | Block Size | ST Min | First Frame
Flow Control | Block Size | ST Min | First FrameFlow Control | Block Size | ST Min | First Frame
Flow Control | Block Size | ST Min | First Frame
 
Q4 2023 Quarterly Investor Presentation - FINAL - v1.pdf
Q4 2023 Quarterly Investor Presentation - FINAL - v1.pdfQ4 2023 Quarterly Investor Presentation - FINAL - v1.pdf
Q4 2023 Quarterly Investor Presentation - FINAL - v1.pdf
 
Extra-120324-Visite-Entreprise-icare.pdf
Extra-120324-Visite-Entreprise-icare.pdfExtra-120324-Visite-Entreprise-icare.pdf
Extra-120324-Visite-Entreprise-icare.pdf
 
GraphSummit Copenhagen 2024 - Neo4j Vision and Roadmap.pptx
GraphSummit Copenhagen 2024 - Neo4j Vision and Roadmap.pptxGraphSummit Copenhagen 2024 - Neo4j Vision and Roadmap.pptx
GraphSummit Copenhagen 2024 - Neo4j Vision and Roadmap.pptx
 
3 Pitfalls Everyone Should Avoid with Cloud Data
3 Pitfalls Everyone Should Avoid with Cloud Data3 Pitfalls Everyone Should Avoid with Cloud Data
3 Pitfalls Everyone Should Avoid with Cloud Data
 
Introduction to RAG (Retrieval Augmented Generation) and its application
Introduction to RAG (Retrieval Augmented Generation) and its applicationIntroduction to RAG (Retrieval Augmented Generation) and its application
Introduction to RAG (Retrieval Augmented Generation) and its application
 

Docker networking basics & coupling with Software Defined Networks

  • 1. 1 Tél : +33 (0)1 58 56 10 00 Fax : +33 (0)1 58 56 10 01 www.octo.com© OCTO 2013 50, avenue des Champs-Elysées 75008 Paris - FRANCE Follow us on Twitter! @AdrienBlind @ArnaudMazin
  • 2. 2 REMINDER: DOCKER NETWORKING Agenda INTRODUCTION TO SOFTWARE DEFINED NETWORKS MIX UP 1 TAKE AWAY 2 4 3
  • 4. 4 Host Natively, each container runs isolated from the outside world A bridge network (an internal, virtual switch) is provided with Docker but does not allow containerized processes to communicate together without further config (see next slides) Isolation by design Container ‘app’ Bridge docker0 Container ‘db’ Tomcat (port 8080) MySQL (port 3306)
  • 5. 5 Exposing ports allows containers services to talk together through the bridge network Dockerfile: add line “EXPOSE <port>” (several ports can be appended) Command line switch: “docker run ... –expose <port>” Example for the ‘app’ container: “docker run ... –expose 8080” Exposing ports Host Container ‘app’ Bridge docker0 Container ‘db’ Tomcat (port 8080) MySQL (port 3306) TCP 3306 exposed TCP 8080 exposed « The app is able to talk to its database »
  • 6. 6 Linking enables a client container to get information related to a resource container (also known as the linked container) Command line switch: “docker run -link <containername:alias>” Example on ‘app’ container: “docker –run … –link db:dbalias” Linking containers Host Container ‘app’ Bridge docker0 Container ‘db’ Tomcat (port 8080) MySQL (port 3306) Env variables DBALIAS_PORT_3306_TCP=tcp://1.2.3.4:3306 DBALIAS_PORT_3306_TCP_PROTO=tcp DBALIAS_PORT_3306_TCP_ADDR=1.2.3.4 DBALIAS_PORT_3306_TCP_PORT=3306 « The app knows where to join its database »
  • 7. 7 Mapping ports enable to publish container’s ports on “external interfaces”. Ports may be translated. Command line switch: “docker run -p <externalport:insideport>” Example for ‘app’ container: “docker –run … –p 80:8080” Mapping ports Host Container ‘app’ Bridge docker0 Container ‘db’ Tomcat (port 8080) MySQL (port 3306) « The app is reachable from the external network at port 80 of the host, while the database container only remains reachable to other containers » IP_interface TCP 80 map Tomcat’s 8080 port External network
  • 8. 8 These characteristics enables containers: To either remain fully isolated or talk to all other containers of the same host having their services exposed To map one-by-one services on the hosts interface Hmm… What if I want to isolate groups of containers? Conclusion
  • 9. 9 Introduction to Software Defined Networks
  • 10. 10 Traditional datacenter management VM VM VM VM VM VM VM VM VM Internet Internet DMZ Physical overview Logical overview Tenant #1 Tenant #3 Tenant #2 LAN DMZ LAN DMZ1 DMZ2 Logical topologies are quite different from physical ones These designs traditionally relies a lot on low network layers (L2, etc.)
  • 11. 11 Multi datacenter perspective VM VM VM VM VM VM VM VM VM Physical overview VM VM VM VM VM VM VM VM VM • Limited to 2048 VLANs • Lack of dynamic provisioning • Involves subnetting or encapsulation to flow over L3 networks Internet
  • 12. 12 SDNs proposes network solutions embracing cloud paradigms Massively multi-tenant Thousands tenants, massively scalable Easy & fast (de)provisioning Infra as code, API centric Infrastructure agnostic L3, does not stick with lower levels (physical designs, vlans & co) Decouple infrastructure & tenants lifecycles Cross technology, vendor agnostic SDNs value proposal
  • 13. 13 Enables to abstract networking topologies & services from wiring and equipments Centralize network intelligence Standardized management APIs: ex. OpenFlow for both physical & virtual network equipments SDNs overview (Source Wikipedia)
  • 14. 14 On hosts (hypervisors, Docker hosts…), SDNs mostly rely on: Allocating network bridges (virtual and internal switches) Setting ACLs to decide which flow to allow or deny Connecting these bridges to external world through real host’s interfaces Host perspective
  • 15. 15 Network perspective – Low level isolation Host #3 SDN network #1 SDN network #1 Host #1 SDN network #1 SDN network #1 Host #2 SDN network #1 L2-Network focused Keep traditional paradigms but use API/centralize intelligence Requires VLANs, VPLS… to spread same virtual networks accross several hosts Enforces low-level isolation Consider API-based network configuration (ie. OpenFlow) to centralize and facilitates network management, making it more dynamic VPLS Router Physical net. VPLS network The link tags both virtual network trafics in vlans The VPLS ensure providing L2 networks at all ends – strong req.!
  • 16. 16 Full-mesh, network agnostic and encapsulated approach Relies on L3 networks and GRE, VXLAN… tunnels for inter-hosts communication (avoid using L2) Network agnostic, til hosts can route trafic SDN Routers must route traffic between an inner virtual net and the ext. world Network perspective – Full mesh Host #3 Host #1 Host #2 SDN network #1 SDN network #1 SDN network #1 SDN network #1 SDN network #1 Router Physical net. Flow encapsulation L3 network
  • 18. 18 How to support several containers related to a same tenant, accross multiple hosts (or even multiple datacenters or providers), and avoid them to talk to other containers in the same time ? Answer to this question enables several usecases Isolate containers of a same app without having to face limits of a single Docker host Resilience (ex. spread an app server farm over multiple hosts) Multi providers (ex. spread containers over several clouds/hosters, overflow mgmt…) … Usecases – Back to Docker Internet LAN DMZ DMZ DMZ 1 DMZ 2 LAN Container Tenant #1 Tenant #3 Tenant #2
  • 19. 19 Host #1 Host #3Host #2 0. From where we start Container ‘app’ Container ‘db’ Bridgedocker0 Container ‘app’ Container ‘db’ Bridgedocker0 Container ‘app’ Container ‘db’ Container ‘app’ Bridgedocker0 Container ‘app’ TCP ports of services running in containers are mapped Get rid of actual Docker bridges implementation ! If not, all containers will talk together across a same host
  • 20. 20 Use OpenVSwitch to create bridges on each host, for each tenant’s subnet. For instance, on host #1: » ovs-vsctl add-br tech-br » ovs-vsctl add-port tech-br tep0 -- set interface tep0 type=internal » ifconfig tep0 192.168.1.1 netmask 255.255.255.0 » ovs-vsctl add-br sdn-br0 » ovs-vsctl set bridge sdn-br0 stp_enable=true 1. Create SDN compliant bridges Host #1 sdn-br0 Host #3 sdn-br0 sdn-br1 Host #2 sdn-br0 sdn-br1 Simplified view. Detailed insight exposed in later slides Once per host: common plumbing (detailed slide 24) For each bridge: create and protect against ethernet loops using Spanning Tree Protocol (beware, in complex/large deployments, it may consumes a lot of CPU!)
  • 21. 21 2. Link SDN bridges Host #1 sdn-br0 Host #3 sdn-br0 sdn-br1 Host #2 sdn-br0 sdn-br1 Use OpenVSwitch to link corresponding bridges accross hosts In this example, we decided to use the full-mesh approach. On host #1: ovs-vsctl add-port sdn-br0 gre0 --set interface gre0 type=gre options:remote_ip:1.2.3.2 ovs-vsctl add-port sdn-br0 gre1 --set interface gre1 type=gre options:remote_ip:1.2.3.3 1.2.3.1 1.2.3.2 1.2.3.3 Simplified view. Detailed insight exposed in later slides
  • 22. 22 U 3. Instanciate VMs and map them to the bridges Host #1 sdn-br0 Host #3 sdn-br0 sdn-br1 Host #2 sdn-br0 sdn-br1 Container ‘app’ Container ‘db’ Container ‘app’ Container ‘db’ Container ‘app’ Container ‘app’ Container ‘db’ Container ‘app’ Container ‘db’ Instanciate containers without pre-built interfaces to avoid plugging containers to native docker0 bridge Use “docker run … -n=false” switch in “docker run” calls
  • 23. 23 U 4. Connect containers to the appropriate bridge Host #1 sdn-br0 Host #3 sdn-br0 sdn-br1 Host #2 sdn-br0 sdn-br1 Container ‘app’ Container ‘db’ Container ‘app’ Container ‘db’ Container ‘app’ Container ‘app’ Container ‘db’ Container ‘app’ Container ‘db’ Use pipework.sh from J. Petazzoni to easily plug containers to a chosen bridge https://github.com/jpetazzo/pipework Creates network adapter in each containers, allocate them an IP (manually/static vs DHCP), and plug it to the bridge. Per container: “pipework bridge_name $container_id container_ip/24”
  • 24. 24 Switch Insight - Detailed view between two hosts Previous drawings were simplified to ease overall understanding Following schema details more deeply what happened inside a single host Host #1 sdn-br0 Container Host #2 Container gre 0 tech-br tep0 eth0 sdn-br0 Container Container gre 0 tech-br tep0 eth0 Switch ovs-vsctl add-br tech-br ovs-vsctl add-port tech-br tep0 -- set interface tep0 type=internal ovs-vsctl add-port sdn-br0 gre0 --set interface gre0 type=gre options:remote_ip:1.1.1.1 GRE tunnel in which the traffic really flows Ethernet link between an adapter and a switch L2 switch Network adapter pipework sdn-br0 $container_id 192.168.0.3/24 eth1 eth1ovs-vsctl add-br sdn-br0eth1 eth1 1.1.1.1/24 2.2.2.2/24 192.168.1.2/24 192.168.0.3/24192.168.0.2/24192.168.0.1/24 192.168.0.4/24 4 7 6 1 2 ifconfig tep0 192.168.1.1 netmask 255.255.255.0 3 L3 routed network Docker container Docker host pipework sdn-br0 $container_id 192.168.0.4/24 8 192.168.1.1/24 Repeat step #6 to create additional tunnels in order to reach other hosts ovs-vsctl set bridge sdn-br0 stp_enable=true 5Virtual, direct link established through the GRE tunnel
  • 25. 25 Bonus: Alternate design - OpenStack Neutron paradigms Alternate design, based on OpenStack Neutron paradigms – notice that use of VLAN limits to 2048 tenant networks on each hosts All VMs/containers of a same tenant network are segregated inside a dedicated, local VLAN of a shared unique bridge Full-mesh of GRE tunnels between all hosts On each host, local mapping between a local tenant network VLAN and its GRE identifier shared across all hosts Full story from VM A to B (tenant #1): traffic outgoing A is tagged with VLAN 20 entering br-int, flows to br-tun, is untagged entering GRE tunnel while the GRE identifier 11111 is set on transmitted packets. At the other end of the GRE tunnel, the traffic having the GRE id 11111 is assigned to VLAN 40, then flow outside br-tun, to br-int, and is finally untagged before entering B. Full story from A to C (tenant #1): traffic is tagged with VLAN 20 entering br-int, then flows to br-eth1 which finally untag inbound trafic (or assign a different VLAN corresponding to the external world) Switch Host #1 br-int br-eth0 eth0 Switch GRE tunnel in which the traffic really flows Ethernet link between an adapter and a switch L2 switch Network adapter L3 routed network VM or container Host/server br-eth1 eth1 br-tun Tenant #2 Local VLAN 30 Tenant #1 Local VLAN 20 A single bridge is used for all VMs/containers ; VMs of different tenants isolated using local VLANs (not exposed externally !) A single bridge is used as end-points for all GRE tunnels used for full-mesh One bridge is created for each physical interface Host #2 br-int br-eth0 eth0 br-tun Tenant #2 Local VLAN 50 Tenant #1 Local VLAN 40 Switch or VLAN (not related to internal VLANs) gre 0 gre 0 A B Server C Flow rules: Tenant #1: VLAN 20  GRE ID 11111 Tenant #2: VLAN 30  GRE ID 11112 Single patch link between the two bridges supporting all traffic from/to full-mesh Flow rules: Tenant #1: VLAN 40  GRE ID 11111 Tenant #2: VLAN 50  GRE ID 11112
  • 27. 27 Use Docker for containers hosting, externalize SDN management Disable bridges management features in Docker, use OpenVSwitch Abstract from low level network considerations whenever possible, between hosts (L2 VLANs for instances): consider tunneling Get further Use OpenStack Neutron to centralize & automatize the whole network conf. You definitively use VLANs ? Consider encapsulating several VLANs in your own tenant network Other (dirty) options: Docker in VMs nesting Multiple Docker instances on the same host ebtables/iptables/openvswitch acls on flat network Take away
  • 28. 28