Blog

Whilst the team has been hard at work on Lagoon 2, we’ve still found time to squeeze out a round of improvements, updates and bugfixes! We’ve also had to push out a quick 1.9.1 release to fix up a couple of unfortunate regressions – thank you so much to our customers and users for helping us to get to the bottom of the issues so quickly!

Given that Silverstripe is built on PHP, supports Composer and has a similar configuration to Drupal, it has been relatively straightforward to implement Silverstripe CMS on the Lagoon platform. Silverstripe also supports Redis, Solr and Varnish to improve site performance and searchability.

Due to the team’s focus on DrupalCon Global in the last couple of weeks, we’ve got a triple release to cover here (so apologies for being a little late!)

Back in our Lagoon 2020 Roadmap we discussed the work being undertaken to bring Lagoon to Kubernetes, and in Lagoon 1.4.0 (in April) we introduced the ability to run Lagoon workloads (projects/sites) on managed Kubernetes clusters. We’ve also variously discussed some of the aspects of what Lagoon 2.0 will bring; in our webinars, posts about managed Kubernetes, and even our migration process.

In our recent webinar, Michael and Ben covered the “blue-green” functionality included in the recent Lagoon releases. We decided to call our implementation Active/Standby to avoid confusion and be more explicit about the action it performs.

1.7.0 brings the first release of the new Problems Database functionality, developed by our partners at Amazee Labs, along with the first couple of integrations. We’ll talk more shortly about the great potential for the Problems Database, but for now we’ve included the ability to collate Image vulnerability scans from Trivy (integrated with our Harbor install) and parse site audit and remediation activity generated by Drutiny).

Active/Standby deployments, also known as blue/green deployments, are a way to seamlessly switch over your production content. Your active (or green) environment is your current active production environment. Your standby (or blue) environment is your standby environment, where you have changes staged that are ready to roll out. The environments are otherwise identical, so the go-live is just a flip of a switch. All incoming traffic is now routed to your new active environment, and the previous active environment takes the standby position. 

The main reason for this release is to ensure that our images and infrastructure are ready to support Drupal 9 on release day. We’ll also be releasing a blog post outlining what we’ve put in place.

As everybody knows, Drupal 9 is just around the corner. As a hosting provider, we need to be able to make sure that our customers who wish to utilize Drupal 9 can do so. The release comes with a few environment requirements that we need to make sure we can handle, and adds a few more behind-the-scenes actions we needed to prepare ourselves.

As we start discussing what Lagoon 2.0 might look like, we’ve been working hard on our roadmap. In addition, - the updates we need to support Drupal 9 will hopefully be coming in the next couple of weeks. We’ve identified that the version of MariaDB (10.2.31) included in all Lagoon releases to 1.5.0 does not meet the minimum standard for Drupal 9 (10.3.7) – so we will be upgrading it to version 10.4.13, as per Alpine 3.11, as well as introducing example projects and tests for D9. Stay tuned!

In our recent blog post Michael outlined why amazee.io is working so hard to make Lagoon work in managed Kubernetes. The benefits of better autoscaling and reduced maintenance obviously are the headline grabbers, but today we want to discuss one of the most important benefits to amazee.io and our customers: portability.

As foreshadowed in the Lagoon 2020 roadmap, native Kubernetes support was always going to feature large in the first half of this year – we got a large portion of the work done in our Austin sprint and this is the release of that (and some follow-up) work. Rest assured that we’re still working on features and fixes for the Openshift components (the two can exist side-by-side quite happily for now). As we develop new features, we will take into consideration compatibility with both platforms.

Lagoon Version 2 is in beta testing now and its release is on the horizon. Version 2’s biggest and most exciting new feature will be the capability to deploy into native Kubernetes clusters.

Lagoon 1.3.0 will be released soon! Changes will include improvements to our testing setup and some necessary image updates and removals foreshadowed in Lagoon 1.2.0.

When we started building Lagoon, best practices for containerized hosting were still being developed, and building everything based on OpenShift was an obvious choice, as it provided an enterprise-class solution.

In anticipation of the Lagoon 1.2.0 release, this blog post is a quick overview of the new features and improvements to expect on December 16th. You can view...

Three years ago, amazee.io was founded as a secure, high-performance, cloud-based container hosting provider. It was born within the Amazee Group, a leading ...

Grouping System and RBAC One of the major changes will be the introduction of the RBAC system, which you can read more about here. Along with the role-based ...

Cron Jobs in Kubernetes Our Applications use Cron Jobs to run admin tasks like publishing content or cleaning up a database. Currently, we use an always runn...

This month marks the third year of amazee.io! So, how did we get here? Initially, the amazee.io platform was built within Amazee Labs to answer the Drupal-sp...