Containerising Compo.sr

Hi,
I am about to embark on an experiment of using Kubernetes to manage a containerised version of Compo.sr, database and app server.

There are a few reasons for this, but mainly to learn more about containerisation and hopefully to get a scalable and portable version of Compo.sr - it might be a disaster, but I figured that I don't have anything to lose except for time.

There are quite a few Kubernetes offerings by Cloud providers now - I would really like to see how easy it would be to move between them and what the performance would be like.

Has anyone else on here played in this area?

I know from Chris that Compo.sr is stateless and writes everything to its database, so that should allow me to use the multi pod approach to scale up and down.

For the actual containers I will use a volume for the database and one for the public_html directory of the app server - I figure that I will need to make a few other files part of a volume so that they persist a container upgrade. There is a really great example for mySql that I will be using, that clearly shows the config files and the database tables themselves that need to be preserved.

Does Compo.sr write to any files outside of the public_html directory? If it is at installation time then that is fine as it will get baked into the container image and persist. What happens at upgrade time? Is that only changes overlaid in the public_html directory, so I can safely let the upgrade happen from the webpage (as the volume is persistant).

I think that this is the scenario without Kubernetes:
(1) Create a container image with Apache, PHP (plus extensions) and any other settings important to Compo.sr
(2) Start an off the shelf MySql container (within the same network as (1), so that they can DNS lookup each other) and a Volume for the database and some settings important to Compo.sr
(3) Start the container in (1) with a volume for the files in public_html
(4) Use the browser to configure Compo.sr

I then plan to do the same under Kubernetew control - will update when I find out more!

Cheers
Ade

Hi,

Actually the filesystem is used quite a lot. Most of the *_custom directories, and uploads directory, will have data dynamically written in.

For example, adding/editing Comcode pages, uploading files, changing theme images, making new themes, changing language strings, addon management.

If I were doing it I'd likely either:

1. try and use something like NFS symlinks for folders where files change (if we can assume very low latency for shared storage)
2. custom coding to implement Composr's sync_file function, which is kind of like a hook (not an actual hook) for synching new/changed files/directories around

Nothing is changed outside the base (install) directory in Composr.

To be honest I'd only recommend containers for a situation where there's at least 1 full time senior programmer working on a project. I don't want to be negative, but there's a lot of complex conditions.

For example, on an upgrade local file changes will happen, as well as database changes. But if another instance was running along with a different version of the code, it could cause some chaos. So you'd need to deploy a new version immediately across each instance, or take all instances down at a time of low traffic, sequentially bringing them back up again. To do that you'd need to be doing stage-tested upgrades (probably on an entirely separate private network of instances), and really have a very strong knowledge of exactly what kind of changes are going to propagate through. I can't imagine that happening outside a situation where a full time programming team is in control.

Thanks for the reply Chris.

There are capabilities in Kubernetes to deal with upgrades and blue/green testing - those of the sort of things I want to learn how to deal with - don't worry this is only for play at the moment :-)

Compo.sr may not be perfect for a containerised solution, but that is how a lot of the apps are today - it will be fun learning what does and does not work and how to fix or workaround the issues.

Cheers
Ade