Dmitri Korotkevitch walks us through creating a home lab with Docker containers:
Obviously, in the real life, we do not work with vanilla SQL Server installation. We need to customize it by changing SQL Server settings and logins, creating and/or restoring the databases and do other actions. There are a couple of ways how you can do that.
The first approach is customizing existing container manually and creating the image from it using docker container commit command. After that, you can start the new containers from created image the same way as we already discussed. We will cover a couple ways to move data to and from containers later.
There is the better way, however. You can automate this process by utilizing docker build command. The process is very simple. You just need to define DockerFile, which contains the reference to the main image and specifies the build actions. You can copy scripts and database backups into the image, run SQLCMD, BCP and PowerShell scripts there – you, pretty much, have the full control. Internally, Docker runs every command inside deployment containers (creating and destroying them during the process) saving the final one as the target image.
Read the whole thing.
Up until now Azure Container Instances only had one option to allow us to connect. That was assigning a public IP address that was directly exposed to the internet.
Not really great as exposing SQL Server on port 1433 to the internet is generally a bad idea: –
Now I know there’s a lot of debated about whether or not you should change the port that SQL is listening on to prevent this from happening. My personal opinion is, that if someone wants to get into your SQL instance, changing the port isn’t going to slow them down much. However, a port change will stop opportunistic hacks (such as the above).
But now we have another option. The ability to deploy a ACI within a virtual network in Azure! So let’s run through how to deploy.
Click through for those instructions.
Kevin Sookocheff explains some scenarios in which stateful Kubernetes services can work well:
With leader election, you begin with a set of candidates that wish to become the leader and each of these candidates race to see who will be the first to be declared the leader. Once a candidate has been elected the leader, it continually sends a heart beat signal to keep renewing their position as the leader. If that heart beat fails, the other candidates again race to become the new leader. Implementing a leader election algorithm usually requires either deploying software such as ZooKeeper, or etcd and using it to determine consensus, or alternately, implementing a consensus algorithm on your own. Neither of these are ideal: ZooKeeper and etcd are complicated pieces of software that can be difficult to operate, and implementing a consensus algorithm on your own is a road fraught with peril. Thankfully, Kubernetes already runs an etcd cluster that consistently stores Kubernetes cluster state, and we can leverage that cluster to perform leader election simply by leveraging the Kubernetes API server.
Kubernetes already uses the Endpoints resource to represent a replicated set of pods that comprise a service and we can re-use that same object to retrieve all the pods that make up your distributed system. Given this list of pods, we leverage two other properties of the Kubernetes API: ResourceVersions and Annotations. Annotations are arbitrary key/value pairs that can be used by Kubernetes clients, and ResourceVersions mark the unique version of every Kubernetes resource in the cluster. Given these two primitives, we can perform leader election in a fairly straightforward manner: query the Endpoints resource to get the list of all pods running your service, and set Annotations on those resources. Each change to an Annotation also updates the ResourceVersion metadata. Because the Kubernetes API server is backed by etcd, a strongly consistent datastore, you can use Annotations and the ResourceVersion metadata to implement a simple compare-and-swap algorithm.
Google has used this approach to implement leader election as a Kubernetes Service, and you can run that service as a sidecar to your application to perform leader election backed by etc. For more on running a leader election algorithm in Kubernetes, refer to this blog post.
This is one of the parts that container services like Docker are striving to answer, but I don’t think they have it quite nailed down yet.
Andrew Pruski walks us through setting up SQL Server 2019 CTP 2 on Linux with Docker for Windows:
If you’ve been anywhere near social media this week you may have seen that Microsoft has announced SQL Server 2019.
I love it when a new version of SQL is released. There’s always a whole new bunch of features (and improvements to existing ones) that I want to check out. What I’m not too keen on however is installing a preview version of SQL Server on my local machine. It’s not going to be there permanently and I don’t want the hassle of having to uninstall it.
This is where containers come into their own. We can run a copy of SQL Server without it touching our local machine.
Click through for the step-by-step.
SQL Server 2019 is now available on Red Hat Enterprise Linux as a Red Hat Certified Container Images and Ubuntu-based container images enabling you to take advantage of the latest SQL Server engine innovations such as new SQL Graph features, and Data Discovery and Classification. We are also making it possible to adopt SQL Server in containers with existing scenarios such as Replication and Distributed Transaction which are now part of SQL Server 2019 on Linux.
This makes it easier to get started with SQL Server 2019 without potentially messing up your already-working systems.
I strongly urge anyone with an interest in learning Kubernetes to watch this presentation, as it makes a great job of explaining Kubernetes from the ground up.
“Out of the box”, Kubernetes will look after scheduling. If there is a requirement to ensure that pods only run on a specific set of nodes, there is a means of doing this via label selectors, as documented here. A label selector is a directive of influencing resource utilization related decisions made by the cluster.
Read the whole thing.
Melody Zacharias shows us how to remove the Windows container service from a machine:
This week I wanted to try out a new product from a vendor. I thought I may use it for a demo so wanted to be able to run it on my laptop. You never know when you go to do a demo and cannot access Azure, so I try to always put my demos on my laptop as a backup; just in case….
The product required me to remove all previous versions of windows containers on my machine. The vendor recommended I use this posh command.
Remove-WindowsFeature ContainersI was fairly sure I did not have any but wanted to check to make sure.
Melody walks through a few tricky issues, including the difference between the command on Windows 10 versus Windows Server.
Praveen Sripati shares an opinion on where the various Hadoop and Big Data platforms are headed:
The different Cloud Vendors had been offering Big Data as a service for quite some time. Athena, EMR, RedShift, Kinesis are a few of the services from AWS. There are similar offerings from Google Cloud, Microsoft Azure and other Cloud vendors also. All these services are native to the Cloud (built for the Cloud) and provide tight integration with the other services from the Cloud vendor.
In the case of Cloudera, MapR and HortonWorks the Big Data platforms were not designed with the Cloud into considerations from the beginning and later the platforms were plugged or force fitted into the Cloud. The Open Hybrid Architecture Initiative is an initiative by HortonWorks to make their Big Data platform more and more Cloud native.
It’ll be interesting to see where this goes.
Kellyn Pot’vin-Gorman has a new series on learning Linux for SQL Server DBAs:
As this series of articles are published, it will be important that you have a way to do some hands on with Linux, not just read about this powerful operating system. To accomplish this, my recommendation is to download Docker for Windows.
Choosing to use Docker over a VM or a cloud deployment might seem odd at first, but I’ve found that Docker is the perfect option from the testing and classes I’ve led. The Docker image is light–using a minute number of resources on any laptop. Access to the docker image isn’t dependent upon Wi-Fi or the user having a cloud account. The image, for the most part, offers an experience that is incredibly similar to a full Linux server in functionality for no additional cost.
Once you’ve downloaded Docker and have it installed, create a Linux container with SQL Server on your workstation, (thanks to Microsoft) to work with and build your knowledge. Start by opening a Command Prompt, cmd from the search option in Windows.
This post is mostly setup and updating packages. I also want to pitch We Speak Linux if you’re in this boat. Kellyn did our inaugural webinar, too.
Kellyn Pot’vin-Gorman has a set of tips for working with SQL Server on Linux using Docker:
Easy Download
Docker is available for Mac and Windows with a simple installation by the defaults.
- Download the correct installation for your OS type.
- Run the installer and keep all the defaults, choosing Linux containers, not Windows containers
- Reboot Windows workstations- Done.
Incredibly Simple MSSQL Container Install
Microsoft has done a great job of creating a very small, (maybe a bit too small, but we’ll get into that later…) image that can be used to create a running Linux container with SQL Server. This grants to student a great opportunity to simulate much of what it would be like to work on a real Linux server.
Click through to read the whole thing. And Kellyn’s not kidding about the image missing basic packages.
Kevin Feasel
2018-10-16
Containers
No Comment