Linux and open source designs are increasingly leading the technology industry in innovation, and it’s been exciting for the WinDocks team to bring the power of Docker's open source project to the Windows community. Since the launch of WinDocks earlier this year, support of automated Build and Test has emerged as one of the top use-cases.In this article we explore the use of Git with containers to deliver fast, integrated .NET and SQL Server environments.
In addition to being faster than VMs, containers typically yield a 3-5x reduction in VMs used, with great license cost savings. Host maintenance is also simplified, as containers are updated with the latest host image.
Docker's open source project defines an API for working with application containers, and a method of application packaging that includes all software dependencies. Docker is contributing toward a formal standard through the Linux foundation, and has become a cross platform design with collaboration between Microsoft and Docker. The Microsoft implementation, however, follows the Linux container design and relies on a shell for configuring application behavior. A shell based container works well for Windows console apps, Windows services, and most .NET apps, but won’t work for SQL Server and other Windows applications. We discuss the differences between the WinDocks and Microsoft container designs here. In this exercise we’ll use WinDocks containers.
WinDocks provides containers with support of .NET and SQL Server, on Windows 8, Windows 10, Windows Server 2012, and Windows Server 2016. All editions of SQL Server are supported from SQL Server 2008 through SQL Server 2016. SQL Server container instances allow more to be done on any given Server or set of licensed cores, and complies with Microsoft’s per-server and per-core licensing.
We’ll use a public repo on Github.com to pull a .NET application, and show how it is integrated with a SQL Server container. The result is a simple workflow for developers or testers. The tooling is particularly useful for DBA’s, who provide updated SQL Server images and allow the respective teams to self-service integrated environments.
We used a Windows 8.1 laptop with SQL Server 2014 for this exercise, with the WinDocks Community Edition (a free downloadable edition of WinDocks). WinDocks detects and installs on the Windows OS and configures SQL Server support based on the edition of SQL Server installed. The WinDocks Community Edition is also available in preconfigured Vs through Amazon’s AWS Marketplace. To get started: Install Git on your WinDocks host, and install WinDocks Community Edition.
Windows containers are tools for developers or testers to self-service integrated environments. A user can setup (and delete) SQL Server containers, with DBA approved SQL image, in seconds, and a team can work on identical isolated instances on a shared VM. Containers are easily deleted and replaced, and are ideal for destructive testing. Containers provide user and process isolation for applications, and .NET and SQL Server containers benefit from namespace isolation.
A Windows container host needs configurable support for “administrative” processes, such as mounting a network hosted database, or support of third party storage systems (such as NetApp SnapManager). WinDocks includes support for configuring administrative processes via the \Windocks\config\node.cfg file. Git requires administrative privileges, and we included Windows commands to support Git (see image below). You will see “RUN_AS_ADMIN_CMD” used later to support Git commands.
Two public github repos are used. GitDockerFile is the DockerFile that will clone our .NET application (DotNetSample). The GitDockerFile also includes a PowerShell script that we’ll use later.
Open a command prompt as Admin, and clone the GitDockerFile to your local machine:
Use File Explorer to open the DockerFile. The DockerFile defines a sequence of commands that are executed sequentially by the Docker daemon. DockerFiles begin with the base image, and in this case refers to the .NET-4.5 image. The second step “Git Clones” the dotnetsample repo to the container. The third step copies the web.config file into the container.
Refer to both images below for the sequence in creating an integrated .NET + SQL Server container environment. There are three steps: 1) create and start the SQL Server container, 2) edit the web.config file to include the SQL port and password, 3) launch the .NET application.
Once the SQL Server container is running, open the TestGitClone folder (that was cloned from the Git repo), and open the web.config file using notepad. Edit the IP address and port, and the sa password as shown. When updated, build the dotnet container.
The sequence of building the two containers is shown below. The Docker Build incorporates the Git clone in the building of the .NET application. The final step is to start the .NET application.
Congratulations, you’ve built a fully integrated container environment. Open a browser and navigate to the localhost:10004\dotnetsample to see the integrated environment. The SQL Server container is accessible through SQL Server Management studio, or other tools.
The WinDocks base .NET image includes a similar instance of the .NET application, so in this case we actually have two applications running in the container. This isn’t a recommended practice, but doesn’t affect the purpose of this exercise. The base image application is accessible at: localhost:10004
An alternative to the Docker command line is to use a PowerShell script. A sample script was included in the earlier Git Clone (GitDockerFile): Link.ps1. Open the script and note that parameters are included for the WinDocks host IP address, the reference to the TestGitClone folder, and the SQL Server image. Modify these if needed, but don’t change the reference to the standard Docker daemon port of 2375!
There are a variety of ways to run PowerShell scripts in UnRestricted mode.
The script automates the same workflow as discussed earlier. The script starts by launching a SQL Server container, starts the container, parses the port and SQL sa password, and updates the web.config file. Once the web.config file is updated, the script builds and starts the .NET container.
In less than a minute, a fully integrated environment is ready. These containers can easily be deleted and replaced just as quickly.