When creating Infrastructure as Code, most IaC languages create dependencies between resources so that resources are created in the correct order, and we wait for a resource to complete creation before we start creating a resource that depends on it. A lot of the time this is handled automatically, but you can also add explicit dependencies as well. However, sometimes these dependencies don’t do the job.
Sometimes a resource will be complete, at least as far as the IaC is concerned, but it’s not actually ready in the cloud provider.
One of the benefits of using a multi-cloud Infrastructure as Code tool like Pulumi or Terraform is that you can easily transition between layers in different providers. For example, you can deploy a Kubernetes cluster in Azure with AKS, and then using the same IaC deploy pods and services into that cluster. To do this, the IaC tool needs to retrieve some credentials in the form of a Kubeconfig file, from the cluster it has just deployed.
Pulumi recently announced the beta release of their Azure Native provider. This provider allows the creation of Azure infrastructure using Pulumi, with the native part meaning that this is auto-generated from the Azure APIs, rather than hand-crafted like some of the Terraform-based providers. Upgrading to v2 should be a fairly easy process, there are no huge tasks to undertake, but there are some things to be aware of, which we will look at in this article.
Pulumi recently announced support for using OIDC to authenticate to Azure when deploying your resources. This is separate from the Pulumi service supporting this, which it has done for a while, and means you can use OIDC from any supported deployment mechanism, you don’t have to use the Pulumi service to get this. Let’s take a look at what that means and how to do it.
Why use OIDC? When you deploy resources to Azure, you need to provide some sort of credential to do the deployment.
When you are writing Infrastructure as Code, you try very hard to stick to the providers and resources available in your chosen language, but eventually, most people will hit a point where they need to do something that they can’t do directly in their IaC language - run a script, execute an application etc. Most languages offer a feature to deal with this, Terraform has local/remote exec, and Bicep/ARM has deployment scripts.
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.
