e.g. if we get a clash because someone else has updated the data, it
returns the new data so we should work off that next time.
Also re-fetch the Annotations every time round the main loop for safety.
There was a bug in handling "default-allow" ipsets - it could not
cope with out of order receive of Pod updates. E.g:
1) AddPod(Pod_A, PodIP_A),
2) AddPod(Pod_B, PodIP_A),
3) DeletePod(Pod_A),
would result with PodIP_A being removed from "default-allow" ipset,
as such ipset entries were not refcounted. Bypassing of refcounting
was due to the fact that adding a netpol which dst-selects a Pod which
IP addr is in "default-allow" ipset has to remove the IP addr from
the ipset regardless of refcount value of the IP addr entry in the
ipset. So, refcounting in such case didn't make sense and it was
bypassed.
This commit changes the way entries are refcounted in ipsets, and
it makes "default-allow" ipset the same citizen as other ipsets, so
from now "default-allow" ipset is refcounted.
Now we don't bundle the docker command inside weaveexec, we need to do
an explicit 'docker pull' to ensure the images are there.
Also set the weavedb tag to :latest to remove a warning from docker
Also tag kube-peer log messages with "[kube-peers]": in a standard
deployment they end up interspersed with weaver log messages so this
makes it easier to pick them out.
- Test that pods not matching ingress rules are not able to access
the nettest pods.
- Test upgrading of NPC (from legacy to non-legacy).
- Test new semantics of k8s netpol.
The main difference between new and legacy (pre-1.7) netpol semantics
are the following:
* The DenyDefault ingress isolation annotation is obsoleted.
* Traffic is allowed to a pod if there are no netpol selecting
the pod.
See https://kubernetes.io/docs/api-reference/v1.6/#networkpolicyspec-v1beta1-extensions
vs https://kubernetes.io/docs/api-reference/v1.7/#networkpolicyspec-v1-networking
for more details.
weave-npc can operate either in the legacy or the new mode (default). To
use the legacy, pass "--use-legacy-netpol" arg when starting the npc.
In non-legacy mode we create for each Namespace a default-allow ipset
which stores IP addrs of such Pods which are not selected by any
NetworkPolicy.The ipsets are dst's in rules of the WEAVE-NPC-DEFAULT chain.
Docker 1.13 has changed a default policy of FORWARD chain to DROP
(https://github.com/moby/moby/pull/28257) which makes containers
inaccessible from a remote host when the bridge is exposed.
The change breaks e.g. the AWSVPC mode. To overcome this we install
an explicit rule for accepting forwarded ingress traffic to an
exposed subnet which is appended to the WEAVE-EXPOSE chain.
The chain is a target of the rule "-t filter -A FORWARD -o weave".
The change makes "weave expose" to call the "/expose" HTTP
endpoint implemented in router which exposes the bridge.
Such architectural change required as we need to know whether NPC is
enabled when exposing the bridge and weaver knows this fact the best.
Unfortunately, this change makes impossible to "weave expose"
when weaver is not running.
It's sad because this changes a regular pattern into an irregular one,
which will create spurious diffs if more work is added at the end of
the function. Still, this is easier than fixing the lint runner to
ignore the report.
Mount iptables lock file in weave-kube
iptables uses the file `/run/xtables.lock` so that if changes are
under way, another instance of the iptables command can wait till it
is finished.
We need to mount the lock file from the host to the container in order
for this mechanism to work at all.
Note we rely on kubelet touching the file before running any pods -
see https://github.com/kubernetes/kubernetes/pull/47212
`weaveexec` no longer mounting '/' so we can't access the weavedb file
to get persistent peer ID. If `weaver` was running, we couldn't have
read the file anyway because BoltDB does not support concurrent access
from two processes.
Consequence is that if someone really does need the bridge creation on
'weave expose' the peer ID may change if created pre-1.9.0. We'll just
live with that (per @bboreham).
Fixes#2957
- replace `docker stop` with `weaveuitl stop-container`
- replace `docker kill` with `weaveutil kill-container`
- replace `docker rm` with `weaveutil remove-container`
- replace `docker run` with minimal `weaveutil container-run`
- replace `docker inspect -f {{.ID}}` with `weaveutil container-id`
- replace data-only container `docker create` with `weaveutil create-volume-container`
- remove `docker inspect` dependencies from `weave` script
`rewrite_etc_hosts` and `with_container_fqdn`
- rework `weave` script `check_running` and `check_not_running` to use `weaveutil`
- rework `weave version` to use `weaver` /report API or `weaver --version` if not running
- rework `weave setup`'s `docker pull` to run locally rather than in `weaveexec` container
Otherwise, the plugin is not able to load kernel modules
(openvswitch, vxlan, vport_vxlan) required by fastdp which
makes weave to fallback to sleeve.
CAP_SYS_MODULE is required in order to load kernel modules.
- "You cannot call `weave rmpeer` on more than one host" - yes you
can, but you must not call it on more than one host *for the same
peer*
- `weave forget` has nothing to do with this
- "results in duplicate IPs" - no, it causes duplicate address range
assignments
- "the address is reassigned" - it's the address *range* that is
reassigned
- "claim" is a new and confusing term -> drop
- "address space" -> "address range" (that's what it's called
elsewhere)
It was a hack for a badly-configured Kubernetes install: it shouldn't
be necessary, it will only work on an unsecured install, and it
generates confusing error messages when something is really wrong.
If we have namespaces Source and Destination, and Destination
contains a NetworkPolicy allowing access from Source, we need
to provision the ipsets for Source and add them to relevant
selectors, even though Source is DefaultAllow.
This also fixes an issue where if the Namespace labels are updated,
that would be ignored.
Fixes#3059
As discussed internally, this could just create more confusion for the end-user, than bringing benefits for previous users who would potentially wonder why the URLs have changed.
GitHub only allows git.io to point to content hosted under github.com, therefore it was not possible to have the short URLs point to Weave Cloud's Launch Generator.
Currently:
- there is no easy way to change the way we install Docker from Net
- if build-tools' default was to change, Net could break.
This change addresses this situation.
Before this change, when using Docker 17.06 we get:
tests/integration/container_test.py:121: in test_create_with_restart_policy
'You cannot remove a running container', err
E AssertionError: 'You cannot remove a running container' not found in u'You cannot remove a restarting container
The modified image simply checks for "You cannot remove a".
There are 3 ways to get help:
• weave --help
• weave help
• weave <command> --help
At the moment, only the first one prints the usage instantaneously, the
others go much further in the script and take quite some time, which is
not idea of impatient users.
Note that "help" only works because it's not a recognized command and
ends up in the default case of "case $COMMAND" (and indeed, "Unknown
weave command 'help'" is displayed). This is because handle_help_arg()
always returns true and so the second part of:
handle_help_arg "$1" || handle_help_arg "--$1"
is never evaluated.
This commit changes things a bit so all 3 ways to get help are
recognized early, print the usage and exit.
Currently our `Makefile` and `bin/release` scripts are such that we effectively do the following when releasing:
```
publish:
for arch in [amd64 arm arm64]:
sub-publish:
clean_bin
publish
plugin_publish
```
which leads the Docker v2 plugin to contain `arm64` binaries even though we target `amd64`.
Swaping `publish` and `plugin_publish` is a simple way to avoid this.
The fix ensures that if odp is not supported (usually due to
missing openvswitch, vxlan or vport-vxlan kernel modules),
weaver will create the pcap based bridge instead of crashing.
`proxy_parse_args` is currently called:
- once, all the time
- again, if Docker is configured with TLS.
If a second call to `proxy_parse_args` happens, given the way we append to `PROXY_ARGS` and merge proxy and remaining args, genuine arguments like peers can be mixed with flags/options/etc. hence forming an invalid peers list and crashing Weave Net.
Just no-op instead.
This change is necessary because previously a recent build-tools
change no longer excludes prog/* from unit testing since other
projects actually do have genuine tests under there.
This behaviour was breaking the use of pod selectors for the 'from'
part of a rule.
Move checking of local pods into namespace.go so we can maintain
LocalIpSet correctly
If it's destined for a pod on another node it will be checked again
when it reaches that other node. The previous version was rejecting
traffic coming in from outside the cluster.
It is necessary in case when kubelet's args includes `--hostname_override=`.
Without this change, pods on hostname overriding kubelets will never be local,
and all pod's traffic will be blocked.
Details:
- Update weave-kube docs to avoid explicit versioning by leveraging the Launch Generator.
- Update weave-kube docs to mention YAML customisation via the Launch Generator.
- Warn about potential backward incompatibility of the generated YAML, and how to ensure YAML and Net versions are compatible.
Before this change, `go get`-ting` would pick the latest version of `shfmt` which keeps changing, hence frequently breaking our builds.
After this change, we download the `shfmt` binary from its GitHub releases page which is fast and locks the version we use. Note that `RUN` does not like herestrings, hence `echo "..." | sha256sum -c` for checksum.
Alternatives considered:
- `go get gopkg.in/mvdan/sh.v1/cmd/shfmt` -- but `gopkg.in` currently doesn't behave well for this tool
- `go build` from a `git` tag -- but this is much more involved.
We don't get a very useful error object back from go-iptables and I
didn't feel like parsing the message, so just ignore all errors.
It would be racy to try to check if WEAVE-NPC existed before calling
NewChain.
EmptyDir has the same lifetime as the pod, whereas we want our
persistence to extend past that, e.g. when Weave Net is upgraded.
`weave reset` cleans out the file.
We assume that /var/lib is writable.
Since it is only called in contexts where we have already checked that.
We don't need the detail of whether plugin is enabled; if it's not
running then it's ok to remove those socket files.
If the plugin wasn't enabled then that network shouldn't exist.
If the network 'weave' doesn't exist then util_op remove-plugin-network will do nothing.
If it does exist for some reason then docker will pause for a while and remove it anyway.
For some reason the previous version was de-newlined by the shell and
the new version isn't. Since I can't figure out the exact reason the
shell is now behaving differently (man page says it depends on the
quoting that is in effect) I brute-force it with 'tr'.
The standard case for --local is when the weave script in the weaveexec container
is run by the weave script, which has just checked the version.
--local is also used from weave-kube where we don't mount the docker socket and
therefore cannot check.
Since --local is undocumented we will not worry about any other cases; the worst
that can happen is a confusing error message.
The problem is that the plugin name is prefixed with a registry name.
So, if the plugin is fetched from Docker Store, its name will be
"store/weaveworks/net-plugin".
The detection function does an exact match on "weaveworks/net-plugin",
so in the Docker Store case, the presence of the plugin cannot be
detected.
Weave Net initially had the ability to start a single component at a time with `launch-proxy` and `launch-router`.
This change enables this again via `--proxy=false` despite the merge of the proxy and the router.
Note that by default:
- `launch` passes `--proxy` which enables the proxy and keeps behaviour consistent with `launch` pre-merge,
- `weaver` defaults `--proxy` to `false` which disables the proxy and keeps behaviour consistent with `weaver` pre-merge (as it was `weaveproxy`'s responsibility).
Remove tests of situations that don't exist any more and fix the following tests:
- Fix test 660: pass arguments in correct order.
- Fix test 620: no double launch, weave stop instead of kill -9.
- Now that router and proxy have been merged, we should only call `weave launch` once.
- `sudo kill -9` was introduced because we previously had `docker kill` (see: http://github.com/weaveworks/weave/commit/cb73b738621d57727072ae998cdeaec337f23a1a), because we had no `weave stop-proxy` yet (see: http://github.com/weaveworks/weave/commit/e31f21a6d224d61de1d8a940ea4b0b45cebc9723). Pre-proxy-merge, this should just have been `weave stop-proxy`, and now that router and proxy have been merged, we should just call `weave stop`.
- Fix test 650: no double launch.
- Fix test 630: remove redundant case & assertions.
- Fix test 090: remove irrelevant assertions.
PING
Given `proxy` & `router` processes have been merged, `launch-proxy`,
`launch-router`, `stop-proxy`, `stop-router` do not make sense any more, and
should just be `launch` and `stop` with the appropriate flags.
Note: we no longer need to detect awsvpc when launching.
The "AWS VPC" mode is now set via the `--awsvpc` flag.
Before we had to "detect" it when the proxy was potentially started
later, after the router had started.
We drop WEAVEPROXY_DOCKER_ARGS as obsolete.
If this function dies in the middle, the leftover weave-kube-test set
causes this function and weave-npc to break. In particular
this means we can never restart weave with the launch script.
Here we clean up in advance, in case there's leftovers from a previous run
Fixes#2934
"docker.sock" is used to access Docker API which is required to:
1. subscribe to Docker events to configure-arp,
2. query Docker network info to detect whether multicast should be
enabled.
3. get list of Swarm peers before starting the plugin.
(1) is currently not implemented.
(2) is replaced by WEAVE_MULTICAST env var which
can enable multicast for all Weave networks created by
the plugin (not ideal, but better than nothing).
(3) is fixed by not removing "restart.sentinel".
Fixes#2921, as all errors are now ignored, including `ENOENT`.
This command typically attempts to delete the network interface `eth0` of a container being destroyed by Kubernetes.
If this interface has already been destroyed or is missing for whatever reason, we still want to remove this container's entry from IPAM in order to free associated resources.
Fixes:
- `test/run-integration-tests.sh:160:75: arithmetic expressions must consist of names and numbers`
- `test/run-integration-tests.sh:265:56: arithmetic expressions must consist of names and numbers`
- `test/run-integration-tests.sh:295:61: arithmetic expressions must consist of names and numbers`
- `test/run-integration-tests.sh:309:49: arithmetic expressions must consist of names and numbers`
- `test/run-integration-tests.sh:316:41: arithmetic expressions must consist of names and numbers`
- `test/run-integration-tests.sh: run shfmt -i 4 -w test/run-integration-tests.sh`
See also: https://circleci.com/gh/weaveworks/weave/8685
Why:
* In some environments Nodes have an ExternalIP but no InternalIP
This change addresses the need by:
* Falling back to ExternalIP addresses if there isn't an InternalIP for a node
Fixes:
- `test/run-integration-tests.sh:160:75: arithmetic expressions must consist of names and numbers`
- `test/run-integration-tests.sh:265:56: arithmetic expressions must consist of names and numbers`
- `test/run-integration-tests.sh:295:61: arithmetic expressions must consist of names and numbers`
- `test/run-integration-tests.sh:309:49: arithmetic expressions must consist of names and numbers`
- `test/run-integration-tests.sh:316:41: arithmetic expressions must consist of names and numbers`
- `test/run-integration-tests.sh: run shfmt -i 4 -w test/run-integration-tests.sh`
See also: https://circleci.com/gh/weaveworks/weave/8685
This logic was added for backward compatibility and to warn users about changes made ~2 years ago.
Given we are planning a 2.0 release for Weave Net, such logic is now irrelevant and can be removed.
For V2 plugin, "latest" means "latest stable release", to make
instructions simple for end-users. So we don't want to overwrite
"latest" with a random build by accident.
Docker Plugin V2 does not expose a plugin name to the plugin, so we
check for "net-plugin" within driver name of a network to detect
whether network is ours.
- "noDNS" controls whether upon ContainerStarted event a container
should be registered within the Weave DNS.
- "isPluginV2" will be used to determine a path to host's /proc.
Renamed to "is_plugin_v1_enabled" and "is_plugin_v2_enabled".
Improve weave status and weave launch* err message when plugin-v2 is running
```
$ weave launch
Docker plugin "weaveworks/net-plugin" is running; Aborting.
$ weave status
<..>
Service: plugin (v2)
DriverName: weaveworks/net-plugin
```
"docker plugin" does not support tagging plugin images, therefore
we need to build plugin images two times - one for :latest and
for :$(WEAVE_VERSION).
Pushing of :latest happens only if $UPDATE_LATEST is not false.
For example:
```
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
$ docker plugin ls
ID NAME DESCRIPTION ENABLED
e80beb4367a6 weaveworks/pluginv2:latest Weave Net plugin for Docker true
$ weave --local launch
weaveworks/pluginv2 is already running.
$ weave --local launch-proxy
weaveworks/pluginv2 is already running.
$ weave --local launch-router
weaveworks/pluginv2 is already running.
$ weave --local launch-plugin
```
NetworkAllocate is called on Swarm master node which creates a network.
The return option map is used to describe the network, and is passed
to CreateNetwork which is called on all nodes when a service is
created.
Returning nil instead the actual options made Docker to omit
the "works.weave.multicast" flag, thus no multicast could be used
in Swarm.
This simplifies the following:
- plugin-v2 does not need to start "plugin" as a separate process, thus
Docker is able to properly restart plugin-v2 in a case of any child
process failing.
- No need for weaveplugin container.
plugin is enabled by default when running "weave launch". when starting
only the router, you should pass "--plugin" parameter to enable it.
The env var WEAVE_NO_PLUGIN is no more.
Since 1.12.0, `docker inspect -f "{{ .NetworkSettings.Networks.<network>.Aliases }}"` also returns the container's short ID.
See also: https://github.com/docker/docker/blob/master/CHANGELOG.md
> 1.12.0 (2016-07-28)
> Networking
> Add container's short-id as default network alias #21901
Upgrading `docker/docker-py` to 1.9.0-rc2 effectively relaxes test assertions for:
- `tests/integration/network_test.py#test_connect_with_aliases`
- `tests/integration/network_test.py#test_create_with_aliases`
which do something equivalent to:
```
$ docker network create net1
$ docker run --name c1 -d busybox top
$ docker network connect --alias foo --alias bar net1 c1
$ docker inspect -f "{{ .NetworkSettings.Networks.net1.Aliases }}" c1
[foo bar e52bf50e5ee7]
```
allowing us to be consistent with the above change.
In 1.8.1, the below fails as the container's short ID would be present:
```
self.assertEqual(
container_data['NetworkSettings']['Networks'][net_name]['Aliases'],
['foo', 'bar'])
```
In 1.9.0-rc2, the below passes as the container's short ID is ignored:
```
aliases = (
container_data['NetworkSettings']['Networks'][net_name]['Aliases']
)
assert 'foo' in aliases
assert 'bar' in aliases
```
The vars can be customized before enabling the plugin with e.g.:
docker plugin set $PLUGIN_NAME set WEAVE_MTU=8160
The ARP settings apply to "weave" bridge. In order to manipulate them,
we bind mount the host's /proc to /host/proc.
(The mount type of /proc changed to bind, Otherwise (when type =
"proc"), the kernel does not propagate pids of host processes as the
plugin runs in a separate PID ns.)
Persistence relies on weave.db which is stored under
/var/lib/weave/weave.db on the host.
NOTE: we do not persist peer list for plugin-v2, as it gets
restored from existing alive master nodes during the peer discovery.
The peer discovery relies on "GET /info" API call which returns
list of master nodes. The peer list is passed to weaver when
launching it.
If node is a master, then we pass "--ipalloc-alloc
consensus=$(MASTER_NODES_COUNT)" to weaver. Otherwise, we pass
"--ipalloc-alloc observer".
Without this commit, `kubeadm` typically upgrades whichever version of Kubernetes is installed, sometimes leading to conflicts in between components' version.
This fixes the issue behind #2876 and should avoid build failures like [weave/8373](https://circleci.com/gh/weaveworks/weave/8373).
They seem to stop Docker using its build cache.
Removing the line entirely stops weaveproxy from working, as it
assumes it can exec `./weave` from the current directory.
The executables have dependencies that are not apparent to `go build`;
notably the build container. If Go doesn't see anything is out of date
then it will do nothing, hence touch the file so next time we run
`make` it is up to date.
It is possible to receive FastDatapathCryptoInitSARemote control plane
message before Confirm'ing a connection. In such case, resetting
heartbeatTimer leads to null pointer dereference, as the timer is
initialized during Confirm'ation.
In this situation, skipping the reset is non-harmful, because
Confirm'ing will reset it.
NB: the reset to 0 should only happen after establishing the connection
on both ends.
weave-kube is run by alpine image which uses busybox. modprobe of
busybox will return the "module not found" error [1], if a module is
built-in, which is an opposite behavior to modprobe distributed in
mainstream distros (e.g. ubuntu).
[1]: https://bugs.busybox.net/show_bug.cgi?id=5270
Previously, the first line of the Dockerfile would have been selected, regardless of its value.
What we want is to actually select the first line matching the regex, and then extract the group corresponding to the Go version out of it.
- One unique file to list all dependencies and dependencies' versions (except Go, currently defined in `build/Dockerfile`).
- Custom versions can now be injected into Vagrant VMs.
- Vagrant dev VMs, Vagrant test VMs, and `run-integration-tests.sh` all source from `DEPENDENCIES`, to keep things 'DRY'.
- Vagrant versions can be overriden using environment variables, like it was possible in `run-integration-tests.sh`.
The intention, per the comments, is that host1 should claim from host2.
But host2 and host3 can carve up the space either way round. If host1
claims from host3 then there is a race whether anyone finds out about
it.
Adding a 'prime' on host2 ensures the space is all owned by host2 at that point.
doing it from the script
Note we need to run weaver in the host pid namespace, so it can search
for existing container IPs. Also now we are firing off sub-processes
it's better to not be PID 1 so Linux doesn't expect us to reap zombies.
This should be useful when we just want to type one make integration-tests / ./run-integration-tests command to make/start VMs/configure them/test, but also investigate potential failures afterwards.
This should make development easier by allowing developers to set HOSTS in their calling shell, and re-use the value for this env. var. when calling individual test scripts, e.g.:
```
cd test
eval $(./run-integration-tests.sh setup)
./200_dns_test.sh
```
CircleCI keeps 10 nodes in order to speed up the build, but the default is 3, as this is the minimum required to run any test. This should make more sense as a default for a developer to quickly start an environment and iterate.
There may be situations when Terraform/Ansible/etc. fail to provision test machines.
In these cases, we want to fail fast instead of waiting until we time out in circle-test-pre and circle-test-smoke.
This way, Vagrant VMs and cloud-provided VMs are configured in the exact same way, hence avoiding configuration drift and subtle bugs associated to different versions of software.
Provisioning and configuration being expensive time-wise, we create Google Cloud Platform images for each Docker/Kubernetes/Kubernetes CNI versions triple, and configure these once (instead of for each build), and then re-use these in subsequent builds, effectively implementing a 'cache' of images.
Reason: test is periodically failing because of the timeout being too aggressive, especially when using Google Cloud Platform together with Terraform and Ansible.
If building against the latest 'build-tools', you would typically get:
tools/runner/runner.go:18:2: cannot find package github.com/weaveworks/common/mflag
This change fixes the issue by upgrading both dependencies.
Makes what the build does explicitly and helps for potential debugging.
Also reminds us that we are skipping these files, so that we ultimately shfmt them and stop lint-ignoring them.
Previous commit upgrades Weave Net to the latest version of `build-tools`.
However, `./tools/test`'s default behaviour has changed, so we need to explicitly pass new options/arguments, in order to keep it behaving like before fd568682c3.
Lint-ing all of Weave Net is currently not desirable because:
* it would create conflicts on many branches,
* it would pollute the git history,
* etc.
and because `lint` currently lints all files except `./vendor`, this breaks Weave Net's build.
As a result, Weave Net is not using the latest commit in `build-tools`'s `master` branch, which is also source of problems:
* it limits standardisation of projects across Weaveworks,
* it limits the ability to use the latest features of `build-tools`,
* it complexifies merging changes in `build-tools` (e.g. #53 and weaveworks/weave#2694 for weaveworks/weave#2647),
* etc.
This change:
* brings Weave Net to the latest version of `build-tools` (which now supports `.lintignore` files),
* adds such a `.lintignore` file to skip all bash scripts (in order to avoid breaking the build).
`GLOB`s in `.lintignore` can then, over time and as scripts are `shfmt`-ed, be relaxed and maybe even removed.
If the machine coordinating the test runs does not have jq, then test #175 fails with:
> test #1 "weave_on test-0.lon1.weave-net report | jq -r '.Router.Targets[] | tostring' | sort" failed:
> expected "test-1.lon1.weave-net
> test-2.lon1.weave-net"
> got nothing
This change completely removes the dependency on jq to make the test more robust and avoid potential confusion.
Test hard-codes a string containing '\n' and then expects echo
to interpret it as a newline, which it does not without the -e option.
This fixes flaky test runs like the below:
>>> Running /root/src/github.com/weaveworks/weave/test/150_connect_forget_2_test.sh on [138.68.153.213 138.68.149.186]
>>> Test /root/src/github.com/weaveworks/weave/test/150_connect_forget_2_test.sh finished after 12.4 secs with error: exit status 1
test #5 "direct_peers 138.68.149.186 | sort" failed:
expected "138.68.153.213\n138.68.149.186"
got "138.68.149.186\n138.68.153.213"
So we don't accidentally read or write the hosts's /etc.
Also move the other volumes under /host to be more consistent with
what the weave script expects.
This is a combination of 4 commits.
The first commit's message is:
2677 docu, how to publish prometheus metric endpoint on all interfaces
This is the 2nd commit message:
2677 change docu on how to publish metrics, be more careful with publishing on all interfaces
This is the 3rd commit message:
2677 fix spelling
This is the 4th commit message:
2677 fix wrong port title and grammar
Enabled hairpin mode on vethwe-bridge was one of the root causes
for installing looping flows in the fastdp mode.
Also, it confused the weave custom L2 bridge, as the bridge treats
a bounced back packet, e.g. ARP brodcast request, as a local one
(the case for "Captured a packet associated with remote host").
Previous fix in b4a43f1b85 did not work
when built with code coverage.
Running a test script with -v causes `weave_on` to output progress
messages, so we don't want to use those commands inside `$()`
So something waiting for the config (e.g. Kubernetes) doesn't try to
talk to Weave before then (this only helps on first install, but that
tends to be when things are busiest).
- Rewrote conditions to keep c.ident immutable and hopefully makes
things clearer.
- Added a case to tolerate reclaim after we have used CNI (passed CID
is “_” and existing CID is a real container ID).
test #4 "[
3e52b548e6df304c61ea5bee0af4b3515e025e7e25152c65ecae3d03c71cf52d ==
Unable to claim: address 10.32.0.3/12 is already owned by
fbe411facc8b657c5850591ab56fc40fb56160d43db0d7363a29ba3edad61134
Unable to claim: address 10.32.0.1/12 is already owned by
cf16a2bcdee8dd1ef7e5f0a611127611e67ea734f45d7526678fc3b1fc0c6f5d
3e52b548e6df304c61ea5bee0af4b3515e025e7e25152c65ecae3d03c71cf52d ]"
failed:
program terminated with code 2 instead of 0
1 of 6 tests failed in 6.499s.
The metrics include:
- weave_packets_total
- weave_bytes_total
The problem with those metrics is that fastdp periodically flushes
flows including their stats thus makes the current implementation
of the metrics unreliable.
Serve metrics+status on status socket and api+status+metrics on api
socket; the reasoning is that metrics or status are read-only hence
may be scraped from an off-machine connection, while we don't want to
open the control port up unprotected.
This implementation should be more efficient because it only uses the
names under /proc, whereas the previous implementation fetched the
full directory entry for each one, and sorted them too.
Otherwise, we risk to lose peer list when any failure happens after
the creation but before storing the list and as a consequence,
the weave container gets restarted.
The change applies to GetNetDevsWithPredicate. The function calls
FindNetDevs which already does the same filtering.
The change prevents from "container-addrs" (weaveutil) returning
"unable to open X process namespace" error which happens when
a container dies while the cmd is being executed.
New behaviour in Docker 1.12 means it disregards a plugin-supplied
address pool that overlaps an existing route, which causes a hang as
noted in #2469. When we pass in the subnet, Docker believes we really
do want that address range and avoids the hang.
The sources include:
- /etc/machine-id (generated by "systemd-machine-id-setup") or
/var/lib/dbus/machine-id (generated by "dbus-uuidgen").
- /sys/class/dmi/id/product_uuid.
- /sys/hypervisor/uuid.
The product of the concatenation should produce an unique identifier
which is stable across reboots.
Docker for Mac 1.12.0-rc3 (as of beta18) looks for mounted paths on VM
first, and when it doesn't find them there, it assumes they refer to
paths on the Mac OS host. At which point it will complain that the
paths don't exit.
So instead we mount / since that will always exist on the VM. It's
also what we used to do already when launching the router.
Fixes#2434.
since people keep tripping over that.
Also
- add new error message spat out by recent dockers correct the socket
- URLs - they had fallen victim to a 'docker'->'Docker' replacement
- shorten the note on using the plugin
The #2418 has changed a behaviour of "weave ps" which outputs
"Link not found" in the case of weave not running. The previous
behaviour was to output an empty line.
Make sure that any network namespace changes happens at the end of
the cmd invocation. Otherwise, we are risking to end up in a situation
in which OS scheduling threads are in a "wrong" namespace.
See WithNetNS for more details.
- Optimize. Use LinkByName instead of iterating over list of available
links. Linux does not support interfaces with the same names.
- Remove unnecessary indirection in utility functions which return
common.NetDev.
* highlight the need for `weave expose` in CNI/k8s
Fixes#2405
* Extend error message
* rearranged the sentences
weave launch <peer hosts> seems a bit orphaned here maybe include the weave connect command as well, since it's being mentioned.
Added log lines for packets that we will broadcast;
Added log lines for flows we don't know how to handle;
Moved the line for when we expect to insert a flow down to the miss-handler;
Packets handled by the bridge already have their own logging via --pktdebug
We want to setup the necessary arp settings as soon as possible
and before we re-insert DNS entries. Otherwise, the announced
containers might not be reachable.
Also, do not try to reclaim for weave:expose inside populate_router,
because we do expose before calling it.
In order to re-attach the router and make it work in awsvpc mode,
the following has to be done:
- expose_ip on the router
- adjusting arp settings
- restoring host routes
To detect that we run in awsvpc mode, we inspect cmd parameters
of the weave router instead of GET'ing /ipinfo/tracker. This is so,
because the HTTP server started by the router might not be running
at the time of restoration.
If no peer for transfer is found, we transfer them to
mesh.UnknownPeerName to notify the ring update tracker.
Makes the awsvpc tracker to remove local entries from
the VPC route table when the last peer calls "weave reset".
This requires the following additional steps:
- Setting proxy_arp on on the bridge, because that's how we do
the routing (check the comment at the place where we set it on).
- Disable ARP requests queueing, because it introduces unnecessary
delay for the first ARP request resulting in a high latency of
the first packet (on t2.micro machines I've encountered ~700ms
latency). Also, the queue is bounded, so we might risking to drop
the requests.
When running in the AWSVPC mode, we need to do the following:
- Keep the HW TX offloading on.
- Check that the allocated address belongs to the default subnet,
because only one subnet is allowed and it should be the default one.
If it is not possible to determine whether AWSVPC is on, we ignore
all the steps, because the attachment routines have to work
regardless whether the router is running and the AWSVPC detection
is done by querying the /ipinfo/tracker endpoint served by
the router.
The tracker's HandleUpdate method is called by the ring update routines.
In addition, we add a dummy overlay for AWSVPC to make `weave (status|
report)` to produce reasonable reports which includes AWS hosts
connection state.
The smoke-tests are meant to be run in a context where you have just
uploaded a build. If that upload failed and we don't do this check
then we will download the 'latest' images from DockerHub.
Now it's off by default, and there is an option to enable the
multicast route per-network.
We turn it on for the `weave` network created when we start the plugin.
Also move netlink and netns code from common to net
Creates interface if not already there
Adds addresses
Move the set link 'up' to after addresses are added
This change is backward compatible, because the underlying types of
address.Offset (the previous type) and address.Count are the same
and the Gob encoder does not require types to exactly correspond.
When Docker restarts a container and something goes wrong attaching
the network, kill the process inside the container instead of killing
the container, so that Docker will restart it again
- it either retries for consensus or retries operations we would have tried previously.
There is no point retrying pending operations if we are waiting for consensus.
- it either retries for consensus or retries operations we would have tried previously.
There is no point retrying pending operations if we are waiting for consensus.
- strip "Weave" and "Weave Net"
- "Integrating a Host Network with Weave" -> "Integrating with the
Host Network"
- "Configuring Weave to Explicitly Use an IP Range" -> "Allocating IPs
in a Specific Range"
- move "Managing Services in Weave Net" up so it comes after
"Integrating a Host Network with Weave Net", to which it is deeply
related
- move "Adding and Removing Hosts Dynamically" down so it is adjacent
to the other sections which talk about peer connectivity
vendor/github.com/Sirupsen/logrus to latest release 0.10.0
vendor/github.com/appc/cni to latest master
vendor/github.com/boltdb/bolt to latest release 1.2.0
vendor/github.com/coreos/go-iptables to latest release 0.1.0
vendor/github.com/fsouza/go-dockerclient to latest master
vendor/github.com/docker/docker to latest release 1.11.0
vendor/github.com/docker/libnetwork to v0.7.0-dev.6 matching docker 1.11.0
vendor/github.com/docker/machine to latest release v0.7.0
vendor/github.com/google/gopacket to latest master
vendor/github.com/gorilla/context to latest release 1.1
vendor/github.com/gorilla/mux to latest release 1.1
vendor/github.com/hashicorp/go-cleanhttp to latest master
vendor/github.com/miekg/dns to latest master
vendor/github.com/opencontainers/runc to latest release 0.1.0
vendor/github.com/stretchr/testify unchanged at 1.1.3
vendor/github.com/vishvananda/netlink to latest master
vendor/github.com/vishvananda/netns to latest master
vendor/github.com/weaveworks/go-checkpoint unchanged; already at latest on master
vendor/github.com/weaveworks/go-odp to latest master
vendor/github.com/weaveworks/mesh to latest master
vendor/golang.org/x/crypto to latest master
Otherwise, we are risking to leak DNS entries which happens when
ContainerName is passed to `weave reset` and subsequent internal call
to nameserver creates a new entry instead of replacing the old one.
The ContainerID of the new entry is set to ContainerName and in such case
stopping the container will not remove the new entry.
Merging a ring now indicates whether the ring has been updated. This
prevents excessive allocation retries, which in turn can result in
repeated space requests - i.e. if an allocation cannot proceed due to
lack of space - which in turn can result in excessive ring
fragmentation since many of the requests will result in the creation
of a new ring entries, due to the need to split ranges.
Fixes#2181.
2016-04-17 12:40:18 +01:00
415 changed files with 18126 additions and 5335 deletions
- our help page, to choose the best channel (Slack, etc.) to reach out: https://www.weave.works/help/
** Is this a FEATURE REQUEST? **
If so, please search existing feature requests, and if you find a similar one, up-vote it and/or add your comments to it instead.
If you did not find a similar one, please describe in details:
- why: your use-case, specific constraints you may have, etc.
- what: the feature/behaviour/change you would like to see in Weave Net
Do not hesitate, when appropriate, to share the exact commands or API you would like, and/or to share a diagram (e.g.: asciiflow.com): "a picture is worth a thousand words".
** Is this a BUG REPORT? **
Please fill in as much of the template below as you can.
Thank you!
-->
## What you expected to happen?
## What happened?
<!-- Error message, actual behaviour, etc. -->
## How to reproduce it?
<!-- Specific steps, as minimally and precisely as possible. -->
## Anything else we need to know?
<!-- Cloud provider? Hardware? How did you configure your cluster? Kubernetes YAML, KOPS, etc. -->
## Versions:
<!-- Please paste in the output of these commands; 'kubectl' only if using Kubernetes -->
This release fixes a race-condition in the IP reclaim code for weave-kube
where two nodes could end up fighting over the same space and break
connectivity #3190, #3192
## Release 2.1.2
This release fixes a couple of bugs discovered since the release of Weave Net 2.1.0
##Bug fixes
* Fix crash seen when starting 10-15 nodes simultaneously #3184,#3186
* Fix NetworkPolicy blocking traffic if updates come out of order from Kubernetes #3177,#3181
Thanks to the following contributors:
@zignig
[Full list of changes](https://github.com/weaveworks/weave/milestone/66?closed=1)
## Release 2.1.1
As 2.1.0, but fixing a couple of installation glitches. #3175,#3176
## Release 2.1.0
##New Features
Improved Kubernetes Network Policy - Weave Net now supports the
'v1' policies introduced in Kubernetes 1.7 as well as the 'beta'
policies supported previously. See [Kubernetes 1.7 changelog](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.7.md#network)
for differences. To use old policies, `--use-legacy-netpol` argument
should be passed to `weave-npc`. #3105,#3141,#3151,#3169
Weave Net now reclaims IP addresses owned by Kubernetes nodes which
have been deleted from the cluster - this avoids running out of IP
addresses when many nodes are added and deleted over a long period.
#2797,#3149,#3170,#3172
##Other improvements
* Export a Prometheus-style metric giving count of unreachable peers #3119
* Update 'gopacket' library to reduce memory use by approx 15MB #3160
* Replace bundling the 'docker' binary with our own code to avoid
security vulnerability alerts and save space #2957,#3110
##Bug fixes
* When `weave expose` is used, allow traffic into the Weave network -
up till version 1.12 Docker would do this for us, but in 1.13 they
stopped so now we do it. This change makes `weave expose` require
Weave Net to be running. #2758,#3122
* Arm64 build now works on non-kubernetes installs #2832,#3110
* TX offload was being disabled in 'awsvpc' mode, which slows down packet sending #3089
* Removed spurious 'nil' in logs from CNI DEL operation #3143
##Build and test
* Images are now also built for the ppc64le platform #3129
* Tweak build scripts to run on OSX as well as Linux #3135
##External Contributors
Thanks to the following contributors:
@caarlos0
@dtshepherd
[Full list of changes](https://github.com/weaveworks/weave/milestone/59?closed=1)
## Release 2.0.5
Bug fixes
* Fix /etc/hosts inside containers so the container's name resolves to
its Weave Net address #3136,#3138
* New weave-kube config for Kubernetes 1.7 and 1.8 which resolves an
intermittent conflict with kube-proxy that could break Weave Net
until reboot #2998,#3134
* Remove persistence file in `weave reset` when using Docker plugin V2 #3103,#3114
Build and test
* Some trivial changes to placate go-lint #3137
[Full list of changes](https://github.com/weaveworks/weave/milestone/63?closed=1).
## Release 2.0.4
Bug fixes
* weave-npc failed on Centos 7, due to older 'ipset' version in kernel #3099,#3100
[Full list of changes](https://github.com/weaveworks/weave/milestone/62?closed=1).
## Release 2.0.3
Bug fixes
* Weave-npc would crash on a policy with no 'from' part - regression introduced in 2.0.2 #3095,#3096,#3097
[Full list of changes](https://github.com/weaveworks/weave/milestone/61?closed=1).
## Release 2.0.2
Bug fixes and minor improvements
* Fix race condition in weave-npc which would intermittently block all traffic for a namespace #3057,#3059
* Ensure Fast Datapath works on machines that need to mount the kernel module dynamically #3080
* Regression: weave-npc would block everything if `kubelet --hostname-override` was used #3049,#3051
* Fix netfilter rules to block containers from accessing the Weave Net control endpoint #3093
* If DNS server is off then disable proxy DNS registration, to avoid spurious errors #3054,#3088
* Add comments to each iptables rule and ipset, to help when troubleshooting #3064
* Remove code that checked for an outdated fallback address for Kubernetes api-server #3071
* Add a label to the weavedb image so it can be filtered out by tools #3066
* Fix various build and continuous-integration failures #3061
* Print 'help' text faster in the weave script #3056
* Add an option to create continuous integration hosts in different ways #3060
* Remove remnants of the pre-2.0 proxy and plugin from build and test #3035,#3036
[Full list of changes](https://github.com/weaveworks/weave/milestone/60?closed=1).
## Release 2.0.1
Bug fixes and minor improvements
* Fall back to slower data path (`sleeve`), rather than crashing, when the machine lacks VXLAN support (required for “fast data path”, `fastdp`) #3043
* Fix bug in processing of arguments when Docker has TLS enabled, rather than crashing with invalid peers list, e.g. `lookup --tlsverify: no such host`#3039
* Add `kube-system` namespace back to `weave-kube`'s YAMLs, preventing omissions leading to errors like `error contacting APIServer: the server does not allow access to the requested resource`#3033,#3042
* Fix release script to prevent ARM64 binaries to end up in AMD64 `net-plugin`, leading to `Error response from daemon: dial unix /run/docker/plugins/<id>/weave.sock: connect: no such file or directory` when installing `net-plugin`#3045
*`weave reset` and `weave rmpeer` now only contact Weave Cloud when Weave Net is configured with a Weave Cloud token, preventing unnecessary requests and potentially confusing `401 Unauthorized` errors in Weave Net’s logs #3044
[Full list of changes](https://github.com/weaveworks/weave/milestone/58?closed=1).
## Release 2.0.0
New Features
Peer Discovery via Weave Cloud
You can now get all your Weave Net peers to find each other via the
Weave Cloud service, instead of maintaining a list of peers at
More details in the [change log](https://github.com/weaveworks/weave/issues?q=milestone%3A1.7.0).
## Release 1.6.2
Bug fixes and minor improvements
* Fixed hang after stopping and restarting on Docker 1.12 #2469/#2502
* Avoid an error on Google container images by checking for tx offload support #2504
* Fixed an issue where the supplied peer list could be ignored when restarting after failure #2503/#2509
* Check for empty peer name on launch #2495/#2501
More details in the [change log](https://github.com/weaveworks/weave/issues?q=milestone%3A1.6.2).
## Release 1.6.1
Bug fixes and minor improvements
*`weave ps` was occasionally failing to list allocated addresses of containers #2388/#2418/#2445
*`weave launch[-router]` on 4.2 kernel would appear to succeed even if the fast datapath VXLAN UDP port was in use by a different process #2375/#2474
* Launching the proxy would fail when the Docker daemon could not be detected #2457/#2424
* The CNI plugin did not work with Apache Mesos #2394/#2442
* Router stopped working after a restart in the AWSVPC mode #2381/#2409
* Router crashed when the Docker API endpoint parameter was explicitly set to empty #2421/#2467
* The CNI plugin did not work on recent versions of Docker for Mac #2434/#2442
* The CNI plugin assigns an IP to the bridge if necessary, which avoids failures if `weave expose` has not run yet #2471
* Distinguish peer name collisions from attempts to connect to self in logs #2460
* Improve host clock skew detection message #2174
* Improve the error message returned when executing `weave launch-plugin` without the router running #2293/#2416
* The `create-bridge` subcommand was not enabled in the fast datapath mode #2464/2466
* Allow users to omit `weave setup[-cni]` by initializing the CNI plugin on the `launch[-router]` subcommand #2435/#2442
* Reduce verbosity of fast datapath miss event logs #1852/#2417
* Include the `ipam` option in the help output of the `status` subcommand #2425/#2426
* Remove a harmless duplication of the `--no-dns` parameter #2430
* Internal refactoring
* Improvements to testing and building
* Improvements to the documentation
More details in the [change log](https://github.com/weaveworks/weave/issues?q=milestone%3A1.6.1).
## Release 1.6.0
## Highlights
* A new [AWS VPC](https://weave.works/docs/net/latest/using-weave/awsvpc/) mode
that leverages Amazon Virtual Private Cloud for near-native network
performance, as an alternative to the Sleeve and Fast Datapath
overlays
* Docker 1.12 introduced some internal changes that made it
incompatible with previous version of Weave Net - this version
restores compatibility
* An [operational guide](https://weave.works/docs/net/latest/operational-guide)
detailing best practices for deploying and operating Weave Net
* Changes to the target peer list are remembered across restarts,
making it much easier to deploy resilient networks
* The version checkpoint now transmits network mode (e.g. 'awsvpc')
and kernel/docker versions to us to inform and guide our development
efforts. See the [installation documentation](https://weave.works/docs/net/latest/installing-weave/)
for instructions on disabling the checkpoint feature.
More details in the [change log](https://github.com/weaveworks/weave/issues?q=milestone%3A1.6.0).
## Release 1.5.2
Bug fixes and minor improvements
* Weave Proxy did not flush the initial http header in the Docker event stream, which could cause Docker Swarm to show all nodes pending. #2306/#2311
* When using the CNI plugin, if a container was removed and quickly replaced by another using the same IP address, other containers might be unable to contact it. Send an address resolution protocol message to update them. #2313
* Avoid Docker hanging for 1 minute in `weave launch` if the plugin had not shut down cleanly #2286/#2292
* Print an error message when Weave bridge mode is changed without `weave reset`#2304
* Eliminate spurious warning message from IP allocator on plugin shutdown #2300/#2319
* Display error message when address requested in a subnet that is too small (/31 or /32) #2282/#2321
* Add short wait after `weave reset` to allow updates to reach peers #2280
* Weave was occasionally unable to claim existing IP address immediately after launch #2275/#2281
* Refactor some integration tests to run faster and more reliably #2291
## Release 1.5.1
Bug fixes and minor improvements
* Persisted data that was rendered invalid by changing peer name or
allocation range is detected and removed automatically, preventing
crashes and hangs #2246/#2209/#2249
*`weave rmpeer` persists the range takeover in case the peer on which
it was executed dies subsequently #2238
* Launching a container with an explicit `WEAVE_CIDR` in the
allocation range now waits instead of erroring if the allocator
hasn't finished initialising #2232/#2265
* Weave DNS now responds to AAAA queries with an empty answer section,
instead of NXDOMAIN which could be cached and block subsequent
resolution of A records #2244/#2252
* Many improvements to the documentation.
More details in the [change log](https://github.com/weaveworks/weave/issues?q=milestone%3A1.5.1).
Thanks for your interest in contributing to this project and for
taking the time to read this guide.
# Code of conduct
**Be respectful:** disagreements between people are to be expected and are usually the sign of healthy debate and engagement. Disagreements can lead to frustration and even anger for some members. Turning to personal insults, intimidation or threatening behaviour does not improve the situation. Participants should thus take care to ensure all communications / interactions stay professional at all times.
**Be considerate:** remember that the community has members with a diverse background, many of whom have English as a second language. What might appear impolite, may simply be a result of a lack of knowledge of the English language. Bear in mind that actions will have an impact on other community members and the project as a whole, so take potential consequences into account before pursuing a course of action.
**Be forgiving:** humans are fallible and as such prone to make mistakes and inexplicably change their positions at times. Don't assume that other members are acting with malicious intent. Be prepared to forgive people who make mistakes and assist each other in learning from them. Playing a blame game doesn't help anyone.
# Issues
* Before reporting an issue make sure you search first if anybody has already reported a similar issue and whether or not it has been fixed.
* Make sure your issue report sufficiently details the problem:
* If you set up weave in some way other than that described by our [main instructions](https://github.com/zettio/weave#installation), please mention that.
* Include step-by-step instructions to reproduce the issue.
* State the OS platform you are using, i.e. `uname -a`
*`iptables` rules and firewalls can have a great impact on any Linux network; please note whether you have set up any rules and/or are running a firewall on your machine(s).
* If you want to tackle any open issue, make sure you let people know you are working on it.
## Pull Requests
* Please be generous describing your changes.
* Although it is highly suggested to include tests, they are not a hard requirement in order to get your contributions accepted.
* Keep pull requests small so core developers can review them quickly.
* Keep each pull request focused on a specific topic. If you have two things to change, create two pull requests. This helps reviewers to understand the meat of your contribution.
## Workflow
See [WorkingOnWeave](https://github.com/weaveworks/weave/wiki/WorkingOnWeave)
# Acknowledgements
Much of this taken from https://github.com/cloudescape/gowsdl/blob/master/CONTRIBUTING.md
# If the architecture is amd64, add the -amd64 suffix.
$(SUDO)DOCKER_HOST=$(DOCKER_HOST) docker tag $(DOCKERHUB_USER)/$*:$(WEAVE_VERSION)$(DOCKERHUB_USER)/$*-amd64:$(WEAVE_VERSION)
# If the version is latest, tag the -amd64 with latest as well
ifneq($(UPDATE_LATEST),false)
$(SUDO) DOCKER_HOST=$(DOCKER_HOST) docker tag $(DOCKERHUB_USER)/$*-amd64:$(WEAVE_VERSION)$(DOCKERHUB_USER)/$*-amd64:latest
endif
# Push the image with the -amd64-suffix so BINARY-ARCH-named images exist for all arches, so manifest lists may be made and ARCH is replaceable in scripts
[Weaveworks](http://weave.works) is the company that delivers the most productive way for developers to connect, observe and control
Docker containers. The first product developed by Weaveworks, with nearly 5 million downloads to date, is Weave Net, enabling users to get started with Docker clusters and portable apps in a fraction of the time compared to other solutions. In addition, Weaveworks offers Weave Scope, a powerful container monitoring tool that automatically maps Docker containers and their interactions, as well as Weave Flux, a microservice router that automates the access of containers as services.
[Weaveworks](https://www.weave.works) is the company that delivers the most productive way for developers to connect, observe and control
Docker containers.
# Introduction
This document is intended to cover some of the more technical aspects of Weave Net. To learn about our products, including getting
started tutorials, visit our [website](http://weave.works) and
[documentation](http://docs.weave.works).
This repository contains [Weave Net](https://www.weave.works/products/weave-net/), the first product developed by Weaveworks, and with over 8 million downloads to date, enables you to get started with Docker clusters and portable apps in a fraction of the time compared with other solutions.
## Weave Cloud:
[Weave Cloud](https://www.weave.works/product/cloud/) is software-as-a-service that simplifies deployment, monitoring and management for containers and microservices. It extends and complements popular orchestrators, and enables developers and DevOps to realize faster deployments, insightful monitoring, visualization and networking.
Weave Cloud is built using these Open Source projects: [Weave Scope](https://www.weave.works/products/weave-scope/), a powerful container visualization tool that automatically maps Docker containers and their interactions, [Weave Cortex](https://github.com/weaveworks/cortex), a horizontally-scalable version of Prometheus, and [Weave Flux](https://www.weave.works/products/weave-flux/), a continuous deployment tool that works with Kubernetes.
# Weave Net
Weave Net creates a virtual network that connects Docker containers
deployed across multiple hosts and enables their automatic discovery.
Weave Net creates a virtual network that connects Docker containers across multiple hosts and enables their automatic discovery. With Weave Net, portable microservices-based applications consisting of multiple containers can run anywhere: on one host, multiple hosts or even across cloud providers and data centers. Applications use the network just as if the containers were all plugged into the same network switch, without having to configure port mappings, ambassadors or links.
Services provided by application containers on the Weave network can be exposed to the outside world, regardless of where they are running. Similarly, existing internal systems can be opened to accept connections from application containers irrespective of their location.
Applications use the network just as if the containers were all
plugged into the same network switch, with no need to configure port
mappings, links, etc. Services provided by application containers on
the weave network can be made accessible to the outside world,
regardless of where those containers are running. Similarly, existing
internal systems can be exposed to application containers irrespective
of their location.
## <a name="help"></a>Getting help

If you have any questions about, feedback for or a problem with Weave Net:
Weave Net can traverse firewalls and operate in partially connected
networks. Traffic can be encrypted, allowing hosts to be connected
across an untrusted network.
- Read [the Weave Net docs](https://www.weave.works/docs/net/latest/overview).
- Invite yourself to the <a href="https://weaveworks.github.io/community-slack/" target="_blank"> #weave-community </a> slack channel.
- Ask a question on the <a href="https://weave-community.slack.com/messages/general/"> #weave-community</a> slack channel.
- Join the <a href="https://www.meetup.com/pro/Weave/"> Weave User Group </a> and get invited to online talks, hands-on training and meetups in your area.
- Send an email to <a href="mailto:weave-users@weave.works">weave-users@weave.works</a>
- <a href="https://github.com/weaveworks/weave/issues/new">File an issue.</a>
With Weave Net you can easily construct applications consisting of
multiple containers, running anywhere.
Your feedback is always welcome!
Weave Net works alongside Docker's existing (single host) networking
capabilities, so these can continue to be used by containers.
## Further Information
## Installation
To get started, you should be running Linux (kernel 3.8 or later) and have Docker
(version 1.6.0 or later) installed. Then install Weave Net with
sudo curl -L git.io/weave -o /usr/local/bin/weave
sudo chmod a+x /usr/local/bin/weave
For usage on OSX (with Docker Machine) you first need to
[make sure that a VM is running and configured](https://docs.docker.com/installation/mac/#from-your-shell).
Then you can launch Weave Net directly from the OSX host.
For installing Weave Net on other platforms, follow the [integration guides](http://weave.works/product/integrations/).
Weave Net respects the environment variable `DOCKER_HOST`, so you can run
it locally to control a weave network on a remote host.
Weave Net
[periodically contacts Weaveworks servers for available versions](https://github.com/weaveworks/go-checkpoint).
New versions are announced in the log and in
[the status summary](http://docs.weave.works/weave/latest_release/troubleshooting.html#weave-status).
To disable this check, run:
```
export CHECKPOINT_DISABLE=1
```
before launching Weave Net.
## Quick Start Screencast
<a href="https://youtu.be/kihQCCT1ykE" alt="Click to watch the screencast" target="_blank">
<img src="/docs/hello-screencast.png" />
</a>
## Example
Say you have docker running on two hosts, accessible to each other as
`$HOST1` and `$HOST2`, and want to deploy an application consisting of
two containers, one on each host.
On $HOST1 you would run:
host1$ weave launch
host1$ eval $(weave env)
host1$ docker run --name a1 -ti ubuntu
> NB: If the first command results in an error like
host1# ip xfrm state add src ${IP1} dst ${IP2} proto esp spi 0x4c856ffc replay-window 256 flag esn reqid 0 mode transport aead 'rfc4106(gcm(aes))' ${KEY1} 128
host1# ip xfrm state add src ${IP2} dst ${IP1} proto esp spi 0x9b0830bc replay-window 256 flag esn reqid 0 mode transport aead 'rfc4106(gcm(aes))' ${KEY2} 128
host1# ip xfrm policy add src ${IP1}/32 dst ${IP2}/32 dir out tmpl src ${IP1} dst ${IP2} proto esp spi 0x4c856ffc reqid 0 mode transport
host2# ip xfrm state add src ${IP2} dst ${IP1} proto esp spi 0x9b0830bc reqid 0 replay-window 256 flag esn mode transport aead 'rfc4106(gcm(aes))' ${KEY2} 128
host2# ip xfrm state add src ${IP1} dst ${IP2} proto esp spi 0x4c856ffc reqid 0 replay-window 256 flag esn mode transport aead 'rfc4106(gcm(aes))' ${KEY1} 128
host2# ip xfrm policy add src ${IP2}/32 dst ${IP1}/32 dir out tmpl src ${IP1} dst ${IP2} proto esp spi 0x9b0830bc reqid 0 mode transport
This document describes the various ways that weave as a binary gets launched, and where and how it processes options.
The goal is to enable maintainers to modify functionality without having to reverse engineer the code to find all of the places you can start a weave binary and what it depends upon.
## Components
### weaver
`weaver` is the primary binary: it sets up the weave bridge to which containers are attached, manages IP address allocation, serves DNS requests and does many more things.
Since version 2.0, `weaver` also bundles the Docker Plugin (legacy version) and Docker API Proxy which used to be shipped as separate containers.
### weaveutil
weaveutil is a binary which provides a number of functions for managing an existing weave network. It gets information about the network, attaches and detaches containers, etc.
For the majority of interactions with an existing weave network, you will launch `weaveutil` in some manner or another.
Almost all options can be passed as `--option` to `weaveutil`. These options are created in `prog/weaveutil/main.go` with a table mapping each command to a dedicated golang function.
In addition to operating in normal mode, `weaveutil` has several additional operating modes. Before processing any commands, `weaveutil` checks the filename with which it was called.
* If it was `weave-ipam` it delegates responsibility to the `cniIPAM()` function in `prog/weaveutil/cni.go`, which, in turn, calls the standard CNI plugin function `cni.PluginMain()`, passing it weave's IPAM implementation from `plugin/ipam`.
* If it was `weave-net` it delegates responsibility to the `cniNet()` function in `prog/weaveutil/cni.go`, which, in turn, calls the standard CNI plugin function `cni.PluginMain()`, passing it weave's net plugin implementation from `plugin/net`.
Finally, `weaveutil` is called by `weaver` when it needs to operate in a different network namespace.
Go programs cannot safely switch namespaces; see this [issue](http://github.com/vishvananda/netns/issues/17).
The call chain is `weaver`->`nsenter`->`weaveutil`.
### weave
Wrapping `weaver` and `weaveutil` is `weave`, a `sh` script that provides help information and calls `weaveutil` as relevant.
### weave-kube
weave-kube is an image with the weave binaries and a wrapper script installed. It is responsible for:
1. Setting up the weave network
2. Connecting to peers
3. Copy the weave CNI-compatible binary plugin `weaveutil` to `/opt/cni/bin/weave-net` and weave config in `/etc/cni/net.d/10-weave.conf`
4. Running the weave network policy controller (weave-npc) to implement kubernetes' `NetworkPolicy`
Once installation is complete, each network-relevant change in a container leads `kubelet` to:
1. Set certain environment variables to configure the CNI plugin, mostly related to the container ID
2. Launch `/opt/cni/bin/weave-net`
3. Pass the CNI config - the contents of `/etc/cni/net.d/10-weave.conf` to `weave-net`
Thus, when each container is changed, and `kubelet` calls weave as a CNI plugin, it really just is launching `weaveutil` as `weave-net`.
The installation and setup of all of the above - and therefore the entrypoint to the weave-kube image - is the script `prog/weave-kube/launch.sh`. `launch.sh` does the following:
1. Read configuration variables from the environment. When the documentation for `weave-kube` describes configuring the weave network by changing the environment variables in the daemonset in the `.yml` file, `launch.sh` reads these environment variables.
2. Set up the config file at `/etc/cni/net.d/10-weave.conf`
3. Run the `weave` initialization script
4. Run `weaver` with the correct configuration passed as command-line options
## Adding Options
To add new options to how weave should run with each invocation, you would do the following:
1. determine to which `weave` command you want to add the option(s). `weave` normally is launched as `weave <command> <options> ...`.
2. Add the option to `weave` script help for each `weave` command you wish to make it available. As of this writing, all of the commands and their options are listed in the function `usage_no_exist()`.
3. Add the option to `weave` script option processing for the `weave` command, under the `case $COMMAND in` in the main `weave` script.
4. In the function for the `weave` command, determine if the command should be passed on to `weaveutil` or `weaver`. Pass the option on to `weaveutil` or `weaver`, as appropriate, in the format `--option`, in the function for the `weave` command.
5. Add a command-line option `--option` to `weaveutil` or `weaver` as appropriate.
6. If the option can be configured for CNI:
* have `prog/weave-kube/launch.sh` read it as an environment variable and set inside
* set a default for the environment variable in `prog/weave-kube/weave-daemonset-k8s-1.6.yaml` and `weave-daemonset.yaml`
* if it should be set via `weaver` globally on its one-time initialization invocation, pass it on in `launch.sh`
* if it needs to be set via `weaveutil` on each invocation of `weave-net`, have `launch.sh` save it as an option in the CNI config file `/etc/cni/net.d/10-weave.conf` and then have the CNI code in `plugin/net/cni.go` in `weaveutil` read it and use where appropriate
- it will continue to ask for space until it receives some, or its
copy of the ring tells it all peers are full in that subnet.
### Data persistence
Key IPAM data is saved to disk, in a [BoltDB](https://github.com/boltdb/bolt)
file, stored within a [data volume container](https://docs.docker.com/engine/userguide/containers/dockervolumes/#creating-and-mounting-a-data-volume-container)
named `weavedb`.
This file is used to persist data for various Weave Net components; for IPAM it contains:
* the division of the IP allocation range amongst peers, and
* allocation of addresses to containers on the local peer,
so that it is immediately available when the peer restarts.
### Claiming an address
If a Weave process is restarted, in most cases it will hear from
another peer which ranges it used to own, but it needs to know which
individual IP addresses are assigned to containers in order to avoid
giving the same address out in subsequent allocation requests. The
weave script invokes the `claim` command in `populate_ipam` to do
this.
If a Weave process is restarted,
- if `weavedb` is present, then it loads persisted IPAM data from there, as
described, in the previous section;
- else, it learns from other peers which ranges it used to own.
Weave Net then consults the allocator to know which individual IP addresses
are assigned to containers, and therefore avoid giving the same address out in
subsequent allocation requests.
When the Allocator is told to claim an address, there are four
* Ensure you are still on the right branch, since Go may switch to `master` as part of `make update`
github-release](https://help.github.com/articles/creating-an-access-token-for-command-line-use/); select the `repo` OAuth scope; set and export `$GITHUB_TOKEN` with this value
## Release Types
@@ -133,9 +130,15 @@ Finally, for **Mainline** releases only:
### Finish up
* If not on master, merge branch into master and push to GitHub.
* Merge the branch you are on into `latest_release_doc_updates` and push to GitHub.
* Close the [milestone](https://github.com/weaveworks/weave/milestones) in GitHub and create the next milestone
* Update the `#weavenetwork` topic heading on freenode (requires 'chanops' permission)
* For a mainline release vX.Y.0, create a release branch X.Y from the
tag and push to GitHub - this will result in X.Y.0 site docs being
published to https://www.weave.works
* Add the new version of `weave-net` to the checkpoint system at
https://checkpoint-api.weave.works/admin
* File a PR to update the version of the daemonset at
return[]string{"-m","set","--match-set",string(nsIpsetName),"dst","-j","ACCEPT","-m","comment","--comment","DefaultAllow isolation for namespace: "+namespace}
}
func(ns*ns)ensureBypassRule()error{
varipsetipset.Name
ifns.legacy{
ipset=ns.allPods.ipsetName
}else{
ipset=ns.defaultAllowIPSet
}
common.Log.Debugf("ensuring rule for DefaultAllow in namespace: %s, set %s",ns.name,ipset)
Loaded 100 of 415 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.