Announcing “Pitch-burgh”, an innovation contest at DrupalCon Pittsburgh, where members of the Drupal community can pitch their ideas to receive funding.
[…] The entrepreneurs give short 2-3 minute presentations in the hopes of securing funding for their idea.
In previous posts we covered how the Frontend and queue mechanisms can talk
with the Backend. We also covered the stand-alone work we’ve been doing
within Drumkit to support Drupal on Kubernetes. In this
post, we’ll discuss how we plan to integrate this new Backend into the existing
Aegir 5 architecture.
To integrate the Kubernetes Backend into Aegir 5, we will need to build new
top-level entities (see this earlier post about
Clusters, Projects, Releases, and Environments) for the …
As mentioned in the first part of the series, our
most recent work on Aegir5 itself has been reworking the queue system. In this
post, we explore this topic in more detail.
The Aegir5 queue is implemented using
Celery, which is a full-featured
Python-based task queue, built atop RabbitMQ. Initially we built dispatcherd
which …
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.
