Azure web EndtoEnd IAC with Managed Instance

Bicep deployment flow -

Some of the main parameters I'm passing to the main Bicep template are related to environmental configuration mapping. These parameters map to the environment and location, and the same concept applies to the location and location list parameters. If an organization follows a standard naming convention for shortening environment and location names, the configuration map may not seem significantly beneficial when choosing flexibility over reduced complexity. However, the full names of locations and environments often differ from their short names, and this is where the configuration provides flexibility to match the short names to the organization's standards.

For instance, if the location is "westus," the config map will automatically use "wus" as the short name for the location. Similarly, for the environment "development," it will automatically use "dev" or "np-dev," but this may need adjustment based on the organization's short-naming standard.

In addition, the main template relies on other parameters during deployment:
Subscription: This is the subscription ID needed for completing the deployment to a particular subscription.

AppInstance Name: It's a key parameter for generating unique names for the resource group and resources within it. For example, if the organization prefix is "cxt," the location is "westus," and the app name is "bananaapp" for the dev environment, the naming prefix in the main Bicep template would generate "cxt-wus-dev-bannanaapp-RG" for the resource group. The remaining code references remove the "RG" suffix from the resource name and add the relevant resource suffix using the replace command.

The main Bicep template calls the resource group module, which creates the application resource group, and then calls other resource modules, including Application Service Plan, Web App, Database Subnet, Database Route Table (including Network Security Group for the Managed Instance), Keyvault, and Storage Account if the deployment Boolean variable is set to "yes." It also includes a User Managed Identity that can be attached to any resource for data plane deployment related to the database and web later.

There are several naming conventions and orchestration steps used in the Resource Group module to create names for various resources based on factors like environment and network resource group naming.

For example, it checks whether the network resource group contains "prd" and determines the VNET suffix accordingly. Similarly, it generates a PE subnet variable based on whether it's for production or Dev/Test/UAT.

The code also handles naming restrictions for Keyvault and Storage Account, abbreviating and ensuring the names are within certain character limits. It converts names to lowercase and removes special characters for Storage Account names.

Finally, the code discusses the deployment of Managed Instance NSG rules and routing tables, mentioning that careful planning is required beyond what's mentioned in Microsoft learn modules. It provides specific NSG and Route Table names for SQL MI and mentions other details that can be found in the GitHub repository's readme file.

GitHub Action Flow

In my GitHub Actions and pipeline job setup, I'm using Open ID connect credentials for passwordless federated access. These credentials grant contributor rights to the subscription for this specific GitHub organization and the main branch repository. To ensure security, I pass the Subscription name, TenantID, and Client ID as secrets, avoiding any exposure of this information in the code, deployment outputs, or public Git URL access.

Less sensitive information is passed as environment variables within the code, making it easy to change them from the GUI, especially for users who deploy the code but are not its authors.

I've organized my workflow into three main jobs:

Linting and Validation Jobs: These jobs run in parallel to assess the code's integrity.

Preview or What If Jobs: These jobs execute after the linting and validation jobs have completed successfully.

Deploy Jobs: These jobs rely on the output from the preview job to initiate the deployment of Azure resources.

Additionally, there is a "Smoke Test Job" that depends on the deployment job to finish before conducting tests on the web app.

Each of these jobs involves preflight validation, what-if analysis, and deployment steps, which typically include checking out the code, installing dependencies, and deploying the code.

GitHub Actions workflows consist of one or more jobs, and each job contains one or more steps. You can have multiple workflows, multiple jobs per workflow, and multiple steps per job. Triggers and events can be configured to automatically initiate workflows, or they can be triggered manually or based on code pushes.

Each job defines a runner, which is the execution environment for the job. Multiple jobs can run in parallel, but you can control their execution order using "needs" or conditional job dependencies.

The actual work within each step can involve running shell scripts or using predefined actions (scripts designed to perform specific tasks).

Code repository link -

pchettri3/web-sql-mi: none ASE web app with SQL MI (github.com)