The creation of an Azure Site to Site VPN is (even by Software Defined Networking standards)…involved. This isn’t a problem unique to Azure and isn’t aided by the desire by vendors to call all of their components something unusual rather than the terminology that already exists. Setup is a very manual and time consuming process, however Terraform can completely automate and codify the process. Example code for this post can . . .
When working at scale with secret creation we can employ Vault’s Dynamic Secrets functions, however another less used and sometimes more flexible option is to leverage Terraform to create secrets at run time, allowing the injection of your secrets from pseudorandom secret generation in to Vault and then using these newly minted secrets further on in the creation process when creating resources in your cloud platform. Example code for this . . .
Terraform is great, it’s as simple as that, codifying complex infrastructure provisioning in to simple, readable configuration files, however there are some scenarios where you have bespoke requirements that you would like to do in a script that HCL just doesn’t offer (a problem that can plague many configuration languages and is slowly trying to be addressed as configuration languages mature more, as a side note check out Brendan Burn’s . . .
In previous posts we looked at a basic example of creating Immutable Infrastructure via BitBucket Pipelines using Terraform as well as why we would want to use Immutable Infrastructure and what benefits it brings. However we didn’t look at how to extend the pipeline in to Configuration Management. We’re going to look at that now, leveraging Ansible within the pipeline to automatically configure the instances we create immediately after they . . .
Previously I’ve looked at Azure DevOps as a fantastic platform for deploying CI/CD pipelines, and it is, however it’s obvious inclination for Azure makes it something of an issue when trying to work on other public cloud providers, and Azure obviously isn’t the only game in town. There’s also the issue of complexity. Whilst Azure DevOps is incredibly flexible and powerful, this leads to complexity and we don’t always need . . .
In a previous post we’ve looked at how to build Azure infrastructure with Terraform and handle sensitive secrets by storing them within Vault and looking them up at run time. This however still poses a problem if we’re using the default local backend for Terraform; particularly that these secrets will be stored in plain text in the resulting state files and in a local backend they will be absorbed in . . .
Previously I’ve looked in detail at the uses of two of Hashicorp’s offering’s; Terraform and Vault. Predictably, the union of these two platforms allows for some ideal ways to further streamline the process of cloud provisioning, in this case by securely handling the myriad secrets needed for cloud shaping and configuration. In this post I’ll be looking at a fairly simple configuration to get started. The sample code for this . . .
If you’re anything like me, you probably spent years hearing about the wonders of containerisation and didn’t know where to start. Docker, Kubernetes, Swarm, ECS, App Services and Containers are thrown around as almost interchangeable terms and to the uninitiated it’s just another wall of terms that means nothing (spoiler: the terms aren’t interchangeable and Docker isn’t the only game in town, it’s just the most popular form of container). . . .