Better separation between code and data

[mmallejac]

Hi Tim,

How are you ?

I am wondering about the way the Docker volume foswiki_www is currently done, since it contains both data and code.

Now we still have to manually proceed with the extensions upgrade, which seems counter-intuitive to me, especially in a Dockerized world. Wouldn't it be beneficial to have only data in the volumes ? This way it would be enough to pull a newer Docker image and restart the container to be up-to-date. More like a black-box thing.

I know a bit about the Foswiki folder structure, but not enough to foresee the implications of such change. That would also imply to have enough extensions provided with the images so that most of the users are ok with that (this is probably already the case). The other ones would have to add their specific extensions within the Dockerfile and build their own image.

What do you think ?

Take care,
Michel

[timlegge]

Hi

Things are good. Hope you are doing okay. I have given that a little thought over time but have not looked at it closely.

I caused myself some issues a while ago when I updated the extensinons and was missing a perl module. Luckily that part of the docker image works well.

It is likely possible to pull out the webs but its a bit complicated because the names of the webs are unique to each installation and some configuration changes cause shanges to Main and System Webs under data. Things like registering users, etc.

It is likely that a somewhat complex mixture of files and directories could do what you want but someone more aware of the file structure than I am would need to weigh in.

I find that the current model treats the perl and library dependancies and OS versions as interchangable in the docker image works fairly well and all the Foswiki application is managed as a volume. That way I can have different extensions installed than you have for instance.

I think to take advantage of docker more fully, Foswiki will need some core changes to keep all site changes in a seperate directory. Still then, unless you want to force everyone to have the same extensions those would need to be seperate.

Not much help I am afraid as I don't currently know how to approach it but feel free to take a look.

Tim

[mmallejac]

Yes, here so far so good. Some people got sick around us, some quite heavily even in the 30's, but we knock on wood... (and wash hands after !).

Great, thanks for sharing this. I have also some troubles with the update process. Maybe I'll have to start over a new instance and import back the data.

Maybe @MichaelDaum would have some thoughts on this matter ?

Michel

[MichaelDaum]

The easiest/most natural way of separating the vhosts' data from the core is facilitated by the directory structure of VirtualHostingContrib: the perl code and all extensions reside in one directory while all virtual hosts are on another, clearly separated from the core engine. I tend to share the System (and Applications) webs between all vhosts using symlinks to keep redundancy low.

[mmallejac]

Sounds good ! Would VirtualHostContrib work only for one host ?
What your describe would really help the upgrade process while running under Docker

[MichaelDaum]

Yes, works fine with just one vhost.