Docs - Alternative to Notion / Outline with OIDC, GDPR compliant, PDF Export (with template) etc...

[jdaviescoates]

@jadudm said in Docs - Alternative to Notion / Outline with OIDC, GDPR compliant, PDF Export (with template) etc...:

Long-and-short, there is no apparent easy path to bring this to Cloudron as a single-container/single Dockerfile application.

[jadudm]

This post is deleted!

[Neiluj]

@jadudm Thanks for taking a look - this sounds more complicated than anticipated.

Please forgive my ignorance since I am trying to understand a bit better - I though that some elements for packaging this were already available from Cloudron infrastructure:

• nginx-ingress controller -> is this anything else that nginx being part of the package? if so I am pretty sure that this has already been done in other package
• an OIDC provider -> I think that this is definitely part of the cloudron infra. Many app packages use this now
• a PostgreSQL server -> I think that this is also part of the cloudron infra. Many app packages use Cloudron PostgresSQL as a service?
• a Memcached server -> Isn't this was Redis is for ? if so, does it differs from any other package?
• a S3 bucket -> while this is not integrated in Cloudron as a service, I believe other packages have a similar approach. For example, A mastodon Cloudron app is able to point to a S3 bucket. Is this any different here?

Again, I am probably mislead somewhere here and I have no experience (yet) in packaging any app, so I am grateful for any additional info here.

Also, If one was attempting to relay info upstream to hope to have this included in Cloudron one day, what info/request/wishes would be relevant to communicate?

Many thanks again,

[jadudm]

@Neiluj

I would welcome input from a member of the team on this.

Docker is intended to run a single process in a single container. When you want to run multiple services, you run multiple containers.

This is where you (typically) would use some kind of tool to orchestrate or compose those containers. For example, a docker-compose.yml will define a set of services, and how they connect and interact with each-other.

Cloudron is designed to host singleton containers. Unlike industrial-scale platforms as a service, it provides limited tooling for how to define connections to other services. The manifest allows you to connect to the services that exist; for example, I can say "connect to the Cloudron-provided Postgres server." However, I have no way to say "I have chosen to run an S3 server/Minio at location X, and please use it." As a result, it puts a significant burden on the user. Further, there is no way within the package to say "this should not boot if that service is not present." You have to write custom code in order to provide that logic.

Further, the Docs app itself wants to run multiple services. The frontend is separate from multiple backends in their design. The app itself has orchestration concerns and considerations.

So while I appreciate people saying "but it is all there!," we're not discussing what is required to make this a production-grade package.

1. You have to pull the codebase.
2. Study how it wants to be run, and decide how it can be run in Cloudron.
3. Write a custom build/containerization script for the app, compressing multiple services (that want to be in multiple containers) into a single container.
4. Write custom code to make sure external services that are not part of the Cloudron PaaS are present, and fail gracefully/in a way that a non-expert user can debug, so that they can add those services and connect them to the app.
5. Make this all automated and testable.
6. Maintain all of this while upstream rapidly evolves.

I'm forgetting things, I'm sure. I estimate 80-120h of work in this, and it is essentially devops work. It should bill at $85+/hour. Further, I'm notorious for underestimating how long it takes to develop features by a factor of 2x-4x. So, I think this is work worth at least $8K-$12K---to say nothing of having to maintain the package, against a large, fast-moving target. (And, while it is open source, governments tend to be very careful about accepting changes from third parties, because there are significant security and compliance burdens they must bear.)

Maybe I'm just accustomed to deployments in Ansible and Terraform, and am overstating the difficulty of this deploy. However, my experience is that when a system is designed to run one way, and you want it to run some other way, there's significant work involved.

So, in return, please forgive my ignorance. I may be misunderstanding things about packaging for Cloudron, and you may be right: this may be easier than I think.

I've started poking at a package for Planka to refresh myself on packaging, because it is a singleton Node app that only has Postgres as an external dependency. It is an example, in my mind, of an app that fits the Cloudron model perfectly. However, anything that wants orchestration beyond the core services Cloudron provides---especially when some of those services are custom components internal to the application itself---is, in my mind, significantly more effort.

[Neiluj]

@jadudm Thanks for your further input. It helps me forming a better understanding whatever the outcome of this discussion is.

That packaging apps in general and maybe this one in particular has a resource cost (time, money etc..) is no doubt of mine. So I am already grateful for the time you, others, everyone is spending considering this.

I am looking forward to the input of others too and @staff if possible, to see if this is a "yay or nay" situation or if there is more nuance to it.

I would also still be keen in exploring to which extend relaying information upstream might have an influence on packaging this for Cloudron.

[jadudm]

Agreed. I'm not offering thoughts from a spirit of "GIVE UP!," by any means. It is more from the perspective of "I think this one is trickier than it seems at first glance."

But, I am still learning. So, the staff may say "this is actually easy!" Or, they might say "Yep, it's kinda tricky." And, as a result, we all learn more.

[avatar1024]

@Neiluj said in Docs - Alternative to Notion / Outline with OIDC, GDPR compliant, PDF Export (with template) etc...:

I would also still be keen in exploring to which extend relaying information upstream might have an influence on packaging this for Cloudron.

You can always make the request on their github as one person there might be interested in helping and knowledgeable about making a package. But yes it would be great a stir from @staff here on whether this looks doable at all with the current Cloudron infrastructure. This app does look great and more open than outline (which is pretty great too, but with too many restrictions on the self-hosted version).

[Neiluj]

v3.3 is out: https://github.com/suitenumerique/docs/releases/tag/v3.3.0
Also mentioned in the Self-Host github section:

"In the works: Docker Compose, YunoHost"

Would be great to see Cloudron in there.

[SansGuidon]

I agree with you, now if you compare the NextCloud compose setup https://github.com/nextcloud/docker?tab=readme-ov-file#running-this-image-with-docker-compose with the one for Docs : https://github.com/suitenumerique/docs/blob/main/docker-compose.yml you will notice that due to the plethora of services and setup required for Docs to work, this is not so-easy to port Docs on Cloudron. Not technically impossible , but still there is lot of chirurgy required. I guess it could take days worth of work (testing and rework and hacks) just to make it work til it breaks on next major upgrade. I guess at this point it's likely best to run Docs on a dedicated VPS rather than risking having unstable Docs on Cloudron.

[Neiluj]

@SansGuidon - thanks for your reply.
Just to be clear: I am not in hiding and know/understand that in the current state, it would take an important amount of work to make this happen on Cloudron.

I suppose I am coming from a slightly different angle: if they mentioned that Docker Compose and YunoHost are work in progress, then they might be open to also work on making it happen for Cloudron and thus make some accommodating changes from their end too -> "going at it from both side and we meet in the middle" kind of situation.

However, this would ask someone with Cloudron packaging / deployment to get in touch with them and discuss what is possible.

[SansGuidon]

I think shipping for YunoHost and Docker compose almost is similar work for them, while shipping for Cloudron which is not packaging with Docker Compose at all, would take them too much work. A bit like shipping a video game for BSD or Linux for a couple users, while your main market is at ease using Windows. Not only the initial work would be plenty, but also the maintenance for them, without having lot of ROI, would be a decision factor. Thus if we want such app on Cloudron, which is less known, we will likely need to do the work ourselves, because the way Cloudron package apps is a specific format which is not compatible with Docker compose at all.

EDIT: Related = https://forum.cloudron.io/topic/11580/support-for-docker-compose/3

[nebulon]

I am also following their matrix channel and the app seems to be still under heavy development. My idea was to package it once they remove the beta tag on their website, but maybe we can look into the packaging side already earlier.

[Neiluj]

Hi @nebulon - Thanks for the info. This is great news and highly appreciated. Let me know if you feel there is anything I can contribute to to make this happen.