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 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 . . .
Recently we looked at integrating Ansible Tower with Hashicorp Vault, but I thought it would be worth taking a look at another popular Secrets management system, Azure Key Vault. Whilst the solution isn’t exactly the same using Azure Key Vault and Tower was my first time trying to integrate Ansible with a centralised Secrets repository, so let’s take a look at how to achieve the integration as it’s not very . . .
Outside of the tools, technology and other bells and whistles of the DevOps mindset are the concepts of CI/CD (Continuous Integration and Continuous Delivery). Getting to grips with this mentality and the tools used to implement it can be a challenge but not one that needs to take a lifetime, especially not if you’ve been observing some sensible behaviour out of the gate. A multitude of tools claim to have . . .
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). . . .
In working with the Dynamics 365 Finance and Operations APIs a couple of things became apparent quickly, the first is that the documentation is pretty dreadful, the second is that the documentation makes wild assumptions about other technologies and is geared directly towards developers. Having come from a sysadmin background this created a problem that a lot of us have had to deal with. It seems unreasonable to complain that . . .