AzureFeeds

This blog post dives deep into the deployment-related aspects, aiming to clarify these choices. To provide a clear visual guide based on my experience working with customers, I’ve put together a flowchart (as seen in Figure 1) that helps navigate the decision-making process based on your specific scenario.

Please see the attachment “Decoding SQL Linux options” to access the hyperlinks as shown in figure 1.

Let’s imagine you’re a Data Engineer, a developer, or even a DBA looking to deploy SQL Server on Linux to support applications running natively on Linux or within Kubernetes environments.

The Familiar Path: Traditional Package-Based Deployments

If you prefer and value operational familiarity and find it straightforward to deploy, manage, automate, and troubleshoot SQL Server when installed traditionally on a virtual or physical machine. Or, maybe your organization has specific security and compliance requirements that favour traditional deployments. Or, you might have complex, non-containerized workloads where a traditional setup is the current preference.

If any of these resonates with you, then the “traditional virtual machine or physical machine based” deployment route is likely your starting point.

Once you’ve decided on this approach, the next step is to talk to your system administrators to understand the available and preferred Linux distributions within your environment. SQL Server installation are fully supported for production workloads for the following three choices:

• SQL Server on Red Hat Enterprise Linux (RHEL)


• SQL Server on SUSE Linux Enterprise Server (SLES)


• SQL Server on Ubuntu

Each of these options, represented as leaf nodes in the flowchart, comes with specific instructions for adding the necessary repositories based on the major version of the distribution. Following this, you can deploy the SQL Server packages and configure them according to your needs.

For specific configuration requirements, such as enabling trace flags or setting environment variables for SQL Server, you can leverage the mssql-conf utility. You can find a comprehensive list of mssql-conf options in the official documentation: Configure SQL Server Settings on Linux – SQL Server | Microsoft Learn.

Additionally, you may have a question: Can I install SQL Server for production workload on other distribution that are not listed in this flow chart or here: Release notes for SQL Server 2022 on Linux – SQL Server | Microsoft Learn, the answer is yes you may, but it comes with limited support and not recommended to run production workload. For details, refer: Support policy for SQL Server – SQL Server | Microsoft Learn

Embracing Agility and Scale: Containerized Deployments of SQL Server

Now, let’s shift our focus to the world of containers. If your priority is faster deployments, scalability, and deploying more than one SQL Server instance on a single machine then containerization is a compelling option. Containers offer a lightweight and portable way to package SQL Server and its dependencies, ensuring consistency across different environments.

As the flowchart illustrates, when you opt for a containerized deployment, you have choices regarding the orchestration platform:

Kubernetes/OpenShift Based Clusters: For production-grade workloads demanding high availability, scalability, and robust orchestration, deploying SQL Server containers on Kubernetes (or OpenShift, a Kubernetes distribution) is a powerful solution. Kubernetes provides the framework for managing container lifecycles, scaling, networking, and storage in a flexible manner. This approach is particularly well-suited for modern, cloud-native applications. If you choose to deploy SQL containers on a Kubernetes/Openshift based clusters, then you have two ways to deploy the containers:

• Manual Deployment via YAML manifests or Helm Charts: This provides fine-grained control over the deployment configuration. You define the desired state and version of your SQL Server containers using YAML files or leverage Helm charts for templating and packaging your Kubernetes applications. This as name suggests is more of a manual deployment.


• Operator-Based Deployment on k8s clusters: Operators are Kubernetes extensions that automate the management and lifecycle of stateful applications like SQL Server. We have our partner DH2i who have developed an operator that helps deploy SQL Server and Highly available always on availability group on DxEnterprise clustering stack, refer to the “Operator based deployment on k8s cluster with Always On availability group” leaf node for details.


• Azure Arc enabled data service: Using Azure Arc it is possible to run the Azure data services on-premises and in public cloud using Kubernetes and the infrastructure of your choice. You can refer to the “Azure Arc for SQL MI” leaf node to help you deploy an evergreen SQL Server, that has cloud like elasticity on-premises and has other benefits like self-service provisioning, unified management.

Standalone Host:

If you have a Windows-based machine and want to deploy SQL Server Linux container images or SQL Server Linux packages without installing a virtual machine on top of your Windows client/server, you can leverage the Windows Subsystem for Linux (WSL). This allows you to install SQL Server Linux packages or SQL Server container images directly on Windows. Note that this setup is only supported for development purposes only and is not intended for production environments or workloads. For detailed instructions, please refer to WSL 2: Install SQL Server on Windows Subsystem for Linux – SQL Server | Microsoft Learn.

If you’re using a standalone Linux host and want to deploy containerized SQL Server without setting up a full Kubernetes cluster, you can run SQL Server containers directly using a container runtime like Docker.

You can choose the container image based on your Linux distribution:

• Use RHEL-based containers on Red Hat Enterprise Linux hosts,


• SLES-based containers on SUSE Linux Enterprise Server hosts


• Or, Ubuntu-based containers on Ubuntu hosts

These options are fully supported for production workloads and are a great choice for quick deployment without a container orchestration engine like Kubernetes. Many customers use this method for production, development, testing, or smaller-scale deployments where the overhead of a Kubernetes cluster might not be necessary. While you’ll be responsible for manual orchestration and scaling in this scenario, it still offers the benefits of container isolation and simplified deployment.

Making the Right Choice for Your Needs

Ultimately, the decision between traditional package-based deployments and containerized deployments hinges on your specific requirements, existing infrastructure, team expertise, and the nature of your workloads.

Choose traditional packages when familiarity, strict compliance needs, or non-containerized complex workloads are paramount.

Embrace containers when agility, scalability, rapid deployment, and efficient resource utilization are key drivers. Kubernetes further enhances these benefits for production environments, while standalone container deployments offer a lighter-weight alternative for certain use cases.

By understanding these different deployment avenues, you can confidently choose the path that best aligns with your goals for running SQL Server on Linux. Let me know your thoughts and if you find this useful.