Embrace DevOps as a Database Administrator – Build container images with latest code release

In the previous posts of this series, automating code release and putting T-SQL code under source control was discussed. In this post, we will discuss about how the latest code release can be put on the containers directly and leverage the same image to build Dev/Test/Prod environments.

The flow of this post will be :

1. Spin a SQL container on Linux

2. Restore a database on the container

3. Run SQLPackage.exe to automate the code release to container

4. Build an image with all the changes

5. Spin containers with the latest changes for dev/test/prod

Note : – I presume, you have an understanding about containers. If not, please check this post before reading further.

In the last post, we discussed about SQLPackage.exe to automate the code release.

image

and the input parameters for this exe were as follows:

Script:

“C:\Program Files (x86)\Microsoft SQL Server\140\DAC\bin\sqlpackage.exe”

/action:Publish

/sourceFile:”C:\Users\harshch\source\repos\DBcouncil\DBcounil\bin\Debug\DBcouncil.dacpac”

/targetconnectionstring:”Data Source=localhost; Initial Catalog=WideWorldImporters; Integrated Security=true;”  << target connection string will point to the container

1) Let’s look at the container environment, we have got here.  Container was spun using the following commands and we have a container instance running with a DB:

docker run -e “ACCEPT_EULA=Y” -e “MSSQL_SA_PASSWORD=test123@” -e “MSSQL_PID=Developer” –cap-add SYS_PTRACE -p 1401:1433 microsoft/mssql-server-linux

image

2) Let’s copy the backup file to the container:

image

3) After restoring the database to the container instance , let’s run the schema comparison tool to identify the delta of changes:

image

4) Same set of changes are identified:

image

5) Let’s use SQLpackage.exe to deploy the change to container:

“C:\Program Files (x86)\Microsoft SQL Server\140\DAC\bin\sqlpackage.exe”

/action:Publish

/sourceFile:”C:\Users\harshch\source\repos\DBcouncil\DBcounil\bin\Debug\DBcouncil.dacpac”

/targetconnectionstring:”Data Source=localhost,1404; Initial Catalog=WideWorldImporters; Integrated Security=false; user id=sa ;password=test123@”   << target connection string pointing to the container>>

image

6) Let’s connect to SQL instance built on container and see if the changes have been deployed:

image

7) Now let’s commit these changes to the container image so that, next container we spin has all these changes inbuilt. Again, this entire lifecycle can be automated through powershell or windows scripts. Moreover, this script can be part of build process in TFS for automating the application release.

Syntax to commit the changes to image is  – docker commit < containerID > < newcustomimagename >  (mentioned in step 2 in the below screenshot)

image

if you see the size of image named SQL_2017_release1 is higher than the other images because the database has been restored in this image.

9) Now, let’s spin up a container from this image and see if we have the database already created:

c:\Program Files (x86)\Microsoft SQL Server\140\DAC\bin>docker run -e “ACCEPT_EULA=Y” -e “MSSQL_SA_PASSWORD=test123@” -e “MSSQL_PID=Developer” –cap-add SYS_PTRACE -p 1405:1433 -v  -d sql_2017_release1

image

10)  Let’s connect to the new container SQL instance and see if we have the database created with all the changes:

image

We can see all the deployed changes were successfully ported to the new container. This new image could be used to build dev/test/Prod environments. In the next post, we will discuss about how to orchestrate containers using Kubernetes on Azure.

HTH!

Advertisements