Last week, the Lagoon team released their first release candidate for Lagoon 2. In this post we'll cover a few of the headline features that make it slightly different to Lagoon 1.
Updated architecture
In Lagoon 1.x, Lagoon could support a local and (under certain conditions) remote Openshift 3 clusters. In Lagoon 1.4, we added additional support for remote Kubernetes clusters.
Having reviewed this architecture, it became clear to the team that supporting remote workloads should be the norm, giving a logical separation to the services needed to power Lagoon and the client workloads running on it. In addition, Lagoon required a high level of administrative access to the remote clusters, which could have presented an issue with higher-security installations. Ben has developed a great controller-based solution that effectively delegates the job of deploying projects and environments, running tasks, and monitoring builds to these target remote clusters, and only connecting to the main Lagoon to update status, or collect new builds or tasks.
Going forward, we will be referring to the main Lagoon install (where the API, authentication, notification and other operational services live) as “Lagoon Core”. The Lagoon component that is used to run client projects (where the environments, database services, etc, run) is now referred to as “Lagoon Remote.” This allows Remote to just be an application installed into a cluster managed by a different team. Of course, for smaller installs, Lagoon Core and Remote can be colocated.
To fully support the Kubernetes ecosystem, both Lagoon Core and Lagoon Remote (as well as the other allied Lagoon tools) can all be deployed using Helm charts.
Find more about the architecture in our Git Repository
Node 16, Alpine 3.13 and the updated MariaDB connector
Lagoon was built on Node.js 10, and has been pinned there for the last few years, because of a complicated web of npm dependencies. In preparation for Lagoon 2, Brandon untangled this web as part of upgrading our MariaDB/MySQL connector to the latest version of the official npm package (https://www.npmjs.com/package/mariadb). This gives us some of the newly-available performance benefits, as well as unblocking the Node.js 16 upgrade for the rest of the application. We’ve also updated all the system images to the latest version available of Alpine 3.13. The one exception is the MariaDB-based api-db and keycloak-db images are still on MariaDB 10.4 (while we work out the upgrade path to 10.5).
New logs2webhook service
More and more of our users are tying their Lagoon deployments into other systems. They are used to retrieve backups or database dumps, check post-deploy UI consistency, and perform other tasks. In order to integrate these systems more closely together, Blaize has added a logs2webhooks service that will allow users to create another notification endpoint (to join the existing Slack, email, Microsoft Teams and RocketChat versions). We’ve got a broader overhaul of the notification system in our sights, but this will help our users now, so we’ve added it.
API Audit logging
One of the most important aspects of running systems that are placed into highly secure environments is the presence of audit logging for privileged users. While Lagoon already had very verbose logs, pinpointing some API-driven requests could be fairly taxing. Tim has added a logging service into the API that collects the requests, and generates a searchable log entry for it. This will return the user, source, command and other necessary information. It makes it much easier to find out who actioned what, and where it came from. Again, it’ll be refined over time, but we thought it important enough to release now.
Lagoon 2 supports per-cluster Harbor 2 installations
Lagoon’s traditional architecture has closely coupled the installation of Harbor (the image registry) with the Lagoon component. Now that we have moved to a Lagoon Core and Lagoon Remote architecture, it makes sense to locate the registry as physically close to the destination projects as possible, to minimize transfer times, cost, and latency, as well as tightening the security perimeter. Administrators have the option of defining which image registry is in use for a particular cluster. This allows for multi-cluster installations to share a common image registry.
Adding Gitea support to Lagoon
Lagoon has long supported all versions of GitHub, GitLab and Bitbucket as source code management options. As part of the local development workflow we undertook for Lagoon 2, we were looking for a full-featured local Git server to enable more rapid testing and prototyping. Gitea is a lightweight self-hosted Git service, available as a Helm chart and deployable anywhere. We have added the necessary webhook handlers into Lagoon to support it (they differ ever so slightly from GitHub). For anyone looking for a completely in-cluster (either in-cloud or local) workflow, Gitea now works with Lagoon!
Develop locally on Kubernetes with an expanded suite of tests
Lagoon had a lot of tests – covering core operations (variables, promotions, active/standby), integrations (Gitlab, GitHub and BitBucket, DBaaS) and project types (Drupal, Python, Node.js etc). These test processes always ran sequentially, and could not be easily selected. Scott has done a fantastic job in rebuilding Lagoon to run locally via Helm charts, but also in configuring Helm’s chart-testing facility to control test runs. Toby has done a lot of work to refactor these tests to be more self-sufficient – meaning that they can provision and remove their own test projects, and also to overhaul the entire suite – adding new tests (mongoDB, Elasticsearch), upgrading old ones, and adding new versions.
And there will be more coming!
As we write this, the next collection of new features to Lagoon 2 are nearing completion. Now that the team can solely focus on Lagoon 2 development, expect to see some great stuff!
Top comments (0)