1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
|
# docker-cloudify
This repository contains Cloudify artifacts used to orchestrate the deployment of Docker containers. See the example blueprints in the [`examples` directory](examples).
More details about what is expected from Docker components can be found in the DCAE ONAP documentation.
## Input parameters
### start
These input parameters are for the `start` `cloudify.interfaces.lifecycle` and are inputs into the variant task operations `create_and_start_container*`.
#### `envs`
A map of environment variables that is intended to be forwarded to the Docker container as environment variables. Example:
```yaml
envs:
EXTERNAL_IP: '10.100.1.99'
```
These environment variables will be forwarded in addition to the *platform-related* environment variables like `CONSUL_HOST`.
#### `volumes`
List of maps used for setting up Docker volume mounts. Example:
```yaml
volumes:
- host:
path: '/var/run/docker.sock'
container:
bind: '/tmp/docker.sock'
mode: 'ro'
```
This information is used to pass forward into [`docker-py` create container call](http://docker-py.readthedocs.io/en/1.10.6/volumes.html).
key | description
--- | -----------
path | Full path to the file or directory on the host machine to be mounted
bind | Full path to the file or directory in the container where the volume should be mounted to
mode | Readable, writeable: `ro`, `rw`
#### `ports`
List of strings - Used to bind container ports to host ports. Each item is of the format: `<container port>:<host port>`.
Note that `DockerContainerForPlatforms` has the property pair `host_port` and `container_port`. This pair will be merged with the input parameters ports.
```yaml
ports:
- '8000:8000'
```
Default is `None`.
#### `max_wait`
Integer - seconds to wait for Docker to come up healthy before throwing a `NonRecoverableError`.
```yaml
max_wait:
60
```
Default is 300 seconds.
### stop
These input parameters are for the `stop` `cloudify.interfaces.lifecycle` and are inputs into the task operation `stop_and_remove_container`.
#### `cleanup_image`
Boolean that controls whether to attempt to remove the associated Docker image (true) or not (false).
```yaml
cleanup_image
True
```
Default is false.
## Using DMaaP
The node type `dcae.nodes.DockerContainerForComponentsUsingDmaap` is intended to be used by components that use DMaaP and expects to be connected with the DMaaP node types found in the DMaaP plugin.
### Node properties
The properties `streams_publishes` and `streams_subscribes` both are lists of objects that are intended to be passed into the DMaaP plugin and used to create additional parameters that will be passed into the DMaaP plugin.
#### Message router
For message router publishers and subscribers, the objects look like:
```yaml
name: topic00
location: mtc5
client_role: XXXX
type: message_router
```
Where `name` is the node name of `dcae.nodes.Topic` or `dcae.nodes.ExistingTopic` that the Docker node is connecting with via the relationships `dcae.relationships.publish_events` for publishing and `dcae.relationships.subscribe_to_events` for subscribing.
#### Data router
For data router publishers, the object looks like:
```yaml
name: feed00
location: mtc5
type: data_router
```
Where `name` is the node name of `dcae.nodes.Feed` or `dcae.nodes.ExistingFeed` that the Docker node is connecting with via the relationships `dcae.relationships.publish_files`.
For data router subscribers, the object looks like:
```yaml
name: feed00
location: mtc5
type: data_router
username: king
password: "123456"
route: some-path
scheme: https
```
Where the relationship to use is `dcae.relationships.subscribe_to_files`.
If `username` and `password` are not provided, then the plugin will generate username and password pair.
`route` and `scheme` are parameter used in the dynamic construction of the delivery url which will be passed to the DMaaP plugin to be used in the setting up of the subscriber to the feed.
`route` is the http path endpoint of the subscriber that will handle files from the associated feed.
`scheme` is either `http` or `https`. If not specified, then the plugin will default to `http`.
### Component configuration
The DMaaP plugin is responsible to provision the feed/topic and store into Consul the resulting DMaaP connection details. Here is an example:
```json
{
"topic00": {
"client_role": "XXXX",
"client_id": "XXXX",
"location": "XXXX",
"topic_url": "https://some-topic-url.com/events/abc"
}
}
```
This is to be merged with the templetized application configuration:
```json
{
"some-param": "Lorem ipsum dolor sit amet",
"streams_subscribes": {
"topic-alpha": {
"type": "message_router",
"aaf_username": "user-foo",
"aaf_password": "password-bar",
"dmaap_info": "<< topic00 >>"
},
},
"streams_publishes": {},
"services_calls": {}
}
```
To form the application configuration:
```json
{
"some-param": "Lorem ipsum dolor sit amet",
"streams_subscribes": {
"topic-alpha": {
"type": "message_router",
"aaf_username": "user-foo",
"aaf_password": "password-bar",
"dmaap_info": {
"client_role": "XXXX",
"client_id": "XXXX",
"location": "XXXX",
"topic_url": "https://some-topic-url.com/events/abc"
}
},
},
"streams_publishes": {},
"services_calls": {}
}
```
This also applies to data router feeds.
|
