Merge branch 'weave_1.1_readme_updates'

README.md

@@ -67,8 +67,8 @@ two containers, one on each host.
 
 On $HOST1 we run:
 
-    host1$ weave launch && weave launch-dns && weave launch-proxy
-    host1$ eval $(weave proxy-env)
+    host1$ weave launch
+    host1$ eval $(weave env)
     host1$ docker run --name a1 -ti ubuntu
 
 > NB: If the first command results in an error like
@@ -81,21 +81,18 @@ On $HOST1 we run:
 > `sudo`, since some commands modify environment entries and hence
 > they all need to be executed from the same shell.
 
-The first line runs the weave router, DNS and Docker API proxy, each
-in their own container. The second line sets the `DOCKER_HOST`
-environment variable to point to the proxy, so that containers
-launched via the docker command line are automatically attached to the
-weave network. Finally, we run our application container; this happens
-via the proxy so it is automatically allocated an IP address and
-registered in DNS.
+The first line runs weave. The second line configures our environment
+so that containers launched via the docker command line are
+automatically attached to the weave network. Finally, we run our
+application container.
 
 That's it! If our application consists of more than one container on
 this host we simply launch them with `docker run` as appropriate.
 
 Next we repeat similar steps on `$HOST2`...
 
-    host2$ weave launch $HOST1 && weave launch-dns && weave launch-proxy
-    host2$ eval $(weave proxy-env)
+    host2$ weave launch $HOST1
+    host2$ eval $(weave env)
     host2$ docker run --name a2 -ti ubuntu
 
 The only difference, apart from the name of the application container,
@@ -113,11 +110,10 @@ available. Also, we can tell weave to connect to multiple peers by
 supplying multiple addresses, separated by spaces. And we can
 [add peers dynamically](http://docs.weave.works/weave/latest_release/features.html#dynamic-topologies).
 
-The router, DNS and Docker API proxy need to be started once per
-host. The relevant container images are pulled down on demand, but if
-you wish you can preload them by running `weave setup` - this is
-particularly useful for automated deployments, and ensures that there
-are no delays during later operations.
+Weave must be started once per host. The relevant container images are
+pulled down on demand, but if you wish you can preload them by running
+`weave setup` - this is particularly useful for automated deployments,
+and ensures that there are no delays during later operations.
 
 Now that we've got everything set up, let's see whether our containers
 can talk to each other...