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.
`GossipBroadcast` in the `TestRouter` only goes one hop. In
`TestTransfer` the three peers are connected in a chain, and hence we
need to take extra care to ensure propagation to all peers.
Fixes#2180.
...so that we can start multiple weaves on a machine w/o them sharing
a single db container and tripping over each other as a result.
Unbreaks multiweave.
Fixes#2177
We provide a very small image to use for this container.
Also we add an empty weavedata.db file to weave image so it doesn't crash when run without volume override
now you can
- run `vagrant provision` any time
- upgrade the base image with `vagrant box update`
- upgrade docker inside the VM w/o
...etc...
...without breaking things!
So that tests don't have to be careful about ensuring that allocators
are stopped exactly once, or rely on the magic mesh.ChannelSize for
non-blocking behaviour.
Closing a subscription can cause the associated fd to be re-used while
the subscription goroutine is also still trying to use it. Which can
have disastrous consequences.
So as a work around we don't close subscriptions. This means we leak
an fd, some buffer space, and goroutine. The latter will eventually
block in a channel send of a subscription event, since nothing is left
reading ont the other end. So at least it won't be consuming cycles.
...rather than exploding
i.e. the former returns nothing and the latter leaves naming related
container settings untouched, just like happens in the proxy and
plugin.
Fixes#2099.
Updated the "About Weaveworks" section to differentiate between our overall mission and a Weave Net-specific overview; also included brief descriptions of Weave Scope and Weave Flux. Corrected product names missed in last update.
Updated for consistent pronoun usage; corrected product and company references, following our standardized naming conventions; fixed other minor grammatical errors.
Consistency, consistency, consistency:
- prefix all log messages with "[net]" - important since the same
process acts as both a network and ipam driver
- include the API function name in all log messages
- log request and response details at debug level
- log request summary at info level
- log ContainerStarted as a pseudo API function, but only at debug
level (since it can be quite high volume)
And eliminate some dot imports.
It is a library function, so logging of any errors should be left to
the caller.
We also get rid of a logged warning which contained the complete data
structure returned by netlink.LinkByName.
So this function now does no logging at all. Which is how it should be.
This isn't as efficient as it could be. In particular we end up
broadcasting the ipam state for every peer listed. To avoid that we'd
have to change the HTTP API, and would no longer be able to use
'DELETE'. That is just not worth it.
Closes#2044.
...rather than Space.NumFreeAddressesInRange; we don't care about the
universe.
Alternatively we could make Space.AddRanges return the count. But
AddRanges doesn't know whether the ranges overlap with existing free
space - that is only guaranteed by the context - so would have to do
much the same before/after calculation.
Another alternative would be to add the range sizes in
AdminTakeoverRanges. But that is more code and less clear.
The nil FlowOp check in collectFlowOps was not addressed with the
introduction of DiscardingFlowOp. This meant that DiscardingFlowOps
produced in the router core would get handled by fastdp as if they were
foreign FlowOps, preventing flow creation and so leading to unwarranted
ODP misses.
To fix this, collectFlowOps cannot simply eliminate FlowOps for which
Discards() is true, because it's true for odpFlowKeyFlowOp. So the
Discards() case has to be handled in FastDatapath send().
Otherwise it will always install the latest docker version, which will be
undesirable when new major releases are done, until they are well tested.
For instance, docker after automatically updating to 1.9, it was killing my VM
when spawning a kubernetes cluster, due to a high CPU consumption, probably due
to https://github.com/docker/docker/issues/17720
Travis insists that one picks a project language. There is no go left
in the steps executed by travis. Instead we have Python, Ruby and
shell. Let's pick the first...
Picking Python makes travis unhappy with "Can not perform a '--user'
install. User site-packages are not visible in this
virtualenv". Dropping the '--user' flag fixes that.
(cherry picked from commit 1d8d098450)
There is no point running builds, tests, lints on Travis, since we
already do that on Circle.
The only thing we aren't doing (and can't do) on Circle is doc
publishing, so now Travis does just that.
(cherry picked from commit 1038cbd1a3)
this is an optimisation... there is no point attempting to attach a
'restarting' container - it will fail.
When the container *actually* restarts we'll get a 'Start' event, and
attach at that point.
Also, there is no point checking for 'Paused' since 'Paused' ->
'Running'.
Reworked interface to router so we split setting up the initial list
from beginning to make connections - we shouldn't do that until
after router.Start().
Invoke the new create_veth from a few places, eliminating code
duplication and inconsistencies.
Semantic differences:
- init_bridged_fastdp now skips the veth creation/config if the veth
already exists. This eliminates routing blips. Though in reality
something very strange must have happened to end up in this code
with an existing veth.
- init_bridged_fastdp no longer deletes the $BRIDGE and $DATAPATH when
veth creation/configuration fails. This is consistent with
init_bridge, which does not delete $BRIDGE when something goes
wrong. And it is generally desirable since the init_* functions are
invoked on potentially existing bridges - e.g. following 'weave
stop'.
- attach_bridge and setup_router_iface_bridge used to mark one veth
end 'up', then invoke add_iface_* for it, and then mark the other
end 'up'. create_veth marks both ends 'up' first. This makes no
practical difference in these cases.
notable other differences:
- we detect veth presence by checking whether *both* ends are present,
rather than just one. We deliberately continue to (and fail in) the
veth creation if one end already exists. This can only happen when
we've stumbled across a different interface, since a veth end cannot
exist independently. So it is right to treat this as an error.
- init_bridged_fastdp invokes add_iface_bridge instead of duplicating
what that does. Also makes for nice coherence with the
add_iface_fastdp it is invoking too.
Multiweave now creates a temporary bridge with an IP alias per router
in the host netns, and overrides the router to bind to that specific
IP for weave protocol and data traffic and http control.
This was causing container entrypoints to execute too early,
e.g. before the interface had been given an IP address. But only when
running with --no-multicast-route, since otherwise weavewait is
waiting for the multicast route to appear.
Fixes#1942.
This avoids trying to decide if "restarting" is as good as "running".
In wait_for_status we now explitly check_running, and
in dns_add/remove we add an extra check_running test.
They will be named 'weavevolumes-v1.4.3', 'weavevolumes-latest', etc.
Use a label to identify these containers so they can all be removed on `weave reset`.
This is to address the plugin case, where the veth will have a name like 'ethwe0'.
Previously we only looked at the device named exactly 'ethwe'.
Covers `weave ps` and reclaim of addresses for IPAM and WeaveDNS.
- Create an auxilliary container 'weavevolumes' to hold the '/w/w'
files, and map into that instead of creating new volumes every time.
- Show "/bin/false" as its command in `docker ps` instead of
"/home/weave/sigproxy".
- Remove volumes when cleaning up smoketest containers.
The assumptions on which this test was based were violated by the
introduction of fast datapath. A new rule is required to block fast
datapath traffic, to ensure that sleeve is selected for forwarding; the
rules must also be moved from the FORWARD chain to INPUT as the router
now runs in the host netns (NB we use INPUT instead of OUTPUT as the
latter results in sleeve receiving an 'operation not permitted' udpv4
write error when it tries to send a packet that is too big, rather than
the packet just being silently dropped as required)
The current minimum PMTU we can detect is eight bytes, which, being
lower than the minimum IPv4 MTU of 68 bytes, can cause an exception in
the sleeve packet fragmentation implementation. We increase that minimum
to 552, the lowest PMTU value that Linux will cache.
...if possible. This provides a stable peer identity across
reboots. If we cannot determinbe the system UUID then we revert to a
random MAC, as before.
Fixes#901.
Note that we remove the ability to set the weavemesh network name, or
disabling it altogether. This was always poorly support, since the
removal operation only ever operated on the default name. The option
was also not listed in the usage, though it was in the docs.
It's pointless and inconsistent. Firstly, deletion will fail if there
are any attached containers. Secondly, we run the plugin with
restart=always, so it will get restarted and the network re-created.
Removal of the network does still happen on `weave stop|reset`, if
possible.
- Use submodules for vendoring.
- Don't go clean, now that everything is in .pkg.
- sudo -E as we need the environment variables.
- Install -race version of std so the tests can run without sudo.
- Cache the build image on circle, use the rebuild-image script from tools.
As of e12dbb460 (#1758) we no longer force the usage of pcap when
encryption is enabled. Hence...
- we no longer need to figure out whether the router was started with
a password when re-attaching it from the proxy. We therefore remove
the code for that.
- there is no longer any mode in which we pass both `--datapath` and
`--iface` options to the router. Previously this would only happen
when encryption was enabled and the only overlay used for
connections was sleeve. It is not clear what the behaviour is when
these conditions do not hold, so, to be safe, we prevent the
specification of both flags.
Travis insists that one picks a project language. There is no go left
in the steps executed by travis. Instead we have Python, Ruby and
shell. Let's pick the first...
Picking Python makes travis unhappy with "Can not perform a '--user'
install. User site-packages are not visible in this
virtualenv". Dropping the '--user' flag fixes that.
There is no point running builds, tests, lints on Travis, since we
already do that on Circle.
The only thing we aren't doing (and can't do) on Circle is doc
publishing, so now Travis does just that.
...since that is a) inefficent and b) can block when IPAM hasn't had
consensus.
We can only end up in this situation when DOCKER_HOST is pointing at
the weave proxy and we are running `weave run|attach` with
`--local`. So it's very much an edge case.
Fixes#1858.
With the per-broadcast-source GossipSenders gone, we can get rid of
GossipSender gc...
Instead of maintaining a Connection->GossipSender map in the
GossipChannels - which we then need to gc when connections get closed
- we keep gossip_channel_name->GossipSender maps in LocalConnections.
Access to the map is guarded by a separate lock, rather than re-using
the LocalConnection lock. This reduces lock contention and risk of
deadlock.
In the GossipSenders, we replace the Stop() method with a signalling
channel, i.e. senders stop when that channel gets closed. Handily, the
LocalConnection.finished channel fits that description. So when a
LocalConnection's run loop terminates, any existing and future
associated GossipSenders will end up terminating too.
Previously broadcasts were being handled by one GossipSender per
broadcast source (and channel), which sends the broadcast to all next
hops, and hence can stall when a single destination is stalled.
Here we get rid of these per broadcast source GossipSenders. Instead
broadcasts are sent to per-connection GossipSenders for all next hops.
For this we use the existing GossipSenders we have set up for ordinary
gossip. In order to deal with broadcasts they need one GossipData cell
per broadcast source, since only broadcasts from the same source can
be Merge()ed. So we add a PeerName->GossipData map of cells, in
addition to the existing cell for ordinary gossip.
The GossipSender goroutine picks one of the cells at a time, Encode()s
the contents and sends it. It prefers the ordinary gossip cell over
the broadcast cells since typically ordinary gossip is more important.
To reduce coupling, the GossipSenders don't actually know how to
construct protocol messages. They just invoke a couple of functions
for that - one for ordinary gossip and one for broadcast - which are
supplied by the GossipChannel.
There are two downsides to this change:
1. broadcasts get encoded per connection, rather than just once
2. we can potentially end up with O(n_peers^2) cells, each containing
accumulated (via GossipData.Merge()) broadcasts. For this to happen,
the peer must
- deal with gossip from most nodes. This doesn't happen in
(near)complete connection topologies. Hypercube topologies are
probably the worst case uniform topology. And a star topology is the
worst case for a single (the centre) peer.
- have backlogged connections to most of its neighbours, without
those connections being completely stalled (since that would cause
heartbeat timeouts to terminate them).
Furthermore, for this to matter in practise, the accumulated broadcast
GossipData must be sizeable:
- For topology gossip, GossipData is just a set of PeerNames. Which
takes very little space and is bounded, since there is a finite
number of peers. And, if we could get rid of workaround for #1793
(cbaa92dcb), then topology broadcasts would only ever contain
information about the source peer, so the GossipData would contain
just one PeerName.
- IPAM only employs broadcast during initialisation and shutdown.
- DNS broadcasts contain DNS entries for containers on the source
peer. Each entry will typically be 100-200 bytes. The accumulated
broadcast GossipData from a peer will contain entries for all the
peer's DNS entries, worst case. This includes tombstones,
i.e. entries for containers that have died. If there is churn,
i.e. DNS entries being added and removed continuously, and the churn
rate exceeds the rate at which we can forward those entries, then
the accumulated broadcast GossipData can grow unbounded. Note that
this is the case on master too; the difference here is that we can
have up to n_peers copies of that GossipData.
- level 2 headings for top-level instead of level 3
- put all status reporting as L3s under one L2 heading
- add 'Reboots' to ToC
- move 'Stopping weave' into its own section and and move that
In particular don't require Send() to be serialised by the caller.
We split up the triple(!) purpose 'cell' channel into:
1) a 'cell' member, holding pending GossipData or nil
2) a 'more' channel, for signalling that 'cell' has been filled
3) a 'stop' channel, for requesting termination
An error in SendProtocolMsg indicates that the connection is
permanently broken. So there is no point continuing to attempt to send
gossip on it.
The connection will eventually be removed from LocalPeer, and any
associated GossipSenders will be gc'ed, but that doesn't happen
straight away, so this change is about not doing unnecessary work in
the meantime.
This is a one-sided operation, so we shouldn't be touching the
remote's Peers.
Also fix the associated test... When both 1 and 2 have lost their
connection to 3, they no longer have a route to 3 and hence gc it.
And because they no longer have a route, gossip from them won't get
through to 3.
We were creating peers with NewPeerFrom, which copies the Version (but
not connections). That's not what happens for a real connection, where
remote peers are always created with an initial version of 0.
The mistake results in brokenness: when we subsequently receive a
topology update for that peer with the same version then we ignore it,
even though the update contains connection information which is new to
us.
Related, it is conceptually wrong to call FetchWithDefault on the
remote router. That is not what happens for a real connection - the
FetchWithDefault occurs in the symmetric counterpart.
The kernel processes vport deletion asynchronously, meaning that we can
sometimes fail to recreate vxlan vports on startup with an EADDRINUSE
error. We compensate by retrying a small number of times with a short
sleep on encountering this error, failing as before on a different error
or exhaustion of retries.
Prior to optional encryption support, enabling encryption disabled the
fast datapath overlay (because it doesn't support encryption) but left
the OVS datapath netdev in place for bridging (so that users could
switch encryption on and off without resetting the bridge). In this
situation the ODP miss handler is guaranteed to be invoked for every
packet, so as an optimisation the weave script configured the router to
use pcap to capture packets from the bridge as that is slightly more
efficient. The introduction of optional encryption means the guarantee
no longer holds, and so the optimisation must be removed.
If overlay encryption is required between peers, the fast datapath
forwarder returns an error rather than aborting the process, allowing
the overlay switch to fall back gracefully to an encrypted sleeve
overlay connection.
Add a 'Trusted' feature to the protocol exchange which indicates whether
the remote considers us to be reachable via a secure network; overlay
encryption will be disabled in the event that both peers agree. For
backwards compatibility purposes a default value of untrusted is assumed
if the feature is missing.
Instead of calculating all routes in one go, we calculate them when
needed.
Except for unicast routes, and broadcast routes from ourself. We still
calculate those eagerly because they are needed to route locally
captured/fdp-missed packets, and performing route calculcations in
that critical path increases the chances of dropping packets due to
not keeping up.
Well, technically only the established & symmetric routes are needed
for the data plane, but we might as well calculate the equivalent
routes for the control plane - it keeps the code simple and uniform.
Calculating all routes is O(n_peers^2), so this change represents a
huge saving in situations where not all of them are needed, which is
quite common, especially when the topology is evolving rapidly.
One downside of this new approach is that we can no longer suppress
OnChange callbacks when the data plane routes remain unchanged. This
means we will be purging the FDP flows more frequently than before,
e.g. when only the control plane topology changed, e.g. new
connections appeared that haven't been marked as 'established'
yet. It's a small price to pay, fixable if we really care, and in any
case making FDP flow invalidation more fine-grained would be a better
approach.
Fixes#1761.
real Connections do not process gossip until after AddConnection.
mockChannelConnection wasn't behaving in that way, which resulted in
some sporadic test failures since it would cause some gossip to get
processed too early, which in turn would trigger gc of some of the
just-received peers, which we would then find missing in the test
assertions.
To fix this we introduce a latch on mockChannelConnection which closes
when the remote end is ready to receive gossip. Effectively this
emulates the entering of LocalConnection.receiveTCP after the call to
AddConnection completes.
Unfortunately an open latch will cause sendPendingGossip to block. We
get around that by abandoning checks in "half-connected" connection
states.
Fixes#1765.
This is more efficient since broadcasting about other peers is
strictly redundant. Any change to the peers will be broadcast by
those peers anyway. And SendAllGossipDown takes care of informing new
peers about others on first connect, and periodic gossip take care of
missed broadcasts.
The only reason we did broadcast about the remote peer is to reduce
the liklihood of UnknownPeerError and the associated throwing away of
gossip. This was always a bit of kludge, and is no longer necessary
since UnknownPeerError is gone.
Now peers only ever broadcast information about themselves. Which,
unlike information about other peers, is always authorative and most
up-to-date. Which is nice.
when encountering an unknown peer in received gossip, rather than
ignoring the entire gossip we create a placeholder Peer. This has
version 0 and uid 0, which means it will be replaced by any complete
peer information subsequently received via gossip.
We copy docker.sock owner to symlinks. Permissions are not copied,
because the permissions will inherit from the target.
use versioned exec image to create symlinks
This was missing.
There are two parts to this change:
1. updating the Peers.byName mapping when HasShortID changed (in
addition to the existing update on ShortID change). We need to be
careful about the sequencing here - both ShortID and HasShortID must
be set between the calls to deleteByShortID and addByShortID, since
the former is meant to delete the existing entry (hence use the old
values) and the latter add the new entry (hence use the new values).
2. update a peer when the received info has the same version and UID
but the current record has HasShortID=false, and the received info has
HasShortID=true. This caters for the case where we receive an update
about a weave 1.2+ peer first via a pre-1.2 peer (which does not
transmit ShortIDs, and always sets HasShortID=false) and subsequently
via a 1.2+ peer. The former update will force us to communicate with
that peer over the 'sleeve' overlay. We want to accept the latter
update, even though the version is the same, in order to update the
ShortID and HasShortID, so we can switch to fastdp.
Fixes#1731.
Previously the count of tokens was claimed to be a count of addresses in use,
which is incorrect.
Also rename `appendAddresses` to `appendOwned` since it doesn't involve addresses.
Don't use the word "universe" in user-visible output; it is an internal term.
Removed everything but owned ranges from 'weave status ipam' results, for consistency with similar functions
We need Connection.Shutdown to be non-blocked, and the way we achieved
this is by spawning a goroutine. However, there can be a potentially
unbounded number of Connection.Shutdown invocations. For example, if
the TCP connection has gone bad then any Connection.SendProtocolMsg
invocation will end up invoking Connection.Shutdown. There can be many
such invocations until the Connection has been removed from the
various data structures (e.g. LocalPeer.connections and
GossipSender.senders). Hence we can end up with with an unbounded
number of spawned goroutines.
To fix this, we introduce a one-element error channel on the
connection. Connection.Shutdown does a non-blocking send on that, and
the Connection.actorLoop reads from it and terminates.
This will throw away all but the first error encountered, but that is
fine and not much different from what was happening before (where we'd
throw away all but one of the errors encountered).
The same piece of GossipData can be shared and subject to different
Merge operations. We either need to copy the data when we share it, or
create copies on modification, i.e. copy-on-write.
We choose the latter, since it is more efficient and there is just one
mutating operation.
Fixes#1697.
This reverts commit 262352f8bb, reversing
changes made to 312691376a due to a bug
whereby `weave env` returns a unix domain socket with an incorrect path.
This change will be superceeded by #1694.
This lets you use -H unix://*.sock outside /var/run/weave. Using a
socket directly in /var/run (i.e. /var/run/foo.sock), will reintroduce
the bug with namespaces not being GCed, so that is a warning.
The deadlock described for SendProtocolMsg (if it was going via the
actor) cannot occur since all sending of broadcasts and gossip by
LocalPeer is mediated by GossipSenders, the interaction with which is
non-blocking.
Docker attempts to recreate networks on startup which means the plugin
container has to be started. If it isn't started automatically by Docker
with a restart policy, it's not possible to start it manually because
Docker is blocked.
Forward can return nil if the remote peer has HasShortID false. That
can happen if we learn about a 1.2 peer from a 1.1 peer and attempt to
connect to it.
This change just fixes the panic. HasShortID will never be set, so we'll
fall back to sleeve. But if that occurs, if can be fixed by a restart of
the affected routers.
This is mostly a matter of moving some files, changing package names,
changing some imports, and changing some type references.
We duplicate the odd constant & global var, and the intmac/macint
functions, since neither 'router' or 'mesh' nor, really,' common' are
a natural home for them.
...since the main connections only need to know about the former.
We make LocalConnection.Overlay (formerly '.forwarder') public since
the router needs access to it, and it shouldn't be doing that via a
private field.
Previously when a peer restarted, information about the new
incarnation (i.e. with a different UID) was not accepted by other
peers (and connections would be dropped) unless all knowledge of the
previous incarnation had been purged. This could result in a lot of
connection churn and hence connectivity disruption, and, in some
pathological cases, very slow convergence and hence acceptance of the
new incarnation into the network.
We now no longer drop connections when encountering different
incarnations of a peer. There are two situations when that can happen:
1) on connection establishment
we simply proceed
2) on receipt of gossip
to ensure convergence we
a) treat the UID as an additional discriminator when deciding whether
we should update our information about a peer with that which was
gossiped. Specifically, we update the information we hold when a) the
gossiped version is greater, or b) is the same and the UID is
greater.
b) include the UID in the information we update
c) move our own version number beyond any we receive for ourselves, if
the received UID differs from ours.
With (a) we establishes a total order of peer information across
several incarnations of the same peer. i.e. we consider information to
be fresher if it has a higher version, or the same version and higher
UID. This may seem somewhat counter intutive, since it will generally
treat information about new incarnations as older than old
incarnations, since incarnations always start life with version 1. But
to do better we'd need to establish a total order of incarnations that
matches their temporal occurrence. Which requires some sort of durable
state.
So instead we have (c). Through that we learn the highest version
number of any old incarnation of ourselves that other peers still
hold, and then make sure that our version is greater than
that. Essentially we continue where the old incarnations left
off. It's as if instead of restarting we had simply changed UIDs. And
due to (a) and (b) the information about the new incarnation of
ourselves, now with a higher version, will supersede that of the old
incarnations.
Fixes#1554.
Previously it was set by the script only in fastdp mode; and in the
router's main.go otherwise. Yet every interaction of the script with
weave assumes the port is the script's HTTP_PORT=6784. By always
starting the router with options to listen on that port we ensure that
the router is in fact listening where the script expects it to.
In doing this get rid of router.HTTPPort. We do need to hard-code the
port in the proxy instead, but relying on router.HTTPPort was flawed
anyway, for the above reasons.
The test script runs commands inside containers via docker exec to
ensure the ethwe carrier is up. We must not run these commands via the
proxy because it will interpose weavewait, which will block forever if
attachment has failed (e.g. due to #1556).
It's possible to build that kernel with openvswitch, and vxlan, but
without the vport_vxlan module that glues them together. And at
least one distro has actually done this.
If the local peer's short ID was updated, we broadcastPeerUpdate at
the end (in unlockAndNotify), so there is no need to include the local
peer in the current update.
Also, reading peers.ourself.Version is bad here - we don't take a lock
and it's written by other goroutines. Doesn't actually break anything
though since it's a uint64 and hence atomic.
* User makes /start request, and blocks on the waiter
* ContainerStarted fires with ID
* Container goes away
* We try to inspect the container to get the entrypoint, which fails
* Previously, this wouldn't call notifyWaiters and the /start would hang (I expect)
When we get a forwarded packet, we put its source MAC into the MAC cache,
overriding any existing entry. But we could have a flow which says
to forward packets destined to that MAC based on the old entry. Such
a flow could be prolonged indefinitely by attempts to send to the MAC.
This is obviously bad, so do InvalidateRoutes in such cases.
Previously, the proxy would run the weave script in ways that did
not run the weaver executable. Now they can. This is a problem because
of the contortions involved in using golang's code coverage support
in the integration tests, which require the weaver command line args to
be slightly mangled.
This means:
* The 'weave' netdev is an OVS datapath
* The weave router container runs with --net=host in order to access
the datapath.
* The MTU is set to a smaller value, to allow vxlan encapsulation.
Setting the WEAVE_NO_FASTDP environment variable disables these
things, effectively running the router without fast datapath. It is
an environment variable rather than an option to 'weave launch'
because it takes effect in create_bridge, which is called from many
subcommands, and it doesn't seem practical to add option processing to
all of them.
These are needed to support vxlan encapsulation. In a vxlan packet,
the only place we can straightforwardly hold the source and
destination peer identifiers used by the weave router is in the
24-bit VNI (vxlan network identifier) field. This gives us 12 bits to
indicate a peer. The resulting limit of 4096 peers on a weave network
does not seem like a problem in the near future. But it does mean
that decentralized allocation makes collisions fairly likely even in
weave networks of sizes that are common today. Fortunately, the
problem is much more tractable than IPAM because we can detect when
collisions occur and take action to resolve them.
...instead of the weave container. This is cleaner.
'weave:extern' because typically these entries will refer to external
(non-weave) IP addresses. And because it's the same length as
'weave:expose', which is desirable for 'weave status dns' output.
When a container died before we got into the allocation code (inside
the allocator run loop) we would not cancel the allocation since the
container death event will have been processed by the allocator before
it had any knowledge of the container.
The fix is to move the container-aliveness check inside the allocation
code. That way we still detect the death even if the event has already
flown past.
We only need to perform the check once, since any subsequent death
will result in an event that is processed by the allocator when it has
recorded the container in its state.
Fixes#1459.
There are three significant changes here:
- rewrite ring.ErrDifferentSeeds errors
- remove the pre-checking of ranges and instead rewrite
ring.ErrDifferentRange errors
- don't pruneNicknames() and signal ringUpdated() when there was an
error
We don't rewrite other errors since our current belief is that only
ErrDifferentSeeds and ErrDifferentRange can arise from user error.
This is an early detector for a multitude of other symptoms, some of
which cause panics.
When creating the ring we record the paxos-supplied normalised list of
peers used for seeding. This subsequently gets gossipped around as
part of the Ring data structure, and checked in ring.Merge that it is
the same for the recipient.
There are some subtleties due to the desire to maintain backward
compatibility and deal with empty rings
- The gossip gob decoder will ignore the Ring.Seeds field when an old
weave receives a Ring from a new weave. So everything on the old
weave will just continue to work as before.
- The gossip gob decoder will set the Ring.Seeds field to nil when a
new weave receives a Ring from an old weave. We therefore omit the
seed equivalence check when the received Seeds slice is empty.
- Our ring may not have any seeds - either because it is empty or was
created from a ring received from an old weave. We therefore a) omit
the seed equivalence check in that situation, and b) set our seeds
to those received. Note that this allows us to learn about the seeds
well after ring creation - a situation which may arise when
receiving gossip from a mixture of old and new weaves.
Fixes#1463.
If a connection gets through all the handshake and subsequent checks -
i.e. it ends up getting added to the LocalPeer's connection list - but
gets terminated within one minute (of the start of the successful
connection attempt), then we apply the existing backoff logic to
schedule a retry, instead of retrying immediately.
In order to do this we retain the 'Target' data structure for such
connections, marking it as 'connected' instead of deleting it (as we
did previously).
Fixes#953.
- On-the-wire gossip messages are sorted case sensitive, but in memory they are sorted case-insensitive.
- Add test for case insensitive match on multiple names.
- Use git submodule for tools.
- Update Makefile to use submodules.
- Put submodule at tools/
- Tidy up some obsolete references to tools in .gitignore.
- inline http_call into call_weave
- rename http_call_ip to http_call
- make http_call take the IP & port as one single "address" argument
instead of separate args
Without this, building with go-1.5 fails with
go get ./prog/weavewait
go install net: open /usr/local/go/pkg/linux_amd64/net.a: permission denied
This makes the options passed too "go get"/"go build" consistent for
all executables. So it should be safe with go-1.4.
That way we no longer rely on the weavexec image version tag, which
may not always be present. Since the proxy is embedded in the
weaveexec image, this effectively versions the image.
Also report the *local* script version instead of the embedded script
version. There is no point in reporting the latter since it will
always match the weaveexec version.
Closes#1341.
For fast datapath, the router core will only be invoked upon datapath
misses. And it needs to yield routing decisions in a form that can be
used to configure the in-kernel datapath. So here we make the router
core yield FlowOps, which represent operations which actually do
something with a packet. The router core obtains these in turn from
the Bridge or the Overlay, depending on what it wants to do with
a packet.
For fast datapath, it's critical that the router makes decisions based
only on the required packet header information (as the same header
information will be used when configuring the ODP flow rules). So we
pass only that information into the router core, in the form of
PacketKeys.
The overall effect is to curry the router core: Rather than taking a
packet and doing something with it, it takes packet header information
and returns a function that does something with a packet.
This introduces interfaces to represent the packet forwarding
mechanism, and brings all the scattered UDP-related code together into
a single implementation.
This is not a pure refactoring, although much of the code in sleeve.go
has been copied from pre-existing code, and the UDP protocol remains
the same in spirit. The biggest change is the organization of the
forwarder goroutines (there is now one instead of two, and that
goroutine does a lot of auxiliary work as well as forwarding).
Performance testing between VMs on my laptop suggests that packet
throughput has not gone down, and may even have improved slightly.
* 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).
## Release 1.5.0
## Highlights
- A new [Container Network Interface](https://github.com/appc/cni#cni---the-container-network-interface) plugin.
- This release is much more robust against unscheduled restarts,
because it persists key data to disk.
- New configuration options that are useful when you create or
auto-scale larger networks.
- Weave now periodically checks for updates (can be disabled)
Plus many bug fixes and minor enhancements. More details below and in
the [change log](https://github.com/weaveworks/weave/issues?q=milestone%3A1.5.0).
## Release 1.4.6
Fixes some issues encountered by our users.
* Restarting a peer could leave stale entries in WeaveDNS
#1867/#2023/#2081
* Weave proxy occasionally failing to attach any new containers
#2016/#2049
Other fixes:
* Resolved a crash when a restarting peer re-connected to a peer that
had not received the latest IPAM data #2083/#2092
* Make IP address space available immediately after a dead peer is
removed #2068
## Release 1.4.5
Higher performance for multicast and broadcast traffic when using
Weave's Fast Datapath
* The flow rule to deliver broadcast and multicast packets in-kernel
was not created correctly, hence every such packet caused a
context-switch to the software router #2003/#2008
Other fixes:
* Remove DNS entries for containers that are being restarted by Docker
but are not live yet #1977/#1989
* Don't let one failing allocation attempt prevent others from
succeeding; they could be in different subnets which are more
available #1996/#2001
* Don't complain on second router launch on kernels that lack support
for Fast Datapath #1929/#1983
* Fix build broken by change in libnetwork IPAM API #1984/#1985
## Release 1.4.4
Fixing a rather serious issue that slipped through our preparations
for Docker 1.10:
* Restarting Docker or rebooting your machine while the Weave Net
plugin is running causes Docker 1.10.0 to fail to start #1959/#1963
Also one other small fix:
* Avoid a hang when trying to use plugin and proxy at the same time
#1956/#1961
## Release 1.4.3
Preparing for Docker 1.10, plus some bug-fixes.
* Avoid hang in Docker v1.10 on `docker volume ls` after `weave stop`,
`weave stop-plugin` or `weave reset`#1934/#1936
* Fix "unexpected EOF" from Docker 1.10 on `docker exec` with Weave
proxy `--rewrite-inspect` enabled #1911/#1917
* Avoid losing DNS entries and potentially double-allocating IP
Addresses allocated via plugin, on router restart; also extend
`weave ps` to show IP addresses allocated via plugin #1745/#1921
* Stop creating lots of copies of `weavewait` program in Docker
volumes #1757/#1935
* Prevent container starting prematurely when proxy in
`--no-multicast-route` mode #1942/#1943
* Log error message from plugin rather than crashing when weave not
running #1906/#1918
* Warn, don't error, if unable to remove plugin network in 'weave
stop', to avoid breaking the usual upgrade or config change process
#1900/#1919
* Don't crash if network conditions suggest only very small packets
will get through #1905/#1926
* Cope with unexpected errors during route traversal when starting
container via proxy #1909/#1910/#1932
## Release 1.4.2
Bug-fixes and minor improvements.
* A race condition in weavewait that would occasionally hang
containers at startup #1882/#1884
* Having the plugin auto-restart prevents successful `weave launch` on
reboot #1869
* Work round weave router failure on CoreOS 4.3 caused by kernel bug
#1854
*`weave launch` would exit with error code on docker <1.9 #1851
* Running `eval $(weave env)` multiple times would break `eval $(weave
env --restore)` #1824/#1825
* Don't complain in `weave stop` about "Plugin is not running" when
plugin is not enabled #1840/#1841
* `weave --local launch` would fail if utility program
`docker_tls_args` could not be found #1844
* Improved error reporting when TLS arg detection fails #1843
* Improve error reporting when docker isn't running #1845
* Add `--trusted-subnets` usage to `weave` script #1842
* weave run can hang under rare combinations of options #1858
## Release 1.4.1
This is a bug-fix release to cover a few issues that came up since the
release of 1.4.0.
* Weave would fail to launch when `$DOCKER_HOST` was set to a TCP socket secured with TLS #1820/#1822
* Weave would fail to stop when run against Docker pre-1.9 #1815/#1817
* Issue a warning instead of failing on `--with-dns` option to proxy, which was removed #1810/#1812
* Make `weave version` show the plugin version #1797/#1813
* Make `weave launch` show when the a container is restarting #1778/#1814
* Make `weave launch` fail if the plugin is running, for consistency with router and proxy. #1818/#1819
More details in the [change log](https://github.com/weaveworks/weave/issues?q=milestone%3A1.4.1).
## Release 1.4.0
**Highlights**
* The Docker Network plugin can now operate without a cluster store, so it is now run by default.
* You can now use the fast datapath over trusted links and Weave encryption over untrusted links, in the same network.
Plus many bug fixes and minor enhancements. More details below and in
the [change log](https://github.com/weaveworks/weave/issues?q=milestone%3A1.4.0).
## Release 1.3.1
**Highlights**
* The minimum Docker version has been increased to 1.6 due to the
[upcoming deprecation of Dockerhub access](https://blog.docker.com/2015/10/docker-hub-deprecation-1-5/)
for old clients. From December 7th onwards previous versions of the
`weave` script will fail to pull down images from the hub; if you
are unable to upgrade to 1.3.1 immediately you can work around this
by running `weave --local setup` in conjunction with a compatible
Docker client installation
* Docker networking plugin now works with older kernels and allows you
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
[Weaveworks](http://weave.works) is the company that develops Weave -
the most productive way for developers to connect, observe and control
Docker containers. To learn about our products, including getting
started tutorials, visit our [website](http://weave.works), read about
the
[1.0 release of Weave](http://blog.weave.works/2015/06/18/weave-1-0-is-out-and-it-is-good/),
visit our [documentation](http://docs.weave.works) or continue to read
about some of the more technical aspects of Weave in this readme.
[Weaveworks](https://www.weave.works) is the company that delivers the most productive way for developers to connect, observe and control
Docker containers.
# Weave
This repository contains [Weave Net](https://www.weave.works/products/weave-net/), the first product developed by Weaveworks, and with nearly 5 million downloads to date, it enables you to get started with Docker clusters and portable apps in a fraction of the time compared with other solutions.
Weave creates a virtual network that connects Docker containers
deployed across multiple hosts and enables their automatic discovery.
Other products from Weaveworks include [Weave Scope](https://www.weave.works/products/weave-scope/), a powerful container monitoring tool that automatically maps Docker containers and their interactions, and [Weave Flux](https://www.weave.works/products/weave-flux/), a microservice router that automates the access of containers as services.
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.
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.
Weave can traverse firewalls and operate in partially connected
networks. Traffic can be encrypted, allowing hosts to be connected
across an untrusted network.
With weave you can easily construct applications consisting of
multiple containers, running anywhere.
Weave works alongside Docker's existing (single host) networking
capabilities, so these can continue to be used by containers.
## Installation
Ensure you are running Linux (kernel 3.8 or later) and have Docker
(version 1.3.1 or later) installed. Then install weave with
sudo curl -L git.io/weave -o /usr/local/bin/weave
sudo chmod a+x /usr/local/bin/weave
CoreOS users see [here](https://github.com/fintanr/weave-gs/blob/master/coreos-simple/user-data) for an example of installing weave using cloud-config.
Weave respects the environment variable `DOCKER_HOST`, so you can run
it locally to control a weave network on a remote host.
## Quick Start Screencast
<a href="https://youtu.be/BF9YJSPQUcY" 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 we 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
- go get github.com/weaveworks/wordepress && cd /home/ubuntu/src/github.com/weaveworks/wordepress && git checkout v1.0.0 && cd cmd/wordepress && go get
- cd $SRCDIR; bin/publish-site "$WP_LIVE_URL" "$WP_LIVE_USER" "$WP_LIVE_PASSWORD"
# - go get github.com/weaveworks/wordepress && cd /home/ubuntu/src/github.com/weaveworks/wordepress && git checkout v1.0.0 && cd cmd/wordepress && go get
# - cd $SRCDIR; bin/publish-site "$WP_DEV_URL" "$WP_DEV_USER" "$WP_DEV_PASSWORD"
# issues:
# branch: /.*/
# owner: weaveworks
# commands:
# - go get github.com/weaveworks/wordepress && cd /home/ubuntu/src/github.com/weaveworks/wordepress && git checkout v1.0.0 && cd cmd/wordepress && go get
# - cd $SRCDIR; bin/publish-site "$WP_DEV_URL" "$WP_DEV_USER" "$WP_DEV_PASSWORD"
Start,Endaddress.Address// [min, max) tokens in this ring. Due to wrapping, min == max (effectively)
Peerrouter.PeerName// name of peer owning this ring instance
Peermesh.PeerName// name of peer owning this ring instance
Entriesentries// list of entries sorted by token
Seeds[]mesh.PeerName// peers with which the ring was seeded
onUpdateOnUpdate
}
func(r*Ring)assertInvariants(){
@@ -36,41 +41,52 @@ var (
ErrNotSorted=errors.New("Ring not sorted")
ErrTokenRepeated=errors.New("Token appears twice in ring")
ErrTokenOutOfRange=errors.New("Token is out of range")
ErrDifferentSeeds=errors.New("Received ring was seeded differently from ours!")
ErrDifferentRange=errors.New("Received range differs from ours!")
ErrNewerVersion=errors.New("Received new version for entry I own!")
ErrInvalidEntry=errors.New("Received invalid state update!")
ErrEntryInMyRange=errors.New("Received new entry in my range!")
ErrNotFound=errors.New("No entries for peer found")
)
funcerrInconsistentEntry(mine,theirs*entry)error{
returnfmt.Errorf("Inconsistent entries for %s: owned by %s but incoming message says %s",mine.Token,mine.Peer,theirs.Peer)
}
funcerrEntryInMyRange(theirs*entry)error{
returnfmt.Errorf("Peer %s says it owns the IP range from %s, which I think I own",theirs.Peer,theirs.Token)
}
funcerrNewerVersion(mine,theirs*entry)error{
returnfmt.Errorf("Received update for IP range I own at %s v%d: incoming message says owner %s v%d",mine.Token,mine.Version,theirs.Peer,theirs.Version)
mflag.BoolVar(&c.NoRewriteHosts,[]string{"-no-rewrite-hosts"},false,"do not automatically rewrite /etc/hosts. Use if you need the docker IP to remain in /etc/hosts")
mflag.StringVar(&c.TLSConfig.CACert,[]string{"#tlscacert","-tlscacert"},"","Trust certs signed only by this CA")
mflag.StringVar(&c.TLSConfig.Cert,[]string{"#tlscert","-tlscert"},"","Path to TLS certificate file")
mflag.BoolVar(&c.TLSConfig.Enabled,[]string{"#tls","-tls"},false,"Use TLS; implied by --tls-verify")
mflag.BoolVar(&c.TLSConfig.Enabled,[]string{"#tls","-tls"},false,"Use TLS; implied by --tlsverify")
mflag.StringVar(&c.TLSConfig.Key,[]string{"#tlskey","-tlskey"},"","Path to TLS key file")
mflag.BoolVar(&c.TLSConfig.Verify,[]string{"#tlsverify","-tlsverify"},false,"Use TLS and verify the remote")
mflag.BoolVar(&c.WithDNS,[]string{"-with-dns","w"},false,"instruct created containers to always use weaveDNS as their nameserver")
mflag.BoolVar(&c.WithoutDNS,[]string{"-without-dns"},false,"instruct created containers to never use weaveDNS as their nameserver")
mflag.BoolVar(&c.NoMulticastRoute,[]string{"-no-multicast-route"},false,"do not add a multicast route via the weave interface when attaching containers")
mflag.Parse()
ifjustVersion{
fmt.Printf("weave proxy %s\n",version)
fmt.Printf("weave proxy %s\n",version)
os.Exit(0)
}
ifc.WithDNS&&c.WithoutDNS{
Log.Fatalf("Cannot use both '--with-dns' and '--without-dns' flags")
}
SetLogLevel(logLevel)
common.SetLogLevel(logLevel)
Log.Infoln("weave proxy",version)
Log.Infoln("Command line arguments:",strings.Join(os.Args[1:]," "))
ifwithDNS{
Log.Warning("--with-dns option has been removed; DNS is on by default")
mflag.IntVar(&bufSzMB,[]string{"#bufsz","-bufsz"},8,"capture buffer size in MB")
mflag.StringVar(&httpAddr,[]string{"#httpaddr","#-httpaddr","-http-addr"},fmt.Sprintf(":%d",weave.HTTPPort),"address to bind HTTP interface to (disabled if blank, absolute path indicates unix domain socket)")
mflag.StringVar(&iprangeCIDR,[]string{"#iprange","#-iprange","-ipalloc-range"},"","IP address range reserved for automatic allocation, in CIDR notation")
mflag.StringVar(&ipsubnetCIDR,[]string{"#ipsubnet","#-ipsubnet","-ipalloc-default-subnet"},"","subnet to allocate within by default, in CIDR notation")
mflag.IntVar(&peerCount,[]string{"#initpeercount","#-initpeercount","-init-peer-count"},0,"number of peers in network (for IP address allocation)")
mflag.StringVar(&apiPath,[]string{"#api","-api"},"unix:///var/run/docker.sock","Path to Docker API socket")
mflag.StringVar(&httpAddr,[]string{"#httpaddr","#-httpaddr","-http-addr"},"","address to bind HTTP interface to (disabled if blank, absolute path indicates unix domain socket)")
mflag.StringVar(&ipamConfig.Mode,[]string{"-ipalloc-init"},"","allocator initialisation strategy (consensus, seed or observer)")
mflag.StringVar(&ipamConfig.IPRangeCIDR,[]string{"#iprange","#-iprange","-ipalloc-range"},"","IP address range reserved for automatic allocation, in CIDR notation")
mflag.StringVar(&ipamConfig.IPSubnetCIDR,[]string{"#ipsubnet","#-ipsubnet","-ipalloc-default-subnet"},"","subnet to allocate within by default, in CIDR notation")
mflag.IntVar(&ipamConfig.PeerCount,[]string{"#initpeercount","#-initpeercount","-init-peer-count"},0,"number of peers in network (for IP address allocation)")
mflag.StringVar(&dockerAPI,[]string{"#api","#-api","-docker-api"},defaultDockerHost,"Docker API endpoint")
mflag.BoolVar(&noDNS,[]string{"-no-dns"},false,"disable DNS server")
mflag.StringVar(&dnsDomain,[]string{"-dns-domain"},nameserver.DefaultDomain,"local domain to server requests for")
mflag.StringVar(&dnsListenAddress,[]string{"-dns-listen-address"},nameserver.DefaultListenAddress,"address to listen on for DNS requests")
mflag.IntVar(&dnsTTL,[]string{"-dns-ttl"},nameserver.DefaultTTL,"TTL for DNS request from our domain")
mflag.DurationVar(&dnsClientTimeout,[]string{"-dns-fallback-timeout"},nameserver.DefaultClientTimeout,"timeout for fallback DNS requests")
mflag.StringVar(&dnsEffectiveListenAddress,[]string{"-dns-effective-listen-address"},"","address DNS will actually be listening, after Docker port mapping")
mflag.StringVar(&dnsConfig.Domain,[]string{"-dns-domain"},nameserver.DefaultDomain,"local domain to server requests for")
mflag.StringVar(&dnsConfig.ListenAddress,[]string{"-dns-listen-address"},nameserver.DefaultListenAddress,"address to listen on for DNS requests")
mflag.IntVar(&dnsConfig.TTL,[]string{"-dns-ttl"},nameserver.DefaultTTL,"TTL for DNS request from our domain")
mflag.DurationVar(&dnsConfig.ClientTimeout,[]string{"-dns-fallback-timeout"},nameserver.DefaultClientTimeout,"timeout for fallback DNS requests")
mflag.StringVar(&dnsConfig.EffectiveListenAddress,[]string{"-dns-effective-listen-address"},"","address DNS will actually be listening, after Docker port mapping")
mflag.StringVar(&dnsConfig.ResolvConf,[]string{"-resolv-conf"},"","path to resolver configuration for fallback DNS lookups")
returnfmt.Errorf("unable to open host namespace: %s",err)
}elseifnsHost.Equal(nsContainer){
returnfmt.Errorf("Container is running in the host network namespace, and therefore cannot be\nconnected to weave. Perhaps the container was started with --net=host.")
}
mtu,err:=strconv.Atoi(args[2])
iferr!=nil&&args[3]!=""{
returnfmt.Errorf("unable to parse mtu %q: %s",args[2],err)
Loaded 100 of 326 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.