In this article, part of our ongoing series on Azure DevOps, we're diving into how you can deploy Azure SQL Server using Bicep. This process allows you to deploy an Azure SQL Server, generate its connection string, and then pass this connection string into another Bicep file that sets up an App Service in Azure.
Before we get started I'd like to point out that I'll only show certain parts of the Bicep files just to keep this article as short as possible, but you can find the repository link at the end of the article.
How The Bicep Files Will Work
Variables: We will get the DB_ADMIN_USERNAME and DB_ADMIN_PASSWORD from our Azure DevOps pipeline variables.
PowerShell Script: These variables will then be fed into our PowerShell script, which will trigger the Bicep deployment.
SQL Server Module: A separate Bicep module will handle the creation of the SQL Server, generating a connection string as an output.
App Service Module: This connection string will then be used as a parameter in another Bicep module that creates the App Service.
Configuration: The connection string will be added to the App Service configuration under the connection strings instance.
SKU and Tier: We also have a JSON configuration file that specifies the SKU and tier of the database, which for this example will be Basic.
Bicep Code Explained
The main.bicep file combines the modules for the SQL Server and the App. The SQL Server module gets its parameters like databaseSku, databaseTier, databaseAdminUserName, and databaseAdminPassword from the main Bicep parameters.
Here is a snippet from main.bicep:
module sqlServer 'sqlserver.bicep' = {
name: 'sqlserver'
params: {
prefix: prefix
location: location
sku: databaseSku
tier: databaseTier
administratorLogin: databaseAdminUserName
administratorLoginPassword: databaseAdminPassword
}
}
The sqlserver.bicep module is responsible for creating the SQL Server. It also generates a connection string which will be outputted and used by the app.bicep module.
output dbConnectionString string = connectionString
The app.bicep module creates the App Service and attaches the SQL database to it via the connection string.
param connectionString string
resource webApp 'Microsoft.Web/sites@2022-03-01' = {
// ... (other properties)
properties: {
// ...
siteConfig: {
connectionStrings: [
{
connectionString: connectionString
name: 'DefaultConnection'
type: 'SQLAzure'
}
]
}
}
}
The prod.json/qa.json configuration files will specify database details such as its SKU and tier. We can use different values according to our environment. In this case, I'll use Basic for both, but in real-world applications, you might use a lower tier for non-prod environments and a more powerful one for the production environment.
{
"parameters": {
"databaseTier": {
"value": "Basic"
},
"databaseSku": {
"value": "Basic"
}
}
}
The full source code is available on this Azure DevOps repository:
https://dev.azure.com/bujdea/_git/AzureDevopsYamlPipeline
Conclusion
In a real-world application you would also configure database backups using Bicep, allow managed identity authentication, and so on... but for this tutorial, I wanted to keep things simple and show you how easy it is to spin up an Azure SQL Server instance using Bicep. If you would like me to expand on this topic just drop a comment below 👇
