Database Orchestration
Windocks database orchestration is a supervisory database control plane that coordinates database cloning, containerization, periodic production refresh, access control, masking, and script repositories to customize and deliver databases.
Orchestration is needed for database operations at speed and scale for dev, test, reporting, ML, and DevOps. It removes the need for you to write or maintain code. You simply specify the databases needed and how to customize them and Windocks orchestration does the work for you.
Delivering Complete Database Environments
Windocks orchestration is an open system that allows you to use built-in cloning, container, data masking, and synthetic data generation from Windocks or solutions from others.
Database orchestration is used to deliver complete database environments for development, test, support, reporting, ML, and DevOps.
Database orchestration uses a specification (dockerfile) that describes:
- what databases are to be delivered
- where to deliver them (which containers or instances)
- how to clone databases
- whether to mask data
- which Git repo to pull database scripts from and apply them.
- what access controls to use
Windocks orchestration works with Windocks SQL Server Windows containers, as well as Docker Oracle, MySQL, and PostgreSQL containers.
The orchestration is executed using standard REST APIs, docker client, Kubectl commands, Helm charts or the Windocks web application.
Database Orchestration versus Data Orchestration
| Database orchestration | Data orchestration |
|---|---|
| Process of cloning entire databases, customizing them and delivering database environments for dev, test, reporting, support, ML, and DevOps | Process of taking data from different databases, and organizing it into a unified data view for analysis |
| Many clones of databases without combining data from different databases | Logical data warehouse by combining data from different databases |
| Delivers both the database clones and the database service in containers | Delivers just the unfied view |
| Customizes the databases - masking, running scripts, setting authentication controls | No customization, just combination of data from different sources |
Steps to start with Database Orchestration
1. Install Windocks
Download the Windocks Community Edition or email support@windocks.com for a full featured evaluation edition.
Provision a Windows Server VM (Server 2016, 2019, or 2022), install SQL Server (for SQL database delivery) and then install Windocks as described here.
For Oracle database delivery, also install the Windocks service for Linux as described here.
2. Orchestration of Windocks cloning and Windocks SQL containers
Specify:
- the path to one or more SQL backup or database files or Azure SQL BACPAC files, which database cloning to use Windocks database cloning or volume cloning from other companies)
- where to deliver the database clones (Windocks SQL Server Windows containers or SQL Server instances)
- how often to refresh from production, customizations such as database scripts to be applied
- which masking software to use (Windocks masking, other masking solutions or scripts)
- authorization controls
The spec is provided in the form of a dockerfile. Build the image via a web application, command line or REST API.
3. Orchestration of SAN volume cloning and Windocks SQL containers
Specify:
- the details of which storage system to use (Cohesity, Pure, etc)
- the IP address / DNS of the SAN array
- the user name and password for the array
- the locations to mount the volumes cloned by the SAN array.
The Windocks server must be accessible to the SAN array (typically an iSCSI connection) so the array can clone snapshots and attach them to the Windocks server. Windocks will spin up SQL Server containers for the clones and attach the databases in the cloned volumes to the container. Windocks will also manage the lifecycle of the array clones.
To get started, see this tutorial.
4. Orchestration of Windocks cloning, Windocks SQL containers, and Git repo scripts
Specify the backups of the databases to clone, the location of the git repo, the path to the scripts in the repo, and the git branch. The branch can be specified at image build time or at container and clone create time. See the tutorial here
5. Orchestration of Windocks cloning, SQLPlus scripts, and docker Oracle containers
Specify the path to a script that restores Oracle RMAN backups, or the path to Oracle oradata files, and any other SQL scripts to run. Provide the spec in the form of a dockerfile and build the image via a web application, command line or REST API.
6. Orchestration of Windocks cloning or SAN cloning and SQL Server instances
Start with the samples in \windows\samples:
- windocksCloneToSqlInstance
- windocksCloneToSqlInstanceWithFileStream
- sanPureStorageToSqlInstance
7. Orchestration of Windocks cloning, SQL Server controls and Access control
See the samples in windocks\samples:
- accessControl
- authorization