Simplifying hosting services (aka "breaking up the monolith")

Erik Huelsmann ehuels at
Tue Jan 11 19:25:31 UTC 2022


In 2021, has had two types of service interruptions:
(1) mailing lists were not functioning correctly [while regular mail
traffic seemed to be] an (2) deployment of project sites wasn't
working. The latter only came to light recently, but seems to have
existed for some time.

Since I can remember (probably since the creation of the service) has hosted its project webpages on its main domain in a
sub directory, which at times has been called /project/, or /projects/
or even /p/. This setup mixes project hosting with hosting for the
main site itself and restricts the tooling we can use to host the
projects' websites. The reason for the sites not deploying well is
that I've implemented a workaround in the past to be able to deploy
projects using GitLab Pages while our deployment model (deploying to
the /project/ subdirectory on the main domain) is out of line with
what GitLab Pages were designed for.
At the same time, our configuration is running with extensive sets of
rewrite rules to keep historic URLs "working" and redirected to
(hopefully) existing current URLs, which also extremely complicates
our setup.

In order to simplify our setup (and eliminate the deployment problems
we're experiencing) and at the same time add support for requests like
those from Marco who wants to be able to deploy sites for multiple
projects under the same umbrella, I've decided I want to move
projects' sites to their own (sub)domains. In the past I thought this
would need to be subdomains along the lines of
https://<project> Although that's a
deployment model that would work with GitLab Pages, I've decided
against it. I'll move the hosted projects to:


(I acquired for this purpose this morning.)

The setup I'm proposing is that we have a good look at the tons of
rewrite rules we have currently in place and clean up the rewrite
rules that we don't need anymore. Then, we create rewrite rules for
the current project namespaces at<project>/ to map to
https://<project> There are a few projects which
aren't using GitLab Pages to deploy their websites yet, mostly because
they have no active maintainers. These projects will keep being served
from their current locations on the filesystem of the
host, but their content will be available through the new
<project> URL space.

Further change proposals in order to separate the mail flow for the
mailing lists from the regular mail flow (and thereby further reducing
integration between components) are upcoming, but I'll need to address
one thing at a time (due to time constraints).

Are there any comments, remarks, additions, things you want me to take
into account with respect to the above?


Erik. -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.

More information about the clo-devel mailing list