Browse code
bring dab into title and intro
Signed-off-by: Michael Friis <friism@gmail.com>
Michael Friis authored on 2016/06/20 13:27:55Showing 2 changed files
| 1 | 1 |
new file mode 100644 |
| ... | ... |
@@ -0,0 +1,170 @@ |
| 0 |
+# Docker Stacks and Distributed Application Bundles |
|
| 1 |
+ |
|
| 2 |
+## Overview |
|
| 3 |
+ |
|
| 4 |
+Docker Stacks and Distributed Application Bundles are experimental features introduced in Docker 1.12 and Docker Compose 1.8, alongside the concept of swarm mode, and Nodes and Services in the Engine API. |
|
| 5 |
+ |
|
| 6 |
+A Dockerfile can be built into an image, and containers can be created from that |
|
| 7 |
+image. Similarly, a docker-compose.yml can be built into a **distributed application bundle**, and **stacks** can be created from that bundle. In that sense, the bundle is a multi-services distributable image format. |
|
| 8 |
+ |
|
| 9 |
+As of Docker 1.12 and Compose 1.8, the features are experimental. Neither Docker Engine nor the Docker Registry support distribution of bundles. |
|
| 10 |
+ |
|
| 11 |
+## Producing a bundle |
|
| 12 |
+ |
|
| 13 |
+The easiest way to produce a bundle is to generate it using `docker-compose` |
|
| 14 |
+from an existing `docker-compose.yml`. Of course, that's just *one* possible way |
|
| 15 |
+to proceed, in the same way that `docker build` isn't the only way to produce a |
|
| 16 |
+Docker image. |
|
| 17 |
+ |
|
| 18 |
+From `docker-compose`: |
|
| 19 |
+ |
|
| 20 |
+ ```bash |
|
| 21 |
+ $ docker-compose bundle |
|
| 22 |
+ WARNING: Unsupported key 'network_mode' in services.nsqd - ignoring |
|
| 23 |
+ WARNING: Unsupported key 'links' in services.nsqd - ignoring |
|
| 24 |
+ WARNING: Unsupported key 'volumes' in services.nsqd - ignoring |
|
| 25 |
+ [...] |
|
| 26 |
+ Wrote bundle to vossibility-stack.dsb |
|
| 27 |
+ ``` |
|
| 28 |
+ |
|
| 29 |
+## Creating a stack from a bundle |
|
| 30 |
+ |
|
| 31 |
+A stack is created using the `docker deploy` command: |
|
| 32 |
+ |
|
| 33 |
+ ```bash |
|
| 34 |
+ # docker deploy --help |
|
| 35 |
+ |
|
| 36 |
+ Usage: docker deploy [OPTIONS] STACK |
|
| 37 |
+ |
|
| 38 |
+ Create and update a stack |
|
| 39 |
+ |
|
| 40 |
+ Options: |
|
| 41 |
+ -f, --bundle string Path to a bundle (Default: STACK.dsb) |
|
| 42 |
+ --help Print usage |
|
| 43 |
+ ``` |
|
| 44 |
+ |
|
| 45 |
+Let's deploy the stack created before: |
|
| 46 |
+ |
|
| 47 |
+ ```bash |
|
| 48 |
+ # docker deploy vossibility-stack |
|
| 49 |
+ Loading bundle from vossibility-stack.dsb |
|
| 50 |
+ Creating service vossibility-stack_elasticsearch |
|
| 51 |
+ Creating service vossibility-stack_kibana |
|
| 52 |
+ Creating service vossibility-stack_logstash |
|
| 53 |
+ Creating service vossibility-stack_lookupd |
|
| 54 |
+ Creating service vossibility-stack_nsqd |
|
| 55 |
+ Creating service vossibility-stack_vossibility-collector |
|
| 56 |
+ ``` |
|
| 57 |
+ |
|
| 58 |
+We can verify that services were correctly created: |
|
| 59 |
+ |
|
| 60 |
+ ```bash |
|
| 61 |
+ # docker service ls |
|
| 62 |
+ ID NAME REPLICAS IMAGE |
|
| 63 |
+ COMMAND |
|
| 64 |
+ 29bv0vnlm903 vossibility-stack_lookupd 1 nsqio/nsq@sha256:eeba05599f31eba418e96e71e0984c3dc96963ceb66924dd37a47bf7ce18a662 /nsqlookupd |
|
| 65 |
+ 4awt47624qwh vossibility-stack_nsqd 1 nsqio/nsq@sha256:eeba05599f31eba418e96e71e0984c3dc96963ceb66924dd37a47bf7ce18a662 /nsqd --data-path=/data --lookupd-tcp-address=lookupd:4160 |
|
| 66 |
+ 4tjx9biia6fs vossibility-stack_elasticsearch 1 elasticsearch@sha256:12ac7c6af55d001f71800b83ba91a04f716e58d82e748fa6e5a7359eed2301aa |
|
| 67 |
+ 7563uuzr9eys vossibility-stack_kibana 1 kibana@sha256:6995a2d25709a62694a937b8a529ff36da92ebee74bafd7bf00e6caf6db2eb03 |
|
| 68 |
+ 9gc5m4met4he vossibility-stack_logstash 1 logstash@sha256:2dc8bddd1bb4a5a34e8ebaf73749f6413c101b2edef6617f2f7713926d2141fe logstash -f /etc/logstash/conf.d/logstash.conf |
|
| 69 |
+ axqh55ipl40h vossibility-stack_vossibility-collector 1 icecrime/vossibility-collector@sha256:f03f2977203ba6253988c18d04061c5ec7aab46bca9dfd89a9a1fa4500989fba --config /config/config.toml --debug |
|
| 70 |
+ ``` |
|
| 71 |
+ |
|
| 72 |
+## Managing stacks |
|
| 73 |
+ |
|
| 74 |
+Tasks are managed using the `docker stack` command: |
|
| 75 |
+ |
|
| 76 |
+ ```bash |
|
| 77 |
+ # docker stack --help |
|
| 78 |
+ |
|
| 79 |
+ Usage: docker stack COMMAND |
|
| 80 |
+ |
|
| 81 |
+ Manage Docker stacks |
|
| 82 |
+ |
|
| 83 |
+ Options: |
|
| 84 |
+ --help Print usage |
|
| 85 |
+ |
|
| 86 |
+ Commands: |
|
| 87 |
+ config Print the stack configuration |
|
| 88 |
+ deploy Create and update a stack |
|
| 89 |
+ rm Remove the stack |
|
| 90 |
+ tasks List the tasks in the stack |
|
| 91 |
+ |
|
| 92 |
+ Run 'docker stack COMMAND --help' for more information on a command. |
|
| 93 |
+ ``` |
|
| 94 |
+ |
|
| 95 |
+## Bundle file format |
|
| 96 |
+ |
|
| 97 |
+Distributed application bundles are described in a JSON format. When bundles are persisted as files, the file extension is `.dab` (Docker 1.12RC2 tools use `.dsb` for the file extension—this will be updated in the next release client). |
|
| 98 |
+ |
|
| 99 |
+A bundle has two top-level fields: `version` and `services`. The version used by Docker 1.12 tools is `0.1`. |
|
| 100 |
+ |
|
| 101 |
+`services` in the bundle are the services that comprise the app. They correspond to the new `Service` object introduced in the 1.12 Docker Engine API. |
|
| 102 |
+ |
|
| 103 |
+A service has the following fields: |
|
| 104 |
+ |
|
| 105 |
+<dl> |
|
| 106 |
+ <dt> |
|
| 107 |
+ Image (required) <code>string</code> |
|
| 108 |
+ </dt> |
|
| 109 |
+ <dd> |
|
| 110 |
+The image that the service will run. Docker images should be referenced with full content hash to fully specify the deployment artifact for the service. Example: <code>postgres@sha256:f76245b04ddbcebab5bb6c28e76947f49222c99fec4aadb0bb1c24821a9e83ef</code> |
|
| 111 |
+ </dd> |
|
| 112 |
+ |
|
| 113 |
+ <dt> |
|
| 114 |
+ Command <code>[]string</code> |
|
| 115 |
+ </dt> |
|
| 116 |
+ <dd> |
|
| 117 |
+ Command to run in service containers. |
|
| 118 |
+ </dd> |
|
| 119 |
+ |
|
| 120 |
+ <dt> |
|
| 121 |
+ Args <code>[]string</code> |
|
| 122 |
+ </dt> |
|
| 123 |
+ <dd> |
|
| 124 |
+ Arguments passed to the service containers. |
|
| 125 |
+ </dd> |
|
| 126 |
+ |
|
| 127 |
+ <dt> |
|
| 128 |
+ Env <code>[]string</code> |
|
| 129 |
+ </dt> |
|
| 130 |
+ <dd> |
|
| 131 |
+ Environment variables. |
|
| 132 |
+ </dd> |
|
| 133 |
+ |
|
| 134 |
+ <dt> |
|
| 135 |
+ Labels <code>map[string]string</code> |
|
| 136 |
+ </dt> |
|
| 137 |
+ <dd> |
|
| 138 |
+ Labels used for setting meta data on services. |
|
| 139 |
+ </dd> |
|
| 140 |
+ |
|
| 141 |
+ <dt> |
|
| 142 |
+ Ports <code>[]Port</code> |
|
| 143 |
+ </dt> |
|
| 144 |
+ <dd> |
|
| 145 |
+ Service ports (composed of `Port` (`int`) and `Protocol` (`string`). A service description can only specify the container port to be exposed. These ports can be mapped on runtime hosts at the operator's discretion. |
|
| 146 |
+ </dd> |
|
| 147 |
+ |
|
| 148 |
+ <dt> |
|
| 149 |
+ WorkingDir <code>string</code> |
|
| 150 |
+ </dt> |
|
| 151 |
+ <dd> |
|
| 152 |
+ Working directory inside the service containers. |
|
| 153 |
+ </dd> |
|
| 154 |
+ |
|
| 155 |
+ <dt> |
|
| 156 |
+ User <code>string</code> |
|
| 157 |
+ </dt> |
|
| 158 |
+ <dd> |
|
| 159 |
+ Username or UID (format: <name|uid>[:<group|gid>]). |
|
| 160 |
+ </dd> |
|
| 161 |
+ |
|
| 162 |
+ <dt> |
|
| 163 |
+ Networks <code>[]string</code> |
|
| 164 |
+ </dt> |
|
| 165 |
+ <dd> |
|
| 166 |
+ Networks that the service containers should be connected to. An entity deploying a bundle should create networks as needed. |
|
| 167 |
+ </dd> |
|
| 168 |
+</dl> |
|
| 169 |
+ |
| 0 | 170 |
deleted file mode 100644 |
| ... | ... |
@@ -1,171 +0,0 @@ |
| 1 |
-# Docker Stacks |
|
| 2 |
- |
|
| 3 |
-## Overview |
|
| 4 |
- |
|
| 5 |
-Docker Stacks are an experimental feature introduced in Docker 1.12, alongside |
|
| 6 |
-the concept of swarm mode, and Nodes and Services in the Engine API. |
|
| 7 |
- |
|
| 8 |
-A Dockerfile can be built into an image, and containers can be created from that |
|
| 9 |
-image. Similarly, a docker-compose.yml can be built into a **distributed application bundle**, and **stacks** can be created from that bundle. In that sense, the bundle is a multi-services distributable image format. |
|
| 10 |
- |
|
| 11 |
-As of Docker 1.12, the feature is experimental. Neither Docker Engine nor the Docker Registry support distribution of bundles. |
|
| 12 |
- |
|
| 13 |
-## Producing a bundle |
|
| 14 |
- |
|
| 15 |
-The easiest way to produce a bundle is to generate it using `docker-compose` |
|
| 16 |
-from an existing `docker-compose.yml`. Of course, that's just *one* possible way |
|
| 17 |
-to proceed, in the same way that `docker build` isn't the only way to produce a |
|
| 18 |
-Docker image. |
|
| 19 |
- |
|
| 20 |
-From `docker-compose`: |
|
| 21 |
- |
|
| 22 |
- ```bash |
|
| 23 |
- $ docker-compose bundle |
|
| 24 |
- WARNING: Unsupported key 'network_mode' in services.nsqd - ignoring |
|
| 25 |
- WARNING: Unsupported key 'links' in services.nsqd - ignoring |
|
| 26 |
- WARNING: Unsupported key 'volumes' in services.nsqd - ignoring |
|
| 27 |
- [...] |
|
| 28 |
- Wrote bundle to vossibility-stack.dsb |
|
| 29 |
- ``` |
|
| 30 |
- |
|
| 31 |
-## Creating a stack from a bundle |
|
| 32 |
- |
|
| 33 |
-A stack is created using the `docker deploy` command: |
|
| 34 |
- |
|
| 35 |
- ```bash |
|
| 36 |
- # docker deploy --help |
|
| 37 |
- |
|
| 38 |
- Usage: docker deploy [OPTIONS] STACK |
|
| 39 |
- |
|
| 40 |
- Create and update a stack |
|
| 41 |
- |
|
| 42 |
- Options: |
|
| 43 |
- -f, --bundle string Path to a bundle (Default: STACK.dsb) |
|
| 44 |
- --help Print usage |
|
| 45 |
- ``` |
|
| 46 |
- |
|
| 47 |
-Let's deploy the stack created before: |
|
| 48 |
- |
|
| 49 |
- ```bash |
|
| 50 |
- # docker deploy vossibility-stack |
|
| 51 |
- Loading bundle from vossibility-stack.dsb |
|
| 52 |
- Creating service vossibility-stack_elasticsearch |
|
| 53 |
- Creating service vossibility-stack_kibana |
|
| 54 |
- Creating service vossibility-stack_logstash |
|
| 55 |
- Creating service vossibility-stack_lookupd |
|
| 56 |
- Creating service vossibility-stack_nsqd |
|
| 57 |
- Creating service vossibility-stack_vossibility-collector |
|
| 58 |
- ``` |
|
| 59 |
- |
|
| 60 |
-We can verify that services were correctly created: |
|
| 61 |
- |
|
| 62 |
- ```bash |
|
| 63 |
- # docker service ls |
|
| 64 |
- ID NAME REPLICAS IMAGE |
|
| 65 |
- COMMAND |
|
| 66 |
- 29bv0vnlm903 vossibility-stack_lookupd 1 nsqio/nsq@sha256:eeba05599f31eba418e96e71e0984c3dc96963ceb66924dd37a47bf7ce18a662 /nsqlookupd |
|
| 67 |
- 4awt47624qwh vossibility-stack_nsqd 1 nsqio/nsq@sha256:eeba05599f31eba418e96e71e0984c3dc96963ceb66924dd37a47bf7ce18a662 /nsqd --data-path=/data --lookupd-tcp-address=lookupd:4160 |
|
| 68 |
- 4tjx9biia6fs vossibility-stack_elasticsearch 1 elasticsearch@sha256:12ac7c6af55d001f71800b83ba91a04f716e58d82e748fa6e5a7359eed2301aa |
|
| 69 |
- 7563uuzr9eys vossibility-stack_kibana 1 kibana@sha256:6995a2d25709a62694a937b8a529ff36da92ebee74bafd7bf00e6caf6db2eb03 |
|
| 70 |
- 9gc5m4met4he vossibility-stack_logstash 1 logstash@sha256:2dc8bddd1bb4a5a34e8ebaf73749f6413c101b2edef6617f2f7713926d2141fe logstash -f /etc/logstash/conf.d/logstash.conf |
|
| 71 |
- axqh55ipl40h vossibility-stack_vossibility-collector 1 icecrime/vossibility-collector@sha256:f03f2977203ba6253988c18d04061c5ec7aab46bca9dfd89a9a1fa4500989fba --config /config/config.toml --debug |
|
| 72 |
- ``` |
|
| 73 |
- |
|
| 74 |
-## Managing stacks |
|
| 75 |
- |
|
| 76 |
-Tasks are managed using the `docker stack` command: |
|
| 77 |
- |
|
| 78 |
- ```bash |
|
| 79 |
- # docker stack --help |
|
| 80 |
- |
|
| 81 |
- Usage: docker stack COMMAND |
|
| 82 |
- |
|
| 83 |
- Manage Docker stacks |
|
| 84 |
- |
|
| 85 |
- Options: |
|
| 86 |
- --help Print usage |
|
| 87 |
- |
|
| 88 |
- Commands: |
|
| 89 |
- config Print the stack configuration |
|
| 90 |
- deploy Create and update a stack |
|
| 91 |
- rm Remove the stack |
|
| 92 |
- tasks List the tasks in the stack |
|
| 93 |
- |
|
| 94 |
- Run 'docker stack COMMAND --help' for more information on a command. |
|
| 95 |
- ``` |
|
| 96 |
- |
|
| 97 |
-## Bundle file format |
|
| 98 |
- |
|
| 99 |
-Distributed application bundles are described in a JSON format. When bundles are persisted as files, the file extension is `.dab` (Docker 1.12RC2 tools use `.dsb` for the file extension—this will be updated in the next release client). |
|
| 100 |
- |
|
| 101 |
-A bundle has two top-level fields: `version` and `services`. The version used by Docker 1.12 tools is `0.1`. |
|
| 102 |
- |
|
| 103 |
-`services` in the bundle are the services that comprise the app. They correspond to the new `Service` object introduced in the 1.12 Docker Engine API. |
|
| 104 |
- |
|
| 105 |
-A service has the following fields: |
|
| 106 |
- |
|
| 107 |
-<dl> |
|
| 108 |
- <dt> |
|
| 109 |
- Image (required) <code>string</code> |
|
| 110 |
- </dt> |
|
| 111 |
- <dd> |
|
| 112 |
-The image that the service will run. Docker images should be referenced with full content hash to fully specify the deployment artifact for the service. Example: <code>postgres@sha256:f76245b04ddbcebab5bb6c28e76947f49222c99fec4aadb0bb1c24821a9e83ef</code> |
|
| 113 |
- </dd> |
|
| 114 |
- |
|
| 115 |
- <dt> |
|
| 116 |
- Command <code>[]string</code> |
|
| 117 |
- </dt> |
|
| 118 |
- <dd> |
|
| 119 |
- Command to run in service containers. |
|
| 120 |
- </dd> |
|
| 121 |
- |
|
| 122 |
- <dt> |
|
| 123 |
- Args <code>[]string</code> |
|
| 124 |
- </dt> |
|
| 125 |
- <dd> |
|
| 126 |
- Arguments passed to the service containers. |
|
| 127 |
- </dd> |
|
| 128 |
- |
|
| 129 |
- <dt> |
|
| 130 |
- Env <code>[]string</code> |
|
| 131 |
- </dt> |
|
| 132 |
- <dd> |
|
| 133 |
- Environment variables. |
|
| 134 |
- </dd> |
|
| 135 |
- |
|
| 136 |
- <dt> |
|
| 137 |
- Labels <code>map[string]string</code> |
|
| 138 |
- </dt> |
|
| 139 |
- <dd> |
|
| 140 |
- Labels used for setting meta data on services. |
|
| 141 |
- </dd> |
|
| 142 |
- |
|
| 143 |
- <dt> |
|
| 144 |
- Ports <code>[]Port</code> |
|
| 145 |
- </dt> |
|
| 146 |
- <dd> |
|
| 147 |
- Service ports (composed of `Port` (`int`) and `Protocol` (`string`). A service description can only specify the container port to be exposed. These ports can be mapped on runtime hosts at the operator's discretion. |
|
| 148 |
- </dd> |
|
| 149 |
- |
|
| 150 |
- <dt> |
|
| 151 |
- WorkingDir <code>string</code> |
|
| 152 |
- </dt> |
|
| 153 |
- <dd> |
|
| 154 |
- Working directory inside the service containers. |
|
| 155 |
- </dd> |
|
| 156 |
- |
|
| 157 |
- <dt> |
|
| 158 |
- User <code>string</code> |
|
| 159 |
- </dt> |
|
| 160 |
- <dd> |
|
| 161 |
- Username or UID (format: <name|uid>[:<group|gid>]). |
|
| 162 |
- </dd> |
|
| 163 |
- |
|
| 164 |
- <dt> |
|
| 165 |
- Networks <code>[]string</code> |
|
| 166 |
- </dt> |
|
| 167 |
- <dd> |
|
| 168 |
- Networks that the service containers should be connected to. An entity deploying a bundle should create networks as needed. |
|
| 169 |
- </dd> |
|
| 170 |
-</dl> |
|
| 171 |
- |