API Doc: component-type-docker.md
For Docker components, NAME should be set to `HOSTNAME`, which was provided as
an ENV variable inside of your container.
The binding service integrates with the streams and services section of your
component specification. For example, if you specify that you call a service:
```
"services": {
"calls": [{
"config_key": "vnf-db",
"request": {
"format": "dcae.vnf.meta",
"version": "1.0.0"
},
"response": {
"format": "dcae.vnf.kpi",
"version": "1.0.0"
}
}],
...
}
```
Then the config binding service will find all available IP addresses of
services meeting your needs, and provide them to you under your `config_key`:
```
// your configuration
{
"vbf-db" : // see above
[IP:Port1, IP:Port2,…] // all of these meet your needs, choose one.
}
```
Regarding `<config binding service hostname>:<port>`, there is DNS work going
on to make this resolvable in a convenient way inside of your container.
However, currently you will be given a name as an ENV variable,
`CONFIG_BINDING_SERVICE`, and you will need to query Consul's service discovery
to get
`<config binding service hostname>:<port>`.
Q: Is the complete entry point information of the config binding service
included in the ENV variable `CONFIG_BINDING_SERVICE` so that we could use the
value of this variable to access the config binding service?
-----------------------------------------------------------------------------------------------------------------------
Every [Docker component is registered](../architecture/service-discovery) with
the platform's service discovery layer. Docker components are not expected to
make the explicit make registration calls because that is done by through a
platform 3rd party registration service. A couple things are needed from
component developers in order for this registration to occur successfully:
1. Docker images must be created from a Dockerfile that has an
[`EXPOSE`](https://docs.docker.com/engine/reference/builder/#/expose)
instruction. This applies to components that listen on a port.
2. Component healthcheck details must be provided in the Docker auxiliary
component specification
### Expose port
Components that listen on a specific port must explicitly declare in their
Dockerfile that port using the `EXPOSE` instruction before building the image.
Warning! At the current time, you can not expose multiple ports in your
Dockerfile or registration *will not work* correctly.
Q: What if we want to expose more than one ENV(not limited to the `port` only)
variables using the EXPOSE instruction? Is that supported?
-----------------------------------------------------------------------------------------------------------------------
API Doc: service-discovery.md
Q: There's no detailed specification on service discovery. Do I miss it or is
it not provided yet? If it's not provided, when will that be uploaded to the
gerrit repo? This interface is quite crutial for us._______________________________________________
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss
