Update README.rd, Add missing information on ADDITONAL_SERVICES for Swarm Setups

There are limitations on using links for identification of load balances services when using Swarm with overlay network.
Swarm will still try to schedule linked services together on same node.

There is already a second option which is to pass in load balanced service names via the ADDITIONAL_SERVICES envvar instead of using links but was not really documented. This removes some of the issues legacy links has when using Swarm.
I was gonna add a non-link dependent option but someone already did the work ;)

Author: dgilling

README.md

@@ -76,7 +76,7 @@ Legacy link refers to the link created before docker 1.10, and the link created
 **Note**: Any link alias sharing the same prefix and followed by "-/_" with an integer is considered to be from the same service. For example: `web-1` and `web-2` belong to service `web`, `app_1` and `app_2` are from service `app`, but `app1` and `web2` are from different services.
 
 
-### Running with Docker Compose v2(new links, compatible with Docker Swarm)
+### Running with Docker Compose v2(new links)
 
 Docker Compose 1.6 supports a new format of the compose file. In the new version(v2), the old link that injects environment variables is deprecated.
 
@@ -86,7 +86,6 @@ Similar to using legacy links, here list some differences that you need to notic
 - A link is required in order to ensure that dockercloud/haproxy is aware of which service it needs to balance, although links are not needed for service discovery since docker 1.10. Linked aliases are not required.
 - DO not overwrite `HOSTNAME` environment variable in `dockercloud/haproxy container`.
 - As it is the case on Docker Cloud, auto reconfiguration is supported when the linked services scales or/and the linked container starts/stops.
-- This image is also compatible with Docker Swarm, and supports the docker native `overlay` network across multi-hosts.
 
 ##### example of docker-compose.yml running in linux:
 
@@ -124,6 +123,41 @@ Similar to using legacy links, here list some differences that you need to notic
 
 Once the stack is up, you can scale the web service using `docker-compose scale web=3`. dockercloud/haproxy will automatically reload its configuration.
 
+#### Running with Docker Compose v2 and Swarm (using envvar)
+When using links like previous section, the Docker Swarm scheduler can be too restrictive. 
+Even with overlay network, swarm (As of 1.1.0) will attempt to schedule haproxy on the same node as the linked service due to legacy links behavior. 
+This can cause unwanted scheduling patterns or errors such as "Unable to find a node fulfilling all dependencies..."
+
+Since Compose V2 allows discovery through the service names, Dockercloud haproxy only needs the links to indentify which service should be load balanced.
+
+A second option is to use the `ADDITIONAL_SERVICES` variable for indentification of services.
+
+- Set the `ADDITIONAL_SERVICES` env variable to your linked services.
+- You also want to set depends_on to ensure the web service is started before haproxy so that the hostname can be resolved. This controls scheduling order but not location.
+- The container still needs access to the docker daemon to get load balanced containers' configs.
+- If any trouble with haproxy not updating the config, try running reload.sh or set the `DEBUG` envvar.
+- This image is also compatible with Docker Swarm, and supports the docker native `overlay` network across multi-hosts.
+
+##### example of docker-compose.yml in 'project_dir' directory running in linux:
+
+	version: '2'
+	services:
+	  web:
+	    image: dockercloud/hello-world
+	  blog:
+	    image: dockercloud/hello-world
+	  lb:
+	    image: dockercloud/haproxy
+    	   depends_on:
+             - web
+             - blog
+           environment:
+             - ADDITIONAL_SERVICES=project_dir:web,project_dir:blog
+	    volumes:
+	      - /var/run/docker.sock:/var/run/docker.sock
+	    ports:
+	      - 80:80
+
 ## Configuration
 
 ### Global and default settings of HAProxy###