What is new in Azure Bicep v0.6?

Hello freinds,

Thank you everyone who has landed in this page to check out my Global Azure 2022 session – What is new in Azure Bicep language?

I had a great joy while interacting with a number of attendees.
Thank You for checking this blog and please feel free to reach out back with your questions.

What is new in Azure Bicep language?

As you might know, the Azure Bicep language brings a new Infrastructure as a Code (IaC) approach to manage your Azure resources in a clean way.
We also have a classic ARM JSON template that is/was traditionally used to define Azure infrastructure resources in a declarative way.

However, it is not easy to author and maintain ARM JSON templates when your project grows in complexity.

A demo screenshot from the session

But, I have good news for you – Microsoft infrastructure team has been working on new language to ease this process. Thus, an Azure Bicep language is created to simplify management of your infrastructure while re-using the code.

In this, I have introduced new features and capabilities of Azure Bicep v0.5 & v0.6 language. You also see demos on how it is simple to create, manage a modularized Azure infrastructure-as-code, while using familiar tools and extensions on VS Code.

A screenshot from the slides

If you missed this session, no worries, you are covered, as this session was recorded. It is freely availiable on the #cloudmarathoner πŸ– ⏩ YouTube channel here.

The slides and as well as links to the recommended resources are posted on my πŸ– 🍴 GitHub repo here.

Please, feel free to check up this GitHub repo, share & fork it as you like πŸ‘

Simplifying Azure IaC with Azure Bicep child resources

Hello Cloud Marathoners,

The infrastructure-as-code (IaC) is not a just a “buzzword”, it is brought by a necessity to manage your digital estate more predictably while source-controlling the changes that are introduced over time. In its turn, this approach makes it easier to keep your workload environments compliant and saves ton of time in troubleshooting, development and auditing your resources

In this post, we will look into the necessity of child resources in Azure and how Bicep language simplifies their management and declaration as a code.

why azure bicep child resources?

There are a number of scenarios where it makes perfect sense to declare resources within the context of their parent. For example; storage blob containers could not be declared and used without a parent storage account.

In addition to Blob containers, there are many other child resource types in Azure like:

  • Virtual network subnets
  • SQL databases
  • Azure Cosmos DB containers
  • SQL databases
  • VM extensions

How could you define child resources?

Unsurprisingly, there is more than one way to define Azure Bicep child resources. Each approach will depend on a specific use case that you or your team is looking forward to delivering.

Further we will use the example of a storage account resource to describe different options of child resource declarations. This will make it easier to describe the concepts and available options to you. However, these concepts could be easily used on other Azure services like VMs and VNets that do have child resources too.

All the options and sample codes are available on Learn-Bicep GitHub repo page.

Option-1 : Child resource created with reference to parent

Our first option is declaring a child Blob container resource as a separate independent resource with a reference to a parent resource. Like, it is illustrated on the example screen-shot from the Learn-Bicep repo.


For this option to work, we would need to declare an Azure Storage Blob service too. Let’s look into how it could be done while considering a second option.

Option-2 : Including a child resource in the declaration

Our second option is declaring a Storage Blob service resource as a separate independent resource with a reference to a parent Storage Account resource. Then it has an inner declaration for a container child resources within the Storage Blob service.

Let’s look at the example screen-shot from the Learn-Bicep repo.

This option might be an ideal approach if you have few child resources in your declaration. However, it would not be the most efficient one to use, if the number of child resources you are required to deploy is in dozens, hundreds or even thousands.

Option-3 : Automation and looping with enumeration πŸ™‚

The final option will serve you well, if you have 100s of pre-defined containers that should be deployed into your Azure environment.

By leveraging the “iterative loops” in Bicep we can easily iterate over these containers while creating them in a compact and repeatable manner, like in the following screen-shot from the repo code.


Looking for more Bicep goodness?

A community of developers and engineers started a great initiative – to help everyone to learn Azure Bicep for #free by sharing & contributing to the AWESOME-Azure-Bicep GitHub repo.

Please, like ⭐ subscribe 🍴 & fork it πŸ‘
As always #SharingIsCaring

summary

In this post, you have learned about three different options to declare Bicep child resources.

All code samples and presented Bicep files are placed in β€œLearn-Bicep” GitHub repo πŸ‘‰ https://github.com/ElYusubov/Learn-Bicep/blob/main/samples/14-deploy-child-parent-scenarios.bicep πŸ‘

Would you be interested in a recorded short video that demonstrates these capabilities ?

Latest updates on OSS 🧑 AWESOME Azure Bicep πŸ’ͺ

Hello Cloud Marathoners!

As you were informed in my last post, I have published a new GitHub repo to help the community and new learners with Azure Bicep resources. The new repo – AWESOME Azure Bicep πŸ’ͺ is getting a high interest from all of you.

Thank you very much for accessing, starring ⭐ and forking 🍴 it!
If you learn about it now, please check it out here.

And this is not all. We have plenty of room to grow this repo with the latest contributions from you.

Two new contributors

In less than a week, we got two great contributions from Kasun Rajapakse and Luke Murray πŸ™Œ. Thank you very much for your contributions!

Get started with Azure Bicep

Let’s step-up your game and start learning the latest πŸš€ Azure #infrastructureascode language (aka, Bicep).
I sincerely invite you to become a part of this really great “learn and share” initiative of Azure Bicep.

Share your interest and knowledge with the community by opening your very first GitHub PR.

Looking for a video course on Azure Bicep ?πŸ€”
>> Azure Bicep First Look πŸ‘‰Β https://lnkd.in/eWsxf3hjΒ is here to help!

Summary

This project is growing and let’s become a part of this Azure Bicep community !

Ready to make your first PR to Awesome Azure Bicep repo?
Please check out the contribution guide or reach out if you need help in this process.

What are the good options to manage sensitive info in Azure Bicep?

Hello Cloud Marathoners,

Every seasoned IT professional knows that sensitive information should not be exposed as a clear text on any code. This is especially true for infrastructure-as-code (aka, IaC) scenarios where passwords and keys are part of the deployment.

One way to stay compliant in accomplishing this goal is the integration of an Azure Key Vault service into your deployment code. This Azure security service is primarily intended to store sensitive information like password, keys, certificates, connections, etc.

In this post, we will look into two different ways how we could integrate Azure Key Vault services in our Azure Bicep code.


Option – 1: Using getSecret() function

Our first option is to delegate this important work to a getSecret() function. This option could be used with an existing Azure Key Vault resource that is declared in your Azure Bicep code.

Let’s look into an example where an existing Azure Key Vault service is referenced to provide administrative password for SQL server deployment.

Deploying Azure SQL instance with Azure Key Vault

This sample Bicep code is using sqldb.bicep file as a module, where parameters; such as sqlServerName and adminLogin are passed through with a secret name of ExamplePassword.

The ExamplePassword secret name should be already set and ready in the referenced Key Vault service above. Here is the view of this secret on Azure portal.

Azure Key Vault with secretes in portal

Let’s have a quick view into the sqldb.bicep file, as it is referenced in the main Bicep file.

sqldb.bicep file

Now, let’s deploy these resources with a secret value from Key Vault resource that has a secret name ExamplePassword.

What happened? I am getting an error on my first deployment execution πŸ™

Error on deploying Bicep code with SQL server provisioning

Upon carefully analyzing error, I see the following reason for this error:

At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.”,”details”:[{“code”:”RegionDoesNotAllowProvisioning”,”message”:”Location ‘East US 2’ is not accepting creation of new Windows Azure SQL Database servers at this time.

Azure deployment error

Based on the error message, we change the location to eastus and re-run the script. Now, we got the following positive result in console and portal:

Deployment results in Azure Portal RG

Next, we will attempt to login into a SQL Server instance.
A successful login will look like the following screen:

Successful login into the SQL instance

Important Note:

If you are getting an error during the login then try to check the following steps:

  • adminLogin name is entered correctly
  • your IP address is added to the SQL server firewall rules
  • grab a cup of coffee and check back in 5 minutes

Description of a typical login error into a SQL server instance is provided below. I checked the firewall rules and made a cup of coffee => before getting a successful log-in πŸ™‚

Requires your location IP activation

Option -2: Referencing as a secretName in parameter

The second option is pretty straightforward, if you have already used it on ARM template deployments.

Note: Please check out the following post – Four parameterization options for your Azure Bicep deployments for detailed information on available options.

We just need to reference Azure Key Vault secret like in the following example:

Using a parameter file and referencing the Key Vault secretName will do the trick in extracting the value and provisioning your resource.

Let’s run the bicep file that deploys multiple RGs and an Azure VM that uses VMPassword secret.

Running deployment with Bicep parameter file

A successful deployment provisions following RG with the VM resources:

Next, we should smoke test our deployment by locating the resource group “rg-demo-vm-1116” and using deployment parameters to RDP into Windows server:

Finally, we are able to see that secret and admin user name pair worked as expected

Azure VM deployed using Key Vault secret

Summary

In this post, we looked into two available options that harden our infrastructure code by removing hard-coded sensitive information and replacing it with Azure Key Vault reference. Thus, avoiding any potential leaks of passwords, secrets, etc.

IMHO, first option is better than the later one, because it does not expose subscription id and other small details.

What will be your choice? Please, share on LinkedIn post comments section.

Thank you for your interest my #cloudmarathoner friends!
Please, check other Azure Bicep posts and let me know your feedback.

What is next?

All code samples and presented Bicep files are placed in “Learn-Bicep” GitHub repo πŸ‘‰ https://lnkd.in/ds-h9VQx

Please, join me to learn more about Azure Bicep πŸ’ͺ on an Omaha Azure User Group meetup scheduled to happen on November 17th.

Azure Bicep presentation for Omaha Azure User Group

Hello friends,

I am very excited to see you all in the next Omaha Azure User Group meetup. This time we will speak about the latest advancements and use cases you could apply in your Azure resource authoring toolkit.

This meeting will take place on November 17th, starting at 6 PM CST. Details of the event are posted here: https://lnkd.in/gzh_sF8e and on my LinkedIn post.

Please, make your registration at the meetup website here.


Support & Subscribe toΒ #cloudmarathonerΒ LinkedInΒ tagΒ πŸ‘πŸ‘€
Stay tuned for more Azure, Automation & Security related posts.

Fᴏʟʟᴏᴑ ᴍᴇ 🎯 α΄€Ι΄α΄… become α΄€Β #cloudmarathonerΒ β›…πŸƒβ€β™‚οΈπŸƒβ€β™€οΈ – 𝐋𝐄𝐓’𝐒 π‚πŽπππ„π‚π“ πŸ‘

Festive Tech Calendar 2021 event

Hi Cloud Marathoners,

As you may know, it is that time of a year when great content will be coming to the town! You could enjoy and learn throughout the month of December, as people behind the #festivetechcalendar will be bringing you lots of new content from different communities and people around the globe.

https://festivetechcalendar.com/

This year, I have submitted two sessions and have been nicely surprised yesterday. Both sessions have been accepted and I am looking forward to deliver following sessions for the community:

Session # 1: What you need to know about Azure AD security defaults?

Accepted session – “What you need to know about Azure AD security defaults?


In this session above, we will discuss about how to get started with Azure security on right foot and its challenges. We will focus on importance of a strong Identity and Access in any cloud solution that we are creating for our customers. One simple way to get started is review and adjustment of security default options in Azure AD. We will also look into the set of practices to get you started with Azure AD setup and learn about the benefits of Azure Security Benchmark.

Session # 2: All you need to know about Azure Bicep configurations

Accepted session -“All you need to know about Azure Bicep configurations”

In the second session, we will talk about Azure Bicep – a new language that aims to ease Azure resource authoring and management. This new language comes with a powerful VS Code extension and config file options.
In this session, we will unveil dozens of powerful features in our config file to suit your style of coding on VS Code and cheer up our productivity skills. We will apply our fresh skills by creating several Bicep demos in the process. 

Conclusion

I sincerely hope that these sessions will spark your interest and I am looking forward to see you all during this event. But most importantly, I hope you could have lots of fun during this festive month.

Stay tuned for more Azure AD, Automation & Security related posts.

Fᴏʟʟᴏᴑ ᴍᴇ 🎯 α΄€Ι΄α΄… become α΄€ #cloudmarathoner β›…πŸƒβ€β™‚οΈπŸƒβ€β™€οΈ – 𝐋𝐄𝐓’𝐒 π‚πŽπππ„π‚π“ πŸ‘

Hardening parameter inputs on Azure Bicep files

Hello Cloud Marathoners,

In my previous Azure Bicep post, I wrote about four parameterization options that could be used with Bicep language. We also looked into the Azure Bicep resource templates, and how they help to author and manage Azure resources more cleanly and easily.

Azure Bicep Tips – Hardening parameter inputs

Now, I would like to share a couple tips on how to harden your parameter inputs. This will help you to avoid deployment errors that you could easily prevent by restricting and checking Bicep parameter values.

Tip # 1: Min and Max length of resource names

In our previous post, we have built and demoed the webapp-service-w-param.bicep file. It had no parameter input validation. Thus, that template is open for failures when you enter 'a' for the appServiceAppName input parameter. Here is the link to the repo.

webapp-service-w-param.bicep

However, it is pretty straightforward to avoid such false entries by checking the allowed name length of the Microsoft.Web/serverFarms resource in the Microsoft docs Resource name rules page.

Based on “Resource name rules” page we can add following functions:

The @minLength and @maxLength function are going to define and enforce min and max length of the parameter, while @description will help to define the purpose of the parameter.

Tip # 2: Defining purpose of the parameter

It is always helpful to add meaningful description to your parameters, even though it is not required by Azure Bicep template. Believe it or not, people who are new to your code will appreciate it. For example: we have a location parameter in our template, and adding the following description clarifies the purpose of this parameter for everyone, including myself, later in a month when I am re-visiting my code.

Tip # 3: Restricting parameter value entries that match your organization’s policy

The final tip is already revealed in our screen-shot above. It makes a valid and important sense to enforce your organization’s Azure policies on any provisioning scripts, in addition to the Azure Policies.

In our example: we are restricting deployment of Azure resources only into the following Azure regions to comply with the company policy to make every party happy.

Thus, I have shared a few tips that you could use to harden your Azure Bicep code and avoid some common deployment errors in advance.

Here is the complete view into our hardened webapp-service Bicep file:

Summary

Preventing deployment failures, especially the once that are caused by invalid input parameters are an easy fix on an Azure Bicep language. Checking the resource name restrictions and allowed values is one easy tip to prevent those errors. I would recommend checking the Microsoft documentation on “Naming rules and restrictions for Azure resources” and bookmark it for your reference.

Thank you πŸ™ for reading this post and learning how to prevent Azure Bicep deployment failures by hardening the input parameter values.

Please check out the Learn Bicep GitHub repo, and follow it.
Thanks, πŸ™ πŸ™Œ!

Stay tuned for more Azure automation & Azure Bicep posts.

Fᴏʟʟᴏᴑ ᴍᴇ 🎯 α΄€Ι΄α΄… become α΄€ #cloudmarathoner β›…πŸƒβ€β™‚οΈπŸƒβ€β™€οΈ – 𝐋𝐄𝐓’𝐒 π‚πŽπππ„π‚π“ πŸ‘

Four parameterization options for your Azure Bicep deployments

Hello Cloud Marathoners,

In my last posts, I wrote about Azure CL and a Bicep language. The Azure Bicep language, helps to author and manage Azure resources more cleanly and easily on your Azure subscription.


The parameterization of infrastructure deployment files is an important skill where true power of automation and code reuse comes forward.
Let’s learn about different parameterization options that you could use in your Azure Bicep deployments. As an example, we will examine the following parameterization options on an Azure Bicep web app deployment file.

βœ”οΈ Using Bicep file as is

βœ”οΈ Using default parameters on your bicep file

βœ”οΈ Simply adding parameters into your command line

βœ”οΈ Using a separate file for parameters, per environment

Option 1: Using Bicep file as is

This first option is the most straightforward way to declare your parameters. However, you would have to enter each parameter name, every time you are deploying the Azure resources.

Following screenshot is a default Bicep web app declaration with parameters. Check the Learn Bicep repo here πŸ‘


Now, let’s declare an Azure CLI command that will deploy our Azure Bicep file into a Resource group.

# Create a rg-test-deploy RG
az group create -l eastus -g 'rg-test-deploy'

# Option-1: Run deployment file as is
az deployment group create -g 'rg-test-deploy' -f .\param-files\webapp-service-w-param.bicep

# List all webapps in the subscription
az webapp list --query [].name -o table

Option 2: Using default parameters on your bicep files

The second option will allow us to deploy our Bicep file without entering the default values each time. However, it would require an update on file each time you want to change parameter values 😒

Now, we can take the previous webapp-service Bicep file, and add its default values. The updated Bicep file will look like the following screenshot:


Our Azure CLI deployment script would just get a new file name

# Option-2: Run deployment with default values
az deployment group create -g 'rg-test-deploy' -f .\param-files\webapp-service-default-param.bicep

# You could also add preflight check with "-c" at the end of each deployment script

Option 3: Simply adding parameters into your command line script

If you would prefer to type parameters and values on a terminal then third option can deliver it for you. That script will look like the following sample:

# Option-3: Run deployment with inline parameters
az deployment group create -g 'rg-test-deploy' -f .\param-files\webapp-service-w-param.bicep -p location='eastus' appServiceAppName='param-demoapp18' appServicePlanName='asp-param-demo'

Option 4: Using a separate file for parameters, per environment

The last option has multiple advantages over prior options. As you could create separate environment parameters in their own dedicated files and manage them accordingly.
For example: You can create a separate param file for “Dev” environment deployments; like in the following screenshot.

Note: parameter files for Bicep language are using a JSON notation, similar to the way how ARM JSON declares parameter files with a following schema.

"https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#"

And our deployment script will look like the following sample:

# Option-4: Run deployment with a separate parameter file
az deployment group create -g 'rg-test-deploy' -f .\param-files\webapp-service-w-param.bicep -p .\param-files\webapp-service-parameters-dev.json

# List all webapps in the subscription
az webapp list --query [].name -o table

# Clean all resources from RG
az group delete -n 'rg-test-deploy' --yes

Summary

Thank you πŸ™ for reading this post and learning about four different options to deploy your Azure Bicep files using Azure CLI.

Please check out the Learn Bicep GitHub repo, and follow it.
Thanks πŸ™ πŸ™Œ !

Stay tuned for more Azure automation & Azure Bicep posts.

Fᴏʟʟᴏᴑ ᴍᴇ 🎯 α΄€Ι΄α΄… become α΄€ #cloudmarathoner β›…πŸƒβ€β™‚οΈπŸƒβ€β™€οΈ – 𝐋𝐄𝐓’𝐒 π‚πŽπππ„π‚π“ πŸ‘

August month updates from Azure Bicep

Hi friends,

This month we have awesome updates from Azure bicep team that I am happy to share with all of you (Azure community, Deployment Automation, Resource management and Governance geeks πŸ™‚

The following list are August month updates:

  • Bicep Linter, Snippets, Scaffolding
  • Right click build
  • Deployment Stack updates
  • Bicep roadmap plans (v0.5 and eventually v1.0)
  • Bicep registry
  • OCI Artifact standardizations
  • Module registry functionality
  • Module Reference Syntax
  • Parameter Improvement options

Bicep Linter updates

The yellow squiggly lines indicate the Linter violations and complains where best practices are violated. Like, password param should not be checked into the code repository. Another one is using string concat function instead of string interpolation.

Right click build

The right click build on bicep file is a new convince feature that was also added on new build.

You can also use a shortcut keys Ctrl+Shift+B as an alternative way to build your JSON files from bicep files.

Scaffolding feature

This feature also arrived on a v0.4.6 build that provides required-properties to be auto populated to speed up your Azure resource coding. It is derived from a resources swagger spec and auto-populated for you. Yay!

New Code Snippets

You will love to discover that bunch of new snippets has been added.

Just type res- and you will scroll over all those starter boilplet code. Just imagine how much time you will be saving. It is Huge!!!

Bicep Roadmap annoncements

Well, Bicep team annonced that next build will bring the v0.5 and they do target v1.0 by th end of the year. What does it mean is – there will be no API level breaking changes starting from the version v1.0.

What is Next?

Keep tuned for upcoming v0.5 version. The Module registry updates and syntax updates on OCI Artifacts are going to be next Huge things, as they will add into the maturity of this AWESOME tool in Azure!

Check out for more @ GitHub – Azure/bicep: Bicep is a declarative language for describing and deploying Azure resources

Stay tuned for more Azure automation & Security related posts.

Fᴏʟʟᴏᴑ ᴍᴇ 🎯 α΄€Ι΄α΄… become α΄€ #cloudmarathoner β›…πŸƒβ€β™‚οΈπŸƒβ€β™€οΈ – 𝐋𝐄𝐓’𝐒 π‚πŽπππ„π‚π“ πŸ‘

How to check and update Azure CLI version on your workstation?

Hello friends,

I was prompted to update my CLI and wanted to share this easy experience with everyone.


There is an easy straightforward process to check & update your favourite Azure CLI in a few minutes without leaving the command line tool of your choice.

There are 2 commands that you would ever need going forward, assuming that your version of CLI is already “2.x”.

Check your az cli version

Just run the az version --help command first.

Check the AZ CLI version

Running update on AZ CLI

Next, run the az upgrade command and press key Y when prompted to continue.

Upgrade the AZ CLI version

And finally, check the updated version and its extensions if needed.

Verify upraded version and Bicep

In case your AZ CLI is up to date, you could always run az bicep upgrade command and get the job done.

Stay tuned for more Azure automation & Security related posts.

Fᴏʟʟᴏᴑ ᴍᴇ 🎯 α΄€Ι΄α΄… become α΄€ #cloudmarathoner β›…πŸƒβ€β™‚οΈπŸƒβ€β™€οΈ – 𝐋𝐄𝐓’𝐒 π‚πŽπππ„π‚π“ πŸ‘