docker-api mv to tasks
This commit is contained in:
abuehrle committed
1 parent
02328ae43f
commit
562f49b3ad
7 files changed
No files matched your search
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: Using Automatic Discovery With the Weave Net Proxy
|
||||
menu_order: 30
|
||||
search_type: Documentation
|
||||
---
|
||||
|
||||
Containers launched via the proxy use [weaveDNS](/site/weavedns.md)
|
||||
automatically if it is running when they are started -
|
||||
see the [weaveDNS usage](/site/weavedns.md#usage) section for an in depth
|
||||
explanation of the behaviour and how to control it.
|
||||
|
||||
Typically, the proxy passes on container names as-is to weaveDNS
|
||||
for registration. However, there are situations in which the final container
|
||||
name may be out of your control (for example, if you are using Docker orchestrators which
|
||||
append control/namespacing identifiers to the original container names).
|
||||
|
||||
For those situations, the proxy provides the following flags:
|
||||
|
||||
* `--hostname-from-label<labelkey>`
|
||||
* `--hostname-match <regexp>`
|
||||
* `--hostname-replacement <replacement>`
|
||||
|
||||
When launching a container, the hostname is initialized to the
|
||||
value of the container label using key `<labelkey>`. If no `<labelkey>` was
|
||||
provided, then the container name is used.
|
||||
|
||||
Additionally, the hostname is matched against a regular expression `<regexp>` and based on that match,
|
||||
`<replacement>` is used to obtain the final hostname, and then handed over to weaveDNS for registration.
|
||||
|
||||
For example, you can launch the proxy using all three flags, as follows:
|
||||
|
||||
host1$ weave launch --hostname-from-label hostname-label --hostname-match '^aws-[0-9]+-(.*)$' --hostname-replacement 'my-app-$1'
|
||||
host1$ eval $(weave env)
|
||||
|
||||
>**Note:** regexp substitution groups must be pre-pended with a dollar sign
|
||||
(for example, `$1`). For further details on the regular expression syntax see
|
||||
[Google's re2 documentation](https://github.com/google/re2/wiki/Syntax).
|
||||
|
||||
After launching the Weave Net proxy with these flags, running a container named `aws-12798186823-foo` without labels results in weaveDNS registering the hostname `my-app-foo` and not `aws-12798186823-foo`.
|
||||
|
||||
host1$ docker run -ti --name=aws-12798186823-foo weaveworks/ubuntu ping my-app-foo
|
||||
PING my-app-foo.weave.local (10.32.0.2) 56(84) bytes of data.
|
||||
64 bytes from my-app-foo.weave.local (10.32.0.2): icmp_seq=1 ttl=64 time=0.027 ms
|
||||
64 bytes from my-app-foo.weave.local (10.32.0.2): icmp_seq=2 ttl=64 time=0.067 ms
|
||||
|
||||
Also, running a container named `foo` with the label
|
||||
`hostname-label=aws-12798186823-foo` leads to the same hostname registration.
|
||||
|
||||
host1$ docker run -ti --name=foo --label=hostname-label=aws-12798186823-foo weaveworks/ubuntu ping my-app-foo
|
||||
PING my-app-foo.weave.local (10.32.0.2) 56(84) bytes of data.
|
||||
64 bytes from my-app-foo.weave.local (10.32.0.2): icmp_seq=1 ttl=64 time=0.031 ms
|
||||
64 bytes from my-app-foo.weave.local (10.32.0.2): icmp_seq=2 ttl=64 time=0.042 ms
|
||||
|
||||
This is because, as explained above, if providing `--hostname-from-label`
|
||||
to the proxy, the specified label takes precedence over the container's name.
|
||||
|
||||
**See Also**
|
||||
|
||||
* [Name resolution via `/etc/hosts`](/site/weave-docker-api/name-resolution-proxy.md)
|
||||
* [How Weave Finds Containers](/site/weavedns/how-works-weavedns.md)
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: Automatic IP Allocation and the Weave Proxy
|
||||
menu_order: 25
|
||||
search_type: Documentation
|
||||
---
|
||||
|
||||
|
||||
If [automatic IP address allocation](/site/ipam.md) is enabled in Weave Net (by default IPAM is enabled),
|
||||
then containers started via the proxy are automatically assigned an IP address, *without having to specify any
|
||||
special environment variables or any other options*.
|
||||
|
||||
host1$ docker run -ti weaveworks/ubuntu
|
||||
|
||||
To use a specific subnet, you can pass a `WEAVE_CIDR` to the container, for example:
|
||||
|
||||
host1$ docker run -ti -e WEAVE_CIDR=net:10.32.2.0/24 weaveworks/ubuntu
|
||||
|
||||
To start a container without connecting it to the Weave network, pass
|
||||
`WEAVE_CIDR=none`, for example:
|
||||
|
||||
host1$ docker run -ti -e WEAVE_CIDR=none weaveworks/ubuntu
|
||||
|
||||
### Disabling Automatic IP Address Allocation
|
||||
|
||||
If you do not want an IP to be assigned by default, the proxy needs to
|
||||
be passed the `--no-default-ipalloc` flag, for example:
|
||||
|
||||
host1$ weave launch --no-default-ipalloc
|
||||
|
||||
In this configuration, containers using no `WEAVE_CIDR` environment
|
||||
variable are not connected to the Weave network.
|
||||
|
||||
Containers started with a `WEAVE_CIDR` environment variable are handled as before.
|
||||
To automatically assign an address in this mode, start the
|
||||
container with a blank `WEAVE_CIDR`, for example:
|
||||
|
||||
host1$ docker run -ti -e WEAVE_CIDR="" weaveworks/ubuntu
|
||||
|
||||
**See Also**
|
||||
|
||||
* [Address Allocation with IP Address Management (IPAM)](/site/ipam.md)
|
||||
* [How to Manually Specify IP Addresses and Subnets](/site/using-weave/manual-ip-address.md)
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: Launching Containers With Weave Run (without the Proxy)
|
||||
menu_order: 50
|
||||
search_type: Documentation
|
||||
---
|
||||
|
||||
In prior versions of Weave Net, we supported a command `weave run`
|
||||
which would run a container and attach it to the Weave Network.
|
||||
|
||||
This command always had limitations, and now we have Docker plugins
|
||||
and the Weave Net Docker API Proxy which do not have those
|
||||
limitations, we have removed `weave run`.
|
||||
|
||||
If you have scripts using `weave run`, you can achieve exactly the
|
||||
same effect by combining `docker run` and `weave attach`; see
|
||||
[Dynamically Attaching and Detaching
|
||||
Containers](/site/using-weave/dynamically-attach-containers.md) for
|
||||
details.
|
||||
|
||||
The `weave start` and `weave restart` commands have also been removed,
|
||||
for the same reasons.
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: Name resolution via `/etc/hosts`
|
||||
menu_order: 40
|
||||
search_type: Documentation
|
||||
---
|
||||
|
||||
|
||||
When starting Weave Net enabled containers, the proxy automatically
|
||||
replaces the container's `/etc/hosts` file, and disables Docker's control
|
||||
over it. The new file contains an entry for the container's hostname
|
||||
and Weave Net IP address, as well as additional entries that have been
|
||||
specified using the `--add-host` parameters.
|
||||
|
||||
This ensures that:
|
||||
|
||||
- name resolution of the container's hostname, for example, via `hostname -i`,
|
||||
returns the Weave Net IP address. This is required for many cluster-aware
|
||||
applications to work.
|
||||
- unqualified names get resolved via DNS, for example typically via weaveDNS
|
||||
to Weave Net IP addresses. This is required so that in a typical setup
|
||||
one can simply "ping `<container-name>`", i.e. without having to
|
||||
specify a `.weave.local` suffix.
|
||||
|
||||
If you prefer to keep `/etc/hosts` under Docker's control (for
|
||||
example, because you need the hostname to resolve to the Docker-assigned
|
||||
IP instead of the Weave IP, or you require name resolution for
|
||||
Docker-managed networks), the proxy must be launched using the
|
||||
`--no-rewrite-hosts` flag.
|
||||
|
||||
host1$ weave launch --no-rewrite-hosts
|
||||
|
||||
**See Also**
|
||||
|
||||
* [Using Automatic Discovery With the Weave Proxy](/site/weave-docker-api/automatic-discovery-proxy.md)
|
||||
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
title: Securing the Docker Communications With TLS
|
||||
menu_order: 20
|
||||
search_type: Documentation
|
||||
---
|
||||
|
||||
If you are [connecting to the docker daemon with
|
||||
TLS](https://docs.docker.com/articles/https/), you most likely want
|
||||
to do the same when connecting to the proxy. The proxy
|
||||
automatically detects the Docker daemon's TLS configuration, and
|
||||
attempts to duplicate it.
|
||||
|
||||
In the standard auto-detection case you can launch a TLS-enabled proxy as follows:
|
||||
|
||||
host1$ weave launch
|
||||
|
||||
To disable auto-detection of TLS configuration, you can either pass
|
||||
the `--no-detect-tls` flag, or you can manually configure the proxy's TLS using
|
||||
the same TLS-related command-line flags supplied to the Docker
|
||||
daemon.
|
||||
|
||||
For example, if you generated your certificates and keys
|
||||
into the Docker host's `/tls` directory, launch the proxy using:
|
||||
|
||||
host1$ weave launch --tlsverify --tlscacert=/tls/ca.pem \
|
||||
--tlscert=/tls/server-cert.pem --tlskey=/tls/server-key.pem
|
||||
|
||||
The paths to your certificates and key must be provided as absolute
|
||||
paths as they exist on the Docker host.
|
||||
|
||||
Because the proxy connects to the Docker daemon at
|
||||
`unix:///var/run/docker.sock`, you must ensure that the daemon is actually
|
||||
listening there. To do ensure this, pass the `-H unix:///var/run/docker.sock` option when starting the Docker daemon,
|
||||
in addition to the `-H` options for configuring the TCP listener. See
|
||||
[the Docker documentation](https://docs.docker.com/articles/basics/#bind-docker-to-another-host-port-or-a-unix-socket)
|
||||
for an example.
|
||||
|
||||
With the proxy running over TLS, you can configure the Docker
|
||||
client to use TLS on a per-invocation basis by running:
|
||||
|
||||
$ docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem \
|
||||
--tlskey=key.pem -H=tcp://host1:12375 version
|
||||
|
||||
or, [by default](https://docs.docker.com/articles/https/#secure-by-default), using:
|
||||
|
||||
$ mkdir -pv ~/.docker
|
||||
$ cp -v {ca,cert,key}.pem ~/.docker
|
||||
$ eval $(weave env)
|
||||
$ export DOCKER_TLS_VERIFY=1
|
||||
$ docker version
|
||||
|
||||
This is exactly the same configuration used when connecting to the
|
||||
Docker daemon directly, except that the specified port is the Weave
|
||||
proxy port.
|
||||
|
||||
|
||||
**See Also**
|
||||
|
||||
* [Setting Up The Weave Docker API Proxy](/site/weave-docker-api.md)
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
title: Using The Weave Docker API Proxy
|
||||
menu_order: 10
|
||||
search_type: Documentation
|
||||
---
|
||||
|
||||
|
||||
When containers are created via the Weave Net proxy, their entrypoint is
|
||||
modified to wait for the Weave network interface to become
|
||||
available.
|
||||
|
||||
When they are started via the Weave Net proxy, containers are
|
||||
[automatically assigned IP addresses](/site/ipam.md) and connected to the
|
||||
Weave network.
|
||||
|
||||
### Creating and Starting Containers with the Weave Net Proxy
|
||||
|
||||
To create and start a container via the Weave Net proxy run:
|
||||
|
||||
host1$ docker run -ti weaveworks/ubuntu
|
||||
|
||||
or, equivalently run:
|
||||
|
||||
host1$ docker create -ti --name=foo weaveworks/ubuntu
|
||||
host1$ docker start foo
|
||||
|
||||
Specific IP addresses and networks can be supplied in the `WEAVE_CIDR`
|
||||
environment variable, for example:
|
||||
|
||||
host1$ docker run -e WEAVE_CIDR=10.2.1.1/24 -ti weaveworks/ubuntu
|
||||
|
||||
Multiple IP addresses and networks can be supplied in the `WEAVE_CIDR`
|
||||
variable by space-separating them, as in
|
||||
`WEAVE_CIDR="10.2.1.1/24 10.2.2.1/24"`.
|
||||
|
||||
|
||||
### Returning Weave Network Settings Instead of Docker Network Settings
|
||||
|
||||
The Docker NetworkSettings (including IP address, MacAddress, and
|
||||
IPPrefixLen), are still returned when `docker inspect` is run. If you want
|
||||
`docker inspect` to return the Weave NetworkSettings instead, then the
|
||||
proxy must be launched using the `--rewrite-inspect` flag.
|
||||
|
||||
This command substitutes the Weave network settings when the container has a
|
||||
Weave Net IP. If a container has more than one Weave Net IP, then the inspect call
|
||||
only includes one of them.
|
||||
|
||||
host1$ weave launch --rewrite-inspect
|
||||
|
||||
### Multicast Traffic and Launching the Weave Proxy
|
||||
|
||||
By default, multicast traffic is routed over the Weave network.
|
||||
To turn this off, for example, because you want to configure your own multicast
|
||||
route, add the `--no-multicast-route` flag to `weave launch`.
|
||||
|
||||
### Other Weave Proxy options
|
||||
|
||||
* `--without-dns` -- stop telling containers to use [WeaveDNS](/site/weavedns.md)
|
||||
* `--log-level=debug|info|warning|error` -- controls how much
|
||||
information to emit for debugging
|
||||
* `--no-restart` -- remove the default policy of `--restart=always`, if
|
||||
you want to control start-up of the proxy yourself
|
||||
|
||||
### Disabling Weave Proxy
|
||||
|
||||
If for some reason you need to disable the proxy, but still want to start other Weave Net components (router, weaveDNS), you can do so using:
|
||||
|
||||
weave launch --proxy=false
|
||||
|
||||
|
||||
**See Also**
|
||||
|
||||
* [Setting Up The Weave Docker API Proxy](/site/weave-docker-api.md)
|
||||
* [Securing Docker Communications With TLS](/site/weave-docker-api/securing-proxy.md)
|
||||
@@ -0,0 +1,96 @@
|
||||
---
|
||||
title: Integrating Docker via the API Proxy
|
||||
menu_order: 50
|
||||
search_type: Documentation
|
||||
---
|
||||
|
||||
The Docker API proxy automatically attaches containers to the Weave
|
||||
network when they are started using the ordinary Docker
|
||||
[command-line interface](https://docs.docker.com/reference/commandline/cli/)
|
||||
or the [remote API](https://docs.docker.com/reference/api/docker_remote_api/).
|
||||
|
||||
### <a name="attaching-containers"></a>Attaching Containers to a Weave Network
|
||||
|
||||
There are three ways to attach containers to a Weave network (which method to use is
|
||||
entirely up to you):
|
||||
|
||||
**1.** The Weave Net Docker API Proxy. See [Setting Up the Weave Net Docker API Proxy](#weave-api-proxy).
|
||||
|
||||
**2.** The Docker Network Plugin framework. The Docker Network Plugin is used when
|
||||
Docker containers are started with the --net flag, for example:
|
||||
|
||||
`docker run --net <docker-run-options>`
|
||||
|
||||
**Where,**
|
||||
|
||||
* `<docker-run-options>` are the [docker run options](https://docs.docker.com/engine/reference/run/)
|
||||
you give to your container on start
|
||||
|
||||
Note that if a Docker container is started with the --net flag, then the Weave Docker API Proxy
|
||||
is automatically disabled and is not used to attach containers.
|
||||
See [Integrating Docker via the Network Plugin (Legacy)](/site/plugin.md) and
|
||||
[Integrating Docker via the Network Plugin (V2)](/site/plugin-v2.md).
|
||||
|
||||
**3.** Containers can also be attached to the Weave network with `weave attach` commands. This method also
|
||||
does not use the Weave Docker API Proxy.
|
||||
See [Dynamically Attaching and Detaching Containers](/site/using-weave/dynamically-attach-containers.md).
|
||||
|
||||
### <a name="weave-api-proxy"></a>Setting Up The Weave Net Docker API Proxy
|
||||
|
||||
The proxy sits between the Docker client (command line or API) and the
|
||||
Docker daemon, and intercepts the communication between the two.
|
||||
It is started along with the router and weaveDNS when you run:
|
||||
|
||||
host1$ weave launch
|
||||
|
||||
**N.B.**: Prior to version 2.0, the `launch-proxy` command allowed to pass configuration options and to start the proxy independently.
|
||||
This command has been removed in 2.0 and `launch` now also accepts configuration options for the proxy.
|
||||
|
||||
|
||||
By default, the proxy decides where to listen based on how the
|
||||
launching client connects to Docker. If the launching client connected
|
||||
over a UNIX socket, the proxy listens on `/var/run/weave/weave.sock`. If
|
||||
the launching client connects over TCP, the proxy listens on port
|
||||
12375, on all network interfaces. This can be adjusted using the `-H`
|
||||
argument, for example:
|
||||
|
||||
host1$ weave launch -H tcp://127.0.0.1:9999
|
||||
|
||||
If no TLS or listening interfaces are set, TLS is auto-configured
|
||||
based on the Docker daemon's settings, and the listening interfaces are
|
||||
auto-configured based on your Docker client's settings.
|
||||
|
||||
Multiple `-H` arguments can be specified. If you are working with a
|
||||
remote docker daemon, then any firewalls in between need to be
|
||||
configured to permit access to the proxy port.
|
||||
|
||||
All docker commands can be run via the proxy, so it is safe to adjust
|
||||
your `DOCKER_HOST` to point at the proxy. Weave Net provides a convenient
|
||||
command for this:
|
||||
|
||||
host1$ eval $(weave env)
|
||||
host1$ docker ps
|
||||
|
||||
The prior settings can be restored with
|
||||
|
||||
host1$ eval $(weave env --restore)
|
||||
|
||||
Alternatively, the proxy host can be set on a per-command basis with
|
||||
|
||||
host1$ docker $(weave config) ps
|
||||
|
||||
The proxy can be stopped, along with the router and weaveDNS, with
|
||||
|
||||
host1$ weave stop
|
||||
|
||||
If you set your `DOCKER_HOST` to point at the proxy, you should revert
|
||||
to the original settings prior to running `stop`.
|
||||
|
||||
|
||||
**See Also**
|
||||
|
||||
* [Using The Weave Docker API Proxy](/site/weave-docker-api/using-proxy.md)
|
||||
* [Securing Docker Communications With TLS](/site/weave-docker-api/securing-proxy.md)
|
||||
* [Launching Containers With Weave Run (without the Proxy)](/site/weave-docker-api/launching-without-proxy.md)
|
||||
|
||||
|
||||
Reference in new issue
Block a user