Add Official Unraid Community App

[kophi]

Please consider adding dawarich as an official community app to Unraid.

The instructions on how to publish the docker-compose file within Unraid is described here: https://forums.unraid.net/topic/57181-docker-faq/#comment-566084. Policy and notes can be found here: https://forums.unraid.net/topic/87144-ca-application-policies-notes/

While there already is an Unraid app for dawarich it is based on a 3rd party container and repo at https://hub.docker.com/r/freikin/dawarich. I would much prefer an official release from this project itself.

Just as a reminder we've already talked about this in the Github Discussions: https://github.com/Freika/dawarich/discussions/150

Thank you for your outstanding work! 🔥

[x5nder]

+1!

[Freika]

I have no capacity to build and maintain an official Unraid template/app, but if someone from the community will be able to do so, I'll endorse and advertise it as the recommended way to run Dawarich on Unraid systems. I'd only ask the volunteer to be sure that they will be able to maintain it and keep it up to date with the changes coming in new releases

[adromir]

There is already an "unofficial" one in the Unraid Community Appstore. Maybe you can Endorse this.

This is the Support Thread https://forums.unraid.net/topic/133764-support-grtgbln-docker-templates/

(This is for all the Templates Maintained by this user)

[Freika]

@adromir I have no contact with the author of this unofficial community app. Ideally, we should be in touch so I could consider nuances of the platform and the author would ping me if some problems are introduced in new releases. Without that I can't really endorse that

[adromir]

@Freika I posted in his support thread, that you are looking or an active maintainer of an official Unraid Template. So lets see if he is interested in Taking over

[nwithan8]

@Freika I posted in his support thread, that you are looking or an active maintainer of an official Unraid Template. So lets see if he is interested in Taking over

Hello, sure, I'm willing to help.

[Freika]

@adromir thank you!

@nwithan8 Awesome! I'm not really familiar with how Unraid is different from a standard Ubuntu server running a web app in docker container, so if you could provide main differences, maybe I could consider them in future releases? Also, feel free to join our Discord server, it'd be easier to chat there. Thanks!

[adromir]

Unraid is basically a "nas" optimised OS on Slackware basis. The webdashboard is to configure it. See it a bit like OMV or Truenas if you are familiar with it. There aren't really any specific things that you need to consider, except that Dockers are installed from these Templates, which are basically just a specific xml file

[nwithan8]

@adromir did a good job of explaining it in his comment. The XML file is just instructions for the Community Apps plugin on Unraid to parse and present a GUI-based configuration screen for Docker applications. As far as developing the XML itself, it's largely just translating a Docker Compose file to the specific syntax.

[Freika]

@nwithan8 this issue (and some other created earlier) indicates a problem with Unraid: it looks like data migrations are not being run in the Unraid env. They are usually being run as part of the application starting process, maybe you have an insight of what might be the reason for that?

[nwithan8]

@nwithan8 this issue (and some other created earlier) indicates a problem with Unraid: it looks like data migrations are not being run in the Unraid env. They are usually being run as part of the application starting process, maybe you have an insight of what might be the reason for that?

Do you know off-hand what calls that web-entrypoint.sh script? I'm wondering if we need to add some post-arguments for the Docker command to run migrations. My concern would be though that if the migrations ran every time the container started, it might cause issues (if the migration process doesn't handle already-completed migrations nicely)

[Freika]

It's being used as an entrypoint file in the default docker-compose.yml file. Since compose file uses web-entrypoint.sh, it should run both database migrations and data migrations, but for some reason on an Unraid systems data migrations are not being run.

Both database and data migrations are working that way so once they ran one time, they won't be running again, record of it is stored in the database. Already completed migrations should not be a problem

[t3chguy]

Relying on changing the entrypoint where the default Docker image entrypoint is just nasty. Why not publish 2 images with the correct entrypoint set, with the entrypoint command being very last, thus sharing all previous image layers between the 2 images intrinsically and being able to abstract the entrypoint away from a detail that all deployments must concern themselves with.

The unraid app seemingly current specifies thus:

Which does not run the entrypoint, it'd need to specify --entrypoint web-entrypoint.sh in Extra Parameters: to override the one baked into the image

[Freika]

@t3chguy because I'll have to maintain twice as many images. If the problem is known, am I right to suggest it's fixable from Unraid's side?

[adromir]

@Freika do you build the images manually yourself? I have just set up a Jenkins instance on my Webserver, and I'd offer it to use it as an automated builder for the dawarich containers

[t3chguy]

Maintain? No, they'd be identical bar the entrypoint, should even just be a single Dockerfile with a build-arg entrypoint. Even the 2nd docker build would be instant due to the way docker image layers & caching works.

Of course it is fixable from Unraid's side, just like it had to be "fixed" in the compose side, just like it'd need to be fixed in every side which touches entrypoints (helm?)

I'm not going to fight in either direction as I use compose so it makes very little difference to me, but it feels messy and unlike the defacto norm in Docker.

[t3chguy]

do you build the images manually yourself? I have just set up a Jenkins instance on my Webserver, and I'd offer it to use it as an automated builder for the dawarich containers

That is very redundant nowadays, when Github offers free CI in Github Actions as this repo is already using: https://github.com/Freika/dawarich/actions/workflows/build_and_push.yml

[t3chguy]

@Freika If you're interested in a PR which does the following then LMK.

1. updates the Dockerfile to take the ENTRYPOINT as a build-arg
2. adds a Docker bakefile to spec the 2 inherent variants (images) you are shipping
3. updates the github action to use the bakefile

This would be wholly backwards compatible until a time in the future when you choose to change the entrypoints where anyone hardcoding them in their compose yaml will fall foul to having had to hardcode them due to your earlier decisions.

[Freika]

Well, I guess it'd be easier to write a proper instruction for Unraid users then? So they wouldn't suffer from my earlier and future decisions and do the deployment the Unraid way

[Freika]

With that in mind, I'd suggest anyone proficient in Unraid to make a PR to the docs, as I currently have no time or mental capacity to introduce changes in Dockerfile or the way Dawarich currently being deployed in an average homelab

[t3chguy]

I'm not suggesting "the Unraid way" - I don't fully agree with the CA Templates thing they have going on, I suggest "the portable" way which works however you choose to run the Docker OCI. Be it compose, helm, Unraid, whatever, without needing to manually specify entrypoint=<variable> per usage to vary between the main & sidekiq.

Other users relying on graphical Docker environments without compose support are equally impacted.

as I have no time or mental capacity to introduce changes in Dockerfile or the way Dawarich currently being deployed in an average homelab

My offer of doing the "heavy" lifting still stands, and I reemphasise that it is wholly backwards compatible as it doesn't change the deployment method inherently, it just changes the broken (as defined by you in https://github.com/Freika/dawarich/issues/928#issuecomment-2791045048) ENTRYPOINT as specified in the docker image itself

[nwithan8]

Relying on changing the entrypoint where the default Docker image entrypoint is just nasty. Why not publish 2 images with the correct entrypoint set, with the entrypoint command being very last, thus sharing all previous image layers between the 2 images intrinsically and being able to abstract the entrypoint away from a detail that all deployments must concern themselves with.

The unraid app seemingly current specifies thus:

Which does not run the entrypoint, it'd need to specify --entrypoint web-entrypoint.sh in Extra Parameters: to override the one baked into the image

Thanks @t3chguy for providing this insight. I have updated the template accordingly to redirect the container to use the web-entrypoint.sh script rather than the default entrypoint.sh, hopefully that should cause the Web Server container in the Dawarich stack to behave properly.

[Freika]

I'm not suggesting "the Unraid way" - I don't fully agree with the CA Templates thing they have going on, I suggest "the portable" way which works however you choose to run the Docker OCI. Be it compose, helm, Unraid, whatever, without needing to manually specify entrypoint=<variable> per usage to vary between the main & sidekiq.

Other users relying on graphical Docker environments without compose support are equally impacted.

as I have no time or mental capacity to introduce changes in Dockerfile or the way Dawarich currently being deployed in an average homelab

My offer of doing the "heavy" lifting still stands, and I reemphasise that it is wholly backwards compatible as it doesn't change the deployment method inherently, it just changes the broken (as defined by you in #928 (comment)) ENTRYPOINT as specified in the docker image itself

@t3chguy PR is welcome, although I'll still have to get the grasp of the changes and cannot guarantee it'll be accepted any time soon. Thank you

@nwithan8 does it mean you'll be able to introduce a change that will allow the unraid to run data migrations as they should? Also, it might be easier to communicate if you could join the discord server, but no pressure

[nwithan8]

I'm not suggesting "the Unraid way" - I don't fully agree with the CA Templates thing they have going on, I suggest "the portable" way which works however you choose to run the Docker OCI. Be it compose, helm, Unraid, whatever, without needing to manually specify entrypoint=<variable> per usage to vary between the main & sidekiq.

Other users relying on graphical Docker environments without compose support are equally impacted.

as I have no time or mental capacity to introduce changes in Dockerfile or the way Dawarich currently being deployed in an average homelab

My offer of doing the "heavy" lifting still stands, and I reemphasise that it is wholly backwards compatible as it doesn't change the deployment method inherently, it just changes the broken (as defined by you in #928 (comment)) ENTRYPOINT as specified in the docker image itself

@t3chguy PR is welcome, although I'll still have to get the grasp of the changes and cannot guarantee it'll be accepted any time soon. Thank you

@nwithan8 does it mean you'll be able to introduce a change that will allow the unraid to run data migrations as they should? Also, it might be easier to communicate if you could join the discord server, but no pressure

Already done: https://github.com/nwithan8/unraid_templates/commit/a18ba717e12cd630d6f04eac2723302cadcc9275

[mswdev]

+1 support for an official Unraid CA app and installation guide. Or simply endorsing @nwithan8 's Unraid Communitiy App with added unraid documentation.

[adromir]

It's already happening

[mswdev]

I successfully deployed Dawarich tonight on my Unraid server using @nwithan8's Unraid Community App template. Initially, I encountered some confusion due to a Rails S3 KeyError. Using ChatGPT (o4-mini-high), reviewing a comment from @nwithan8's Unraid support thread here, and reading through previous comments, I determined the issue stemmed from the breaking changes introduced in the recent Dawarich 0.25.4 release.

Specifically, version 0.25.4 requires two new manual configurations:

• Setting the new environment variable SELF_HOSTED=true
• Mounting a new Docker volume (dawarich_storage) to /var/app/storage

These updates haven't yet been incorporated into the Unraid Community App XML maintained by @nwithan8. After manually applying the environment variable and path for mounting the volume to my instance, Dawarich is now working properly.

Side note, I don't feel the docs are very clear about the need? requirement? for the second container of Dawarich for sidekiq. I couldn't find much in the docs regarding this other than the fact that it's in the docker compose file example and it's listed as a requirement by @nwithan8 in his Unraid CA description.

I still don't really understand what this second container is even for or why it's needed when it's using the exact same image for the primary Dawarich container?

[zodiac715]

I successfully deployed Dawarich tonight on my Unraid server using @nwithan8's Unraid Community App template. Initially, I encountered some confusion due to a Rails S3 KeyError. Using ChatGPT (o4-mini-high), reviewing a comment from @nwithan8's Unraid support thread here, and reading through previous comments, I determined the issue stemmed from the breaking changes introduced in the recent Dawarich 0.25.4 release.

Specifically, version 0.25.4 requires two new manual configurations:

* Setting the new environment variable SELF_HOSTED=true

* Mounting a new Docker volume (dawarich_storage) to /var/app/storage

These updates haven't yet been incorporated into the Unraid Community App XML maintained by @nwithan8. After manually applying the environment variable and path for mounting the volume to my instance, Dawarich is now working properly.

Side note, I don't feel the docs are very clear about the need? requirement? for the second container of Dawarich for sidekiq. I couldn't find much in the docs regarding this other than the fact that it's in the docker compose file example and it's listed as a requirement by @nwithan8 in his Unraid CA description.

I still don't really understand what this second container is even for or why it's needed when it's using the exact same image for the primary Dawarich container?

Sidekiq seems to be required only for the api. But im with you: The documentation can be better. Example: The manual configurations are only for Dawarich "himself", but not for the Sidekiq.

I'm not a developer and my english is really unstable but if i can help (translations in german or things like this) please ask me

[nwithan8]

I successfully deployed Dawarich tonight on my Unraid server using @nwithan8's Unraid Community App template. Initially, I encountered some confusion due to a Rails S3 KeyError. Using ChatGPT (o4-mini-high), reviewing a comment from @nwithan8's Unraid support thread here, and reading through previous comments, I determined the issue stemmed from the breaking changes introduced in the recent Dawarich 0.25.4 release.

Specifically, version 0.25.4 requires two new manual configurations:

* Setting the new environment variable SELF_HOSTED=true

* Mounting a new Docker volume (dawarich_storage) to /var/app/storage

These updates haven't yet been incorporated into the Unraid Community App XML maintained by @nwithan8. After manually applying the environment variable and path for mounting the volume to my instance, Dawarich is now working properly.

Side note, I don't feel the docs are very clear about the need? requirement? for the second container of Dawarich for sidekiq. I couldn't find much in the docs regarding this other than the fact that it's in the docker compose file example and it's listed as a requirement by @nwithan8 in his Unraid CA description.

I still don't really understand what this second container is even for or why it's needed when it's using the exact same image for the primary Dawarich container?

Thanks for bringing this to my attention, I've updated the templates accordingly.

[Freika]

Side note, I don't feel the docs are very clear about the need? requirement? for the second container of Dawarich for sidekiq. I couldn't find much in the docs regarding this other than the fact that it's in the docker compose file example and it's listed as a requirement by @nwithan8 in his Unraid CA description.

I still don't really understand what this second container is even for or why it's needed when it's using the exact same image for the primary Dawarich container?

Have a look at the bottom of this page, the info section: https://dawarich.app/docs/intro#update-your-dawarich-instance

It contains info on what containers you should have running to have fully functional Dawarich instance