With publish-service and default-network support, a container could be
connected to a user-defined network that is backed by any driver/plugin.
But if the user uses port mapping or expose commands, the expectation
for that container is to behave like existing bridge network.
Thanks to the Libnetwork's CNM model, containers can be connected
to the bridge network as a secondary network in addition to the
user-specified network.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Now that the default network mode is "default" and this mode is chosen
even if the mode is empty string, it is not correct to have builder
still pointing to "bridge" as default (though this is daemon default).
Signed-off-by: Madhu Venugopal <madhu@docker.com>
- brings in vxlan based native multihost networking
- added a daemon flag required by libkv for dist kv operations
- moved the daemon flags to experimental
Signed-off-by: Madhu Venugopal <madhu@docker.com>
This commit makes use of the CNM model supported by LibNetwork and
provides an ability to let a container to publish a specified service.
Behind the scenes, if a service with the given name doesnt exist, it is
automatically created on appropriate network and attach the container.
Signed-off-by: Alessandro Boch <aboch@docker.com>
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Today, endpoints implementing v2 cannot properly fallback to v1 because the underlying transport that deals with authentication (Basic / Token) doesn't get annotated.
This doesn't affect DockerHub because the DockerHub endpoint appears as 'https://index.docker.io/v1/' (in .dockercfg), and the 'v1' tricks this logic just long enough that the transport is always annotated for DockerHub accesses.
Signed-off-by: Matt Moore <mattmoor@google.com>
Just to make life easier on devs so they don't need to 'cd' into
the docs dir just to test their docs edits. This doesn't do anything
more than "cd docs && make docs" so that all of the smarts are still
in the docs's Makefile and not in docker's.
Signed-off-by: Doug Davis <dug@us.ibm.com>
The cleanup to sysinfo package introduced a regression.
If memory cgroup isn't supported and --memory is specified when
starting a container, we should return info instead of nil in
checkCgroupMem(), otherwise we'll access a nil pointer.
Signed-off-by: Zefan Li <lizefan@huawei.com>
These have both been updated to no longer include the empty "scratch" layer, and `hello-world` has a fix for http->https.
Signed-off-by: Andrew "Tianon" Page <admwiggin@gmail.com>
By default, the cgroup setting in libcontainer's configs.Cgroup for
memory swappiness will default to 0, which is a valid choice for memory
swappiness, but that means by default every container's memory
swappiness will be set to zero instead of the default 60, which is
probably not what users are expecting.
When the swappiness UI PR comes into Docker, there will be docker run
controls to set this per container, but for now we want to make sure
*not* to change the default, as well as work around an older kernel
issue that refuses to allow it to be set when cgroup hiearchies are in
use.
Docker-DCO-1.1-Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com> (github: estesp)
