|
...
|
...
|
@@ -1,16 +1,17 @@
|
|
1
|
1
|
Design
|
|
2
|
2
|
======
|
|
3
|
3
|
|
|
4
|
|
-The main goals of libnetwork are highlighted in the [roadmap](../ROADMAP.md).
|
|
|
4
|
+The vision and goals of libnetwork are highlighted in [roadmap](../ROADMAP.md).
|
|
5
|
5
|
This document describes how libnetwork has been designed in order to acheive this.
|
|
6
|
6
|
Requirements for individual releases can be found on the [Project Page](https://github.com/docker/libnetwork/wiki)
|
|
7
|
7
|
|
|
8
|
|
-## Legacy Docker Networking
|
|
|
8
|
+Many of the design decisions are inspired by the learnings from the Docker networking design as of Docker v1.6.
|
|
|
9
|
+Please refer to this [Docker v1.6 Design](https://github.com/docker/libnetwork/blob/docs/legacy.md) document for more information on networking design as of Docker v1.6.
|
|
9
|
10
|
|
|
10
|
|
-Prior to libnetwork a container's networking was handled in both Docker Engine and libcontainer.
|
|
11
|
|
-Docker Engine was responsible for providing the configuration of the container's networking stack.
|
|
12
|
|
-Libcontainer would then use this information to create the necessary networking devices and move them in to a network namespace.
|
|
13
|
|
-This namespace would then be used when the container is started.
|
|
|
11
|
+## Goal
|
|
|
12
|
+
|
|
|
13
|
+libnetwork project will follow Docker and Linux philosophy of developing small, highly modular and composable tools that works well independently.
|
|
|
14
|
+Libnetwork aims to satisfy that composable need for Networking in Containers.
|
|
14
|
15
|
|
|
15
|
16
|
## The Container Network Model
|
|
16
|
17
|
|
|
...
|
...
|
@@ -35,55 +36,86 @@ A Network is a group of Endpoints that are able to communicate with each-other d
|
|
35
|
35
|
An implementation of a Network could be a Linux bridge, a VLAN etc...
|
|
36
|
36
|
Networks consist of *many* endpoints
|
|
37
|
37
|
|
|
38
|
|
-## API
|
|
|
38
|
+## CNM Objects
|
|
|
39
|
+
|
|
|
40
|
+**NetworkController**
|
|
|
41
|
+`NetworkController` object provides the entry-point into libnetwork that exposes simple APIs for the users (such as Docker Engine) to allocate and manage Networks. libnetwork supports multiple active drivers (both inbuilt and remote). `NetworkController` allows user to bind a particular driver to a given network.
|
|
|
42
|
+
|
|
|
43
|
+**Driver**
|
|
|
44
|
+`Driver` is not an user visible object, but drivers provides the actual implementation that makes network work. `NetworkController` however provides an API to configure any specific driver with driver-specific options/labels that is transparent to libnetwork, but can be handled by the drivers directly. Drivers can be both inbuilt (such as Bridge, Host, None & overlay) and remote (from plugin providers) to satisfy various usecases & deployment scenarios. At this point, the Driver owns a network and is responsible for managing the network (including IPAM, etc.). This can be improved in the future by having multiple drivers participating in handling various network management functionalities.
|
|
|
45
|
+
|
|
|
46
|
+**Network**
|
|
|
47
|
+`Network` object is an implementation of the `CNM : Network` as defined above. `NetworkController` provides APIs to create and manage `Network` object. Whenever a `Network` is created or updated, the corresponding `Driver` will be notified of the event. LibNetwork treats `Network` object at an abstract level to provide connectivity between a group of end-points that belong to the same network and isolate from the rest. The Driver performs the actual work of providing the required connectivity and isolation. The connectivity can be within the same host or across multiple-hosts. Hence `Network` has a global scope within a cluster.
|
|
|
48
|
+
|
|
|
49
|
+**Endpoint**
|
|
|
50
|
+`Endpoint` represents a Service Endpoint. It provides the connectivity for services exposed by a container in a network with other services provided by other containers in the network. `Network` object provides APIs to create and manage endpoint. An endpoint can be attached to only one network. `Endpoint` creation calls are made to the corresponding `Driver` which is responsible for allocating resources for the corresponding `Sandbox`. Since Endpoint represents a Service and not necessarily a particular container, `Endpoint` has a global scope within a cluster as well.
|
|
|
51
|
+
|
|
|
52
|
+**Sandbox**
|
|
|
53
|
+`Sandbox` object represents container's network configuration such as ip-address, mac-address, routes, DNS entries. A `Sandbox` object is created when the user requests to create an endpoint on a network. The `Driver` that handles the `Network` is responsible to allocate the required network resources (such as ip-address) and pass the info called `SandboxInfo` back to libnetwork. libnetwork will make use of OS specific constructs (example: netns for Linux) to populate the network configuration into the containers that is represented by the `Sandbox`. A `Sandbox` can have multiple endpoints attached to different networks. Since `Sandbox` is associated with a particular container in a given host, it has a local scope that represents the Host that the Container belong to.
|
|
|
54
|
+
|
|
|
55
|
+**CNM Attributes**
|
|
|
56
|
+
|
|
|
57
|
+***Options***
|
|
|
58
|
+`Options` provides a generic and flexible mechanism to pass `Driver` specific configuration option from the user to the `Driver` directly. `Options` are just key-value pairs of data with `key` represented by a string and `value` represented by a generic object (such as golang `interface{}`). Libnetwork will operate on the `Options` ONLY if the `key` matches any of the well-known `Label` defined in the `net-labels` package. `Options` also encompasses `Labels` as explained below. `Options` are generally NOT end-user visible (in UI), while `Labels` are.
|
|
|
59
|
+
|
|
|
60
|
+***Labels***
|
|
|
61
|
+`Labels` are very similar to `Options` & infact they are just a subset of `Options`. `Labels` are typically end-user visible and are represented in the UI explicitely using the `--labels` option. They are passed from the UI to the `Driver` so that `Driver` can make use of it and perform any `Driver` specific operation (such as a subnet to allocate IP-Addresses from in a Network).
|
|
|
62
|
+
|
|
|
63
|
+## CNM Lifecycle
|
|
|
64
|
+
|
|
|
65
|
+Consumers of the CNM, like Docker for example, interact through the CNM Objects and its APIs to network the containers that they manage.
|
|
|
66
|
+
|
|
|
67
|
+0. `Drivers` registers with `NetworkController`. Build-in drivers registers inside of LibNetwork, while remote Drivers registers with LibNetwork via Plugin mechanism. (*plugin-mechanism is WIP*). Each `driver` handles a particular `networkType`.
|
|
39
|
68
|
|
|
40
|
|
-Consumers of the CNM, like Docker for example, interact through the following APIs
|
|
|
69
|
+1. `NetworkController` object is created using `libnetwork.New()` API to manage the allocation of Networks and optionally configure a `Driver` with driver specific `Options`.
|
|
41
|
70
|
|
|
42
|
|
-The `NetworkController` object is created to manage the allocation of Networks and the binding of these Networks to a specific Driver
|
|
43
|
|
-Once a Network is created, `network.CreateEndpoint` can be called to create a new Endpoint in a given network.
|
|
44
|
|
-When an Endpoint exists, it can be joined to a Sandbox using `endpoint.Join(id)`. If no Sandbox exists, one will be created, but if the Sandbox already exists, the endpoint will be added there.
|
|
45
|
|
-The result of the Join operation is a Sandbox Key which identifies the Sandbox to the Operating System (e.g a path)
|
|
46
|
|
-This Key can be passed to the container runtime so the Sandbox is used when the container is started.
|
|
|
71
|
+2. `Network` is created using the controller's `NewNetwork()` API by providing a `name` and `networkType`. `networkType` parameer helps to choose a corresponding `Driver` and binds the created `Network` to that `Driver`. From this point, any operation on `Network` will be handled by that `Driver`.
|
|
47
|
72
|
|
|
48
|
|
-When the container is stopped, `endpoint.Leave` will be called on each endpoint within the Sandbox
|
|
49
|
|
-Finally once, endpoint.
|
|
|
73
|
+3. `controller.NewNetwork()` API also takes in optional `options` parameter which carries Driver-specific options and `Labels`, which the Drivers can make use for its purpose.
|
|
50
|
74
|
|
|
51
|
|
-## Component Lifecycle
|
|
|
75
|
+4. `network.CreateEndpoint()` can be called to create a new Endpoint in a given network. This API also accepts optional `options` parameter which drivers can make use of. These 'options' carry both well-known labels and driver-specific labels. Drivers will inturn be called with `driver.CreateEndpoint` and it can choose to reserve any required resources when an `Endpoint` is created in a `Network`. The `Driver` must return the reserved resources via the `sandbox.Info` return object. LibNetwork will make use of the `SandboxInfo` when a Container is attached later. The reason we get the `sandbox.Info` at the time of endpoint creation and not during the `Join()` is that, `Endpoint` represents a Service endpoint and not neccessarily the container that attaches later.
|
|
52
|
76
|
|
|
53
|
|
-### Sandbox Lifecycle
|
|
|
77
|
+5. `endpoint.Join()` can be used to attach a container to a `Endpoint`. The Join operation will create a `Sandbox` if it doesnt exist already for that container. The Drivers can make use of the Sandbox Key to identify multiple endpoints attached to a same container. This API also accepts optional `options` parameter which drivers can make use of.
|
|
|
78
|
+ * Though it is not a direct design issue of LibNetwork, it is highly encouraged to have users like `Docker` to call the endpoint.Join() during Container's `Start()` lifecycle that is invoked *before* the container is made operational. As part of Docker integration, this will be taken care of.
|
|
|
79
|
+ * one of a FAQ on endpoint join() API is that, why do we need an API to create an Endpoint and another to join the endpoint.
|
|
|
80
|
+ - The answer is based on the fact that Endpoint represents a Service which may or may not be backed by a Container. When an Endpoint is created, it will have its resources reserved so that any container can get attached to the endpoint later and get a consistent networking behaviour.
|
|
54
|
81
|
|
|
55
|
|
-The Sandbox is created during the first `endpoint.Join` and deleted when `endpoint.Leave` is called on the last endpoint.
|
|
56
|
|
-<TODO @mrjana or @mavenugo to more details>
|
|
|
82
|
+6. `endpoint.Leave()` can be invoked when a container is stopped. The `Driver` can cleanup the states that it allocated during the `Join()` call. LibNetwork will delete the `Sandbox` when the last referencing endpoint leaves the network. But LibNetwork keeps hold of the `sandbox.Info` and will be reused when the container joins again. This ensures that the container's resources are reused when they are Stopped and Started again.
|
|
57
|
83
|
|
|
58
|
|
-### Endpoint Lifecycle
|
|
|
84
|
+7. `endpoint.Delete()` is used to delete an endpoint from a network. This results in deleting an endpoint and cleaning up the cached `sandbox.Info`.
|
|
59
|
85
|
|
|
60
|
|
-The Endpoint is created on `network.CreateEndpoint` and removed on `endpoint.Delete`
|
|
61
|
|
-<TODO @mrjana or @mavenugo to add details on when this is called>
|
|
|
86
|
+8. `network.Delete()` is used to delete a network. LibNetwork will not allow the delete to proceed if there are any existing endpoints attached to the Network.
|
|
62
|
87
|
|
|
63
|
|
-### Network Lifecycle
|
|
64
|
88
|
|
|
65
|
|
-Networks are created when the CNM API call is invoked and are not cleaned up until an corresponding delete API call is made.
|
|
|
89
|
+## Implementation Details
|
|
66
|
90
|
|
|
67
|
|
-## Implementation
|
|
|
91
|
+### Networks & Endpoints
|
|
68
|
92
|
|
|
69
|
|
-Networks and Endpoints are mostly implemented in drivers. For more information on these details, please see [the drivers section](#Drivers)
|
|
|
93
|
+LibNetwork's Network and Endpoint APIs are primiarly for managing the corresponding Objects and book-keeping them to provide a level of abstraction as required by the CNM. It delegates the actual implementation to the drivers which realizes the functionality as promised in the CNM. For more information on these details, please see [the drivers section](#Drivers)
|
|
70
|
94
|
|
|
71
|
|
-## Sandbox
|
|
|
95
|
+### Sandbox
|
|
72
|
96
|
|
|
73
|
|
-Libnetwork provides an implementation of a Sandbox for Linux.
|
|
|
97
|
+Libnetwork provides a framework to implement of a Sandbox in multiple Operating Systems. Currently we have implemented Sandbox for Linux using `namespace_linux.go` and `configure_linux.go` in `sandbox` package
|
|
74
|
98
|
This creates a Network Namespace for each sandbox which is uniquely identified by a path on the host filesystem.
|
|
75
|
99
|
Netlink calls are used to move interfaces from the global namespace to the Sandbox namespace.
|
|
76
|
100
|
Netlink is also used to manage the routing table in the namespace.
|
|
77
|
101
|
|
|
78
|
|
-# Drivers
|
|
|
102
|
+## Drivers
|
|
79
|
103
|
|
|
80
|
104
|
## API
|
|
81
|
105
|
|
|
82
|
|
-The Driver API allows libnetwork to defer to a driver to provide Networking services.
|
|
|
106
|
+Drivers are essentially an extension of libnetwork and provides the actual implementation for all of the LibNetwork APIs defined above. Hence there is an 1-1 correspondance for all the `Network` and `Endpoint` APIs, which includes :
|
|
|
107
|
+* `driver.Config`
|
|
|
108
|
+* `driver.CreateNetwork`
|
|
|
109
|
+* `driver.DeleteNetwork`
|
|
|
110
|
+* `driver.CreateEndpoint`
|
|
|
111
|
+* `driver.DeleteEndpoint`
|
|
|
112
|
+* `driver.Join`
|
|
|
113
|
+* `driver.Leave`
|
|
83
|
114
|
|
|
84
|
|
-For Networks, drivers are notified on Create and Delete events
|
|
|
115
|
+These Driver facing APIs makes use of unique identifiers (`networkid`,`endpointid`,...) instead of names (as seen in user-facing APIs).
|
|
85
|
116
|
|
|
86
|
|
-For Endpoints, drivers are also notified on Create and Delete events
|
|
|
117
|
+The APIs are still work in progress and there can be changes to these based on the driver requirements especially when it comes to Multi-host networking.
|
|
87
|
118
|
|
|
88
|
119
|
## Implementations
|
|
89
|
120
|
|
|
...
|
...
|
@@ -96,7 +128,7 @@ Libnetwork includes the following drivers:
|
|
96
|
96
|
|
|
97
|
97
|
### Null
|
|
98
|
98
|
|
|
99
|
|
-The null driver is a `noop` implementation of the driver API, used only in cases where no networking is desired.
|
|
|
99
|
+The null driver is a `noop` implementation of the driver API, used only in cases where no networking is desired. This is to provide backward compatibility to the Docker's `--net=none` option.
|
|
100
|
100
|
|
|
101
|
101
|
### Bridge
|
|
102
|
102
|
|
Madhu Venugopal authored on 2015/05/06 21:07:32