For our cloud computing, we typically use an OpenStack provider because of its open-source nature: There’s no vendor lock-in, and the IaaS code is peer-reviewed unlike providers such as AWS, Azure, GCP, etc. (Shout out to Vexxhost for having great support!) As such, we’ve been using OpenStack’s Swift object storage service for storing Terraform’s state, which allows Terraform to track all of the resources it manages for automating infrastructure.
Terraform is an essential tool for automating cloud-computing infrastructure and storing it in code (IaC). While there are several ways to navigate between deployment environments (e.g. Dev, Staging & Prod), I’d like to talk about how this can be done with environment variables, and explain why it can’t be done more naturally with Terraform variables.
If you’ve ever done any software development, or even if you haven’t, you’ve probably heard of GitLab. It’s great for developing, securing and maintaining software, being a fairly complete DevOps toolbox. We actually use it for tracking all of our work items, even outside of software (with the exception of CRM, but they’re working on that). For example, we have projects in there for operations, business development, HR, etc. The issue boards are fantastic.
At Consensus, we spend a fair bit of our time building complex Drupal systems
and the infrastructure that supports them. In that context, the simplicity of a
tool like Hugo caught my attention. Hugo is a static site
generator written in Go that has proven elegant and flexible for many
situations where a simple (or even slightly complex) website is called for, and
the venerable Drupal is overkill.
Perhaps one of the best uses we’ve found for this tool is to provide technical
documentation …
