DOCKER-585: Support --network option in `docker run` for specifying networks

Details

Issue Type:Wishlist
Priority:4 - Normal
Status:Resolved
Created at:2015-10-01T16:22:22.000Z
Updated at:2018-05-07T17:51:41.152Z

People

Created by:Former user
Reported by:Former user
Assigned to:Former user

Resolution

Fixed: A fix for this issue is checked into the tree and tested.
(Resolution Date: 2016-07-28T18:57:22.000Z)

Related Issues

Description

Currently in Triton, we have a cloudapi to set the network to be used for docker containers,
`sdc-fabric network set-default $networkUUID`
This doesn't work well when user has to constantly switch between different networks. With the introduction of network plugin in Docker, we can leverage the syntax of specifying networks in the `docker run` command.

Some background: At this time, the closest equivalent Docker networking solution to Triton's fabric is the "overlay driver" for multi-host networking (still in experimental phase). The definition for a network is embedded in their overlay driver and is not exposed to user. The create network call is simply `docker network create -d overlay $networkName`. The networking solution is also linked to service discovery which supports some level of DNS.
(ref: https://github.com/docker/docker/blob/master/experimental/networking.md,
http://blog.docker.com/2015/06/networking-receives-an-upgrade,
https://github.com/docker/docker/blob/master/experimental/compose_swarm_networking.md)

Due to the major differences in the network payload (attributes such as subnet, routes are not alterable by user) and the immaturity of the solution as a whole, we won't attempt to replicate the `docker network` commands. For now we'll limit the enhancement to support the syntax for specifying the target fabric network in the `docker run` command. The Docker implementation is tied to service however, e.g.
`docker run itd -publish-service=$serviceName.$networkName debian:latest`

tl;dr
Additional notes: In the context of Docker Swarm, the container name is by default the $serviceName, and there is one network that span multiple hosts so there is no need to assign $networkName. That is close to what we have today when each account has a default network. But there is no DNS and containers have to communicate through IP address.

Comments

Comment by Josh Wilsdon
Created at 2015-10-01T16:25:47.000Z
Updated at 2018-05-07T17:51:41.132Z

would it be better to support this feature through labels?


Comment by Former user
Created at 2015-10-01T22:51:56.000Z

Amended the description as I omitted some pertinent details related to Docker's service discovery portion of their solution.

To Josh's point - I've also thought about using labels as it's cleaner (esp if service is entangled in the Docker implementation). If we are going to use labels for TCNS, we might as well stick with labels for everything. The only drawback may be the need to explain this major divergence.

If we are sticking with --publish-service, we may consider using it for both network and TCNS. Behind the scenes, we can still persist the service name as machine tags.

Time for @accountid:624d9b6cfd5e4500704833c5 input.


Comment by Former user
Created at 2015-10-02T00:21:58.000Z

> would it be better to support this feature through labels?

I can see the appeal, but if people are expecting to express network membership and service name with `--publish-service=$serviceName.$networkName`, we should be very careful about pursuing a different path.


Comment by Former user
Created at 2015-10-02T00:22:15.000Z

> we may consider using it for both network and TCNS

`--publish-service` allows just one service name, but TCNS assumes that a service will be reachable via many different tags.


Comment by Former user
Created at 2016-05-20T16:48:06.000Z

@accountid:62561a9d4f1d57006a24d3ff Is there an updated description of what this will implement? AFAIK the "docker run --publish-service ..." option isn't a thing anymore. This is about "docker run --net ..." support now, right? Is it more than that?


Comment by Former user
Created at 2016-05-20T17:14:06.000Z

@accountid:62561aa44f1d57006a24d40c docker run --net= will be supported, at first for either 'bridge' (the existing default), or the name/id of a network. I'd hoped to support --link in combination (which work differently than legacy links), but I think that's best deferred at this point.


Comment by Former user
Created at 2016-05-27T23:46:25.000Z

Per discussions we (Casey, Matt and I) had today, I am documenting the following for future documentation purpose, since we don't have a RFD on this:


Comment by Former user
Created at 2016-07-25T23:07:16.000Z

sdc-napi commit adc1936 (branch master, by Matt Smillie)

DOCKER-585 enable docker run --network


Comment by Former user
Created at 2016-07-28T18:31:18.000Z

sdc-docker commit 547ee2d (branch master, by Matt Smillie)

DOCKER-585: Support --network option in `docker run` for specifying networks


Comment by Former user
Created at 2016-07-28T18:57:22.000Z

See DOCKER-897, DOCKER-898 for follow-up features.


Comment by Former user
Created at 2016-07-29T14:55:09.000Z

sdc-docker commit e98159d (branch master, by Angela Fong)

DOCKER-585 Doc update on docker run and docker create --network option