Deploying apps that treat code as data

[girish]

@mehdi said in Deploying apps that treat code as data:

@girish said in Deploying apps that treat code as data:

Latest versions of node don't allow symlinking node_modules anymore

Do you have a source on this ? I am very surprised, as a lot of nodejs utilities use symlinks in node_modules, things like Lerna (https://lerna.js.org/), or even native npm link.

Yes, see https://github.com/npm/cli/issues/3669 and (related) https://github.com/nodejs/node/issues/22922 . We symlink node_modules in the nodebb app which doesn't work anymore because of this. Not 100% sure but I think npm link creates symlinks inside node_modules which is different from this one where node_modules itself is symlinked.

[privsec]

Why not offer an option within the app to determine whether or not it is write protected?

[infogulch]

@privsec If the user installs a plugin which is stored in the code area, and the backup only backs up the data area, when the app is deleted and restored from a backup it will lose the plugin and potentially also data.

[privsec]

@infogulch
could the backup locations be updated?

[murgero]

@robi Ah yes - this is what I was thinking about.

@mehdi - My apologies, I may have been thinking of alternate syntax to the symlinking command.

[MooCloud_Matt]

@girish

Probably a possible solution is to allow multiple Volumes to be mounted to the container, so there is no need for a syslink, and is still easy to backup, the backup script knows which volume to backup for each container.
Is a bit more work on the Backup script, but should allow an easier port to Cloudron.

Or, I see as an alternative the release of the Manifest standard as a separate Spec from Cloudron, like the "Compose Spec".
This should allow developers to better understand what cloudron and the manifest support and how they work, and hopefully start to act more in line with safer containerization standards.

[timconsidine]

@girish : it will for sure be impossible to persuade others to do it the Cloudron way, so the problem has to be addressed.

Personally I feel the Cloudron stability and reliability is SO IMPORTANT that it must be preserved and it is the priority. If it is impossible to find a solution, we have to accept a situation like "sorry, this XXX app is such a mess, it is not possible to make it comply with Cloudron standards, and even though it is good functionality, and we could possibly package it, we're not going to. Because it's a mess."

While I don't have a technical solution approach to the problem, I think it's almost inevitable that we end up with another status of apps :

• OFFICIAL (package tested, released, maintained, conforms to Cloudron standards)
• UNSTABLE (although I don't like this word : should be Beta or not-yet-officially-released)
• MESS or "Pig's Breakfast" (packaged, works, use it, but maintained as best endeavours, esp ref backups, because upstream dev does not conform to Cloudron standards)

Not ideal, but better than lowering Cloudron standards. Would rather accept not having XXX app in the store.

[mehdi]

I quite agree with @timconsidine . We could have these apps on Cloudron, but with a big fat red warning that says the app is unsupported :

• zero user support
• larger backups
• no auto-update

If unhappy: bother the original author.

[robi]

@moocloud_matt said in Deploying apps that treat code as data:

a possible solution is to allow multiple Volumes to be mounted to the container

This is along the lines of OpenEBS storage discussion here.

Elegant way to install an "elevator" to any directory in the container and swap out files we might need, without disrupting the app.

[MooCloud_Matt]

@robi
in general, having support for multiple drivers for Volumes is a good idea, but set in the Manifest standard the support for multiple volumes, could solve the issue at least partially.