In our previous post, we looked at the Tasks
and Operations which form the building blocks for the user interface in Aegir5.
Here we’ll look at the additional entities required to support the
Kubernetes-based backend framework.
It is worth noting that Aegir has always had a tension between Developer and
SysAdmin use-cases. We’ll cover this in more depth in a later post. For the
moment, we’re focused on the Developer use-case.
In our previous post, we talked about our recent
client work building a Kubernetes-based system for hosting web applications.
We’ve defined a general framework to support our development and production
hosting workflows, and recognized this as a solid basis for an alternate
backend to plug in to the existing Aegir5 front-end. Today we’ll take a look at
the Drupal architecture underlying that front-end.
In Aegir5, the building blocks consist of Task and Operation entities. Tasks …
Lately we’ve been working with clients ranging from large Canadian government
departments to small commercial SaaS companies, who have asked us to deploy CMS
apps to Kubernetes (K8S) clusters running on Openstack. In spite of our
continued feeling that most of the time Kubernetes Won’t Save
You, we’ve found it to be surprisingly useful
in certain contexts. In fact, we’ve started to think that K8S will prove an
extremely valuable backend to plug in to our existing Aegir5 …
Aegir5 development is happening! We (Consensus) have been making steady
progress on it over the last few years and are looking to kick off a new burst
of focused development. Here’s a summary of progress that has been made so far
and how you can contribute.
First off, as you’re probably aware, Aegir5 is a
complete re-write of Aegir. We are intending to build on all the great aspects
of Aegir, while freeing ourselves from a
codebase that is rooted in PHP 4. We’re using D9+ …
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.
Last week our fully remote team gathered in person at a beautiful
spot in Prince Edward County, Ontario, for our
second annual company retreat. Our first iteration in 2021 was a resounding
success, and we decided to do it again this year. In both cases, we took
advantage of the high-bandwidth nature of being together in physical space to
hold a variety of big picture conversations about our accomplishments, direction
and goals.
As we try to do in all our work, we sought to iterate and improve …
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.
For the past few months, we’ve been working with the Drupal Association on a project to enhance the security of the Drupal.org software repository. The most succinct way of describing this project is:
Securing automated software deployments from supply chain attacks.
Recently, on a long drive with my mother, I tried to explain this project to her. She is probably the least technical person I know. This may sound like the common tech trope, but it’s not. This has nothing to do with …
When Consensus began, we were 4 equal partners doing roughly the same work, and
generally equivalent levels of skill and experience. We all pitched in to run
the company, while billing as many client hours as possible to keep the lights
on.
As we’ve grown, we’ve managed to find a balance between paying ourselves a fair
wage and being able to cover expenses. Strategically, we’ve aimed to generate
some profit with which to fund our longer-term goals, but not at the expense of
a …
