One of the Infrastructure as Code tools I often talk about on this blog is Pulumi. I’m a fan of its ability to use real programming languages toe define infrastructure and the flexibility this brings to what you can do during a deployment. The benefits of Pulumi for developers who need to deploy infrastructure are clear, but for IT Pros, who maybe don’t have so much experience in using programming languages, it can be intimidating.
Pulumi allows you to use real development languages to create your Infrastructure as Code. Because of this, you will usually need several prerequisites and libraries installed in your development environment, depending on which language you are using. You can set these up on your development PC, but one alternative approach is to use GitHub Codespaces. GitHub Codespaces allows you to quickly deploy a pre-configured development environment, along with your code running as a cloud service.
As you probably know, I talk quite a bit about Bicep. Invariably when I do, I get a comment or question like “why would I switch from Terraform to Bicep” or “This is pointless, Terraform already does all this”. Well, here’s the secret: if you’re using Terraform and are happy with it, then Bicep isn’t aimed at you!
Microsoft’s primary goal when creating the Bicep language was to remove the barrier of entry when using Infrastructure as Code in Azure.
Absolutely nothi… oh wait, they might have some uses.
When choosing an Infrastructure as Code (IaC) tool, there are many differentiating factors among the options available, but one that often comes up in this conversation is whether or not they use a state file. Some languages, such as Terraform and Pulumi, use a state file to track what has been deployed outside the cloud provider’s system. In contrast, other languages, like ARM templates and Bicep, don’t have a state file and rely on the actual state of the resource.
Over the last few months, I’ve been working on YouTube series called Bicep for Real, which aims to help you learn the Bicep language whilst applying it to a real project and a real-world scenario. This series goes beyond just Bicep and covers version control, automated tests, CI/CD and automated deployments. The aim is for people to come away from this series not only with knowledge of the Bicep language but also how it applies to their projects and real-world workloads.
Azure Active Directory B2B has the ability to invite guest users. This allows you to invite users from other Azure AD tenants into your tenant so that you can grant them access to resources in your tenant (Azure RBAC, Office 365, Azure DevOps, etc.). When you add a guest user, they will be emailed an invite, and when they click on this and accept the invite, the guest tenant will now be displayed in their tenant selector in Azure.
Have you ever wondered why you can’t create some Azure resources using ARM or Bicep, or it’s not present in the Pulumi API, but sometimes you can do it in Terraform, or just not? If you work with Infrastructure as Code, you need to understand the difference between the Control Plane and Data Plane.
These two planes represent two different types of operations in Azure.
Control Plane Most top-level Azure resources fall under the control plane.
Sometimes you need your Kubernetes workloads to interact with the underlying host OS, this can be for many reasons but a few common scenarios include:
Monitoring agents that need to read metrics from the host Tools that need to access the underlying container runtime Access to the host network or storage Amending the configuration on the host Installing additional software or agents on the host For Linux hosts, this is fairly straightforward using a privileged daemonset on these nodes which can then access these host resources, but privileged containers aren’t an option for Windows nodes.
