Infrastructure on Wesley Camargo

Getting Started with Azure: What are Azure Virtual Machines and how to create it using Terraform

Tue, 21 Nov 2023 18:45:11 +0100

Getting Started with Azure: What are Azure Virtual Machines and how to create it using Terraform

Azure VMs are like your own computer on the cloud. You can choose between different Operational Systems, such as Linux and Windows, and they can be used for different goals, like hosting a website for example.

Photo by imgix on Unsplash

Virtual Machines are part of a category called Infrastructure as Code, and they are still relevant in many scenarios, even with the advent of Platform as Code, where you are in control of many aspects, such as security, identity and access, high availability, and others.

What do I need to create a Virtual Machine on Azure?

To create the VM there are a few Azure resources that are necessary to be created before, as we can see in the image below:

Resources that are Pre-requisites

There are some resources that are not necessarily part of the same life cycle of your VM, and you might have already created them on your Azure environment. On the script that I am providing below, they are being created, but you might decide to use a resource that already exists.

**Resource Group: **A resource group works similarly to a folder, where you can group the resources that have something in common. It can be resources of the same type, such as VMs, or the most recommended, resources that share the same life cycle.

**Virtual Network: **In an Azure VNet, you are able to create a private space, where your resources can communicate securely. It works similarly to the network that you are connected to right now to read this post, but it sits on Azure.

Subnet: They are subdivisions of a Virtual Network, helping to keep organized and segmented by different types of resources, like Databases, Front and Backend applications.

Resources that are part of the Virtual Machine life cycle

**Disks: **Disks are used to store operating systems, applications, or data. Each VM created on Azure has at least one OS Disk, but it can have multiple.

Network Interface Card: Also known as NIC, a Network Interface Card is responsible for connecting the VM with the network that we saw earlier. Similar to disks, each VM must have at least one, but also multiple NICs are supported.

Public IP: A Public IP is the communication between the VM and the world. This resource is not mandatory, and in most cases inside a business context, it should be created very cautiously, to avoid any security risk. However, as it is a simple test and I don’t want to complicate it, we need the Public IP to be able to connect to our VM. It is connected to the Network Interface.

Terraform Script

Pre-requisites

Below is the section of Terraform that creates the pre-requisites. As I mentioned before, it is possible to use existing resources, however, you need to adapt the script to use them.

In this script, we are creating the resource group, virtual network, and subnet.

Virtual Machine

Finally, this is the script to create the VM resources. Here we create first a Public IP, the Network Interface Card, and associate the PIP on it, and a VM. Note that the Terraform VM resource already abstracts the disk internally. It’s also interesting to highlight that the VM associates the NIC created before, creating a dependency, which Terraform will identify and create in the correct order.

Complete Script

Below is the complete script, including provider, variables, and outputs:

Conclusion

Below it is the link to my GitHub repository where I am creating a library to have all references related to Terraform. I hope that this post despite being simple might be helpful! wesleycamargo/terraform (github.com)

👋 If you find this helpful, please click the clap 👏 button below a few times to show your support for the author 👇

🚀Join FAUN Developer Community & Get Similar Stories in your Inbox Each Week

From Terraform to Azure Bicep: What You Need to Know about syntax

Fri, 17 Feb 2023 18:31:38 +0100

From Terraform to Azure Bicep: What You Need to Know about syntax

Photo by Botond Czapp: https://www.pexels.com/photo/birds-flying-on-blue-sky-7255793/

Hey there Terraform experts! I am confident that you know the power of infrastructure as Code in managing and provisioning IT infrastructure and have been applying it with the famous HashiCorp tool. But have you heard about Azure Bicep, the newer Microsoft IaC language for managing Azure resources? If you’re curious about the differences between Terraform and Bicep, and how Bicep can help you better manage your Azure resources, you’ve come to the right place. Let’s dive in and explore the world of Infra as Code with Azure Bicep! In this first post, I’m going to break down the basic differences between Terraform and Bicep file structures. These infrastructure-as-code tools have their own unique syntax and components, so it’s important to know what sets them apart. By the end of this post, you’ll have a solid grasp of what makes them tick.

Introducing Terraform and Bicep

Terraform and Azure Bicep are two popular Infra as Code (IaC) tools that allow developers and operations teams to manage and provision cloud infrastructure using development practices.

Terraform is a tool developed by HashiCorp that supports multiple cloud platforms, including Azure, while Azure Bicep is a newer tool developed by Microsoft specifically for managing Azure resources. Both tools have their own syntax and language for defining Infrastructure as Code and offer benefits such as consistency, scalability, and version control. However, there are also some differences between the two, such as how they handle state management and the availability of community-built providers. In the following sessions, we’ll explore the similarities and differences between Terraform and Azure Bicep, and help you decide which tool is best for your infrastructure management needs.

Language and Syntax

Terraform and Bicep has a lot in common. Both use their own domain-specific languages, with a declarative approach, support modularization, and are designed to be human-friendly(I am looking at you, ARM Templates 🙃). Terraform uses HashiCorp Configuration Language, also known as HCL, developed by HashiCorp and has several providers, supporting not only Azure, but AWS, GCP, and even VMWare. Bicep is developed by Microsoft with the intention to abstract the usage of ARM Templates and was developed specifically for Azure, which gave a great integration.

The structure of both languages is similar, within the same building blocks, with the main components being resources, inputs, and outputs, and as I said above, quite easy to read. Below we can see a comparison of the creation of an Azure Storage Account:

Image prepared by the author

Now let’s analyze the main differences:

Provider

The first and biggest difference that note is that in the Terraform example, we have a section called “provider”. As Terraform supports not only Azure but also other providers, it is required to declare the provider that we want to use.

As Bicep is designed specifically for Azure, the provider statement is not required.

Input

Another difference is that the input parameters have different reserved words. In Terraform it’s called variable, the default values are declared with a default statement and its syntax require curly brackets.

Bicep, in turn, declares the inputs by the reserved word param , the attribution of a default value can be done with the equals sign and it’s not required any brackets. Bicep also has a variable reserved world, but it’s used not for inputs, below we can see more about it.

Local variables

Local variables in Terraform have a special section called locals. All necessary variables must be declared in this section and must be accessed by the syntax local.<variable name> and can be used to create combinations and complex operations.

locals { resource_group_name = “myTerraformResourceGroup” location = “West Europe” }On Bicep, it is not necessary to have a specific session, being possible to declare anywhere in the file (although is recommended to do in the beginning to make it more readable). It also makes the syntax a little simpler than in terraform var location = ‘westeurope’

Resources

Finally something in common! For both, Terraform and Bicep, the resource is declared by the reserved word… resource! And there is more in common, in both cases, when declaring the resource you need to declare which resource is desired and you also need to create an alias to this resource, so it will be possible to access information from it, even in the case that you have several resources of the same type. The internal properties will be different depending on each resource type, but in general, you need to provide the resource name, SKU, location, and so on.

Although the concepts are quite the same, the syntax is slightly different as we can see below:

Terraform resource:

resource “azurerm_storage_account” “storage” { name = var.storage_account_name resource_group_name = local.resource_group_name location = local.location account_tier = “Standard” account_replication_type = “LRS” }Bicep resource:

resource storage 'Microsoft.Storage/storageAccounts@2022-09-01' = { kind: 'StorageV2' location: location name: storageAccountName sku: { name: 'Standard_LRS' } }n

Output

The outputs follow a similar logic as the inputs. Terraform requires curly brackets, Bicep no. In terraform, it is necessary to specify the resource type first, then the alias, and finally the property. It is also important to highlight that is not possible to assign a type to an output in Terraform.

output “storage_account_name” { value = azurerm_storage_account.storage.name }Bicep is again, slightly simple. No brackets and you can reference by the alias directly, without having to declare the resource type. In Bicep is also possible to assign a type in the output, which is useful in some cases.

output storageName string = storage.namen

Terraform storage account example

Bicep storage account example

Conclusion

In conclusion, while Terraform and Bicep share some similarities in their purpose and functionality, they have significant differences in syntax, which can affect the user experience and overall efficiency in deploying infrastructure as code. Understanding these syntax differences is crucial for developers to effectively utilize the benefits of each tool and to determine which one is the best fit for a particular project or organization.

In the upcoming posts, we will dive deeper into other differences between both tools, exploring their impact on various aspects of infrastructure deployment and management, and offering practical tips and solutions to common challenges. Stay tuned to learn more about how to optimize your infrastructure as code with Terraform and Bicep!

👋 If you find this helpful, please click the clap 👏 button below a few times to show your support for the author 👇

🚀Join FAUN Developer Community & Get Similar Stories in your Inbox Each Week

Creating Infrastructure as Code for Azure with Azure Bicep step by step

Wed, 23 Mar 2022 10:54:57 +0100

Creating Infrastructure as Code for Azure with Azure Bicep step by step

Photo by Arisa Chattasa on Unsplash

One of the natural steps towards DevOps and Cloud Adoption is to create your Infrastructure using Code. For Azure, the most convenient language for this is Azure Bicep which abstracts several aspects of this complex process, and supports more resources available in Azure than any other tool, making it one of the most powerful Infrastructure as Code tools for Azure.

What is Azure Bicep?

According to Microsoft Documentation, this is the definition of Bicep:

Bicep is a domain-specific language (DSL) that uses declarative syntax to deploy Azure resources. In a Bicep file, you define the infrastructure you want to deploy to Azure, and then use that file throughout the development lifecycle to repeatedly deploy your infrastructure.

In summary, this is an abstraction over ARM templates which simplifies A LOT the development of Infrastructure as Code. Its syntax is much simpler and less verbose than ARM but still has all its capabilities.

As bicep is a DSL, we can consider ARM as an Intermediate Language and we can “build” bicep into ARM to perform our deployments. A curiosity is that the name bicep is a play on words for ARM (Azure Resource Manager) 😄.

How to create an Azure Resource Group with Azure Bicep?

Usually, one of the firsts resources on Azure that we need to create is a Resource Group, as it will group all other resources, and make it easier to administrate.

Create an Azure Resource Group using Azure Bicep it is quite simple, you need just the name of the resource group and the location that it will be created. Additionally, it is necessary to define the *targeScope *as a subscription, it will be explained in more detail below.

It is possible to deploy it in different ways, using Azure PowerShell, Azure CLI, or even Azure API’s. In this example, we will use Azure CLI to execute the deployment.

How to execute an Azure Resource Group deployment with Azure Bicep and Azure CLI?

On the latest versions of Azure CLI, there are different commands to run deployments against different scopes on Azure. To create Azure Resource Groups, it is necessary to use the *subscription *scope, which was also defined on the bicep template above.

The command used is az deployment sub create :

After running the script, we can check the resource group with the command az group show --name rg-bicepdemo :

Image by author

How to create an Azure Storage Account with Azure Bicep and Azure CLI?

When we will create a “common” resource, like Storage Account, Resource Group scope must be used. This is the default behavior of bicep, so it is not necessary to specify like it was for Resource Group creation.

To create resources on Resource Group scope, the Azure CLI command used must be az deployment group create :

To check the Storage Account creation run the command az storage account show --name stbicepdemo

Image by author

As they are in different scopes, it is not possible to run both bicep files with one command, however, I prepared a PowerShell script to run them in sequence:

Conclusion

Azure Bicep is one of the most promising Infra as Code tools for Azure, and it is quite simple to create new templates for it. Its syntax is very simple and easy to learn, so why not give it a chance? :)

See you in the next post! [

](https://faun.to/bP1m5)

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author 👇