...
Firewall considerations
A single-node network doesn't require any firewall openings (beyond what's necessary to expose a web client), because there are no inter-node communications.
Cert considerations
A single-node network doesn't require any cert exchanges, because there are no inter-node communications.
...
Section |
---|
Column |
---|
|
|
Column |
---|
This configuration creates a hub-and-spoke network with a single hub node H, and spoke nodes A, B, and C. A single web client is exposed at the hub; queries originate and terminate at the hub. The spoke nodes only respond to queries. |
|
Hub's shrine.conf
Code Block |
---|
shrine {
...
queryEntryPoint {
...
}
hub {
...
downstreamNodes {
"Node A" = "http://nodeA.example.com/shrine/rest/adapter/requests"
"Descriptive name for node B" = "http://nodeB.example.com/shrine/rest/adapter/requests"
"Human-readable name for node C (can be anything)" = "http://nodeC.example.com/shrine/rest/adapter/requests"
}
}
// NB: no adapter { } block
}
|
Here, we have a shrine.queryEntryPoint block (so that queries may originate at the hub), and a shrine.hub.downstreamNodes block, so the hub knows who to broadcast queries to. The hub does not have a shrine.adapter block, since it's not queryable.
Each spoke's shrine.conf
Code Block |
---|
shrine {
...
adapter {
...
}
}
|
...
Firewall considerations
A hub-and-spoke network requires firewall openings to expose the hub's web client and to allow outbound HTTP requests from the hub to the spokes. For a network with N spokes, N unidirectional firewall openings are required.
Cert considerations
A hub-and-spoke network requires cert exchanges between the hub and each spoke. If there are N spokes, N cert exchanges are necessary.
...
Section |
---|
Column |
---|
|
|
Column |
---|
This configuration creates a fully-meshed network where each node can initate queries. It is similar to the single-node-network outlined above, but at each node, all the other nodes are listed in shrine.hub.downstreamNodes. |
|
shrine.conf
Assuming a 3-node netowrk with nodes A, B, and C:
...
Firewall considerations
A fully-meshed network requires bidirectional firewall openings between each pair of nodes. For N nodes, the number of bidirectional firewall openings required is (N^2 - N) / 2.
Cert considerations
A fully-meshed network requires cert exchanges between each pair of nodes. For N nodes, the number of cert exchanges required is (N^2 - N) / 2.
...
Section |
---|
Column |
---|
|
|
Column |
---|
This configuration creates a hub-and-spoke network with a single hub node H, and spoke nodes A, B, and C. A web client is exposed at each spoke. Each spoke also responds to all incoming queries by acting as an adapter. Having a single hub node reduces the number of firewall openings and cert exchanges required compared to a fully-meshed network, while allowing spoke nodes to expose their own web clients for political, branding, or other purposes. |
|
Hub's shrine.conf
Code Block |
---|
shrine {
...
hub {
...
downstreamNodes {
"Node A" = "http://nodeA.example.com/shrine/rest/adapter/requests"
"Node B" = "http://nodeB.example.com/shrine/rest/adapter/requests"
"Node C" = "http://nodeC.example.com/shrine/rest/adapter/requests"
}
}
// NB: no adapter { } block
}
|
Here, we have a shrine.queryEntryPoint block (so that queries may originate at the hub), and a shrine.hub.downstreamNodes block, so the hub knows who to broadcast queries to. The hub does not have a shrine.adapter block, since it's not queryable.
Each spoke's shrine.conf
Code Block |
---|
shrine {
...
queryEntryPoint {
...
broadcasterServiceEndpoint {
url = "http://hub.example.com/shrine/rest/broadcaster/broadcast"
...
}
}
adapter {
...
}
}
|
...
Firewall considerations
A hub-and-spoke network requires bidirectional firewall openings between the hub and all the spokes. For a network with N spokes, N bidirectional firewall openings are required.
Cert considerations
A hub-and-spoke network requires cert exchanges between the hub and each spoke. If there are N spokes, N cert exchanges are necessary.