Vault offers an array of flexible storage backends with a view to providing a highly available storage location to store secrets, this is a great baked-in design choice as if you make Vault an integral part of your infrastructure you can ill afford a sudden outage, a perfect platform for storing structured data is, of course, a RDBMS (Relational Database Management System), as many of the mainstays are scalable and . . .
In a previous post we’ve looked at how to build Azure infrastructure with Terraform, handle sensitive secrets by storing them within Vault and centrally manage states within Azure Object Storage (confusingly called Containers). In this post we’ll take a look at the same solution but leverage the same technology within AWS, making use of AWS S3 object storage platform and using Terraform to provision further AWS resources. Sample code for . . .
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 . . .
Previously we looked at implementing a CI/CD pipeline using both Terraform and Ansible for provisioning and Configuration Management. In this deployment we relied on an official Python Docker image to build our Ansible environment, however this required a few steps that add a few top-heavy steps that could be solved by creating our own Docker image instead. The sample code for this post is in my GitHub here. Speeding up . . .
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 . . .
Immutable Infrastructure became the new buzzword of DevOps teams a few years ago (around the time that Cattle Not Pets became the decisive philosophy of those same teams) and is one that makes perfect sense. In order for Infrastructure as Code mentalities to be properly executed we need to think of infrastructures (and in particular Cloud Infrastructure) less as nodes to be manually configured and more as abstract objects which . . .
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 complex Linux environment where multiple administrators have a requirement to manage countless machines (or even a small amount of machines), there is inevitably a requirement to manage SSH Private Keys, as well as the large administrative overhead that comes with cycling them when they expire, or new admins join or move teams. Vault offers us a method to remove the churn of key cycling. A fantastic feature of . . .