The orchestration of XMiDT can be quite complicated. Please refer to the architecture to have a better understanding of the components and how they work towards the bigger picture.
To get up and running quickly, or for a small, not highly available instance we have
a docker-compose version available.
This is a great way to see the way that components connect with one another as well as sample configurations
for each machine.
The XMiDT cluster can be configured either to dynamically coordinate via Consul (consul option)
or be statically configured (fixed option). The coordination defines how Petasos routes traffic to Talaria
machines as well as ensuring Talaria machines accept the same traffic. Petasos and Talaria should always
be in lock-step to prevent inbound connections from possibly being stranded. For any production or
production-like instances, we recommend the consul option.
Fixed routing involves configuring each Petasos to know the fqdn/ip of all Talarias in the cluster/region.
| Pro | Con |
|---|---|
| Fast to standup | Scaling is harder |
| One less component to manage | Node failover not supported |
| Prometheus auto-discovery is harder |
No prior setup is necessary. This step will be done at each service level, by providing a list of urls.
Consul allows Petasos to dynamically know about all the Talarias in the datacenter.
| Pro | Con |
|---|---|
| Scaling is fast and easy | TLS can be more complicated |
| Easier metric monitoring | Management of Consul |
| Node failover is supported | Complicated, difficult to stand up |
Once you have your approach and it is up and running, you can stand up Talaria.
This documentation is open-source. Please help improve it by filing issues or pull requests.