github.com/zhuohuang-hust/src-cbuild@v0.0.0-20230105071821-c7aab3e7c840/mergeCode/libnetwork/docs/remote.md (about)

     1  Remote Drivers
     2  ==============
     3  
     4  The `drivers.remote` package provides the integration point for dynamically-registered drivers. Unlike the other driver packages, it does not provide a single implementation of a driver; rather, it provides a proxy for remote driver processes, which are registered and communicate with LibNetwork via the Docker plugin package.
     5  
     6  For the semantics of driver methods, which correspond to the protocol below, please see the [overall design](design.md).
     7  
     8  ## LibNetwork integration with the Docker `plugins` package
     9  
    10  When LibNetwork initialises the `drivers.remote` package with the `Init()` function, it passes a `DriverCallback` as a parameter, which implements `RegisterDriver()`. The remote driver package uses this interface to register remote drivers with LibNetwork's `NetworkController`, by supplying it in a `plugins.Handle` callback.
    11  
    12  The callback is invoked when a driver is loaded with the `plugins.Get` API call. How that comes about is out of scope here (but it might be, for instance, when that driver is mentioned by the user).
    13  
    14  This design ensures that the details of driver registration mechanism are owned by the remote driver package, and it doesn't expose any of the driver layer to the North of LibNetwork.
    15  
    16  ## Implementation
    17  
    18  The remote driver implementation uses a `plugins.Client` to communicate with the remote driver process. The `driverapi.Driver` methods are implemented as RPCs over the plugin client.
    19  
    20  The payloads of these RPCs are mostly direct translations into JSON of the arguments given to the method. There are some exceptions to account for the use of the interfaces `InterfaceInfo` and `JoinInfo`, and data types that do not serialise to JSON well (e.g., `net.IPNet`). The protocol is detailed below under "Protocol".
    21  
    22  ## Usage
    23  
    24  A remote driver proxy follows all the rules of any other in-built driver and has exactly the same `Driver` interface exposed. LibNetwork will also support driver-specific `options` and user-supplied `labels` which may influence the behaviour of a remote driver process.
    25  
    26  ## Protocol
    27  
    28  The remote driver protocol is a set of RPCs, issued as HTTP POSTs with JSON payloads. The proxy issues requests, and the remote driver process is expected to respond usually with a JSON payload of its own, although in some cases these are empty maps.
    29  
    30  ### Errors
    31  
    32  If the remote process cannot decode, or otherwise detects a syntactic problem with the HTTP request or payload, it must respond with an HTTP error status (4xx or 5xx).
    33  
    34  If the remote process http server receives a request for an unknown URI, it should respond with the HTTP StatusCode `404 Not Found`. This allows libnetwork to detect when a remote driver does not implement yet a newly added method, therefore not to deem the request as failed.
    35  
    36  If the remote process can decode the request, but cannot complete the operation, it must send a response in the form
    37  
    38      {
    39  		"Err": string
    40      }
    41  
    42  The string value supplied may appear in logs, so should not include confidential information.
    43  
    44  ### Handshake
    45  
    46  When loaded, a remote driver process receives an HTTP POST on the URL `/Plugin.Activate` with no payload. It must respond with a manifest of the form
    47  
    48      {
    49  		"Implements": ["NetworkDriver"]
    50      }
    51  
    52  Other entries in the list value are allowed; `"NetworkDriver"` indicates that the plugin should be registered with LibNetwork as a driver.
    53  
    54  ### Set capability
    55  
    56  After Handshake, the remote driver will receive another POST message to the URL `/NetworkDriver.GetCapabilities` with no payload. The driver's response should have the form:
    57  
    58  	{
    59  		"Scope": "local"
    60  	}
    61  
    62  Value of "Scope" should be either "local" or "global" which indicates the capability of remote driver, values beyond these will fail driver's registration and return an error to the caller.
    63  
    64  ### Create network
    65  
    66  When the proxy is asked to create a network, the remote process shall receive a POST to the URL `/NetworkDriver.CreateNetwork` of the form
    67  
    68      {
    69  		"NetworkID": string,
    70  		"IPv4Data" : [
    71  		{
    72  			"AddressSpace": string,
    73  			"Pool": ipv4-cidr-string,
    74  			"Gateway" : ipv4-address"
    75  			"AuxAddresses": {
    76  				"<identifier1>" : "<ipv4-address1>",
    77  				"<identifier2>" : "<ipv4-address2>",
    78  				...
    79  			}
    80  		},
    81  		],
    82  		"IPv6Data" : [
    83  		{
    84  			"AddressSpace": string,
    85  			"Pool": ipv6-cidr-string,
    86  			"Gateway" : ipv6-address"
    87  			"AuxAddresses": {
    88  				"<identifier1>" : "<ipv6-address1>",
    89  				"<identifier2>" : "<ipv6-address2>",
    90  				...
    91  			}
    92  		},
    93  		],
    94  		"Options": {
    95  			...
    96  		}
    97      }
    98  
    99  * `NetworkID` value is generated by LibNetwork which represents a unique network. 
   100  * `Options` value is the arbitrary map given to the proxy by LibNetwork. 
   101  * `IPv4Data` and `IPv6Data` are the ip-addressing data configured by the user and managed by IPAM driver. The network driver is expected to honor the ip-addressing data supplied by IPAM driver. The data include,
   102  * `AddressSpace` : A unique string represents an isolated space for IP Addressing 
   103  * `Pool` : A range of IP Addresses represted in CIDR format address/mask. Since, the IPAM driver is responsible for allocating container ip-addresses, the network driver can make use of this information for the network plumbing purposes.
   104  * `Gateway` : Optionally, the IPAM driver may provide a Gateway for the subnet represented by the Pool. the network driver can make use of this information for the network plumbing purposes.
   105  * `AuxAddresses` : A list of pre-allocated ip-addresses with an associated identifier as provided by the user to assist network driver if it requires specific ip-addresses for its operation.
   106  
   107  The response indicating success is empty:
   108  
   109      `{}`
   110  
   111  ### Delete network
   112  
   113  When a network owned by the remote driver is deleted, the remote process shall receive a POST to the URL `/NetworkDriver.DeleteNetwork` of the form
   114  
   115      {
   116  		"NetworkID": string
   117      }
   118  
   119  The success response is empty:
   120  
   121      {}
   122  
   123  ### Create endpoint
   124  
   125  When the proxy is asked to create an endpoint, the remote process shall receive a POST to the URL `/NetworkDriver.CreateEndpoint` of the form
   126  
   127      {
   128  		"NetworkID": string,
   129  		"EndpointID": string,
   130  		"Options": {
   131  			...
   132  		},
   133  		"Interface": {
   134  			"Address": string,
   135  			"AddressIPv6": string,
   136  			"MacAddress": string
   137  		}
   138      }
   139  
   140  The `NetworkID` is the generated identifier for the network to which the endpoint belongs; the `EndpointID` is a generated identifier for the endpoint.
   141  
   142  `Options` is an arbitrary map as supplied to the proxy.
   143  
   144  The `Interface` value is of the form given. The fields in the `Interface` may be empty; and the `Interface` itself may be empty. If supplied, `Address` is an IPv4 address and subnet in CIDR notation; e.g., `"192.168.34.12/16"`. If supplied, `AddressIPv6` is an IPv6 address and subnet in CIDR notation. `MacAddress` is a MAC address as a string; e.g., `"6e:75:32:60:44:c9"`.
   145  
   146  A success response is of the form
   147  
   148      {
   149  		"Interface": {
   150  			"Address": string,
   151  			"AddressIPv6": string,
   152  			"MacAddress": string
   153  		}
   154      }
   155  
   156  with values in the `Interface` as above. As far as the value of `Interface` is concerned, `MacAddress` and either or both of `Address` and `AddressIPv6` must be given.
   157  
   158  If the remote process was supplied a non-empty value in `Interface`, it must respond with an empty `Interface` value. LibNetwork will treat it as an error if it supplies a non-empty value and receives a non-empty value back, and roll back the operation.
   159  
   160  ### Endpoint operational info
   161  
   162  The proxy may be asked for "operational info" on an endpoint. When this happens, the remote process shall receive a POST to `/NetworkDriver.EndpointOperInfo` of the form
   163  
   164      {
   165  		"NetworkID": string,
   166  		"EndpointID": string
   167      }
   168  
   169  where `NetworkID` and `EndpointID` have meanings as above. It must send a response of the form
   170  
   171      {
   172  		"Value": { ... }
   173      }
   174  
   175  where the value of the `Value` field is an arbitrary (possibly empty) map.
   176  
   177  ### Delete endpoint
   178  
   179  When an endpoint is deleted, the remote process shall receive a POST to the URL `/NetworkDriver.DeleteEndpoint` with a body of the form
   180  
   181      {
   182  		"NetworkID": string,
   183  		"EndpointID": string
   184      }
   185  
   186  where `NetworkID` and `EndpointID` have meanings as above. A success response is empty:
   187  
   188      {}
   189  
   190  ### Join
   191  
   192  When a sandbox is given an endpoint, the remote process shall receive a POST to the URL `NetworkDriver.Join` of the form
   193  
   194      {
   195  		"NetworkID": string,
   196  		"EndpointID": string,
   197  		"SandboxKey": string,
   198  		"Options": { ... }
   199      }
   200  
   201  The `NetworkID` and `EndpointID` have meanings as above. The `SandboxKey` identifies the sandbox. `Options` is an arbitrary map as supplied to the proxy.
   202  
   203  The response must have the form
   204  
   205      {
   206  		"InterfaceName": {
   207  			SrcName: string,
   208  			DstPrefix: string
   209  		},
   210  		"Gateway": string,
   211  		"GatewayIPv6": string,
   212  		"StaticRoutes": [{
   213  			"Destination": string,
   214  			"RouteType": int,
   215  			"NextHop": string,
   216  		}, ...]
   217      }
   218  
   219  `Gateway` is optional and if supplied is an IP address as a string; e.g., `"192.168.0.1"`. `GatewayIPv6` is optional and if supplied is an IPv6 address as a string; e.g., `"fe80::7809:baff:fec6:7744"`.
   220  
   221  The entries in `InterfaceName` represent actual OS level interfaces that should be moved by LibNetwork into the sandbox; the `SrcName` is the name of the OS level interface that the remote process created, and the `DstPrefix` is a prefix for the name the OS level interface should have after it has been moved into the sandbox (LibNetwork will append an index to make sure the actual name does not collide with others).
   222  
   223  The entries in `"StaticRoutes"` represent routes that should be added to an interface once it has been moved into the sandbox. Since there may be zero or more routes for an interface, unlike the interface name they can be supplied in any order.
   224  
   225  Routes are either given a `RouteType` of `0` and a value for `NextHop`; or, a `RouteType` of `1` and no value for `NextHop`, meaning a connected route.
   226  
   227  If no gateway and no default static route is set by the driver in the Join response, libnetwork will add an additional interface to the sandbox connecting to a default gateway network (a bridge network named *docker_gwbridge*) and program the default gateway into the sandbox accordingly, pointing to the interface address of the bridge *docker_gwbridge*.
   228  
   229  ### Leave
   230  
   231  If the proxy is asked to remove an endpoint from a sandbox, the remote process shall receive a POST to the URL `/NetworkDriver.Leave` of the form
   232  
   233      {
   234  		"NetworkID": string,
   235  		"EndpointID": string
   236      }
   237  
   238  where `NetworkID` and `EndpointID` have meanings as above. The success response is empty:
   239  
   240      {}
   241  
   242  ### DiscoverNew Notification
   243  
   244  libnetwork listens to inbuilt docker discovery notifications and passes it along to the interested drivers. 
   245  
   246  When the proxy receives a DiscoverNew notification, the remote process shall receive a POST to the URL `/NetworkDriver.DiscoverNew` of the form
   247  
   248      {
   249  		"DiscoveryType": int,
   250  		"DiscoveryData": {
   251  			...
   252  		}
   253      }
   254  
   255  `DiscoveryType` represents the discovery type. Each Discovery Type is represented by a number.
   256  `DiscoveryData` carries discovery data the structure of which is determined by the DiscoveryType
   257  
   258  The response indicating success is empty:
   259  
   260      `{}`
   261  
   262  *  Node Discovery
   263  
   264  Node Discovery is represented by a `DiscoveryType` value of `1` and the corresponding `DiscoveryData` will carry Node discovery data.
   265  
   266      {
   267  		"DiscoveryType": int,
   268  		"DiscoveryData": {
   269                      "Address" : string
   270                      "self" : bool
   271  		}
   272      }
   273  
   274  ### DiscoverDelete Notification
   275  
   276  When the proxy receives a DiscoverDelete notification, the remote process shall receive a POST to the URL `/NetworkDriver.DiscoverDelete` of the form
   277  
   278      {
   279  		"DiscoveryType": int,
   280  		"DiscoveryData": {
   281  			...
   282  		}
   283      }
   284  
   285  `DiscoveryType` represents the discovery type. Each Discovery Type is represented by a number.
   286  `DiscoveryData` carries discovery data the structure of which is determined by the DiscoveryType
   287  
   288  The response indicating success is empty:
   289  
   290      `{}`
   291  
   292  * Node Discovery
   293  
   294  Similar to the DiscoverNew call, Node Discovery is represented by a `DiscoveryType` value of `1` and the corresponding `DiscoveryData` will carry Node discovery data to be delted.
   295  
   296      {
   297  		"DiscoveryType": int,
   298  		"DiscoveryData": {
   299                      "Address" : string
   300                      "self" : bool
   301  		}
   302      }