The fdb.cluster
file is composed of 2 main parts (see Cluster file format):
- The cluster
id
(with optional description
)
- A list of one or more coordinators
IP:PORT
pairs.
Any client must be capable of reaching at least one of the coordinators in the list to talk to the cluster, and it must have the correct cluster ID. If not, it will not be able to connect. There are no built-in service discovery.
This means that you have to provide yourself the initial cluster file to your application. Once it connects to a coordinator node, it will be able to obtain the complete list and update the cluster file by itself (if the topology changes).
One solution for deployment, is to have your application (or deployment script) download the latest fdb.cluster from an internal URL (or file share) if the file is missing, to jump start the setup.
Regarding authentication, unless you use TLS/SSL, the "id" part in the cluster file acts as a pseudo clear-text password. Even if you have the correct set of coordinators , the application must also have the proper cluster ID.
Though it should be considered as the equivalent of the database name in a typical SQL server. It can be easily found and is transmitted in clear if you don't use SSL. I guess it is there to prevent silly mistakes, more than anything else (ex: typing the IP:PORT of a different cluster).