Bastion instance for Hackolade Studio

A bastion instance is a special computer that plays the role of a gatekeeper between a device and a user's machine.  The bastion instance runs Hackolade Studio Command-Line Interface commands on behalf of users, most likely an orchestration of multiple commands.

 

Such setup may be necessary for security reasons, for example because the organization does not want to allow access to database instances, or divulge access credentials.  Another reason might be that an organization wants data modelers to use only the browser deployment of Hackolade Studio.  As explained here, browser security blocks access to on-premise databases via most protocols, forcing a different way of performing some operations.  

 

The diagram below shows a simple architecture leveraging a bastion instance:

 

In general,organizations don't want want to run the risk of queuing requests in a single-threaded mode.  To that effect, it is possible to run the CLI in multi-threaded mode in Docker containers, as documented here.

 

The bastion instance running the Hackolade Studio Command-Line Interface in Docker requires a license key, which must be a Professional (or Workgroup) Concurrent key..

 

Below is a description of the process steps for the above diagram:

1) the user accesses a portal pre-configured to execute Hackolade Studio CLI commands with some default arguments, and some user-selected arguments

2) the portal runs a set of commands, including the request for the CLI to execute the command with the specified arguments

3) the the CLI command is executed in a Docker container, for example the reverse-engineering of a database instance.  The database credentials are known only to the bastion instance and its administrators

4) the portal takes the data model resulting from the reverse-engineering process, and performs a commit and push of the model to the Git repository

5) after the user is notified of the completion of the process, the user can now leverage Hackolade Studio

6) to access the data model for operations such as enrichment, evolution, artifact generation, model compare & merge, etc...

 

With the above scenario, the user has been able to achieve its objective or reverse-engineering without connecting directly to the database instance, and also without personally configuring CLI commands, provided that the portal page has been properly configured for the different use cases.

 

The above is just an example among others to inspire the reader.  There are many permutations and variations possible based on the above scenario.

 

Note: the creation of the portal page and configuration of the CLI commands is the responsibility of the customer, to fit the exact needs of the organization