Running SQL Server with Docker on the Mac
Years back, when I changed from Windows to Mac, folks have informed me regularly I’m crazy. How could I be stupid to operate on MacOS when I am hooked on SQL Server? In my situation, it was not that dreadful, as my principal work is all about content production (composing blog posts, articles, presentations, and training videos), and quite often, I had been linking through an RDP connection to a remote SQL Server. So running on MacOS wasn’t a significant deal for me personally, and for the final hotel, I have a Windows VM that runs in VMware Fusion on my Mac.
But because of the Container theory debut through Docker and the chance to conduct SQL Server right at a Container, my own entire life was shifting even better. I can now run SQL Server 2017+ straight on my Mac, and I don’t desire a Windows VM anymore. Inside this blog post, I wish to explain how it is possible to do precisely the same and operate SQL Server right on your Mac at a Docker container.
Installing SQL Server in a Docker Container
Before you can set up SQL Server at a Docker Container about the Mac, then you need to configure and install Docker itself naturally. I don’t wish to enter the details of how you can set up Docker itself since the vital steps are exceptionally well recorded.
Before You Can Make a Docker Container for SQL Server, you need to pull on the correct Docker Picture from the Docker Registry. In my situation, I have decided to try out the latest CTP version of SQL Server 2019:
docker pull mcr.microsoft.com/mssql/server:2019-CTP2.1-ubuntu
When You’ve pulled the picture, you can view it using all the docker images control on your Terminal:
You’re able to consider a Docker Picture like an ISO document: it is only an image, and also, you can not run it because you need to put it in it. Therefore we have to”set up” the hauled Docker Picture. Back in Docker, you can”install” a picture by conducting it. And that produces the true Docker Container, which will be ultimately the executable which you’re executing. Let us show our Docker Picture using all the docker run control:
docker run -e ‘ACCEPT_EULA=Y’ -e ‘SA_PASSWORD=passw0rd1!’ -p 1433:1433 –name sql2019_ctp2 -d mcr.microsoft.com/mssql/server:vNext-CTP2.0-ubuntu
Because you can see in the command line, you need to pass into a lot of various parameters. Let us have more detailed research on these:
- -e ‘ACCEPT_EULA=Y’
Using the -e option, you establish an environment variable, where SQL Server depends on. In our situation, we must take the EULA to have the ability to utilize SQL Server.
- -e ‘SA_PASSWORD=passw0rd1!‘
Together with the SA_PASSWORD environment factor, we put the password to the SA login.
- -p 1433:1433
Using the -p option, we now scatter a port on the host system (in my case on the Mac) into some port from the Container. The vent on the other side of this colon would be the port to the server system, and the vent on the ideal side of this colon is the vent from the Container. In my scenario, I bind the default SQL Server interface of 1433 inside the Container into port 1433 in my Mac.
So I will immediately access the vulnerable SQL Server Container via my Mac’s IP address on the system. In case you’ve got multiple SQL Server Containers, then you may even bind them to various ports in your server machine to get them separately from one another.
- –name
Together with the –title option, we assign a custom name on our Docker Container.
- -d
With the d option, we define the Docker Picture that we’ve pulled, and you would like to conduct the Docker Container detached in the Terminal. This means you could shut your Terminal, along with your Docker Container remains running in the background.
As soon as you’ve implemented that Docker control, your Docker Container is up and operating.
Accessing SQL Server on a Mac
We’ve 2019 up to and working at a Docker Container. However, how can we get SQL Server? I will begin a Windows VM, also use SQL Server Management Studio to get SQL Server. But I’m again determined by a Windows VM, which likewise needs occasional upgrades, plus it might also be a massive overhead to set up an entire Windows VM only for SQL Server Management Studio…
So let us introduce Azure Data Studio! Azure Data Studio was previously called SQL Operations Studio. Also, it’s a client program with which you can handle SQL Server — on Windows, Linux, and Mac!!!
Because you can see in the preceding image, I’ve connected here straight to localhost. As in the previous step, we’ve subjected the interface 1433 of this Docker Container into our server system. Please do not get me compared to SQL Server Management Studio. Azure Data Studio is”fine,” but…
But hey will run it straight on my Mac (minus needing some Windows VM). I will run SQL statements, I’ve access to Estimated and Actual Execution Programs, and quite importantly — it is adaptive. What do I want more? For the type of work which I am doing, it is enough.
Restoring your first Database
When you return to the previous image, it is possible to realize that you obtained a vanilla setup of SQL Server 2019. You will find all our program databases, the most default configurations, and that is it. There is currently no additional database. So you must make your databases, or else you also take a current database (possibly in the Windows-based SQL Server setup ) and you revive it into your Docker Container. Let us do this now.
In my case, I wish to show you today the vital steps in the way to reestablish AdventureWorks from the Docker Container. To start with, you’ve got to copy your backup file to the Docker Container. However, you can not do a standard cp command in the Terminal since that control doesn’t have any thought on your Docker Container. Makes sense…
Your Docker setup extends to you the control cp with which you can copy a local file to some Docker Container and vice versa. Let us take now our copy of AdventureWorks and copy it into the folder /var/backups of the Docker Container:
docker cp AdventureWorks2014.bak sql2019_ctp2:/var/backups/AdventureWorks2014.bak
As soon as you’ve copied the backup file, we can now restore the DatabaseDatabase. However, the destination folders are somewhat distinct according to a Windows-based SQL Server setup, so we have to transfer our information and log files. So I have implemented at the very first step the next command to acquire the logical record names of the database backup.
RESTORE FILELISTONLY FROM DISK = ‘/var/backups/AdventureWorks2014.bak’
Finding the logical record names of the DatabaseDatabase…
And based on that advice, let us perform today the revive of the Database.
RESTORE DATABASE AdventureWorks2014 FROM DISK = ‘/var/backups/AdventureWorks2014.bak’
WITH
MOVE ‘AdventureWorks2014_Data’ TO ‘/var/opt/mssql/data/Adventureworks2014.mdf’,
MOVE ‘AdventureWorks2014_Log’ TO ‘/var/opt/mssql/data/Adventureworks2014.ldf’
Because you can see, I am transferring the data and log files to the folder /var/opt/MySQL/information. And today, we’ve got our AdventureWorks database revived from our Docker Container.
When You’re finished with your job on your Docker Container, then You Can Quit the Container using the next command:
docker stop sql2019_ctp2
With a docker launch control, you can restart your Container again:
docker start sql2019_ctp2
If that’s the instance, all of the modifications you’ve done on your Docker Container (such as rebuilding the AdventureWorks database) persisted across restarts.
