SQL Server containers are isolated SQL Servers that can be created or torn down on demand using web applications, REST API or command line. Many SQL Servers run on a single machine in containers. SQL Server containers for Windows are available from Windocks. Because production SQL Server runs on Windows, it is a best practice to use SQL Server Windows containers for dev, test, reporting, ML and devops. This requires multiple copies of production data delivered to in containers to users and pipelines.
Many SQL Server containers run on a single machine each on a different port, leading to simplified infrastructure, support and maintenance. Devops pipelines can spin up SQL containers for test and staging environments via a REST API. Containers for testers, developers, reporting and support teams are available via command line or UI
Windocks SQL Server containers for Windows are fully compatible with all your existing investments and tools
SQL Server containers are created from images. You may use an image such as a SQL Server 2016 base image. You may also build your own images from a specification (a dockerfile). The specification can include the databases you want in the image, the masking, any database scripts to run, access controls, etc. Once you build the image, you can create containers from that image. To build an image start with native full backups, or database files or BACPAC files from Azure SQL.
These containers can be delivered with clones of your databases so they can be used for testing or developing with production database clones.
|1. Install Windocks||Download the Windocks Community Edition or email firstname.lastname@example.org 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. Get the backup files ready||Put the SQL Server backup files or raw database files or BACPAC files from Azure SQL in a location accessible to the Windocks server and provide read / write permissions to the machine running Windocks|
|3. Provide the spec to the Windocks orchestrator to build the image||
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), and authorization controls. The spec is provided in the form of a dockerfile. Build the image via a web application, command line or REST API.
|4. Deliver SQL Server containers with customized database clones||From the image, deliver database clones to containers or instances. The image you built defines where the databases are delivered to. You may define an image that delivers containers with clones as well as clones to instances. To deliver containers and clones, use the web application or use the docker command line or the REST API.|
|5. Deliver SQL containers with Agent, reporting (SSRS), analysis (SSAS), and integration (SSIS)||See the tutorial here|
|6. Use the writeable clones in containers||Database clones are delivered either to containers or instances based on the image you built. If you delivered to an instance, then connect to that instance for the database clone. Clones are writeable. Containers are delivered on the machine running Windocks on specified ports. Access these containers with regular database tools or command lines or connection strings.
SQL Server containers are accessed with SQL Management Studio or Azure Data Studio or SQLCMD. Connect with the instance name (such as INSTANCE10002 when the container port is 10002). Or you can use the form IPAddressOfWindocksServer,10002 to connect to the SQL container running on port 10002.
Oracle containers are accessed with SQLPlus, RMAN or UI tools for Oracle. You may put in entries in tnsnames.ora for the containers as you would for Oracle instances. With SQLPlus or RMAN, use the form SQLPLUS sys/password@IPAddressOfWindocksLinuxServer:HostPort/orclcdb as sysdba