Merge pull request docker#191 from ManoMarks/master

Mano Marks · web-flow · commit fed18466911e · 2017-03-09T10:55:44.000-08:00
updating a few references to 1.12
diff --git a/networking/A1-network-basics.md b/networking/A1-network-basics.md
@@ -62,7 +62,7 @@ NETWORK ID          NAME                DRIVER              SCOPE
 ef4896538cc7        none                null                local
 ```
 
-The output above shows the container networks that are created as part of a standard installation of Docker 1.12.
+The output above shows the container networks that are created as part of a standard installation of Docker.
 
 New networks that you create will also show up in the output of the `docker network ls` command.
 
diff --git a/networking/concepts/06-overlay-networks.md b/networking/concepts/06-overlay-networks.md
@@ -89,6 +89,6 @@ Two interfaces have been created inside the container that correspond to two bri
 
 
 
-> The Docker Overlay driver has existed since Docker Engine 1.9, and an external K/V store was required to manage state for the network. Docker Engine 1.12 integrated the control plane state into Docker Engine so that an external store is no longer required. 1.12 also introduced several new features including encryption and service load balancing. Networking features that are introduced require a Docker Engine version that supports them, and using these features with older versions of Docker Engine is not supported.
+> The Docker Overlay driver has existed since Docker Engine 1.9, and an external K/V store was required to manage state for the network. Docker 1.12 integrated the control plane state into Docker Engine so that an external store is no longer required. 1.12 also introduced several new features including encryption and service load balancing. Networking features that are introduced require a Docker Engine version that supports them, and using these features with older versions of Docker Engine is not supported.
 
 Next: **[MACVLAN](07-macvlan.md)**
diff --git a/networking/concepts/10-load-balancing.md b/networking/concepts/10-load-balancing.md
@@ -1,6 +1,6 @@
 ##<a name="lb"></a>Load Balancing Design Considerations
 
-Load balancing is a major requirement in modern, distributed applications. The new Docker Swarm mode introduced in 1.12 comes with a native internal and external load balancing functionalities that utilize both `iptables` and `ipvs`, a transport-layer load balancing inside the Linux kernel.
+Load balancing is a major requirement in modern, distributed applications. Docker Swarm mode introduced in 1.12 comes with a native internal and external load balancing functionalities that utilize both `iptables` and `ipvs`, a transport-layer load balancing inside the Linux kernel.
 
 ###Internal Load Balancing
 When services are created in a Docker Swarm cluster, they are automatically assigned a Virtual IP (VIP) that is part of the service's network. The VIP is returned when resolving the service's name. Traffic to that VIP will be automatically sent to all healthy tasks of that service across the overlay network. This approach avoids any client-side load balancing because only a single IP is returned to the client. Docker takes care of routing and equally distributing the traffic across the healthy service tasks.
@@ -38,7 +38,7 @@ $ docker service inspect myservice
 ###External Load Balancing (Docker Routing Mesh) 
 You can expose services externally by using the `--publish` flag when creating or updating the service. Publishing ports in Docker Swarm mode means that every node in your cluster will be listening on that port. But what happens if the service's task isn't on the node that is listening on that port?
 
-This is where routing mesh comes into play. Routing mesh is a new feature in Docker 1.12 that combines `ipvs` and `iptables` to create a powerful cluster-wide transport-layer (L4) load balancer. It allows all the Swarm nodes to accept connections on the services' published ports. When any Swarm node receives traffic destined to the published TCP/UDP port of a running `service`, it forwards it to service's VIP using a pre-defined overlay network called `ingress`. The `ingress` network behaves similarly to other overlay networks but its sole purpose is to transport mesh routing traffic from external clients to cluster services. It uses the same VIP-based internal load balancing as described in the previous section.
+This is where routing mesh comes into play. Routing mesh is a feature introduced in Docker 1.12 that combines `ipvs` and `iptables` to create a powerful cluster-wide transport-layer (L4) load balancer. It allows all the Swarm nodes to accept connections on the services' published ports. When any Swarm node receives traffic destined to the published TCP/UDP port of a running `service`, it forwards it to service's VIP using a pre-defined overlay network called `ingress`. The `ingress` network behaves similarly to other overlay networks but its sole purpose is to transport mesh routing traffic from external clients to cluster services. It uses the same VIP-based internal load balancing as described in the previous section.
 
 Once you launch services, you can create an external DNS record for your applications and map it to any or all Docker Swarm nodes. You do not need to worry about where your container is running as all nodes in your cluster look as one with the routing mesh routing feature.  
 
diff --git a/networking/concepts/11-security.md b/networking/concepts/11-security.md
@@ -12,7 +12,7 @@ Docker Swarm comes with integrated PKI. All managers and nodes in the Swarm have
 
 ###Securing the Data Plane
 
-In Docker Engine 1.12 Swarm mode the data path (e.g. application traffic) can be encrypted out-of-the-box. This feature uses IPSec tunnels to encrypt network traffic as it leaves the source container and decrypts it as it enters the destination container.  This ensure that your application traffic is highly secure when it's in transit regardless of the underlying networks. In a hybrid, multi-tenant, or multi-cloud environment, it is crucial to ensure data is secure as it traverses networks you might not have control over. 
+In Docker Swarm mode the data path (e.g. application traffic) can be encrypted out-of-the-box. This feature uses IPSec tunnels to encrypt network traffic as it leaves the source container and decrypts it as it enters the destination container.  This ensure that your application traffic is highly secure when it's in transit regardless of the underlying networks. In a hybrid, multi-tenant, or multi-cloud environment, it is crucial to ensure data is secure as it traverses networks you might not have control over. 
 
 This diagram illustrates how to secure communication between two containers running on different hosts in a Docker Swarm. 
 
diff --git a/networking/img/servicediscovery.png b/networking/img/servicediscovery.png
diff --git a/networking/scratch.md b/networking/scratch.md
@@ -11,7 +11,7 @@ When a new service (container) is created it should be able register itself with
 </p>
 
 
-The mechanisms that provide service discovery and load balancing can take many forms. They can be external service or provided natively within Docker without extra infrastructure. In Docker  1.12 automatic service discovery and load balancing is provided right out of the box by the Docker Engine. A service can be defined and traffic is load balanced via DNS to containers. DNS load balancing is covered later in this guide.
+The mechanisms that provide service discovery and load balancing can take many forms. They can be external service or provided natively within Docker without extra infrastructure. In Docker Swarm Mode automatic service discovery and load balancing is provided right out of the box. A service can be defined and traffic is load balanced via DNS to containers. DNS load balancing is covered later in this guide.
 
 External solutions for service discovery and/or load balancing is also possible and may be desired to levarage existing infrastructure or to take advantage of special features. Common external service discovery mechanisms include Consul, etcd, and Zookeeper. Common external load balancers include HAproxy, Nginx, F5, and many more. 
 <br>
diff --git a/swarm-mode/README.md b/swarm-mode/README.md
@@ -1,6 +1,6 @@
 # Docker Swarm Mode Tutorials
 
-[Docker Swarm Mode](https://docs.docker.com/engine/swarm/) is a feature included with Docker Engine 1.12. These tutorials are designed to help you quickly get started testing these new features.
+[Docker Swarm Mode](https://docs.docker.com/engine/swarm/) is a feature Docker introduced in 1.12. These tutorials are designed to help you quickly get started testing these new features.
 
 * [Docker Swarm Mode full tutorial](beginner-tutorial/README.md)
 * [Service deployment on a swarm in the Cloud](cloud-quick-start/README.md)
diff --git a/swarm-mode/beginner-tutorial/README.md b/swarm-mode/beginner-tutorial/README.md
@@ -116,13 +116,13 @@ bxn1iivy8w7faeugpep76w50j    worker3   Ready   Active
 You can also find all your machines by running
 ```
 $ docker-machine ls
-NAME       ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER    ERRORS
-manager1   -        virtualbox   Running   tcp://192.168.99.100:2376           v1.12.1   
-manager2   -        virtualbox   Running   tcp://192.168.99.101:2376           v1.12.1   
-manager3   -        virtualbox   Running   tcp://192.168.99.102:2376           v1.12.1   
-worker1    -        virtualbox   Running   tcp://192.168.99.103:2376           v1.12.1   
-worker2    -        virtualbox   Running   tcp://192.168.99.104:2376           v1.12.1   
-worker3    -        virtualbox   Running   tcp://192.168.99.105:2376           v1.12.1   
+NAME       ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER      ERRORS
+manager1   -        virtualbox   Running   tcp://192.168.99.100:2376           v17.03.0-ce   
+manager2   -        virtualbox   Running   tcp://192.168.99.101:2376           v17.03.0-ce 
+manager3   -        virtualbox   Running   tcp://192.168.99.102:2376           v17.03.0-ce
+worker1    -        virtualbox   Running   tcp://192.168.99.103:2376           v17.03.0-ce
+worker2    -        virtualbox   Running   tcp://192.168.99.104:2376           v17.03.0-ce
+worker3    -        virtualbox   Running   tcp://192.168.99.105:2376           v17.03.0-ce
 ```
 
 The next step is to create a service and list out the services. This creates a single service called `web` that runs the latest nginx:
@@ -331,7 +331,7 @@ Resources:
 Plugins:
   Network:		bridge, host, null, overlay
   Volume:		local
-Engine Version:		1.12.1
+Engine Version:		17.03.0-ce
 Engine Labels:
  - provider = virtualbox
  ```
diff --git a/swarm-mode/cloud-quick-start/README.md b/swarm-mode/cloud-quick-start/README.md
@@ -1,7 +1,6 @@
 # Service deployment on a swarm in the Cloud
 
-Script that create a swarm cluster and deploy a simple service.
-Swarm is created with Swarm mode of Engine 1.12. Can be created on
+Script that create a swarm cluster and deploy a simple service. The Swarm is created with Swarm mode using Docker 1.12 or higher. Can be created on
 * Virtualbox
 * Microsoft Azure
 * Digitalocean
@@ -86,10 +85,10 @@ List all Docker host created
 ```
 $ docker-machine ls
 NAME          ACTIVE   DRIVER         STATE     URL                         SWARM   DOCKER        ERRORS
-manager1      -        virtualbox     Running   tcp://192.168.99.100:2376           v1.12.0-rc2
-manager2      -        virtualbox     Running   tcp://192.168.99.101:2376           v1.12.0-rc2
-worker1       -        virtualbox     Running   tcp://192.168.99.102:2376           v1.12.0-rc2
-worker2       -        virtualbox     Running   tcp://192.168.99.103:2376           v1.12.0-rc2
+manager1      -        virtualbox     Running   tcp://192.168.99.100:2376           v17.03.0-ce
+manager2      -        virtualbox     Running   tcp://192.168.99.101:2376           v17.03.0-ce
+worker1       -        virtualbox     Running   tcp://192.168.99.102:2376           v17.03.0-ce
+worker2       -        virtualbox     Running   tcp://192.168.99.103:2376           v17.03.0-ce
 ```
 
 # Service details
diff --git a/windows/windows-containers/WindowsContainers.md b/windows/windows-containers/WindowsContainers.md
@@ -9,21 +9,21 @@ First, make sure the Docker installation is working:
 ```
 > docker version
 Client:
- Version:      1.12.2
- API version:  1.24
- Go version:   go1.6.3
- Git commit:   bb80604
- Built:        Tue Oct 11 05:27:08 2016
+ Version:      17.03.0-ce
+ API version:  1.26
+ Go version:   go1.7.5
+ Git commit:   60ccb22
+ Built:        Thu Feb 23 10:40:59 2017
  OS/Arch:      windows/amd64
- Experimental: true
 
 Server:
- Version:      1.12.2-cs2-ws-beta
- API version:  1.25
- Go version:   go1.7.1
- Git commit:   050b611
- Built:        Tue Oct 11 02:35:40 2016
+ Version:      17.03.0-ce
+ API version:  1.26 (minimum version 1.24)
+ Go version:   go1.7.5
+ Git commit:   60ccb22
+ Built:        Thu Feb 23 10:40:59 2017
  OS/Arch:      windows/amd64
+ Experimental: true
 ```
 
 Next, pull a base image that&rsquo;s compatible with the evaluation build, re-tag it and do a test-run:

Original file line number	Diff line number	Diff line change
`@@ -89,6 +89,6 @@ Two interfaces have been created inside the container that correspond to two bri`
`89`	`89`
`90`	`90`
`91`	`91`
`92`		-> The Docker Overlay driver has existed since Docker Engine 1.9, and an external K/V store was required to manage state for the network. Docker Engine 1.12 integrated the control plane state into Docker Engine so that an external store is no longer required. 1.12 also introduced several new features including encryption and service load balancing. Networking features that are introduced require a Docker Engine version that supports them, and using these features with older versions of Docker Engine is not supported.
	`92`	+> The Docker Overlay driver has existed since Docker Engine 1.9, and an external K/V store was required to manage state for the network. Docker 1.12 integrated the control plane state into Docker Engine so that an external store is no longer required. 1.12 also introduced several new features including encryption and service load balancing. Networking features that are introduced require a Docker Engine version that supports them, and using these features with older versions of Docker Engine is not supported.
`93`	`93`
`94`	`94`	`Next: [MACVLAN](07-macvlan.md)`