Starting with SQL Server 2017, Microsoft announced you can run SQL in Docker containers. This is great news for DBA’s because we tend to run multiple installations of SQL Server locally and with Docker we can spin up (or remove) a SQL instance fairly quickly.
I’m not going to go into what Docker is because there’s
an entire website
that goes into much more detail than I ever could. This post is going to focus
on a simple SQL installation on Windows 10 using Docker. Let ‘s gooooooo!
First, let’s download and install the latest version of Docker. To find the latest version, open an internet browser and navigate to https://docs.docker.com/docker-for-windows/install/. From here, click “Download from Docker Hub”
You will need to create a docker ID and password if you don’t have one. Once you have this info let’s login.
Next, let’s click “Get started with Docker Desktop” from the home page and “Download Docker Desktop for Windows”
After the download is complete, go ahead and start the install. On the Configuration screen, I’m going to Use Windows containers instead of Linux. Click OK.
Docker Desktop is installing:
After
installation succeeds, you must log out so make sure to save everything!
Upon logging back in, you will be greeted with this message, Hit OK and reboot.
After reboot, let’s open Powershell (as administrator)
and issue the following statement. This will show you that Docker is installed
properly and it will give you the version we are running.
Docker Version
Next, let’s do a search for a SQL Server image. Back in Docker Hub, in the search box, let’s type SQL Server and click on Microsoft SQL Server:
This page will give you all sorts of valuable information.
You can also use the following PowerShell statement to
pull SQL Server images:
Docker search Microsoft
Again, from Powershell, let’s download the Microsoft SQL
Server Developer Edition images. To do this use the following:
–name – this is the name of the container
you are creating
-d – Runs the container in the background
otherwise the container will take over your cmd when it starts
– p port:port – Maps a TCP port on the host
environment (first value) with a TCP port in the container (second value). In
this example, SQL Server is listening on TCP 14331 in the container and this is
exposed to the port, 1433, on the host. I’m using 14331 because I’ll create
multiple containers and each container needs a different port number.
-e – Creates environment variables under the
container execution runtime, for example, sa password and End User License
Agreement (EULA)
sa_password – Create sa password for SQL
instance (Hint, don’t use a $)
ACCEPT_EULA – Yes
It will take a few minutes to finish the install, but it’s
much shorter than a regular SQL install. Once finished, run the following to
get the IP address of the container (make sure to use your container name after
docker inspect):
As you can see, the IP for my container is 172.31.29.174. If I open SQL Server Management Studio and connect to this IP using the sa account and password I created I can connect successfully:
If you have any issues connecting try using the
following docker statement to view the logs:
Docker container logs –details DockerSQL
To remove the container, simply stop the container
Planning and building SQL Server in RDS doesn’t have to
scare you. It’s actually pretty easy and in this post will go over planning a
SQL Server deployment in RDS, creating SQL Server in RDS, and last but not
least configuring the new instance of SQL Server.
Once you can verify that your environment will run
properly in RDS you’ll need to look at the pricing model. When you setup RDS
for SQL Server, the software license is included. AWS used to have a program
called “Bring your own license” or “BYOL”, which allowed you to use a license
that was already bought from Microsoft via an agreement or other. This has been
rumored to expire on June 30, 2019. The software license that is included means
that you don’t need to purchase SQL Server licenses separately. AWS holds the
license for the SQL Server database software. Amazon RDS pricing includes the
software license, underlying hardware resources, and Amazon RDS management
capabilities. The pricing will depend on the selections such as size, edition,
etc.
The following editions are supported in RDS:
Enterprise
Standard
Web
Express
Notice, Developer Edition is not included with RDS and
Web Edition supports only public and internet-accessible webpages, websites,
web applications, and web services.
Instance
Type
You can also choose from On-demand or reserved
instances. On-Demand DB Instances let you pay for compute capacity by the hour
your DB Instance runs with no long-term commitments. This frees you from the
costs and complexities of planning, purchasing, and maintaining hardware and
transforms what are commonly large fixed costs into much smaller variable
costs. This is good for development environments where you can power on and off
the server as it’s being used.
Reserved Instances give you the option to reserve a DB
instance for a one or three year term and in turn receive a significant
discount compared to the On-Demand Instance pricing for the DB instance. Amazon
RDS provides three RI payment options — No Upfront, Partial Upfront, All
Upfront — that enable you to balance the amount you pay upfront with your
effective hourly price.
RDS provides a selection of instance types optimized to
fit different relational database use cases. Instance types comprise varying
combinations of CPU, memory, storage, and networking capacity and give you the
flexibility to choose the appropriate mix of resources for your database. Each
instance type includes several instance sizes, allowing you to scale your
database to the requirements of your target workload. View more details here: https://aws.amazon.com/rds/instance-types/
Storage
Another item to look at when planning your deployment is
storage. RDS uses Amazon Elastic Block Store (Amazon EBS) volumes for database
and log storage. Depending on the amount of storage requested, Amazon RDS
automatically stripes across multiple Amazon EBS volumes to enhance
performance.
RDS offers three different storage types:
General Purpose SSD – also called gp2, this storage type
offers cost-effective storage that can be used for a broad range of different
workloads. These volumes deliver single-digit millisecond latencies and the
ability to burst to 3,000 IOPS for extended periods of time. I would recommend
putting small to medium sized databases on this type.
Provisioned IOPS – This storage type is designed for I/O
intensive workloads, particularly database workloads that require low I/O
latency and consistent throughput. This is also built on SSD and targeted for
IO intensive, high performance databases. Cost wise, this is the highest of the
three storage types.
Magnetic – This storage type is mostly used for backward
compatibility. Amazon recommends using gp2 or Provisioned IOPS for any new
builds. This is ideal for test and dev environments when performance isn’t a
concern. This is the cheapest of the three storage types.
One more item to consider when planning the deployment
is network connectivity. Applications will more than likely need to connect to
your RDS environment so there are a few import concepts to look at it.
Availability Zones – this is simply a data center in an AWS region. The following AWS regions exist.
RDS Availability Zones
Virtual Private Cloud – also called VPC, this is an
isolated virtual network that can span multiple Availability Zones. It’s used
to group different types of resources to the network that need to talk to each
other.
Virtual Private Cloud – also called VPC, this is an isolated virtual network that can span multiple Availability Zones. It’s used to group different types of resources to the network that need to talk to each other.
Now that we’ve outlined some of the deployment planning
tasks, let’s build an instance through the AWS console.
Once inside the console, we’ll click on RDS under the Database heading:
RDS
Once we are on the home page for RDS, we can click Create Database under Get Started. There’s also info for Pricing and costs and some documentation on getting started:
RDS Homepage
Notice in the top right corner is the Availability Zone in which you are logged into. In my case, I’m logged into US East (Ohio) since I’m on the Central Time Zone and Ohio is located closer to me than any other zone:
RDS Availability Zone (selected)
Back to the Select Engine page. For this post, I’m going to install Microsoft SQL Server Express, but you can see the other database engine platforms that are available and the associated editions:
RDS Database Platforms
Next page we can see some of our database details. There are all items we discussed in the planning deployment section above. License model, DB engine version, DB instance class, Time Zone, Storage Type and allocated storage are all configurable on this page. Below are my selections:
RDS SQL Instance Specifications
Scroll down to Settings header and configure the DB instance identifier, Master username and password. The DB instance identifier is a unique name for your DB instances across the current region. For this RDS instance I’ll name it SQLFreelancer:
RDS Database Identifiers
On the Advanced Settings page we’ll configure Network and Security, Windows Authentication, Database Options such as port number, Encryption (where available), Backup retention, Monitoring, Performance Insights, Maintenance options, and Deletion protection. I’m going to choose all the defaults for this post, but this is a page where you want to make sure you choose what is best for your environment.
RDS Database Advanced Settings
Once you are finished on the Advanced Settings page, click Create Database.
Now how easy was that? Creating a new DB instance took about 2 minutes. Once your instance is created let’s click on View DB Instance details:
The details page gives you all sorts of info about your instance:
As defined by Amazon, Amazon Relational Database Service
(Amazon RDS) makes it easy to set up, operate, and scale a relational database
in the cloud. It provides cost-efficient and resizable capacity while
automating time-consuming administration tasks such as hardware provisioning,
database setup, patching and backups. It frees you to focus on your
applications so you can give them the fast performance, high availability,
security and compatibility they need.
RDS is also referred to as a Database as a Service
(DbaaS) or Platform as a Service (PaaS) not to be confused with Infrastructure
as a Service (IaaS) which we’ll discuss in the next paragraph.
DbaaS
vs. IaaS
DbaaS
IaaS
You can choose any DB platform such as
Oracle, MySQL, SQL Server, Amazon Aurora, PostgreSQL, and MariaDB
You create a Virtual Machine and install
OS and DB platform such as SQL Server
DbaaS takes care of backups, High
Availability, Patching, OS, underlying hardware
Iaas will only take care of the VM host
layer and it’s hardware. You will need to manage patching, HA, security, etc.
This is essentially like an on premise server.
Being an Operational DBA, there are a few tasks that RDS
will take over freeing up time for the DBA to focus on other things. Some of
those tasks include the following:
Backups: RDS will continuously take backups
and allow point in time restore capabilities. We no longer have to worry about
disk space or archiving backups to another location.
HA: RDS can automatically setup mirroring to
another data center which allows for redundancy of databases.
Patching: RDS will automatically patch your
SQL Server based on a maintenance window defined by you.
Add Resources such as CPU/Memory: RDS can
increase CPU or Memory on demand as opposed to managing an on premise where the
server might need downtime and you would have to orchestrate the change with
Server Administrators.
Upgrade: With a push of a button you can
automatically upgrade SQL Server and easily roll back if necessary.
Monitoring: Instead of buying a third party
monitoring tool and running through the setup RDS provides a service called
CloudWatch that can easily tap into SQL Server and alert when things go wrong.
Wow! All of these items make managing a SQL Server much
easier for a DBA right? Do you even need a DBA if you’re running RDS? Of course
you do! While it does make some tasks easier for a DBA, RDS will not do the
following:
Write queries, tune queries, test queries:
RDS has no knowledge about the data in each DB. Only a DBA knows the
application and business processes to write and tune queries.
Manage DB security, change control,
configuration settings: Only a DBA familiar with all of the procedures of his/her
company can really make sure the environment is secure, that all changes are
being documented, and that a specific configuration applies to what the
databases are supposed to do.
Tune indexes or maintenance: Again, only the
DBA knows what databases might need indexes or aren’t using specific indexes.
You also know when to run maintenance procedures.
Now that we’ve discussed some of the pros and cons, why
do businesses use DbaaS?
The speed of provisioning increases business value
because instead of waiting weeks to bring a server online including purchasing
software, servers, licenses, managing resources, etc. you can click a few
buttons in the Amazon console and have a fresh SQL Server online in a matter of
minutes.
The automation of regular tasks means there’s less
possibility of human mistake and less hours spent by the admins patching and
managing certain parts of the servers, which means no more late nights.
Employees can now spend more time query tuning, deploying new functionality,
and making sure the performance is the best. All of this leads to increased
revenue for the business.
