This exam assesses the following DevOps skills: β Configure processes and communications β Design and implement source control β Design and implement build and release pipelines β Develop a security and compliance plan β Implement an instrumentation strategy
Your Support is Appreciated!
Thank you π T-Rex Solutions, LLC for a strong and relentless learning culture and for supporting my Microsoft #MVP journey π
In this post, I will be addressing a common an error that could be seen in your GitHub actions, once in a while, called “Error: Az CLI Login failed. Please check the credentials and make sure az is installed on the runner”.
I am very glad to announce the latest stats and progress on our community repo “Awesome Azure Bicep”!
What is Awesome Azure Bicep
This is a GitHub repo that helps you to learn and discover resources that are helping you with the adoption of Azure Bicep – a new #infrastructureascode approach to manage Azure resources.
Few days ago, I was really honored to receive an invitation to speak at a great “Career Panel” Q&A event from Robin Smorenburg and Kevin Evans. This event was the first organized event of Streaming Clouds.
Oh boy, it was such an interesting and honest discussion where myself and other guests honestly shared experiences and struggles, while addressing questions from the live audience.
Cloud careers with Streaming Clouds
This panel focused on addressing the following hot question: – How to break into a cloud career or how to get your career journey to the next stage?
This event covered the certifications and how to gain hands-on experience, community and personal branding, and mentorship.
Dear friends, this event was recorded and available for re-watch at the following LinkedIn url.
I have been getting many questions on how to start an Azure Bicep journey – in a special and AWESOME way π – which brought an idea to create the AWESOME Azure Bicep GitHub repo for the community π
Long story short, this has been on ideation for few days and is life now, as of Jan 18, 2022 ! π
Now, I have started gradually adding important official and community resources to help new #Azure learnersΒ and #cloudmarathoners!
AWESOME Azure Bicep repo
Please, share β and fork π΄ this repo and make your contributions.
I really ask you ππ to make your contributions and help maintain and grow this repo going forward.
Few weeks ago, I participated in the Microsoft OpenHack Containers event. This was an awesome event where I had a chance to coach a team of professionals to tackle containerization challenges.
What is Microsoft OpenHack
Microsoft OpenHack is a developer-focusedβ―engagement that connects development teams (Open)β―with experts to tackle a seriesβ―of real-world challenges through hands-onβ―experimentationβ―(Hack) in person or online (Virtual).
What was in the challenge?
We started with good old docker tooling for containers and ended up migrating those several containers and dependencies to the Azure Kubernetes Services. However, the most interesting part was applying best practices and security configurations to the migrated workloads.
Due to participation disclosure agreement, I would not be able to detail each team challenge (about 7-8). However, this was real teamwork that required learning and experimenting for all the team members.
My team went throughΒ ups and downs while trying to complete the necessary number of challenges to earn the badge. I am very happy that my team was able to complete the required challenges, learn important hands-on skills, and get theirΒ well deserved badges.
I was very pleased to help my team along their containerization journey. At the end, I feel very honored and appreciated to receive an OpenHack Containers Coach badge.
Interested to get started with containers in Azure ?
Check out the following #free resources to start your own containerization learning path in Azure:
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.
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.
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.
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.
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.
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.
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.
Bicep – a new 
Check out a curated list of blogs, videos, tutorials, code, tools, scripts, and anything useful to help you learn 
and 40+ 
from the 
