>> Containers is probably
a technology you've been hearing a lot about.
But how easy is it to get started and why would you want
to run SQL Server 2019 in a container?
This week on Data Exposed.
[MUSIC].
>> Hi, I'm Anna Hoffman and welcome to
this episode of Data Exposed MVP edition.
Today I'm joined by Anthony Nocentino from Centino Systems.
Anthony, thanks for being here today.
>> Thanks for having me, Anna. So excited to be here.
>> We're always excited to have you.
Before we get into it,
I wanted to just ask you to tell us
a little bit about what you do.
>> I'm Anthony Nocentino.
I'm the Consultant and Trainer at Centino Systems and I
specialize in System Architecture and Performance.
I like to design systems.
I like to make things go fast.
>> Awesome, making things go fast,
sounds like a pretty good time.
Today we're going to talk about containers and
maybe something about how containers go fast.
But before we get into, I wanted to ask you,
what is a container and why did these things exist now?
>> Sure, a container is a new way to deploy an application.
Let's walk through what that looks like.
In a datacenter, you might have a physical or virtual computer
and we'll put just a regular host operating system on top of that,
whether it's Linux or Windows.
Then from there that's where things get unique.
Well, traditionally we would install
our applications directly onto the iOS.
But with a container,
a container is going to be a binary image of
our application and all of
its dependencies self-contained in this unit.
Today we're going to be talking about
SQL Server and SQL Server 2019.
We can deploy SQL Server as a Container
inside of an operating system
to consume the underlying resources of that OS.
Then we can go about and deploy even more Containers.
So another SQL Server or
perhaps even another application and build
more complex systems with
containers using that same underlying OS.
What's needed about this is it gives us
the ability to decouple the configuration of
our applications and the state of our applications
because the container becomes the unit of deployment.
What that means is, let's say I
need to come out with a new version of
my application or a new cumulative update for SQL comes along.
Well, since we've decoupled the configuration and the state of
our application from the deployment
of our application by using containers,
I can do something like this.
I can literally delete
my container and redeploy that container on that new version,
I use that same configuration.
I point the application to where the existing data was
and I'm back up and running new version of my application,
but I've maintained the configuration
and to say to my application,
independent of the running of my application.
>> Awesome, that's pretty cool.
There's a lot of different ways I can run SQL Server.
Containers are cool, but why would I want to run on a container?
>> Great question. So why do you want to
run SQL Server in containers?
It's going to come down to this speed and consistency,
being able to do things quickly
and do them over and over in a repeatable way,
because that's going to enable us to be able
to build deployment automation.
So in traditional IT deployment systems,
we spent a lot of time building
our environment in cultivating and maintaining an environment.
Now with containers, we're going to be able to write
code declare applications so that we can
do that quickly in a repeatable way.
Because no matter how good we are as humans,
we're slower than a computer and will
definitely make more mistakes than a computer will.
If we run our applications manually and deploy those manually,
but if we write code to do that,
we can do that quickly and consistently.
Now, that's going to enable us to start maturing our platforms.
You can start doing more complicated things like
DevOps scenarios using
continuous integration and continuous deployment.
Being able to build our application in
a repeatable way and deploy our application in a repeatable way.
As we go along in the story of why we're
going to see as new things come out from Microsoft specifically,
that we're able to use containers as
a building block to build more complex systems.
You see things like
big data clusters or Azure Arc Data Services in
those are using containers as
the building block to build more complex solutions.
The way that it gets done is encode.
That's one of the ways that Microsoft is able to deploy
those complex systems to you in a controlled way,
is to give you the code to deploy those systems.
So the container begin building block underneath that.
One of the key elements for me when I started working with
containers is we're going to
rethink how we deploy our applications.
For so long we're tied up into
the server was the thing that I was deploying and protecting.
It's not, we're going to really be
deploying the application or the surface.
Is there a SQL Server up and running for me to
get access to that data or to rephrase that.
Is there a SQL Server container up
and running that gets me access to that data?
You're going to see in a second when we do
some demonstrations how quickly
it is for me to deploy a container,
delete that container and replace it with a new one,
giving me access back into my data quickly and consistently.
>> Awesome. This sounds really interesting.
I'm really interested to see how
easy it is to get this thing up and running.
What I heard is you're actually
going to use a PowerShell Notebook.
I'm even more excited to
see how you're going to get this thing up and running.
Why don't you go ahead and show us what you got.
>> Here we are in an Azure Data Studio Notebook.
Let's walk through the process of deploying
SQL Server in a container, creating the database,
and then deploying a new version of
SQL Server accessing that same database.
To start off a container,
it doesn't take that much code to do that.
Here I have seven lines of code to deploy SQL Server.
We start off by executing the command docker run.
We give our container name.
In this case it's SQL run.
Now here's an example of how to decouple
configuration from the deployment of our actual application.
We're injecting environment variables to assert
some configuration onto our application,
in this case SQL Server.
So we're accepting the licensing agreement and
injecting a password for our database system.
We're going to make that container available on port 1433.
Here's an example of how we're going to
decouple the state of our application.
We're going to expose a volume from
our underlying operating system into the container.
When SQL Server starts to work,
it's going to read or write its data there.
That gives me the ability to take
my container and throw it away and
put a new one in that same exact location
to access that data again.
On line 7 is the container image that I'm going to start off.
Here you can see I'm using a container image
for SQL Server 2019, CU4.
Within Azure Data Studio Notebook,
I'll progress play, it'll run that code in that cell.
I get along container ID as output here at the bottom.
Now to see if my container is up and running,
I can use the command docker ps.
That's going to give me a listing of the running containers
that are running on my local system here and it's up and running.
You can think of this as the running application.
This is just a container running on my underlying OS.
But the key thing that I want to point out in this line of
output is where the application is running.
In the column on the right there,
we see that the application is running on all IP addresses,
or 0.0.0 on port 1433,
which means I can point any application on my network
to that location to consume the services of this database.
Let's go and do that. Let's run our first query
against SQL Server deployed inside of a container.
I'm going to run a very simple query select Edit version
and in the output there you can see I'm running SQL Server 2019,
CU4, and I did that in about seven lines of code.
We executed that docker run command.
I've been deploying SQL Server for
a long time and it still gets me
excited to see how I can deploy
SQL Server that quickly and that consistently.
Let's create a database inside of that running container.
That's done and check the output.
There we see the four system databases associated with
this particular SQL Server instance
and the test database that we just created together.
Just to go through the lifecycle of deployment,
let's kill this container and deploy a new version of SQL Server.
The way that we go about doing that is we can stop
our running container with docker stop
and in specifying the container name.
Now I'm going to delete that container.
That's just going to delete
the definition of the container from my system.
What that means is I can come back and create
another container and assert some configuration on that.
We're going to start off with docker run again.
I'm going to give it the same name,
SQL1 and inject some configuration.
So accept the Eula and I say password. Now this is where it's key.
We're going to access that same data location.
There you see the same volume that we
created in the first container that we ran.
The key difference between this execution and
the previous execution is I've just upgraded SQL Server to CU5.
We did that in a very short amount of code here.
Going down a little bit further.
Now that that container is up and running,
I run to check at version again,
and it still has to go through
the upgrade process of moving from CU4 to CU5.
If I come back a few seconds later,
you can see I'm already upgraded to CU5.
That's a fantastic piece of functionality.
Be able to move between versions of
SQL Server in a very quick and controlled way.
If I run to check to see
what databases are available on the system.
There we see the system databases
that we had an also that test database.
Going through that lifecycle,
we started up a container,
we created a database,
we deleted the container,
started up SQL Server on a new version of SQL Server,
and we still have access to that data.
Now to close it off here,
if we stop that container just to shut it down
again and remove its definition,
that data is still on
my underlying operating system until I
delete the data itself with a docker volume RM,
and that's when our data goes way.
>> Thanks Anthony. This is really powerful stuff and I think,
two really cool things.
Just to name a few from what you just did is one,
you were able to basically install and deploy
SQL Server twice in less than a minute,
which is just insane as it is.
Until you were able to upgrade,
that maybe took like 5-10 seconds to
upgrade to the newer version of SQL Server 2019.
Those are two things that we talked about going fast
and this is definitely going to help you go much faster.
>> Yeah, thinking about
the scenario where maybe you have a query that you're
working with that operates or
functions different in a different version of SQL Server.
Or you need to test your application on a new version and
having that functionality be
able to move between versions so quickly.
It's really enabling feature of this technology.
>> Awesome. Well, thanks so much for being on the show,
Anthony. We really enjoyed it.
We're going to put some references to this notebook that you
can try out for yourself as well as the documentation.
If you liked this video,
please like this video and leave
us a comment of what you're doing with containers.
In the next video,
we're going to stick around with Anthony and learn
about SQL Server 2019 in Kubernetes.
So taking it really to the next level.
We hope you stick around and we'll see you
next time in Data Exposed.
[MUSIC]