Merge pull request #2212 from weaveworks/issues/2114-wordepress-circleci
Incrementally publish 1.5 branch doc updates directly to live
This commit is contained in:
Adam Harrison committed
commit
671dddf761
13 files changed
+67
-99
No files matched your search
Executable
+39
@@ -0,0 +1,39 @@
|
||||
#!/bin/bash
|
||||
|
||||
set -e
|
||||
set -o pipefail
|
||||
|
||||
PRODUCT=net
|
||||
|
||||
fatal() {
|
||||
echo "$@" >&2
|
||||
exit 1
|
||||
}
|
||||
|
||||
if [ ! -d .git ] ; then
|
||||
fatal "Current directory is not a git clone"
|
||||
fi
|
||||
|
||||
if ! BRANCH=$(git symbolic-ref --short HEAD) || [ -z "$BRANCH" ] ; then
|
||||
fatal "Could not determine branch"
|
||||
fi
|
||||
|
||||
case "$BRANCH" in
|
||||
issues/*)
|
||||
VERSION="${BRANCH#issues/}"
|
||||
;;
|
||||
*)
|
||||
if echo "$BRANCH" | grep -qE '^[0-9]+\.[0-9]+' ; then
|
||||
DESCRIBE=$(git describe --match 'v*')
|
||||
if ! VERSION=$(echo "$DESCRIBE" | grep -oP '(?<=^v)[0-9]+\.[0-9]+\.[0-9]+') ; then
|
||||
fatal "Could not infer latest $BRANCH version from $DESCRIBE"
|
||||
fi
|
||||
else
|
||||
VERSION="$BRANCH"
|
||||
fi
|
||||
;;
|
||||
esac
|
||||
|
||||
echo ">>> Publishing $PRODUCT $VERSION site to $1"
|
||||
|
||||
wordepress --dry-run --url "$1" --user "$2" --password "$3" --product "$PRODUCT" --version "$VERSION" publish site
|
||||
+12
@@ -18,6 +18,7 @@ dependencies:
|
||||
- "~/docker"
|
||||
post:
|
||||
- "sudo apt-get update && sudo apt-get install bc jq"
|
||||
- go get github.com/weaveworks/wordepress/cmd/wordepress
|
||||
- curl https://sdk.cloud.google.com | bash
|
||||
- bin/setup-circleci-secrets "$SECRET_PASSWORD"
|
||||
- "mkdir -p $(dirname $SRCDIR) && cp -r $(pwd)/ $SRCDIR"
|
||||
@@ -62,3 +63,14 @@ deployment:
|
||||
- docker login -e $DOCKER_EMAIL -u $DOCKER_USER -p $DOCKER_PASS
|
||||
- cd $SRCDIR; make clean-bin
|
||||
- cd $SRCDIR; make publish
|
||||
- cd $SRCDIR; bin/publish-site "$WP_DEV_URL" "$WP_DEV_USER" "$WP_DEV_PASSWORD"
|
||||
issues:
|
||||
branch: /issues\/.*/
|
||||
owner: weaveworks
|
||||
commands:
|
||||
- cd $SRCDIR; bin/publish-site "$WP_DEV_URL" "$WP_DEV_USER" "$WP_DEV_PASSWORD"
|
||||
release:
|
||||
branch: /[0-9]+\.[0-9]+/
|
||||
owner: weaveworks
|
||||
commands:
|
||||
- cd $SRCDIR; bin/publish-site "$WP_LIVE_URL" "$WP_LIVE_USER" "$WP_LIVE_PASSWORD"
|
||||
@@ -136,6 +136,9 @@ Finally, for **Mainline** releases only:
|
||||
* 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
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
|
||||
@@ -1,6 +1,5 @@
|
||||
---
|
||||
title: Integrating Kubernetes via the CNI Plugin
|
||||
layout: default
|
||||
menu_order: 65
|
||||
---
|
||||
|
||||
|
||||
+6
-6
@@ -33,7 +33,7 @@ For example, you have a Weave network that runs on hosts A, B, C. and you have a
|
||||
|
||||
The simplest way to accomplish this would be to run Weave on the host and then run, `weave expose` to expose the network to any running containers. See [Integrating a Network Host](/site/using-weave/host-network-integration.md) If this is not possible, you could also expose a port on the container on host B and then connect to it.
|
||||
|
||||
You can read about exposing ports in [Service Exporting](/site/using-weave/service-export.md)
|
||||
You can read about exposing ports in [Service Exporting](/site/using-weave/service-export.md).
|
||||
|
||||
|
||||
**Q: Why am I seeing the same IP address assigned to two different containers on different hosts?**
|
||||
@@ -46,7 +46,7 @@ Once the peers detect the inconsistency, they log the error and drop the connect
|
||||
|
||||
Some peers may be able to communicate their claim to the others before they run `rmpeer` (i.e. it's a race), so what you can expect is a few cliques of peers that are still talking to each other, but repeatedly dropping attempted connections with peers in other cliques.
|
||||
|
||||
For more information on see [Address Allocation with IP Address Management (IPAM)](/site/ipam.md) and also, [Starting, Stopping and Removing Peers](/site/ipam/stop-remove-peers-ipam.md)
|
||||
For more information on see [Allocating IP Addresses](/site/ipam.md) and also, [Starting, Stopping and Removing Peers](/site/ipam/stop-remove-peers-ipam.md).
|
||||
|
||||
|
||||
**Q: What is the best practice for resetting a node that goes out of service?**
|
||||
@@ -62,14 +62,14 @@ All virtualization techniques have some overhead, and Weave's overhead is typica
|
||||
|
||||
Weave Net also automatically uses the fastest datapath between two hosts. When Weave Net can't use the fast datapath between two hosts, it falls back to the slower packet forwarding approach. Selecting the fastest forwarding approach is automatic, and is determined on a connection-by-connection basis. For example, a Weave network spanning two data centers might use fast datapath within the data centers, but not for the more constrained network link between them.
|
||||
|
||||
For more information about fast datapath see [How Fast Datapath Works](/site/how-it-works/fastdp-how-it-works.md)
|
||||
For more information about fast datapath see [How Fast Datapath Works](/site/how-it-works/fastdp-how-it-works.md).
|
||||
|
||||
|
||||
**Q:How can I tell if Weave is using fast datapath (fastdp) or not?**
|
||||
|
||||
To view whether Weave is using fastdp or not, you can run, `weave status connections`
|
||||
|
||||
For more information on this command, see [Using Fast Datapath](/site/using-weave/fastdp.md)
|
||||
For more information on this command, see [Using Fast Datapath](/site/using-weave/fastdp.md).
|
||||
|
||||
|
||||
**Q: Does encryption work with fastdp?**
|
||||
@@ -78,11 +78,11 @@ Encryption does not work with fast datapath. If you enable encryption using the
|
||||
|
||||
You can however have a mixture of fast datapath connections over trusted links, as well as, encrypted connections over untrusted links.
|
||||
|
||||
See [Using Fast Datapath](/site/using-weave/fastdp.md) for more information
|
||||
See [Using Fast Datapath](/site/using-weave/fastdp.md) for more information.
|
||||
|
||||
**Q: Can I create multiple networks where containers can communicate on one network, but are isolated from containers on other networks?**
|
||||
|
||||
Yes, of course! Weave allows you to run isolated networks and still allow open communications between individual containers from those isolated networks. You can find information on how to do this in [Application Isolation](/site/using-weave/application-isolation.md)
|
||||
Yes, of course! Weave allows you to run isolated networks and still allow open communications between individual containers from those isolated networks. You can find information on how to do this in [Application Isolation](/site/using-weave/application-isolation.md).
|
||||
|
||||
|
||||
**Q: Which ports does Weave Net use (e.g. if I am configuring a firewall) ?**
|
||||
|
||||
@@ -1,6 +1,5 @@
|
||||
---
|
||||
title: Understanding how Weave Net Works
|
||||
layout: default
|
||||
menu_order: 90
|
||||
---
|
||||
|
||||
|
||||
@@ -1,6 +1,5 @@
|
||||
---
|
||||
title: How Weave Net Implements Encryption
|
||||
layout: default
|
||||
menu_order: 70
|
||||
---
|
||||
|
||||
|
||||
@@ -24,8 +24,8 @@ With Weave Net downloaded onto your VMs or hosts, you are ready to launch a Weav
|
||||
|
||||
###Quick Start Screencast
|
||||
|
||||
<a href="https://youtu.be/kihQCCT1ykE" alt="Click to watch the screencast" target="_blank">
|
||||
<img src="hello-screencast.png" />
|
||||
<a href="https://youtu.be/kihQCCT1ykE" target="_blank">
|
||||
<img src="hello-screencast.png" alt="Click to watch the screencast" />
|
||||
</a>
|
||||
|
||||
###Guides for specific platforms
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Plugin Command-line Arguments
|
||||
layout: default
|
||||
menu_order: 10
|
||||
---
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ The plugin command-line arguments are:
|
||||
|
||||
* `--log-level=debug|info|warning|error` --tells the plugin
|
||||
how much information to emit for debugging.
|
||||
* `--mesh-network-name=<name>` -- set <name> to blank to disable creation
|
||||
* `--mesh-network-name=<name>` -- set `<name>` to blank to disable creation
|
||||
of a default network, or include a name of your own choice.
|
||||
* `--no-multicast-route` -- stops weave from adding a static IP route for
|
||||
multicast traffic onto its interface
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: How the Weave Net Docker Network Plugin Works
|
||||
layout: default
|
||||
menu_order: 20
|
||||
---
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Automatic IP Allocation and the Weave Proxy
|
||||
layout: default
|
||||
menu_order: 25
|
||||
---
|
||||
|
||||
|
||||
|
||||
@@ -17,7 +17,7 @@ returns the Weave Net IP address. This is required for many cluster-aware
|
||||
applications to work.
|
||||
- unqualified names get resolved via DNS, for example typically via weaveDNS
|
||||
to Weave Net IP addresses. This is required so that in a typical setup
|
||||
one can simply "ping <container-name>", i.e. without having to
|
||||
one can simply "ping `<container-name>`", i.e. without having to
|
||||
specify a `.weave.local` suffix.
|
||||
|
||||
If you prefer to keep `/etc/hosts` under Docker's control (for
|
||||
|
||||
@@ -1,83 +0,0 @@
|
||||
---
|
||||
title: WeaveDNS (service discovery) Design Notes
|
||||
layout: default
|
||||
---
|
||||
|
||||
# WeaveDNS (service discovery) Design Notes
|
||||
|
||||
The model is that each host has a service that is notified of
|
||||
hostnames and weave addresses for containers on the host. Like IPAM,
|
||||
this service is embedded within the router. It binds to
|
||||
the host bridge to answer DNS queries from local containers; for
|
||||
anything it can't answer, it uses the information in the host's
|
||||
/etc/resolv.conf to query an 'fallback' server.
|
||||
|
||||
The service is comprised of a DNS server, which answers all DNS queries
|
||||
from containers, and a in-memory database of hostnames and IPs. The
|
||||
database on each node contains a complete copy of the hostnames and IPs
|
||||
for every containers in the cluster.
|
||||
|
||||
For hostname queries in the local domain (default weave.local), the DNS
|
||||
server will consult the in-memory database. For reverse queries, we
|
||||
first consult the local database, and if not found we query the
|
||||
upstream server. For all other queries, we consult the upstream
|
||||
server.
|
||||
|
||||
Updates to the in-memory database are broadcast to other DNS servers
|
||||
within the cluster. The in-memory database only contains entries from
|
||||
connected DNS servers; if a DNS server becomes partitioned from the
|
||||
cluster, entries belonging to that server are removed from each node in
|
||||
the cluster. When the partitioned DNS server reconnects, the entries
|
||||
are re-broadcast around the cluster.
|
||||
|
||||
The DNS server also listens to the Docker event stream, and removes
|
||||
entries for containers when they die. Entries removed in this way are
|
||||
tombstoned, and the tombstone lazily broadcast around the cluster.
|
||||
After a short timeout the tombstones are independently removed from
|
||||
each host.
|
||||
|
||||
|
||||
## DNS server API
|
||||
|
||||
The DNS server accepts HTTP requests on the following URL (patterns)
|
||||
and methods:
|
||||
|
||||
`PUT /name/<identifier>/<ip-address>`
|
||||
|
||||
Put a record for an IP, bound to a host-scoped identifier (e.g., a
|
||||
container ID), in the DNS database. The request body must contain
|
||||
a `fqdn=foo.weave.local` key pair.
|
||||
|
||||
`DELETE /name/<identifier>/<ip-address>`
|
||||
|
||||
Remove a specific record for an IP and host-scoped identifier. The request
|
||||
body can optionally contain a `fqdn=foo.weave.local` key pair.
|
||||
|
||||
`DELETE /name/<identifier>`
|
||||
|
||||
Remove all records for the host-scoped identifier.
|
||||
|
||||
`GET /name/<fqdn>`
|
||||
|
||||
List of all IPs (in JSON format) for givne FQDN.
|
||||
|
||||
## DNS updater
|
||||
|
||||
The updater component uses the Docker remote API to monitor containers
|
||||
coming and going, and tells the DNS server to update its records via
|
||||
its HTTP interface. It does not need to be attached to the weave
|
||||
network.
|
||||
|
||||
The updater starts by subscribing to the events, and getting a list of
|
||||
the current containers. Any containers given a domain ending with
|
||||
".weave" are considered for inclusion in the name database.
|
||||
|
||||
When it sees a container start or stop, the updater checks the weave
|
||||
network attachment of the container, and updates the DNS server.
|
||||
|
||||
> How does it check the network attachment from within a container?
|
||||
|
||||
> Will it need to delay slightly so that `attach` has a chance to run?
|
||||
> Perhaps it could put containers on a watch list when it's noticed
|
||||
> them.
|
||||
|
||||
Reference in new issue
Block a user