Any given technology is best understood through three lenses at once:
These lenses can be summarised in terms of their key sources:
- The business case for customers: whitepapers, advertisements, and the front page of the product’s website.
- The official developer experience: technical documentation, tutorials and blog posts from developer advocates.
- What it actually is: third-party blogs, technical specifications (if available), and hard-won first-hand experience.
The default for the hacker is to focus on “What it actually is” or, more specifically, “What can I make it do?” But for IT consultants this is not enough. We need to understand the customer…
A powerful way of bringing information into your Terraform configuration, but one which must be used with care
A data source in Terraform is a lot like a resource, but it only implements the “read” operation. So what does that actually mean? Let’s take a walk.
It’s like a query
Well, that was a short walk. A data source is a query, a means of getting data from the outside world and making it available to your Terraform configuration, perhaps to use in an input attribute of a resource or a submodule.
Take for example a Terraform configuration like the following (borrowed from the doco):
data "azurerm_role_definition" "example" {
name = "Contributor"
}
output "contributor_role_definition_id" {
value = data.azurerm_role_definition.example.id
}This can…
There comes a point, early in every infracoder’s journey, when they start to experiment with modules in Terraform. The power! The convenience! The reusability! Then, a little later in that journey, comes the point where they curse Mitchell Hashimoto to hell and back because those modules, well, they were not quite as modular as we had perhaps assumed.
The purpose of this post is to explore this definition found in the Terraform documentation:
Modules are containers for multiple resources that are used together.
The most important thing about Terraform modules is the thing that isn’t in that sentence. …
There is an old story about a bunch of people who each describe a completely different animal, but it turns out they are all talking about the same elephant, each from different perspectives. So it is with Azure when viewed through the various lenses of the Azure portal, the Azure Resource Manager API and the azurerm Terraform provider. Fortunately, I have some good tips for cajoling the big blue elephant into giving up its secrets, so you can automate everything in Terraform the way it should be.
Microsoft is well-known for its commitment to backwards compatibility. For example, to this…
When you are developing an in-house application such as an ecommerce web app or a data pipeline, and adopting DevOps practices, the question can arise as to where CI/CD scripts should live: in the repo with the application source code, or somewhere else?
Broadly, you need to separate the “software” product from the “service” product, at least conceptually.
The “software” product, which clearly does live in the app repo, should contain:
- build scripts, whether they be Dockerfiles, Makefiles, Azure Pipelines YAMLs or whatever build system you require or support for putting the software in a distributable form and placing it…
Pat Conheady
"Wow, what a hack, that will never work" is usually a sign you are heading in the right direction
