Allow custom ports

[robi]

When deploying alternate apps in the LAMP app, there's a need to move apache2 from port 80 to any other port so the alternate app can listen on port 80 and be reachable via the configured domain.

So there needs to be a way to configure apache2 to listen on a different port from /app/data/apache/

There may be a need to offload the healthcheck to another port too until the run.sh script runs the alternate app.

Note: run.sh is not executable by default!

[nebulon]

What is the use-case for using lamp, if apache will not be used? Wouldn't it be better to just use a custom container package?

[girish]

I think writing a custom app is the way to go for this, no? Is this a PHP app?

[robi]

@nebulon @girish

No, as I end up testing all sorts of apps, python, go, node, etc and they run their own web servers for the web app, so I need apache to be able to get out of the way.

[girish]

I feel you want more of a "vm" container which is flexible to run any framework and expose any port.

How would you do this outside cloudron? I think I would get a separate VM basically for testing random apps. I understand wanting to use Cloudron here because it's already there but not sure how this fits into our existing model. We try very hard not to put code in writable sections of containers. LAMP is the only exception but only because of so much legacy out there.

[robi]

No, I want a more usable generic container to use apps within Cloudron that have not been packaged yet.

These can also be the aforementioned app backups one can import.

It's also not helpful to have to modify the system nginx config for proxy port changes, so there needs to be a way for that to work from the LAMP app container itself.

[nebulon]

This all sounds to me like having a custom app package is the way forward, if those apps anyways run their own webserver and expose that port, it should be a rather simple Dockerfile and CloudronManifest with a start.sh just running that?

[robi]

@nebulon Absolutely not.

This is the difference between forcing a relatively difficult custom package with...

1 ...all the other dreaded required things one must do, which includes cloudron-cli, build service, container registry/repo, including a separate host for running cloudron-cli from, etc. ... (it's a bit ridiculous that one can't do this all from a single self-hosted place, like the build service container all in a single cloudron system app! Shame)

2 ...as opposed to allowing for using the LAMP app (or another specific app designed for this) to wget a release archive and run it, potentially adjusting some env vars and port, to have a running app quickly with minimal requirements.

Users have a hard time with 1, and a lot less with 2.

Users are not devs, and you want to be nice to the users and encourage them to look into a gentle onramp to making a custom package eventually, and this currently does not exist..

I hope you understand where this is going and how it complements the idea of saving such app backups, making it even easier for users to import a working app from scenario 2.

[nebulon]

I understand if building an app image is only for devs and sysadmins, as it does require some terminal use and also docker running locally at least (the build services is not required at all). In fact all is required is the cloudron cli and a docker image id (which does not need to be built for Cloudron either).

But to take a step back, it does sound like you are looking for a generic app package, which is like a vm runtime to run any process/script/... which is uploaded into /app/data/. So just like the lamp app only for other stacks with all possible addons enabled. LAMP is only here since it has such a long legacy in linux servers, but really for other stacks it makes so much more sense to write a CloudronManifest.json and a simple Dockerimage alongside to get all the benefits. I feel like there may be some options to streamline that flow instead of just trying to provide some generic and very hard to update/maintain app package from our side.

[robi]

@nebulon said in Allow custom ports:

it does sound like you are looking for a generic app package, which is like a vm runtime to run any process/script/... which is uploaded into /app/data/.

This could be interpreted very broadly, therefore that's not the ask, however that is the end goal if you'd rather solve for that and include the ask in the OP.

Many ways to approach that, which we've covered previously with simple sysbox integration which enhances docker capabilities 10-fold with a single parameter on container launch, and a LEMP or even more generic stack container Cloudron app, all of which make the app backups import/export more functional and open up a new realm of not-yet-packaged app snapshots for more users.

[robi]

Further thoughts on how to make this happen? Use case clear?

[girish]

@robi Use case is clear. The manifest is currently quite static because the design goal is for pre-packaged apps where databases, ports, addons, dependencies, backups are known in advance. Having things optional and dynamic requires fundamental changes and it's a non-trivial change.

Anything is possible of course, so if many want this, we have to look into it.

[robi]

@girish This is not about the manifest or port config there.

As stated in the OP, this is about the ability to modify the LAMP container based apache2 defined port in /etc/apache2, which is read-only and cannot be overridden with the config file in /app/data/apache.

This should be a simple change with an update to the LAMP package.

How do we do that?

P.S. I can make a separate Feature Request, if you wish, for the ability to better control the Nginx proxy port config for Cloudron apps, which would be a larger platform change (which still would not impact the app manifest).

[girish]

@robi said in Allow custom ports:

This should be a simple change with an update to the LAMP package.

It's not a simple change. The http port number that apache exposes is coded in the manifest. This requires the manifest to by dynamic.

[girish]

On a side note, you can also just configure apache to proxy_pass to your app's port.

[robi]

@girish said in Allow custom ports:

The http port number that apache exposes is coded in the manifest. This requires the manifest to by dynamic.

Isn't the manifest info for the Cloudron side of things? Container and proxy config, etc.

Separate from the ability to manually reconfigure apache after the default install?

[robi]

@girish said in Allow custom ports:

On a side note, you can also just configure apache to proxy_pass to your app's port.

Hmm, a double proxy, good idea to test!

[girish]

@robi we use such a thing in some apps like espocrm - https://git.cloudron.io/cloudron/espocrm-app/-/blob/master/apache/espocrm.conf?ref_type=heads#L20 . Many apps have nginx doing proxy pass in the container as well (taiga, pixelfed, onlyoffice, immich, sogo, jitsi etc).

[girish]

@robi said in Allow custom ports:

Separate from the ability to manually reconfigure apache after the default install?

The container exposes a port, 80 in this case. This 80 is hardcoded as httpPort in the manifest.

Thinking more, maybe what you mean is: disable apache altogether, I will run something else on port 80. If this is the case, you are right that manifest does not need to be changed.

I don't think we will support this though. It's not a normal flow to install LAMP and then disable apache as first step and run something else. This works for your specific situation only because you don't want a database or expose another port. What if I want postgres? Java? At this point, you will install everything into a data directory and run it from there. This is really not in the spirit of Cloudron.