Add release v2.8.6

CHANGELOG.md

@@ -1,3 +1,12 @@
+## Release 2.8.6
+
+From this release onwards, the Docker V2 Plugin will be published for all supported architectures. It will be named using the pattern `rajchaudhuri/net-plugin:<version>-<arch>`. The latest version will also be published as `rajchaudhuri/net-plugin:latest_release-<arch>`. Supported architectures are `amd64`,`arm`,`arm64`,`ppc64le` and `s390x`. It can be installed on a Swarm-mode-enabled Docker host as follows:
+
+```bash
+ARCH=$(docker version -f '{{.Server.Arch}}')
+docker plugin install rajchaudhuri/net-plugin:latest_release-$ARCH
+```
+
 ## Release 2.8.5
 
 This release has upgraded dependencies based on CVE recommendations.

README.md

@@ -14,10 +14,10 @@ The history of the ReWeave effort can be found in [HISTORY.md](HISTORY.md).
 On a newly created Kubernetes cluster, the Weave Net CNI pluging can be installed by running the following command:
 
 ```
-kubectl apply -f https://reweave.azurewebsites.net/k8s/v1.28/net.yaml
+kubectl apply -f https://reweave.azurewebsites.net/k8s/v1.29/net.yaml
 ```
 
-Replace `v1.28` with the version on Kubernetes on your cluster.
+Replace `v1.29` with the version on Kubernetes on your cluster.
 
 That endpoint is provided by the companion project [weave-endpoint](https://github.com/rajch/weave-endpoint).
 

prog/net-plugin/config.json

@@ -97,6 +97,14 @@
           "value"
       ],
       "value": ""
+    },
+    {
+      "description": "Whether to use the version check feature of Weave Net",
+      "name": "CHECKPOINT_DISABLE",
+      "settable": [
+          "value"
+      ],
+      "value": "1"
     }
   ],
   "network": {

reweave/CHANGELOG.md

@@ -2,8 +2,28 @@
 
 All changes made to the weave net codebase during the reweave effort will be documented in this file.
 
+## 2.8.6
+
+### Changed
+
+* Changed version in `reweave/Makefile` to 2.8.6
+* Modified reweave and main CHANGELOG.md
+* Modified `reweave/Makefile` to ensure that `make build-plugin` builds the plugin only for the host architecture
+* Made some documentation changes
+
+## 2.8.6-beta1
+
+### Changed
+
+* Changed the V2 plugin build and clean tools to build (and clean) multiple architecture-specific plugins per version, since Docker Managed Plugins are not multi-architecture capable
+* Changed the V2 plugin configuration `prog/net-plugin/config.json` to include `CHECKPOINT_DISABLE` as an option, set to `1` by default to disable latest version checking.
+* Changed the `weave` script to include `export CHECKPOINT_DISABLE=`. This will disable latest version checking for the legacy plugin as well.
+* Changed the documentation in the `website` directory as appropriate.
+
 ## 2.8.5
 
+### Changed
+
 * Changed version in `reweave/Makefile` to 2.8.5
 * Modified reweave and main CHANGELOG.md
 
@@ -237,6 +257,7 @@ A new build process was created here.
 * Multi-stage Dockerfile, and a Makefile for the second stage, in `reweave/build`
 
 ### Changed
+
 * Included image building targets in Makefile directly under `reweave`
 * Changed `IMAGE_VERSION` to `2.8.2-beta0` in Makefile directly under `reweave`
 * The Alpine base image for all weave net images was set to `alpine:3.17.2` via the multi-stage Dockerfile

reweave/Makefile

@@ -1,4 +1,4 @@
-IMAGE_VERSION ?= 2.8.5
+IMAGE_VERSION ?= 2.8.6
 REGISTRY_USER ?= rajchaudhuri
 
 ALPINE_BASEIMAGE ?= alpine:3.19.1
@@ -15,6 +15,7 @@ build-images: submodule
 .PHONY: build-plugin
 build-plugin: ../prog/net-plugin/launch.sh ../prog/net-plugin/config.json
 	REGISTRY_USER=${REGISTRY_USER} IMAGE_VERSION=${IMAGE_VERSION} \
+	PLATFORMS="$$(docker version -f '{{ .Server.Arch }}')" \
 	tools/build-plugin.sh
 
 .PHONY: build

reweave/scans/badge.json

@@ -1 +1 @@
-{"schemaVersion": 1, "label": "Vulnerabilty count", "message": "17", "color": "orange"}
+{"schemaVersion": 1, "label": "Vulnerabilty count", "message": "18", "color": "orange"}

reweave/scans/report.md

@@ -1,9 +1,9 @@
 # Vulnerability Report
 
 ```
-Report date: 2024-04-06
-Unique vulnerability count: 17
-Images version: 2.8.5
+Report date: 2024-04-10
+Unique vulnerability count: 18
+Images version: 2.8.6
 ```
 
 ## Scanner Details
@@ -23,7 +23,7 @@ Supported DB Schema: 5
 
 ## Vulnerabilities
 
-### weave-kube: (17) 
+### weave-kube: (18) 
 
 ```
 NAME           INSTALLED   FIXED-IN  TYPE  VULNERABILITY   SEVERITY 
@@ -40,6 +40,7 @@ curl           8.5.0-r0              apk   CVE-2024-2466   Unknown
 curl           8.5.0-r0              apk   CVE-2024-2398   Unknown   
 curl           8.5.0-r0              apk   CVE-2024-2004   Unknown   
 libuv          1.47.0-r0             apk   CVE-2024-24806  High      
+nghttp2-libs   1.58.0-r0             apk   CVE-2024-28182  Medium    
 ssl_client     1.36.1-r15            apk   CVE-2023-42366  Medium    
 ssl_client     1.36.1-r15            apk   CVE-2023-42365  Medium    
 ssl_client     1.36.1-r15            apk   CVE-2023-42364  Medium    
@@ -64,7 +65,7 @@ ssl_client     1.36.1-r15            apk   CVE-2023-42364  Medium
 ssl_client     1.36.1-r15            apk   CVE-2023-42363  Medium
 ```
 
-### weave: (17) 
+### weave: (18) 
 
 ```
 NAME           INSTALLED   FIXED-IN  TYPE  VULNERABILITY   SEVERITY 
@@ -81,13 +82,14 @@ curl           8.5.0-r0              apk   CVE-2024-2466   Unknown
 curl           8.5.0-r0              apk   CVE-2024-2398   Unknown   
 curl           8.5.0-r0              apk   CVE-2024-2004   Unknown   
 libuv          1.47.0-r0             apk   CVE-2024-24806  High      
+nghttp2-libs   1.58.0-r0             apk   CVE-2024-28182  Medium    
 ssl_client     1.36.1-r15            apk   CVE-2023-42366  Medium    
 ssl_client     1.36.1-r15            apk   CVE-2023-42365  Medium    
 ssl_client     1.36.1-r15            apk   CVE-2023-42364  Medium    
 ssl_client     1.36.1-r15            apk   CVE-2023-42363  Medium
 ```
 
-### weaveexec: (17) 
+### weaveexec: (18) 
 
 ```
 NAME           INSTALLED   FIXED-IN  TYPE  VULNERABILITY   SEVERITY 
@@ -104,6 +106,7 @@ curl           8.5.0-r0              apk   CVE-2024-2466   Unknown
 curl           8.5.0-r0              apk   CVE-2024-2398   Unknown   
 curl           8.5.0-r0              apk   CVE-2024-2004   Unknown   
 libuv          1.47.0-r0             apk   CVE-2024-24806  High      
+nghttp2-libs   1.58.0-r0             apk   CVE-2024-28182  Medium    
 ssl_client     1.36.1-r15            apk   CVE-2023-42366  Medium    
 ssl_client     1.36.1-r15            apk   CVE-2023-42365  Medium    
 ssl_client     1.36.1-r15            apk   CVE-2023-42364  Medium    

reweave/tools/build-plugin.sh

@@ -6,33 +6,79 @@ set -e
 : "${IMAGE_VERSION:=}"
 : "${REGISTRY_USER:=}"
 
-# This variable is used to flag plugin publishing
-: "${PUBLISH:=}"
-
 if [ -z "${IMAGE_VERSION}" ] || [ -z "${REGISTRY_USER}" ] ; then
     >&2 echo "Please provide valid values for IMAGE_VERSION and REGISTRY_USER." 
     exit 1
 fi
 
+# To build the plugin for multiple architecture, the 
+# local Docker engine needs to have the containerd
+# snapshotter enabled.
+if [ "overlayfs" != "$(docker info -f '{{.Driver}}')" ]; then
+    echo "To ensure that the plugin can be built for multiple architectures, the"
+    echo "Docker Engine needs to have the containerd image store feature enabled."
+    echo "Please see https://docs.docker.com/storage/containerd/ to find out how."
+    echo "Run this build again after enabling it."
+    exit 1
+fi
+
+
+# This variable is used to control the architectures for
+# which the plugin will be built.
+: "${PLATFORMS:=amd64,arm,arm64,ppc64le,s390x}"
+
+# This variable is used to flag plugin publishing
+: "${PUBLISH:=}"
+
 WEAVER_IMAGE=${REGISTRY_USER}/weave:${IMAGE_VERSION}
-PLUGIN_IMAGE=${REGISTRY_USER}/net-plugin:${IMAGE_VERSION}
-PLUGIN_BUILD_IMG="plugin-builder"
-PLUGIN_PARENT_DIR="../prog/net-plugin"
-PLUGIN_WORK_DIR="${PLUGIN_PARENT_DIR}/rootfs"
 
-docker container rm -f ${PLUGIN_BUILD_IMG} 2>/dev/null
-docker container create --name=${PLUGIN_BUILD_IMG} "${WEAVER_IMAGE}" true
-rm -rf ${PLUGIN_WORK_DIR}
-mkdir ${PLUGIN_WORK_DIR}
-docker export ${PLUGIN_BUILD_IMG} | tar -x -C ${PLUGIN_WORK_DIR}
-docker container rm -f ${PLUGIN_BUILD_IMG}
-cp "${PLUGIN_PARENT_DIR}/launch.sh" "${PLUGIN_WORK_DIR}/home/weave/launch.sh"
-set +e
-docker plugin disable "${PLUGIN_IMAGE}" 2>/dev/null
-docker plugin rm "${PLUGIN_IMAGE}" 2>/dev/null
-set -e
-docker plugin create "${PLUGIN_IMAGE}" "${PLUGIN_PARENT_DIR}"
+# $1 - Architecture to build for
+build_plugin() {
+    PLUGIN_ARCH=${1:-amd64}
+    PLUGIN_IMAGE=${REGISTRY_USER}/net-plugin:${IMAGE_VERSION}-${PLUGIN_ARCH}
+    PLUGIN_BUILD_IMG="plugin-builder-${PLUGIN_ARCH}"
+    PLUGIN_PARENT_DIR="../prog/net-plugin"
+    PLUGIN_WORK_DIR="${PLUGIN_PARENT_DIR}/rootfs"
 
-if [ "${PUBLISH}" = "true" ]; then
-    docker plugin push "${PLUGIN_IMAGE}"
-fi
+    echo "Building ${PLUGIN_IMAGE}..."
+
+    docker container rm -f "${PLUGIN_BUILD_IMG}" 2>/dev/null
+    docker container create --platform="${PLUGIN_ARCH}" --name="${PLUGIN_BUILD_IMG}" "${WEAVER_IMAGE}" true
+    rm -rf ${PLUGIN_WORK_DIR}
+    mkdir ${PLUGIN_WORK_DIR}
+    docker export "${PLUGIN_BUILD_IMG}" | tar -x -C ${PLUGIN_WORK_DIR}
+    docker container rm -f "${PLUGIN_BUILD_IMG}"
+    cp "${PLUGIN_PARENT_DIR}/launch.sh" "${PLUGIN_WORK_DIR}/home/weave/launch.sh"
+    set +e
+    docker plugin disable "${PLUGIN_IMAGE}" 2>/dev/null
+    docker plugin rm "${PLUGIN_IMAGE}" 2>/dev/null
+    set -e
+    docker plugin create "${PLUGIN_IMAGE}" "${PLUGIN_PARENT_DIR}"
+
+    if [ "${PUBLISH}" = "true" ]; then
+        echo "Pushing ${PLUGIN_IMAGE}..."
+        docker plugin push "${PLUGIN_IMAGE}"
+
+        # If this is not a beta release, also create a "latest-release-$ARCH"
+        # plugin.
+        case "$IMAGE_VERSION" in
+            *-beta*) IS_BETA=1 ;;
+            *) IS_BETA= ;;
+        esac
+
+        if [ -z ${IS_BETA} ]; then
+            echo "Tagging ${PLUGIN_IMAGE} as latest_release..."
+            LATEST_IMAGE=${REGISTRY_USER}/net-plugin:latest_release-${PLUGIN_ARCH}
+            docker plugin create "${LATEST_IMAGE}" "${PLUGIN_PARENT_DIR}"
+            echo "Pushing ${LATEST_IMAGE}..."
+            docker plugin push "${LATEST_IMAGE}"
+        fi
+
+    fi
+
+    echo "Done."
+}
+
+for i in $( echo "$PLATFORMS" | tr ',' ' '); do
+    build_plugin "$i"
+done

reweave/tools/clean-plugin.sh

@@ -11,6 +11,22 @@ if [ -z "${IMAGE_VERSION}" ] || [ -z "${REGISTRY_USER}" ] ; then
     exit 1
 fi
 
-PLUGIN_IMAGE=${REGISTRY_USER}/net-plugin:${IMAGE_VERSION}
+# This variable is used to control the architectures for
+# which the plugin will be built.
+: "${PLATFORMS:=amd64,arm,arm64,ppc64le,s390x}"
 
-docker plugin rm "${PLUGIN_IMAGE}" 2>/dev/null
+# $1 - Architecture to build for
+delete_plugin() {
+    PLUGIN_ARCH=${1:-amd64}
+    PLUGIN_IMAGE=${REGISTRY_USER}/net-plugin:${IMAGE_VERSION}-${PLUGIN_ARCH}
+    echo "Deleting plugin ${PLUGIN_IMAGE}..."
+    set +e
+    docker plugin rm "${PLUGIN_IMAGE}" 2>/dev/null
+    set -e
+}
+
+for i in $( echo "$PLATFORMS" | tr ',' ' '); do
+    delete_plugin "$i"
+done
+
+rm -rf "../prog/net-plugin/rootfs"

weave

@@ -3,6 +3,9 @@ set -e
 
 [ -n "$WEAVE_DEBUG" ] && set -x
 
+# There is no longer a checkpoint service
+export CHECKPOINT_DISABLE=1
+
 # Release Version
 SCRIPT_VERSION="unreleased"
 IMAGE_VERSION=latest

website/faq.md

@@ -118,12 +118,14 @@ network does not block ESP traffic (IP protocol 50). For instance
 on Google Cloud Platform a firewall rule for allowing ESP traffic has
 to be installed.
 
-**<a name="own-image"></a>Q: Why do you use your own Docker image `weaveworks/ubuntu`?**
+~~**<a name="own-image"></a>Q: Why do you use your own Docker image `weaveworks/ubuntu`?**
 
 The official Ubuntu image does not contain the `ping` and `nc`
 commands which are used in many of our examples throughout the
 documentation. The `weaveworks/ubuntu` image is simply the official
-Ubuntu image with those two commands added.
+Ubuntu image with those two commands added.~~
+We now use the official `alpine:latest` image, which already has
+these two commands.
 
 
 **See Also**

website/index.md

@@ -14,9 +14,9 @@ If you are here for the most popular use of Weave Net - the famous one-line inst
 You can install Weave Net on a Kubernetes cluster using:
 
 ```bash
-kubectl apply -f https://reweave.azurewebsites.net/k8s/v1.25/net.yaml
+kubectl apply -f https://reweave.azurewebsites.net/k8s/v1.29/net.yaml
 ```
-where the `v1.25` part can be replaced with any kubernetes version, the minimum being `v1.8`.
+where the `v1.29` part can be replaced with any Kubernetes version, the minimum being `v1.8`.
 
 If you prefer the older method using `kubectl version`, that works too:
 
@@ -33,6 +33,16 @@ kubectl apply -f https://github.com/rajch/weave/releases/latest/download/weave-d
 
 More details, and options can be found on the [Integrating Kubernetes via the Addon]({{ '/kubernetes/kube-addon' | relative_url }}) page.
 
+## Using Weave as a (legacy) Docker Plugin
+
+See [Installing Weave Net]({{ '/install/installing-weave' | relative_url }}), and then [Launching Weave Net]({{ '/install/using-weave' | relative_url }}).
+
+## Using Weave as a Docker Managed (V2) Plugin in Swarm Mode
+
+See [Integrating Docker via the Network Plugin (V2)]({{ '/install/plugin/plugin-v2' | relative_url }}).
+
+**Note:** From version 2.8.6 onwards, the Docker V2 plugin is available for amd64, arm, arm64, ppc64le and s390x architectures. Prior to this, it was only available for amd64.
+
 ## All other uses, and more
 
 For all other uses, proceed to the [Weave Net overview]({{ '/overview' | relative_url }}).

website/install/installing-weave.md

@@ -15,9 +15,11 @@ Install Weave Net by running the following:
 
 ~~If you are on OSX and you are using Docker Machine ensure that a VM is running and configured 
 before downloading Weave Net. To set up a VM see [the Docker Machine
-documentation](https://docs.docker.com/installation/mac/#from-your-shell) or refer to ["Part 1: Launching Weave Net with Docker Machine"](https://web.archive.org/web/20231002233731/https://www.weave.works/guides/part-1-launching-weave-net-with-docker-machine/).~~
+documentation](https://docs.docker.com/installation/mac/#from-your-shell) or refer to ["Part 1: Launching Weave Net with Docker Machine"](https://web.archive.org/web/20231002233731/https://www.weave.works/guides/part-1-launching-weave-net-with-docker-machine/).
 
-After your VM is setup with Docker Machine, Weave Net can be launched directly from the OSX host. Weave Net respects the environment variable `DOCKER_HOST`, so that you can run and control a Weave Network locally on a remote host. See [Using The Weave Docker API Proxy]({{ '/tasks/weave-docker-api/using-proxy' | relative_url }}).
+After your VM is setup with Docker Machine, Weave Net can be launched directly from the OSX host.~~
+
+Weave Net respects the environment variable `DOCKER_HOST`, so that you can run and control a Weave Network locally on a remote host. See [Using The Weave Docker API Proxy]({{ '/tasks/weave-docker-api/using-proxy' | relative_url }}).
 
 With Weave Net downloaded onto your VMs or hosts, you are ready to launch a Weave network and deploy apps onto it. See [Launching Weave Net]({{ '/install/using-weave' | relative_url }}).
 

website/install/plugin/plugin-how-it-works.md

@@ -8,7 +8,7 @@ search_type: Documentation
 The Weave Net legacy plugin actually provides *two* network drivers to Docker -
 one named `weavemesh` that can operate without a cluster store and another one
 named `weave` that can only work with one (like Docker's overlay driver), while
-the V2 plugin provides *one* - `weaveworks/net-plugin:latest_release`
+the V2 plugin provides *one* - `rajchaudhuri/net-plugin:latest_release-<architecture>`
 operating only in swarm mode.
 
 ### weavemesh driver
@@ -41,7 +41,7 @@ The plugin accepts the following options via `docker network create ... --opt`:
    network created when the plugin is first launched has the multicast
    option turned on, but for any networks you create it defaults to off.
 
-### weaveworks/net-plugin:latest_release driver
+### rajchaudhuri/net-plugin:latest_release-&lt;architecture> driver
 
 * The driver runs within the plugin V2.
 * Requires Docker to run in [swarm mode](https://docs.docker.com/engine/swarm/swarm-mode/).

website/install/plugin/plugin-v2.md

@@ -19,7 +19,23 @@ mode and requires Docker version 1.13 or later.
 To install the plugin run the following command on _each_ host already
 participating in a Swarm cluster, i.e. on all master and worker nodes:
 
-    $ docker plugin install weaveworks/net-plugin:latest_release
+    $ docker plugin install rajchaudhuri/net-plugin:latest_release-<architecture>
+
+Here, &lt;architecture> is the processor architecture on which your Docker Engine runs. 
+It is a necessary part of the plugin name, because Docker currently does not support
+multi-architecture plugins. The Weave Net Plugin V2 is available for the following 
+architectures:
+
+* amd64
+* arm
+* arm64
+* ppc64le
+* s390x
+
+You can use the following commands to install the plugin appropriate to your architecture:
+
+    $ ARCH=$(docker version -f '{{.Server.Arch}}')
+    $ docker plugin install rajchaudhuri/net-plugin:latest_release-$ARCH
 
 Docker will pull the plugin from Docker Store, and it will ask to grant
 privileges before installing the plugin. Afterwards, it will start `weaver`
@@ -29,7 +45,7 @@ process which will try to connect to Swarm masters running Weave Net.
 
 There are several configuration parameters which can be set with:
 
-    $ docker plugin set weaveworks/net-plugin:latest_release PARAM=VALUE
+    $ docker plugin set rajchaudhuri/net-plugin:latest_release-$ARCH PARAM=VALUE
 
 The parameters include:
 
@@ -49,31 +65,38 @@ The parameters include:
 
 Before setting any parameter, the plugin has to be disabled with:
 
-    $ docker plugin disable weaveworks/net-plugin:latest_release
+    $ docker plugin disable rajchaudhuri/net-plugin:latest_release-$ARCH
 
 To re-enable the plugin run the following command:
 
-    $ docker plugin enable weaveworks/net-plugin:latest_release
+    $ docker plugin enable rajchaudhuri/net-plugin:latest_release-$ARCH
 
 ### <a name="usage"></a>Running Services or Containers Using the Plugin
 
 After you have launched the plugin, you can create a network for Docker Swarm
 services by running the following command on any Docker Swarm master node:
 
-    $ docker network create --driver=weaveworks/net-plugin:latest_release mynetwork
+    $ docker network create --driver=rajchaudhuri/net-plugin:latest_release-$ARCH mynetwork
 
 Or you can create a network for any Docker container with:
 
-    $ docker network create --driver=weaveworks/net-plugin:latest_release --attachable mynetwork
+    $ docker network create --driver=rajchaudhuri/net-plugin:latest_release-$ARCH --attachable mynetwork
 
 To start a service attached to the network run, for example:
 
     $ docker service create --network=mynetwork ...
 
-Or to start a container:
+To ensure that name resolution (service discovery) works as expected, do one of the following:
+
+* Include `--endpoint-mode=dnsrr` while creating a service. This will correctly resolve the service name to the load-balanced IP address of one of the task containers.
+* OR, include `--hostname=SOMENAME` while creating a servce. This will also resolve `SOMENAME` to the load-balanced IP address of one of the task containers.
+
+To start a container:
 
     $ docker run --network=mynetwork ...
 
+This does not require a `--hostname` option. The container name and any network aliases will correctly resolve to the container's IP address.
+
 **See Also**
 
  * [Integrating Docker via the Network Plugin (Legacy)]({{ '/install/plugin/plugin' | relative_url }})

website/install/plugin/plugin.md

@@ -20,7 +20,7 @@ See [Launching Weave Net]({{ '/install/using-weave#peer-connections' | relative_
 
 After you've launched Weave Net and peered your hosts,  you can start containers using the following, for example:
 
-    $ docker run --net=weave -ti weaveworks/ubuntu
+    $ docker run --net=weave -ti alpine:latest
 
 on any of the hosts, and they can all communicate with each other
 using any protocol, even multicast.
@@ -29,8 +29,8 @@ In order to use Weave Net's [Service Discovery]({{ '/tasks/weavedns/weavedns' |
 must pass the additional arguments `--dns` and `-dns-search`, for
 which a helper is provided in the Weave script:
 
-    $ docker run --net=weave -h foo.weave.local $(weave dns-args) -tdi weaveworks/ubuntu
-    $ docker run --net=weave -h bar.weave.local $(weave dns-args) -ti weaveworks/ubuntu
+    $ docker run --net=weave -h foo.weave.local $(weave dns-args) -tdi alpine:latest
+    $ docker run --net=weave -h bar.weave.local $(weave dns-args) -ti alpine:latest
     # ping foo
 
 
@@ -43,11 +43,11 @@ Just launch the Weave Net router onto each host and make a peer connection with
 
 then run your containers using the Docker command-line:
 
-    host1$ docker run --net=weave -ti weaveworks/ubuntu
+    host1$ docker run --net=weave -ti alpine:latest
     root@1458e848cd90:/# hostname -i
     10.32.0.2
 
-    host2$ docker run --net=weave -ti weaveworks/ubuntu
+    host2$ docker run --net=weave -ti alpine:latest
     root@8cc4b5dc5722:/# ping 10.32.0.2
 
     PING 10.32.0.2 (10.32.0.2) 56(84) bytes of data.

website/install/using-weave.md

@@ -21,13 +21,13 @@ On `$HOST1` run:
 
     host1$ weave launch
     host1$ eval $(weave env)
-    host1$ docker run --name a1 -ti weaveworks/ubuntu
+    host1$ docker run --name a1 -ti alpine:latest
 
 Where, 
 
  * The first line runs Weave Net. 
- * The second line configures the Weave Net environment, so that containers launched via the Docker command line are automatically attached to the Weave network, and, 
- * The third line runs the [application container]({{ '/faq#own-image' | relative_url }}) using [a Docker command](https://docs.docker.com/reference/cli/docker/container/run/).
+ * The second line configures the Docker environment to use the [Weave Net Docker API Proxy]({{ '/tasks/weave-docker-api/weave-docker-api' | relative_url }}), so that containers launched via the Docker command line are automatically attached to the Weave network, and, 
+ * The third line runs an application container using [a Docker command](https://docs.docker.com/reference/cli/docker/container/run/).
 
 > **Note** If the first command results in an error like
 > ```
@@ -44,7 +44,7 @@ Where,
 > host1$ sudo -s
 > host1# weave launch
 > host1# eval $(weave env)
-> host1# docker run --name a1 -ti weaveworks/ubuntu
+> host1# docker run --name a1 -ti alpine:latest
 > ```
 > Do *not* prefix individual commands with `sudo`, since some commands
 > modify environment entries and hence they all need to be executed from
@@ -63,7 +63,7 @@ To launch Weave Net on an additional host and create a peer connection, run the
 
     host2$ weave launch $HOST1
     host2$ eval $(weave env)
-    host2$ docker run --name a2 -ti weaveworks/ubuntu
+    host2$ docker run --name a2 -ti alpine:latest
 
 As noted above, the same steps are repeated for `$HOST2`. The only difference, besides the application container’s name, is that `$HOST2` is told to peer with Weave Net on `$HOST1` during launch. 
 

website/overview/features.md

@@ -79,7 +79,7 @@ See [Integrating Docker via the API Proxy]({{ '/tasks/weave-docker-api/weave-doc
 Weave Net can also be used as a [Docker plugin](https://docs.docker.com/engine/extend/plugins_network/).  A Docker network 
 named `weave` is created by `weave launch`, which is used as follows:
 
-    $ docker run --net=weave -ti weaveworks/ubuntu
+    $ docker run --net=weave -ti alpine:latest
 
 Using the Weave plugin enables you to take advantage of [Docker's network functionality](https://docs.docker.com/engine/extend/plugins_network/).
 
@@ -108,11 +108,11 @@ For a discussion on how Weave Net uses IPAM, see [Automatic IP Address Managemen
 
 ### <a name="naming-and-discovery"></a>Naming and Discovery
  
-Named containers are automatically registered in [weaveDNS]({{ '/tasks/weavedns/weavedns' | relative_url }}), 
+Containers with a hostname are automatically registered in [weaveDNS]({{ '/tasks/weavedns/weavedns' | relative_url }}), 
 and are discoverable by using standard, simple name lookups:
 
-    host1$ docker run -dti --name=service weaveworks/ubuntu
-    host1$ docker run -ti weaveworks/ubuntu
+    host1$ docker run -dti --name=service --hostname=service.weave.local alpine:latest
+    host1$ docker run -ti alpine:latest
     root@7b21498fb103:/# ping service
 
 WeaveDNS also supports [load balancing]({{ '/tasks/weavedns/load-balance-fault-weavedns' | relative_url }}), [fault resilience]({{ '/tasks/weavedns/load-balance-fault-weavedns' | relative_url }}) and [hot swapping]( {{ '/tasks/weavedns/managing-entries-weavedns' | relative_url }}). 

website/tasks/ipam/allocation-multi-ipam.md

@@ -16,13 +16,13 @@ allocation of an address from a particular subnet, set the
 `WEAVE_CIDR` environment variable to `net:<subnet>` when creating the
 container, for example:
 
-    host1$ docker run -e WEAVE_CIDR=net:10.2.7.0/24 -ti weaveworks/ubuntu
+    host1$ docker run -e WEAVE_CIDR=net:10.2.7.0/24 -ti alpine:latest
 
 You can ask for multiple addresses in different subnets and add in
 manually-assigned addresses (outside the automatic allocation range),
 for instance:
 
-    host1$ docker run -e WEAVE_CIDR="net:10.2.7.0/24 net:10.2.8.0/24 ip:10.3.9.1/24" -ti weaveworks/ubuntu
+    host1$ docker run -e WEAVE_CIDR="net:10.2.7.0/24 net:10.2.8.0/24 ip:10.3.9.1/24" -ti alpine:latest
 
 >**Note:** The ".0" and ".-1" addresses in a subnet are not used, as required by
 [RFC 1122](https://tools.ietf.org/html/rfc1122#page-29)).

website/tasks/ipam/manual-ip-address.md

@@ -37,12 +37,12 @@ For example, we can launch a couple of containers on `$HOST1` and
 
 On `$HOST1`:
 
-    host1$ docker run -e WEAVE_CIDR=10.2.1.1/24 -ti weaveworks/ubuntu
+    host1$ docker run -e WEAVE_CIDR=10.2.1.1/24 -ti alpine:latest
     root@7ca0f6ecf59f:/#
 
 And `$HOST2`:
 
-    host2$ docker run -e WEAVE_CIDR=10.2.1.2/24 -ti weaveworks/ubuntu
+    host2$ docker run -e WEAVE_CIDR=10.2.1.2/24 -ti alpine:latest
     root@04c4831fafd3:/#
 
 Then test that the container on `$HOST2` can be reached from the container on `$HOST1`:

website/tasks/manage/application-isolation.md

@@ -27,13 +27,13 @@ specified.
 
 Next, launch the two netcat containers onto the default subnet:
 
-    host1$ docker run --name a1 -ti weaveworks/ubuntu
-    host2$ docker run --name a2 -ti weaveworks/ubuntu
+    host1$ docker run --name a1 -ti alpine:latest
+    host2$ docker run --name a2 -ti alpine:latest
 
 And then to test the isolation, launch a few more containers onto a different subnet:
 
-    host1$ docker run -e WEAVE_CIDR=net:10.2.2.0/24 --name b1 -ti weaveworks/ubuntu
-    host2$ docker run -e WEAVE_CIDR=net:10.2.2.0/24 --name b2 -ti weaveworks/ubuntu
+    host1$ docker run -e WEAVE_CIDR=net:10.2.2.0/24 --name b1 -ti alpine:latest
+    host2$ docker run -e WEAVE_CIDR=net:10.2.2.0/24 --name b2 -ti alpine:latest
 
 Ping each container to confirm that they can talk to each other, but not to the containers of our first subnet:
 
@@ -55,7 +55,7 @@ Ping each container to confirm that they can talk to each other, but not to the
 
 If required, a container can also be attached to multiple subnets when it is started using:
 
-    host1$ docker run -e WEAVE_CIDR="net:default net:10.2.2.0/24" -ti weaveworks/ubuntu
+    host1$ docker run -e WEAVE_CIDR="net:default net:10.2.2.0/24" -ti alpine:latest
 
 `net:default` is used to request the allocation of an address from the default subnet in addition to one from an explicitly specified range.
 

website/tasks/manage/dynamically-attach-containers.md

@@ -9,13 +9,13 @@ When containers may not know the network to which they will be attached, Weave N
 
 To illustrate...
 
-    host1$ C=$(docker run -e WEAVE_CIDR=none -dti weaveworks/ubuntu)
+    host1$ C=$(docker run -e WEAVE_CIDR=none -dti alpine:latest)
     host1$ weave attach $C
     10.2.1.3
 
 where,
 
- *  `C=$(docker run -e WEAVE_CIDR=none -dti weaveworks/ubuntu)` starts a container and assigns its ID to a variable
+ *  `C=$(docker run -e WEAVE_CIDR=none -dti alpine:latest)` starts a container and assigns its ID to a variable
  *  `weave attach` – the Weave Net command to attach to the specified container
  *  `10.2.1.3` - the allocated IP address output by `weave attach`, in this case in the default subnet
 
@@ -25,7 +25,7 @@ If `weave attach` sees the container has a hostname with a
 domain-name, it will add those into WeaveDNS (unless you turn this off
 with the `--without-dns` argument).
 
-    host1$ docker run -dti --name=c1 --hostname=c1.weave.local weaveworks/ubuntu
+    host1$ docker run -dti --name=c1 --hostname=c1.weave.local alpine:latest
     host1$ weave attach c1
     10.32.0.1
     host1$ weave dns-lookup c1

website/tasks/weave-docker-api/automatic-discovery-proxy.md

@@ -38,7 +38,7 @@ For example, you can launch the proxy using all three flags, as follows:
 
 After launching the Weave Net proxy with these flags, running a container named `aws-12798186823-foo` without labels results in weaveDNS registering the hostname `my-app-foo` and not `aws-12798186823-foo`.
 
-    host1$ docker run -ti --name=aws-12798186823-foo weaveworks/ubuntu ping my-app-foo
+    host1$ docker run -ti --name=aws-12798186823-foo alpine:latest ping my-app-foo
     PING my-app-foo.weave.local (10.32.0.2) 56(84) bytes of data.
     64 bytes from my-app-foo.weave.local (10.32.0.2): icmp_seq=1 ttl=64 time=0.027 ms
     64 bytes from my-app-foo.weave.local (10.32.0.2): icmp_seq=2 ttl=64 time=0.067 ms
@@ -46,7 +46,7 @@ After launching the Weave Net proxy with these flags, running a container named
 Also, running a container named `foo` with the label
 `hostname-label=aws-12798186823-foo` leads to the same hostname registration.
 
-    host1$ docker run -ti --name=foo --label=hostname-label=aws-12798186823-foo weaveworks/ubuntu ping my-app-foo
+    host1$ docker run -ti --name=foo --label=hostname-label=aws-12798186823-foo alpine:latest ping my-app-foo
     PING my-app-foo.weave.local (10.32.0.2) 56(84) bytes of data.
     64 bytes from my-app-foo.weave.local (10.32.0.2): icmp_seq=1 ttl=64 time=0.031 ms
     64 bytes from my-app-foo.weave.local (10.32.0.2): icmp_seq=2 ttl=64 time=0.042 ms

website/tasks/weave-docker-api/ipam-proxy.md

@@ -9,16 +9,16 @@ If [automatic IP address allocation]({{ '/tasks/ipam/ipam' | relative_url }}) is
 then containers started via the proxy are automatically assigned an IP address, *without having to specify any
 special environment variables or any other options*.
 
-    host1$ docker run -ti weaveworks/ubuntu
+    host1$ docker run -ti alpine:latest
 
 To use a specific subnet, you can pass a `WEAVE_CIDR` to the container, for example:
 
-    host1$ docker run -ti -e WEAVE_CIDR=net:10.32.2.0/24 weaveworks/ubuntu
+    host1$ docker run -ti -e WEAVE_CIDR=net:10.32.2.0/24 alpine:latest
 
 To start a container without connecting it to the Weave network, pass
 `WEAVE_CIDR=none`, for example:
 
-    host1$ docker run -ti -e WEAVE_CIDR=none weaveworks/ubuntu
+    host1$ docker run -ti -e WEAVE_CIDR=none alpine:latest
 
 ### Disabling Automatic IP Address Allocation
 
@@ -34,7 +34,7 @@ Containers started with a `WEAVE_CIDR` environment variable are handled as befor
 To automatically assign an address in this mode, start the
 container with a blank `WEAVE_CIDR`, for example:
 
-    host1$ docker run -ti -e WEAVE_CIDR="" weaveworks/ubuntu
+    host1$ docker run -ti -e WEAVE_CIDR="" alpine:latest
 
 **See Also**
 

website/tasks/weave-docker-api/using-proxy.md

@@ -17,17 +17,17 @@ Weave network.
 
 To create and start a container via the Weave Net proxy run:
 
-    host1$ docker run -ti weaveworks/ubuntu
+    host1$ docker run -ti alpine:latest
 
 or, equivalently run:
 
-    host1$ docker create -ti --name=foo weaveworks/ubuntu
+    host1$ docker create -ti --name=foo alpine:latest
     host1$ docker start foo
 
 Specific IP addresses and networks can be supplied in the `WEAVE_CIDR`
 environment variable, for example:
 
-    host1$ docker run -e WEAVE_CIDR=10.2.1.1/24 -ti weaveworks/ubuntu
+    host1$ docker run -e WEAVE_CIDR=10.2.1.1/24 -ti alpine:latest
 
 Multiple IP addresses and networks can be supplied in the `WEAVE_CIDR`
 variable by space-separating them, as in

website/tasks/weavedns/load-balance-fault-weavedns.md

@@ -16,7 +16,7 @@ some ping tests.
 ```
 host2$ weave launch $HOST1
 host2$ eval $(weave env)
-host2$ docker run -dti --name=pingme weaveworks/ubuntu
+host2$ docker run -dti --name=pingme alpine:latest
 
 root@ubuntu:/# ping -nq -c 1 pingme
 PING pingme.weave.local (10.32.0.2) 56(84) bytes of data.

website/tasks/weavedns/managing-domains-weavedns.md

@@ -26,7 +26,7 @@ behaviour.
 docker run -ti \
   --dns-search=zone1.weave.local --dns-search=zone2.weave.local \
   --dns-search=corp1.com --dns-search=corp2.com \
-  --dns-search=weave.local weaveworks/ubuntu
+  --dns-search=weave.local alpine:latest
 ```
 
 ## <a name="local-domain"></a>Using a different local domain

website/tasks/weavedns/managing-entries-weavedns.md

@@ -17,7 +17,7 @@ If you want to give the container a name in DNS *other* than its
 hostname, you can register it using the `dns-add` command. For example:
 
 ```
-$ C=$(docker run -ti weaveworks/ubuntu)
+$ C=$(docker run -ti alpine:latest)
 $ weave dns-add $C -h pingme2.weave.local
 ```
 

website/tasks/weavedns/weavedns.md

@@ -28,8 +28,8 @@ resolution, and will register themselves if they either have a
 hostname in the weaveDNS domain (`weave.local` by default) or are given an explicit container name:
 
 ```
-host1$ docker run -dti --name=pingme weaveworks/ubuntu
-host1$ docker run -ti  --hostname=ubuntu.weave.local weaveworks/ubuntu
+host1$ docker run -dti --name=pingme alpine:latest
+host1$ docker run -ti  --hostname=ubuntu.weave.local alpine:latest
 root@ubuntu:/# ping pingme
 ...
 ```
@@ -37,8 +37,8 @@ root@ubuntu:/# ping pingme
 Moreover, weaveDNS always register all network aliases (--network-alias option to docker run).
 
 ```
-host1$ docker run --network weave --network-alias pingme --network-alias pingme2 -dti weaveworks/ubuntu
-host1$ docker run --network weave --hostname=ubuntu.weave.local -ti weaveworks/ubuntu
+host1$ docker run --network weave --network-alias pingme --network-alias pingme2 -dti alpine:latest
+host1$ docker run --network weave --hostname=ubuntu.weave.local -ti alpine:latest
 root@ubuntu:/# ping pingme
 ...
 root@ubuntu:/# ping pingme2