Hello @jadudm
@jadudm said in Stuck on packaging:
I started by wondering if I could use their Docker image as a base image , and just build some layers on top.
If you wish have this app in the Cloudron app store, you need to use the Cloudron base image.
@jadudm said in Stuck on packaging:
I do not know of any way, in the Cloudron app model, to map arbitrary paths inside the container to paths outside the container.
Many apps write to static locations that can not be configured.
When packaging a software for Cloudron with such read-write paths always ask yourself the following question:
is the needed read-write path user-data or runtime-data?
If it is user-data and backup worthy, it should go into /app/data/.
Anything else which is just needed for the runtime should be in /run/ or /tmp/ which is temporary read-write on runtime.
Also good to look at https://docs.cloudron.io/packaging/cheat-sheet/#filesystem.
If you have static paths that need read-write you will have to symlink them accordingly to the destination.
As an example I will use the Nextcloud Cloudron App.
In the Dockerfile you can see the following lines:
# create config folder link to make the config survive updates
RUN rm -rf /app/code/config && ln -s /app/data/config /app/code/config && \
mv /app/code/apps /app/pkg/apps_template && ln -s /app/data/apps /app/code/apps
This way a dead symlinc is created that points to /app/data/apps so this dead symlink needs to be filled on runtime, but the symlink is persistent.
From the start.sh:
cp -rf /app/pkg/apps_template /app/data/apps
So, on startup it needs to checked if the target already exists and if not, copy the original.
This way the dead symlink get filled with life.
This way you can make static read-only paths read-write.
On the topic of runtime paths that need to be read-write but not are not backup worthy.
There also is https://docs.cloudron.io/packaging/manifest/#runtimedirs which makes this a lot easier.
But these paths can only be in /app/code/ so when the app wants to write /etc/ this is no option.
Third approach
This is the correct way. When using the Cloudron base image it is best to build from source.
Some software also offers a apt package which installs other software alongside like mysql.
Many times this can be avoided with apt parameters like --no-install-recommends, but in my opinion, building from source also gives a lot of insights about the software itself which aids further down the road when issues arise.
Fourth approch
@jadudm said in Stuck on packaging:
I could make a PR against their codebase that attempts to move all file write operations into one fixed location in the filesystem, and make that location configurable via ENV var. (Or, multiple locations configurable via multiple ENV vars.)
In my opinion, every software should have configuration options where it writes.
This is always useful and if you have the capacity and knowledge to do these PRs, this should be very welcomed.
But, I know some maintainers can be special. So, if you can deal with the FOSS dev frustration, please go for it.
certs
Here you go: https://docs.cloudron.io/packaging/addons/#tls
@jadudm said in Stuck on packaging:
Are there any packages that exist that overcome these kinds problems? If so, I'd welcome a pointer to those packages, and I'll study those/pull inspiration from them for my packaging problem.
Yes, you can find many apps like in my example for Nextcloud that handle these static paths and move, symlink them to /run/ or /tmp.
@jadudm said in Stuck on packaging:
Have others encountered this in their packaging? Did you find a way around?
Yes of course, every time an app is packaged the read-only nature can be difficult to work with.
One big hint I can also give is the following.
If you have an initial package of your custom app, and it fails to start since it wants to write some random path and does not even tell you where it wants to write.
Put the app in recovery mode, making it all read-write, start your app startup script manually.
Then, if you ssh into your Cloudron server you can run:
docker diff $YOUR_APP_DOCKER_ID
And docker diff will give you a detailed list of what paths were added, deleted or changed.
@jadudm said in Stuck on packaging:
Is it sometimes the case that an app has been developed against a model that simply makes it "unpackageable?" Is this one of those cases?
Some apps can be very tricky to get working and need a lot of tinkering to get the paths and everything in order.
Sometimes it could be just so much that the maintenance of this app would get out of hand.
Then this needs consideration if this is really "worth it".
@jadudm said in Stuck on packaging:
I'm out of questions, really. At some level, it feels like this should be easier/more straight-forward---like I'm missing something. But, maybe I'm not.
Don't throw the towel!
Take breaks when you get stuck.
@BrutalBirdie started this topic once https://forum.cloudron.io/topic/3486/zabbix-appdev-log which could also be done by everyone else.
I would encourage everyone who starts packaging a Cloudron app for the first time to do the same.
This way you are not alone with your struggles and can get fast feedback on roadblocks.
I hope this wall of text is somewhat helpful.
Please, don't hesitate to ask questions before you quit from frustration.
