implement internal routing on single adapter per machine
currently, each service container launched wherever has a unique nunet-adapter attached to it; this is not what we eventually want to have on the platform. see:
- https://gitlab.com/nunet/integration-tests/-/blob/master/.gitlab-ci.yml#L19
- https://gitlab.com/nunet/integration-tests/-/blob/master/integration-test/job-defnitions/nunet-adapter-news-score.hcl#L6
eventually, we should have one nunet-adapter per one machine; that adapter should route requests to/fro all service containers deployed on that machine.
the workarround of one adapter per service container was implemented in order to get the gitlab-ci pipelines working until the service discovery mechanism (and the webrtc communication between adapters) is solved. once we have the solution we need to roll back this workaround.
for that, nunet-adapter will have to:
-
include local data structure / routing table where all service containers deployed on a machine are registered; it could be any efficient data structure, but i suppose that will be a hash table of a few has tables which will map unique id of container (for load balancing), service name and the port of the deployed service; note also that theoretically, several containers with the same service name can be deployed on one machine; -
include metadata about machine capabilities (dedicated resources, free resources -- considering that some resources can be used by running containers), price of machine services, other; -
request calls from the platform will come to the port of adapter (because internal container ports will not be known) and then will be resolved to internal docker ports based on service name; -
each adapter shall be able to call other services directly or via stun/turn servers initially; for machines behind nat, this will involve webrtc magic of this mr nunet/misc-experiments/protocol-engineering!4
Edited by kabir