From 80d9a8913f6a134594c8ab522b9a392274675cd3 Mon Sep 17 00:00:00 2001 From: Carson McManus Date: Thu, 29 Feb 2024 11:42:33 -0500 Subject: [PATCH] rename monolith discovery to service discovery (#312) related: #306 --- balancer-design.typ | 2 +- figures/discovery/discovery-class.mmd | 44 +++++++++---------- figures/discovery/discovery-class.svg | 2 +- figures/discovery/discovery-sequence.mmd | 4 +- figures/discovery/discovery-sequence.svg | 2 +- figures/discovery/monolith-discoverers.svg | 1 - ...iscoverers.mmd => service-discoverers.mmd} | 30 ++++++------- figures/discovery/service-discoverers.svg | 1 + harness-design.typ | 4 +- main.typ | 2 +- monolith-discovery.typ | 34 -------------- service-discovery.typ | 34 ++++++++++++++ visualization-design.typ | 4 +- weekly-reports.typ | 4 +- 14 files changed, 84 insertions(+), 84 deletions(-) delete mode 100644 figures/discovery/monolith-discoverers.svg rename figures/discovery/{monolith-discoverers.mmd => service-discoverers.mmd} (55%) create mode 100644 figures/discovery/service-discoverers.svg delete mode 100644 monolith-discovery.typ create mode 100644 service-discovery.typ diff --git a/balancer-design.typ b/balancer-design.typ index 9ee75d2..31baaf2 100644 --- a/balancer-design.typ +++ b/balancer-design.typ @@ -7,7 +7,7 @@ caption: "Class diagram showing the structure and relationships between types in the Balancer.", ) -Shown in @Figure::balancer-internals-class is the internal structure of the Balancer. The Balancer will discover Monoiths using the `MonolithDiscoverer` (a process further described in @Chapter::MonolithDiscovery), and the `MonolithConnectionManager` will establish connections to each Monolith. `Balancer` will update `BalancerContext` according to the messages it receives from `BalancerLink`. `Balancer` will then use `BalancerContext` to route messages to the appropriate Monoliths. Clients work similarly, except that they establish connections to the Balancer via `BalancerService`. `BalancerService` handles proxying HTTP requests to the appropriate Monoliths, and also accepting and upgrading WebSocket connections. +Shown in @Figure::balancer-internals-class is the internal structure of the Balancer. The Balancer will discover Monoiths using the `MonolithDiscoverer` (a process further described in @Chapter::ServiceDiscovery), and the `MonolithConnectionManager` will establish connections to each Monolith. `Balancer` will update `BalancerContext` according to the messages it receives from `BalancerLink`. `Balancer` will then use `BalancerContext` to route messages to the appropriate Monoliths. Clients work similarly, except that they establish connections to the Balancer via `BalancerService`. `BalancerService` handles proxying HTTP requests to the appropriate Monoliths, and also accepting and upgrading WebSocket connections. #figure( diff --git a/figures/discovery/discovery-class.mmd b/figures/discovery/discovery-class.mmd index d94c2a2..25d2199 100644 --- a/figures/discovery/discovery-class.mmd +++ b/figures/discovery/discovery-class.mmd @@ -1,11 +1,11 @@ classDiagram - class MonolithDiscoverer { + class ServiceDiscoverer { <> - +discover() Result~Vec~MonolithConnectionConfig~~ + +discover() Result~Vec~ConnectionConfig~~ +mode() DiscoveryMode } - note for MonolithDiscoverer "Abstraction over whatever method \nis actually used to discover Monoliths" + note for ServiceDiscoverer "Abstraction over whatever method \nis actually used to discover services" class DiscoveryMode { <> @@ -14,44 +14,44 @@ classDiagram } class DiscoveryTask { - discovery: dyn MonolithDiscovery + discovery: dyn ServiceDiscoverer - monoliths: HashSet~MonolithConnectionConfig~ - discovery_tx: Sender~MonolithDiscoveryMsg~ + monoliths: HashSet~ConnectionConfig~ + discovery_tx: Sender~ServiceDiscoveryMsg~ - +new(discovery: MonolithDiscovery, discovery_tx: Sender~MonolithDiscoveryMsg~) + +new(discovery: ServiceDiscoverer, discovery_tx: Sender~ServiceDiscoveryMsg~) +do_continuous_discovery() -do_discovery() } - class MonolithDiscoveryMsg { - added: Vec~MonolithConnectionConfig~ - removed: Vec~MonolithConnectionConfig~ + class ServiceDiscoveryMsg { + added: Vec~ConnectionConfig~ + removed: Vec~ConnectionConfig~ } class MonolithConnectionManager { - discovery_rx: Receiver~MonolithDiscoveryMsg~ + discovery_rx: Receiver~ServiceDiscoveryMsg~ link: BalancerLink - monoliths: HashSet~MonolithConnectionConfig~ + monoliths: HashSet~ConnectionConfig~ %% There's a mermaid-cli bug that prevents us from using the line below - %%connection_tasks: HashMap~MonolithConnectionConfig, ActiveConnection~ + %%connection_tasks: HashMap~ConnectionConfig, ActiveConnection~ connection_tasks: HashMap - +new(discovery_rx: Receiver~MonolithDiscoveryMsg~, link: BalancerLink) Self + +new(discovery_rx: Receiver~ServiceDiscoveryMsg~, link: BalancerLink) Self +do_connection_job() } - class MonolithConnectionConfig { + class ConnectionConfig { host: HostOrIp port: u16 } - DiscoveryTask --> MonolithDiscoveryMsg : sends + DiscoveryTask --> ServiceDiscoveryMsg : sends DiscoveryTask --> MonolithConnectionManager : connected via one way channel - MonolithDiscoveryMsg --* MonolithConnectionConfig : collects - MonolithDiscoveryMsg --> MonolithConnectionManager : received by - MonolithDiscoverer --o MonolithConnectionConfig : collects - DiscoveryTask --> MonolithDiscoverer : calls - MonolithDiscoverer --> DiscoveryMode - MonolithConnectionManager ..> MonolithConnectionConfig : uses + ServiceDiscoveryMsg --* ConnectionConfig : collects + ServiceDiscoveryMsg --> MonolithConnectionManager : received by + ServiceDiscoverer --o ConnectionConfig : collects + DiscoveryTask --> ServiceDiscoverer : calls + ServiceDiscoverer --> DiscoveryMode + MonolithConnectionManager ..> ConnectionConfig : uses diff --git a/figures/discovery/discovery-class.svg b/figures/discovery/discovery-class.svg index a1ef750..462d6a2 100644 --- a/figures/discovery/discovery-class.svg +++ b/figures/discovery/discovery-class.svg @@ -1 +1 @@ -sendsconnected via one way channelcollectsreceived bycollectscallsuses«trait»MonolithDiscoverer+discover() : Result<Vec<MonolithConnectionConfig>>+mode() : DiscoveryMode«enum»DiscoveryMode+Polling+ContinuousDiscoveryTaskdiscovery: dyn MonolithDiscoverymonoliths: HashSet<MonolithConnectionConfig>discovery_tx: Sender<MonolithDiscoveryMsg>+new(discovery: MonolithDiscovery, discovery_tx: Sender<MonolithDiscoveryMsg>)+do_continuous_discovery()-do_discovery()MonolithDiscoveryMsgadded: Vec<MonolithConnectionConfig>removed: Vec<MonolithConnectionConfig>MonolithConnectionManagerdiscovery_rx: Receiver<MonolithDiscoveryMsg>link: BalancerLinkmonoliths: HashSet<MonolithConnectionConfig>connection_tasks: HashMap+new(discovery_rx: Receiver<MonolithDiscoveryMsg>, link: BalancerLink) : Self+do_connection_job()MonolithConnectionConfighost: HostOrIpport: u16Abstraction over whatever methodis actually used to discover Monoliths \ No newline at end of file +sendsconnected via one way channelcollectsreceived bycollectscallsuses«trait»ServiceDiscoverer+discover() : Result<Vec<ConnectionConfig>>+mode() : DiscoveryMode«enum»DiscoveryMode+Polling+ContinuousDiscoveryTaskdiscovery: dyn ServiceDiscoverermonoliths: HashSet<ConnectionConfig>discovery_tx: Sender<ServiceDiscoveryMsg>+new(discovery: ServiceDiscoverer, discovery_tx: Sender<ServiceDiscoveryMsg>)+do_continuous_discovery()-do_discovery()ServiceDiscoveryMsgadded: Vec<ConnectionConfig>removed: Vec<ConnectionConfig>MonolithConnectionManagerdiscovery_rx: Receiver<ServiceDiscoveryMsg>link: BalancerLinkmonoliths: HashSet<ConnectionConfig>connection_tasks: HashMap+new(discovery_rx: Receiver<ServiceDiscoveryMsg>, link: BalancerLink) : Self+do_connection_job()ConnectionConfighost: HostOrIpport: u16Abstraction over whatever methodis actually used to discover services \ No newline at end of file diff --git a/figures/discovery/discovery-sequence.mmd b/figures/discovery/discovery-sequence.mmd index 504aadf..f506c87 100644 --- a/figures/discovery/discovery-sequence.mmd +++ b/figures/discovery/discovery-sequence.mmd @@ -2,7 +2,7 @@ sequenceDiagram participant MCM as :MonolithConnectionManager box Discovery Module participant DT as DiscoveryTask - participant MD as :MonolithDiscoverer + participant MD as :ServiceDiscoverer end DT->>+MD: Poll for Monoliths @@ -12,5 +12,5 @@ sequenceDiagram Note over DT: Builds a Discovery update message DT->>MCM: Send Discovery update over channel Note over MCM: Connects to discovered Monoliths - + diff --git a/figures/discovery/discovery-sequence.svg b/figures/discovery/discovery-sequence.svg index d3bf796..d78cd0f 100644 --- a/figures/discovery/discovery-sequence.svg +++ b/figures/discovery/discovery-sequence.svg @@ -1 +1 @@ -Discovery Module:MonolithDiscovererDiscoveryTask:MonolithConnectionManagerMaintains a list of connection configsDetermines config list differencesBuilds a Discovery update messageConnects to discovered MonolithsPoll for MonolithsReturn Vec<MonolithConnectionConfig>Send Discovery update over channel \ No newline at end of file +Discovery Module:ServiceDiscovererDiscoveryTask:MonolithConnectionManagerMaintains a list of connection configsDetermines config list differencesBuilds a Discovery update messageConnects to discovered MonolithsPoll for MonolithsReturn Vec<MonolithConnectionConfig>Send Discovery update over channel \ No newline at end of file diff --git a/figures/discovery/monolith-discoverers.svg b/figures/discovery/monolith-discoverers.svg deleted file mode 100644 index 105aa45..0000000 --- a/figures/discovery/monolith-discoverers.svg +++ /dev/null @@ -1 +0,0 @@ -«Trait»MonolithDiscoverer+discover()ManualMonolithDiscoverer+ManualDiscoveryConfig config+new(config: ManualDiscoveryConfig)+discover()HarnessMonolithDiscoverer+HarnessDiscoveryConfig config+new(config: HarnessDiscoveryConfig)+discover()FlyMonolithDiscoverer+FlyDiscoveryConfig config+String query+new(config: FlyDiscoveryConfig)+discover()DnsMonolithDiscoverer+DnsDiscoveryConfig config+new(config: DnsDiscoveryConfig)+discover()DnsDiscoveryConfig+u16 monolith_port+Option<String> dns_server+String query+Option<u64> polling_durationFlyDiscoveryConfig+u16 monolith_port+String fly_app+Option<u64> polling_durationManualDiscoveryConfig+Vec monolithsHarnessDiscoveryConfig+u16 port \ No newline at end of file diff --git a/figures/discovery/monolith-discoverers.mmd b/figures/discovery/service-discoverers.mmd similarity index 55% rename from figures/discovery/monolith-discoverers.mmd rename to figures/discovery/service-discoverers.mmd index 5d3cd09..db46d01 100644 --- a/figures/discovery/monolith-discoverers.mmd +++ b/figures/discovery/service-discoverers.mmd @@ -1,47 +1,47 @@ classDiagram direction BT - class MonolithDiscoverer { + class ServiceDiscoverer { <> +discover() } - ManualMonolithDiscoverer --|> MonolithDiscoverer - HarnessMonolithDiscoverer --|> MonolithDiscoverer - FlyMonolithDiscoverer --|> MonolithDiscoverer - DnsMonolithDiscoverer --|> MonolithDiscoverer + ManualServiceDiscoverer --|> ServiceDiscoverer + HarnessServiceDiscoverer --|> ServiceDiscoverer + FlyServiceDiscoverer --|> ServiceDiscoverer + DnsServiceDiscoverer --|> ServiceDiscoverer - DnsDiscoveryConfig --o DnsMonolithDiscoverer - DnsDiscoveryConfig : +u16 monolith_port + DnsDiscoveryConfig --o DnsServiceDiscoverer + DnsDiscoveryConfig : +u16 service_port DnsDiscoveryConfig : +Option~String~ dns_server DnsDiscoveryConfig : +String query DnsDiscoveryConfig : +Option~u64~ polling_duration - class DnsMonolithDiscoverer{ + class DnsServiceDiscoverer{ +DnsDiscoveryConfig config +new(config: DnsDiscoveryConfig) +discover() } - FlyDiscoveryConfig --o FlyMonolithDiscoverer - FlyDiscoveryConfig : +u16 monolith_port + FlyDiscoveryConfig --o FlyServiceDiscoverer + FlyDiscoveryConfig : +u16 service_port FlyDiscoveryConfig : +String fly_app FlyDiscoveryConfig : +Option~u64~ polling_duration - class FlyMonolithDiscoverer{ + class FlyServiceDiscoverer{ +FlyDiscoveryConfig config +String query +new(config: FlyDiscoveryConfig) +discover() } - ManualDiscoveryConfig --o ManualMonolithDiscoverer + ManualDiscoveryConfig --o ManualServiceDiscoverer ManualDiscoveryConfig : +Vec monoliths - class ManualMonolithDiscoverer{ + class ManualServiceDiscoverer{ +ManualDiscoveryConfig config +new(config: ManualDiscoveryConfig) +discover() } - HarnessDiscoveryConfig --o HarnessMonolithDiscoverer + HarnessDiscoveryConfig --o HarnessServiceDiscoverer HarnessDiscoveryConfig : +u16 port - class HarnessMonolithDiscoverer{ + class HarnessServiceDiscoverer{ +HarnessDiscoveryConfig config +new(config: HarnessDiscoveryConfig) +discover() diff --git a/figures/discovery/service-discoverers.svg b/figures/discovery/service-discoverers.svg new file mode 100644 index 0000000..db50125 --- /dev/null +++ b/figures/discovery/service-discoverers.svg @@ -0,0 +1 @@ +«Trait»ServiceDiscoverer+discover()ManualServiceDiscoverer+ManualDiscoveryConfig config+new(config: ManualDiscoveryConfig)+discover()HarnessServiceDiscoverer+HarnessDiscoveryConfig config+new(config: HarnessDiscoveryConfig)+discover()FlyServiceDiscoverer+FlyDiscoveryConfig config+String query+new(config: FlyDiscoveryConfig)+discover()DnsServiceDiscoverer+DnsDiscoveryConfig config+new(config: DnsDiscoveryConfig)+discover()DnsDiscoveryConfig+u16 service_port+Option<String> dns_server+String query+Option<u64> polling_durationFlyDiscoveryConfig+u16 service_port+String fly_app+Option<u64> polling_durationManualDiscoveryConfig+Vec monolithsHarnessDiscoveryConfig+u16 port \ No newline at end of file diff --git a/harness-design.typ b/harness-design.typ index 04e5746..49cbd37 100644 --- a/harness-design.typ +++ b/harness-design.typ @@ -15,12 +15,12 @@ Auth tokens must be present in all the places they would normally be, but they d == Emulated Monoliths -Emulated Monoliths are not actual Monoliths, they merely act like them. To that end, each emulated Monolith needs to listen on 2 ports each (one for normal http traffic, and one for the balancer websocket connections). This also means that there needs to be a Monolith discoverer that the harness can use to convey the correct ports to the Balancer. (@Section::HarnessMonolithDiscovery) +Emulated Monoliths are not actual Monoliths, they merely act like them. To that end, each emulated Monolith needs to listen on 2 ports each (one for normal http traffic, and one for the balancer websocket connections). This also means that there needs to be a service discoverer that the harness can use to convey the correct ports to the Balancer. (@Section::HarnessMonolithDiscovery) == Emulated Clients Emulated Clients are similar to emulated Monoliths, but they do not need to listen on any ports. They merely need to be able to connect to the Balancer, and send/receive messages. They should behave like a normal client, and they should optionally be able to keep track of the room state they are connected to. -== Conveying Emulated Monoliths to Balancer Discovery +== Conveying Emulated Monoliths to Balancer When emulated Monoliths are created, they need to convey their existence to the Balancer. To that end, the `TestRunner` should also manage a `DiscoveryProvider` that connects to the Balancer and tells it about the emulated Monoliths that are running. For the harness to connect, the balancer first needs a port to listen on. Assuming the port binds correctly, the discoverer will listen until a harness connects, and then store references to all emulated monoliths given by the discovery provider. To handle connecting to the balancer, the harness uses the `DiscoveryProvider` mentioned earlier. The provider takes in a set of emulated monoliths, and connects to the same port the discoverer is listening on. diff --git a/main.typ b/main.typ index 3b1f316..b6c693d 100644 --- a/main.typ +++ b/main.typ @@ -73,7 +73,7 @@ Document rendered on #datetime.today().display() #pagebreak() #include "balancer-design.typ" #pagebreak() -#include "monolith-discovery.typ" +#include "service-discovery.typ" #pagebreak() #include "join-process.typ" #pagebreak() diff --git a/monolith-discovery.typ b/monolith-discovery.typ deleted file mode 100644 index 0b0b04d..0000000 --- a/monolith-discovery.typ +++ /dev/null @@ -1,34 +0,0 @@ -= Monolith Discovery - -In order to establish connections with Monoliths, the Balancer needs to know the network address of each Monolith. This is done through a process called discovery. The discovery process is responsible for finding the network address of each Monolith and connecting to it. @Figure::discovery-sequence shows the sequence diagram for the discovery process. - -There are 2 different discovery modes: Polling and Continuous. Polling is used for `MonolithDiscoverer`s that do not provide real time updates (Like `FlyMonolithDiscoverer`), and Continuous is used for `MonolithDiscoverer`s that do provide real time updates (Like `HarnessMonolithDiscoverer`). The discovery process is ultimately the same for both modes. - -#figure( - image("figures/discovery/discovery-class.svg"), - caption: "Class Diagram for the Monolith Discovery Process." -) - -#figure( - image("figures/discovery/discovery-sequence.svg"), - caption: "Sequence Diagram for the Monolith Discovery Process." -) - -== Implementation - -There are three current implementations of the `MonolithDiscoverer` trait. - -#figure( - image("figures/discovery/monolith-discoverers.svg", width: 85%), - caption: "Class Diagram for Monolith Discoverers." -) - -The first implementation is used when connecting to the instance of the monolith on fly.io. Before connecting the user inputs the port that the monolith should listen on for the load balancer connection and a string representing the fly app. These properties are both encapsulated by the `FlyDiscoveryConfig` struct. - -To discover the monolith, the configuration and a query are passed into the discoverer struct, `FlyMonolithDiscoverer`. In order to connect to the instance on fly.io, an IPv6 DNS lookup is created using the query `global..internal` #cite(). The discovery process uses the results of the lookup and connects the balancer. - -The second implementation is used when manually connecting to any instance excluding the one on fly.io and the discovery process works slightly differently. Any number of monolith connections, represented by the `MonolithConnectionConfig` are passed into the manual discoverer. The discoverer then clones the monoliths and connects. - -`HarnessMonolithDiscoverer` is the third implementation and is used for testing with the harness. The discoverer opens a port and listens for incoming websocket connections. When a connection is made, the discoverer listens for a message from the harness dictating all the monoliths that are visible to the balancer. - -The fourth implementation comes in the form of `DnsMonolithDiscoverer` when connecting the monolith to the docker dns server. This process follows a similar procedure to that of `FlyMonolithDiscoverer` but queries IPv4 addresses instead of IPv6 addresses as Docker does not support IPv6 addresses. \ No newline at end of file diff --git a/service-discovery.typ b/service-discovery.typ new file mode 100644 index 0000000..6b6942a --- /dev/null +++ b/service-discovery.typ @@ -0,0 +1,34 @@ += Service Discovery + +In order to establish connections with Monoliths, the Balancer needs to know the network address of each Monolith. Similarly, the collector needs to know the network addresses of Balancers for visualization. This is done through a process called discovery. The discovery process is responsible for finding the network address of each Monolith and connecting to it. @Figure::discovery-sequence shows the sequence diagram for the discovery process. + +There are 2 different discovery modes: Polling and Continuous. Polling is used for `ServiceDiscoverer`s that do not provide real time updates (Like `FlyServiceDiscoverer`), and Continuous is used for `ServiceDiscoverer`s that do provide real time updates (Like `HarnessServiceDiscoverer`). The discovery process is ultimately the same for both modes. + +#figure( + image("figures/discovery/discovery-class.svg"), + caption: "Class Diagram for the Service Discovery Process." +) + +#figure( + image("figures/discovery/discovery-sequence.svg"), + caption: "Sequence Diagram for the Service Discovery Process." +) + +== Implementation + +There are three current implementations of the `ServiceDiscoverer` trait. + +#figure( + image("figures/discovery/service-discoverers.svg", width: 85%), + caption: "Class Diagram for Service Discoverers." +) + +The first implementation is used when connecting to the instance of the monolith on fly.io. Before connecting the user inputs the port that the monolith should listen on for the load balancer connection and a string representing the fly app. These properties are both encapsulated by the `FlyDiscoveryConfig` struct. + +To discover the monolith, the configuration and a query are passed into the discoverer struct, `FlyServiceDiscoverer`. In order to connect to the instance on fly.io, an IPv6 DNS lookup is created using the query `global..internal` #cite(). The discovery process uses the results of the lookup and connects the balancer. + +The second implementation is used when manually connecting to any instance excluding the one on fly.io and the discovery process works slightly differently. Any number of monolith connections, represented by the `ConnectionConfig` are passed into the manual discoverer. The discoverer then clones the monoliths and connects. + +`HarnessServiceDiscoverer` is the third implementation and is used for testing with the harness. The discoverer opens a port and listens for incoming websocket connections. When a connection is made, the discoverer listens for a message from the harness dictating all the monoliths that are visible to the balancer. + +The fourth implementation comes in the form of `DnsServiceDiscoverer` when connecting the monolith to the docker dns server. This process follows a similar procedure to that of `FlyServiceDiscoverer` but queries IPv4 addresses instead of IPv6 addresses as Docker does not support IPv6 addresses. diff --git a/visualization-design.typ b/visualization-design.typ index 68c5b85..51a646f 100644 --- a/visualization-design.typ +++ b/visualization-design.typ @@ -122,9 +122,9 @@ Grafana is a tool primarily meant for time series data, and no current data sour === Balancer Discovery -While the visualization is running: Multiple instances of the balancer can be active simultaneously, new instances can become active, and instances can go offline. The addresses of these balancers are not known at runtime, so a discovery process similiar to @Chapter::MonolithDiscovery must run to collect data from the discovered balancers. +While the visualization is running: Multiple instances of the balancer can be active simultaneously, new instances can become active, and instances can go offline. The addresses of these balancers are not known at runtime, so a discovery process similiar to @Chapter::ServiceDiscovery must run to collect data from the discovered balancers. -In order to achieve this, a new rust crate will be created to handle this discovery process. Implementation will likely be similar to @Chapter::MonolithDiscovery. A port will be opened to listen for active instances of the balancer. When a connection or connections are found, the balancer discoverer clones the balancer(s) and connects. +In order to achieve this, a new rust crate will be created to handle this discovery process. Implementation will likely be similar to @Chapter::ServiceDiscovery. A port will be opened to listen for active instances of the balancer. When a connection or connections are found, the balancer discoverer clones the balancer(s) and connects. === Querying Balancers diff --git a/weekly-reports.typ b/weekly-reports.typ index c31993a..b0310e4 100644 --- a/weekly-reports.typ +++ b/weekly-reports.typ @@ -54,7 +54,7 @@ *Figures Updated* - Added: @Figure::balancer-channels-client-monolith -- Updated: @Figure::monolith-discoverers +- Updated: @Figure::service-discoverers - Added: @Figure::malformed-websocket-test-sequence - Added: @Figure::monolith-id-sequence - Added: @Figure::DOM-class-visualization @@ -100,7 +100,7 @@ - Minor update to @Figure::balancer-internals-class - Added new figure to describe internals of MonolithSelection trait: @Figure::monolith-selection-internals-class - Ensured all members could run multiple monoliths and load balancers on their systems for manual testing -- Updated @Figure::monolith-discoverers with new implementation for docker +- Updated @Figure::service-discoverers with new implementation for docker - Added information to explain Grafana and D3.js *Tasks for next week*