A cluster engaging with a database instance hosted by a third-party service provider is a common example of external service integration. Carbonio Mesh is used to deploy in Carbonio CE circumstances like this one.
The Scenario and the Requirements
Our example scenario consists of a Carbonio CE Multi-Server installation that contains the following components:
- Carbonio Files Nodes: one or more
- One cluster node (potentially distinct from the Carbonio Files Nodes) was chosen as the terminating gateway.
- Carbonio Files uses a PostgreSQL database, which can either
- A server that is not part of the Carbonio CE infrastructure.
- A third-party service hosts the website remotely.
Because the process needs manual file editing and running commands, the setup requires access to the command line when terminating the gateway, however certain instructions at the conclusion of the procedure require access to the database node.
Finally, keep the cluster credential password handy because token creation requires it.
Let us now begin the operation by first installing Carbonio Mesh and then Carbonio Files.
Setup and security
A few actions must be completed during the initial setup.
Make a committed user.
Create policies. Carbonio Mesh must be made aware of the services to be routed, which in our case is the Carbonio Files database, carbonio-files-db.
Create a directory to hold all of the settings.
Then, in the file /etc/carbonio/gateway/service-discover/policies.json, put the following text.
Finally, the new policy should be picked up by consul.
Export a new bootstrap token, which will allow you to run consul commands and access its APIs. To retrieve the bootstrap token, use the following command followed by the cluster credential password.
Create a new token that is linked to the policy and will be the only one used to connect with the external database.
The Definition of External Service
To function effectively, the terminating gateway must be aware of the precise location of the remote service; hence, we specify both the external service and how the terminating gateway may contact it, as well as how Carbonio Files nodes can access it.
There is currently no CLI command for this, but we can utilise the APIs to do this. Make a file called /etc/carbonio/gateway/service-discover/carbonio-files-db-external.json with the following content:
Then, to register the external service, issue a curl request.
Routing of Services
Now that the terminating gateway and the service have been defined and registered, let Carbonio Mesh know which services can utilise the gateway.
To do so, add the following text to the file /etc/carbonio/gateway/service-discover/gateway-config.hcl, which specifies a carbonio-gateway as a terminating gateway for the carbonio-files-db service.
The above file has two commented entries: they are optional and may not be provided at all in the configuration.
CAFile
A service-specific SSL certificate. Unless a highly particular and sophisticated scenario is set up, this is typically not essential. Indeed, consul is in responsible of encrypting all traffic between nodes and with external resources: services and clients communicate with consul on localhost, thus they may communicate in plain text with it. Before leaving the node, data received from consul on localhost is instantly SSL-encrypted.
SNI
The Server Name Indication (SNI) is an extra layer of security on top of TLS that is used to prevent name mismatches. In the common case where a single web server hosts multiple domains, each with its own SSL certificate, when a client request is received, the web server may not yet know which domain the client is attempting to access because the HTTPS TSL/SSL handshake occurs before the client sends the actual HTTP request for the domain. This may result in the client receiving the incorrect certificate and perhaps terminating the secure connection. Using an SNI overcomes this issue since it allows the domain name to be sent directly during the SSL/TSL handshake.
Make careful to save the settings by running the command below.
At this stage, we are practically finished: Carbonio Mesh setup is complete. Let’s finish up the final few duties.
Service Systemd
Create a systemd unit to regulate whether or not the carbonio gateway is enabled, and hence whether or not access to the external DB is permitted. Create the file /lib/systemd/system/carbonio-gateway.service and fill it with the following text.
Reload systemd after saving the file to make it aware of the new unit file, then activate the new carbonio-gateway service.
Carbonio-files-db configuration
The carbonio-files-db-bootstrap script is commonly used to configure the database, which involves transferring the DB credentials to Carbonio Mesh and creating the DBs. However, because the carbonio-files-db package is not installed, this action must be completed manually on the terminating gateway using these instructions.
- set the database name
- configure username and password
Now, let’s log in to the database node, where a postgres superuser must be created. In this example, we give the user the password ScrtPsw9872. Make use of a strong password of your choosing.
First, log in as the postgres user and begin a direct connection to the database using the CLI client.
Then run the scripts below to create the user.
Exit the client once you’ve finished.
Installation of Carbonio Files Nodes
Carbonio Files installation differs differently from conventional Multi-Server installation. Make certain that the package carbonio-files-db is not installed on any node after the installation. In our instance, the database capabilities are given by an external service rather than by that package. As a result, you must remove it to avoid conflicts.
Install the carbonio-files-ui package on each Proxy Node.
Install these packages on both Nodes where Carbonio Files will be used. We recommend installing them on the two Stores Nodes.
The installation will conclude with the following message:
As a result, carry out pending-setups.
Take Services Out of Catalogue
When the external resource is no longer required, such as when the database is moved to the company’s data centre, the setup of the services is simple to delete.
- Stop the systemd unit service and remove the configuration file from the system.
- Uninstall the gateway configuration.