docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Canary info

This commit is contained in:
paigehargrave 2019-03-27 08:04:13 -04:00 committed by GitHub
parent 830fc89396
commit 397da33f05
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 13 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
ee/ucp/interlock/usage/canary.md
View File

@ -4,16 +4,17 @@ description: Learn how to do canary deployments for your Docker swarm services
keywords: routing, proxy keywords: routing, proxy
--- ---
In this example we will publish a service and deploy an updated service as canary instances. # Publishing a service as a canary instance
The following example publishes a service as a canary instance.
First we will create an overlay network so that service traffic is isolated and secure: First, create an overlay network to isolate and secure service traffic:
```bash ```bash
$> docker network create -d overlay demo $> docker network create -d overlay demo
1se1glh749q1i4pw0kf26mfx5 1se1glh749q1i4pw0kf26mfx5
``` ```
Next we will create the initial service: Next, create the initial service:
```bash ```bash
$> docker service create \ $> docker service create \
@ -27,8 +28,8 @@ $> docker service create \
ehazlett/docker-demo ehazlett/docker-demo
``` ```
Interlock will detect once the service is available and publish it. Once the tasks are running Interlock detects when the service is available and publishes it.After tasks are running
and the proxy service has been updated the application should be available via `http://demo.local`: and the proxy service is updated, the application is available via `http://demo.local`:
```bash ```bash
$> curl -vs -H "Host: demo.local" http://127.0.0.1/ping $> curl -vs -H "Host: demo.local" http://127.0.0.1/ping
@ -56,9 +57,10 @@ $> curl -vs -H "Host: demo.local" http://127.0.0.1/ping
{"instance":"df20f55fc943","version":"0.1","metadata":"demo-version-1","request_id":"f884cf37e8331612b8e7630ad0ee4e0d"} {"instance":"df20f55fc943","version":"0.1","metadata":"demo-version-1","request_id":"f884cf37e8331612b8e7630ad0ee4e0d"}
``` ```
Notice the `metadata` with `demo-version-1`. Notice `metadata` is specified with `demo-version-1`.
Now we will deploy a "new" version: # Deploying an updated service as a canary instance
The following example deploys an updated service as a canary instance:
```bash ```bash
$> docker service create \ $> docker service create \
@ -72,8 +74,8 @@ $> docker service create \
ehazlett/docker-demo ehazlett/docker-demo
``` ```
Since this has a replica of one (1) and the initial version has four (4) replicas 20% of application traffic Since this has a replica of one (1), and the initial version has four (4) replicas, 20% of application traffic
will be sent to `demo-version-2`: is sent to `demo-version-2`:
```bash ```bash
$> curl -vs -H "Host: demo.local" http://127.0.0.1/ping $> curl -vs -H "Host: demo.local" http://127.0.0.1/ping
@ -88,7 +90,7 @@ $> curl -vs -H "Host: demo.local" http://127.0.0.1/ping
{"instance":"c2a686ae5694","version":"0.1","metadata":"demo-version-1","request_id":"724c21d0fb9d7e265821b3c95ed08b61"} {"instance":"c2a686ae5694","version":"0.1","metadata":"demo-version-1","request_id":"724c21d0fb9d7e265821b3c95ed08b61"}
``` ```
To increase traffic to the new version add more replicas with `docker scale`: To increase traffic to the new version, add more replicas with `docker scale`:
```bash ```bash
$> docker service scale demo-v2=4 $> docker service scale demo-v2=4
@ -102,6 +104,5 @@ $> docker service scale demo-v1=0
demo-v1 demo-v1
``` ```
This will route all application traffic to the new version. If you need to rollback, simply scale the v1 service This routes all application traffic to the new version. If you need to rollback, simply scale the v1 service
back up and v2 down. back up and v2 down.