Additional Functionality

[Phoxxphire2309]

This tool is fantastic in deployment for bridge on Docker and Kubernetes however in a real world scenario I feel benefit would be brought in adding additional redundancy

Adding say 3 bridge containers onto one Monolithic VM with Docker causes problems if that VM is to go down, and provides no HA, you would possibly need multiple BridgeCTL with different endpoints which adds additional management

Also allowing deployment of multiple Kubernetes pods on single or multi-site is great, but allowing the ability to scale pods based on demand would better suit and also allowing different kubernetes clusters would allow for multiple site management with Cloud Manager when possibly one site needs a different cluster and networking vs the others

[sf-jfluckiger]

You could achieve redundancy today using these techniques:

• In K8s you can achieve physical redundancy by spinning up bridge agent pods in a Kubernetes cluster that has multiple physical nodes.
• With docker, you can spin up bridge agent containers on two separate machines that both have Docker running.
• Also you can publish a bridge container to a container registry and then use a bash script to spin up multiple containers on a remote machine without having to install bridgectl on that remote machine. The feature for generating the bash script is found in the Run Bridge page if container registry has been configured. (We need to provide better documentation on this).

We will try to provide more documentation about how to implement these solutions with existing BridgeCTL functionality.

---- Ideas for future improvements ---
But you make a good point, it would be nice if BridgeCTL had better out-of-the-box support for physical redundancy . We have been working on better ways to address this capability, but it has not yet been fully implemented.

• We have been working on a remote command gateway api so that multiple BridgeCTL agents can be remotely controlled. This would allow for spinning up agents across multiple machines for redundancy like you mentioned.

• AutoScale feature. This would spin up additional bridge agents when an event was detected, for example a bridge agent becomes disconnected, or the extract refresh queue time becomes long. Or to spin down bridge agents when agents are under-utilized.

These features are still under design and development. We appreciate your feedback and will solicit additional feedback and beta testers when we are ready.

[Phoxxphire2309]

Thanks

With Kubernetes its different in a sense that I may want a complete separate cluster/nodes for each site, if I have 3 sites, each may serve a separate set of databases, and ROLP would dictate you limit that to a set cluster/node and limited database connectivity, atm it treats sites using one cluster which isnt the best way to achieve separated config and design

[sf-jfluckiger]

@Phoxxphire2309,

I added you as a collaborator if you'd like to add some documentation to the wiki on best practices for deployment of bridge containers using best practices for fault tolerance. I think this would be quite useful for many users. I think it is something that needs to be captured in documentation rather than a specific feature of bridgectl, at least initially. Is it ok if I close this issue for now?