Using local repositories with SQL Server on Linux

Reading Time: 4 minutes

In this post I want to cover using local repositories with SQL Server on Linux. Because I discussed with my colleagues recently about offline installations of SQL Server on Linux.

In reality, it is something that has been on my mind for a while now.

To install SQL Server on Linux onto a server which has internet access you usually run a command. This command then installs SQL Server using files stored online. Microsoft hosts these files online in a secured area configured to host install sets.

In the Linux world the location where these files are stored are known as repositories. Which you can read more about in detail here.

From what I have seen, to do SQL Server installations and updates on servers with no internet access is similar for all versions of Linux. For these servers you have to download a file and then run a command to install it.

Now to do this on multiple machines you might have to manage this using a tool like cron. Cron is a scheduling tool you can use in various Linux distributions. You can find out more about it in detail here.

Now, if you come from a Windows background using cron to install SQL Server on multiple servers can seem a bit complex.

In addition, it may appear to be hard to manage with many servers. Especially if have limited Linux experience and you are have used applications like SCCM to manage all your SQL Server updates.

For instance, to install SQL Server on RHEL based servers you first have to download an rpm file. Afterwards, you have to work out how to use cron to copy it to multiple locations and install SQL Server on various servers.

Local repositories

Now, some of you more experienced Linux users probably know there is another way to do this. When I previously had to create a Hadoop environment I had to implement a local repository.

In other words, I copied the contents of the online repository locally and created my own repository on a server.

That way I could manage installing software onto multiple clients using the same secured files in a local location instead of online. Which means I could install using the same method I would have done with internet access.

Proof of concept

Now, because I have been thinking about this for a while I did a small proof of concept of this using a CentOS distribution. Because it had been a while I did use this post here as a rough guide.

Of course, there are other Linux distributions and variants you can install SQL Server on instead of CentOS. You can read more about the various Linux distributions you can install SQL Server on in my previous post here.

Installation

I installed the Server GUI version of CentOS on a virtual machine. Afterwards I installed the latest updates on there. Which I recommend when testing on virtual machines based on RHEL. Be a bit more cautious if thinking about installing updates on your production servers.

Anyway, after the update I installed various components using the yum installer, such as NGINX and Createrepo. I briefly explain these two below as they are important.

NGINX is a web server which you need installed so that client machines can connect remotely to the repository. You can read more about nginx in detail here.

Createrepo is something I have used with RHEL based distributions previously. It allows you to clone an online repository locally and you can read the about it in detail here.

Configuration

After doing the installations I then cloned the online repository for SQL Server 2019 CTP 2.4 onto my virtual machine and configured the local repository.

I admit there were a few teething issues doing this. For example, I had to create a new xml file which did not exist in the local repository for it to work.

Afterwards, I set the default page of NGINX to point to the location of the local repository. At first it did not work, however it did after further configuration changes and a server reboot.

Client server

Afterwards, I then built another CentOS server and installed the relevant updates. I then configured it to point to the new local repository on the other server to install SQL Server.

Again there were some teething issues, but it worked in the end. I then went into the browser on the client and checked I could view the local repository and the files on the other server.

Once that was done I tested installing SQL Server 2019 onto the new server using the local repository. I was expecting more issues, however it worked fine. Which means my theory about using them instead works.

Managing installations

Now you could manage SQL Server installations across the estate at scale using this method.

For example, you could clone various versions of SQL Server from the Microsoft repository online. Which you then use to deploy to many servers which are offline.

Microsoft offerings

In addition, Microsoft could extend the functionality of one of their own deployment tools to host local versions of their repositories.

Alternatively, they could develop a new one especially for various Linux distributions.

Other possibilities

If Microsoft provided a solution to manage local repositories then they could also use it to manage other applications as well.

For example, it could be used for Azure Data Studio if a repository for it becomes available. I did submit a request previously on GitHub to the team and they told me they intend to look at some stage.

Of course, you could look to develop your own solution to manage local repositories instead of waiting for one to be made available.

Final word

As you can see using local repositories with SQL Server on Linux can be used as an alternative to manage your SQL Server updates. And I would love to know people’s thoughts on this topic.

What do you think about using local repositories? Do you see this as a valid way to manage your updates or do you think the current way is fine?

Do you think Microsoft should look at the possibility of implementing this as well, or should they stick to what they are doing now? Interested in everybody’s thoughts so leave a comment.