Electric Eel - How I am using Dockerfile, .env files, compose files

include:
  - path: /mnt/tank/Data/Compose/Ubuntu/compose.yml
    env_file:
      - /mnt/tank/Data/Compose/.env.global
      - /mnt/tank/Data/Compose/Ubuntu/.env

Indeed, this seems to work for variable for the compose interpreter and variables for inside the container.
Sorry for the back and forth.

Here is an explanation how to add your own app icon. How to change icon of custom app? - #25 by adelzu

1 Like

It’s ok, my bad at first for not understanding the specifics and not taking the time to actually see what you are saying. Yes, I change the custom icons myself, thanks for posting and hopefully it exists in Truenas soon. I just wanted to give you a non change Truenas option that is native docker.

What’s weird is it does work to me, but, it’s a semi well known docker workaround that has worked for many many years as docker has never responded to the github issue for your requirement (from someone else). I believe they suggested it originally.

1 Like

So I’m kind of a dummy when it comes to Docker, specifically when it comes to Dockerfiles, as I’ve never had occasion to use them before. So I create $SOMEDIR, and in that create Dockerfile mostly as above (though with Cloudflare because I’m using that), compose.yaml mostly as above, and .env containing my admin email and API credentials.

Then create a custom app containing:

include:
  - $SOMEDIR/compose.yaml

Straightforward enough–but where does the custom Caddy image get built? It has to, right, to include those two plugins? Or does the (effective) docker compose up -d build that as part of the process?

Edit: Well, nothing like just giving it a try. And the answer is, yes, docker compose up does build the Dockerfile. It works, Homepage proxies behind it with just two labels (vs. five with Traefik), and of course Caddy’s configuration is considerably simpler than is Traefik’s. Now a bit of conversion to do on my apps. And work out how to expose Caddy’s API to Homepage…

1 Like

7 posts were split to a new topic: Dockerfile, Caddy, and qBittorrent, oh my!

I found this through Techno Tim’s recent video. Just wanted to drop some appreciation. I’ll be trying this out soon.

1 Like

Two Questions:

Does this work when there are multiple containers within a single Compose file?

Can I use this for existing compose stacks that were created via CLI?

Thanks.

Didn’t try it myself, but see no reason why it wouldn’t.

Perhaps you would need to migrate the content of your volumes. Did you really run your compose from the console?

Hello,

I am new to TrueNAS and I am undecided between dockg and this custom app/include approach.

What I really would like is to keep the dependencies/additional tools to a minimum, so this is a plus of this approach, although realistically, I would need studio code server or similar to edit.

What i am wondering about this approach:
My understanding is that I can export a TrueNas Settings file, load that into another server and everything will be restored from there (except for the Data).

If I go for this approach and restore, would the custom docker files be part of the TrueNAS Settings file? Probably not, right?

But apart from that: What is the benefit of this approach vs. dockge?

Greetings,
Hendrik

I’m almost sure it won’t be backed up.

Didn’t use dockge, so can’t say for sure. But if I were serious about running docker containers on truenas, I would deploy portainer-agent to truenas and then would manage containers from the portainer on a separate machine. Thus, truenas would store only data volumes and images.

Right now I run only 1 container on truenas, so I decided to not go the portainer-agent way. Can’t say that suggested approach is the best; I am just experienced with/used to portainer.

Yes. I have tested this myself.

Yes. Just point the include to that docker compose file. It may need a one of the above fixes if you use a .env file.

Thanks. Just tested this and here are my observations.

  • If the container / stack is already running, you have to down it and it will up when creating via the includes yaml option
  • If using a stack, the stack displays as the App in the GUI and all the containers show when the stack is selected
  • The GUI options to stop/upgrade only apply to the stack - no individual container options
  • The GUI indicates if one of the containers requires an update, but does not specify which container

I wrongly assumed it would show each individual container as the app instead of the stack, but the way it works makes total sense and it does work.

1 Like

I confirm all of this as well. I setup my apps in TrueNAS this way last night.

I like having all of my containers setup with compose so that I can use git to backup the compose.yaml, any .env files, and any other config files. It helps me track what changes I’ve made to a stack in time. It’s come in handy more times than I can count to see ā€œupdated config due to v1.2.3 breaking changeā€. Or else I might fix the same thing multiple times. :smiley:

One other thing I noticed.

It seems you can’t control the stack via CLI once it’s added in the GUI. When I ran ā€˜docker compose ps’ in the stack directory, no containers were listed.

Just an FYI if your intention was to gain some visibility in the GUI but continue managing via CLI. I could also be wrong - I only noticed this when I went to down the test stack I had added using the includes option and did not test thoroughly.

1 Like

I wrote this at some point:

If you want to use the docker compose command to aid you in some tasks:

  1. First check list of projects with docker compose ls. It will print out a table of NAME, STATUS, CONFIG FILES. The names are in format of ix-<HowYouNamedYourAppInUI>
  2. Now run a command like docker compose -p ix-minio ps

Tada :tada:. Very neat. You can use it for some things if you can’t be bothered to do them in the UI or factually can’t do them there, and it’s cleaner than messing up with the containers individually. As for why you can’t instead enter the workdir of Compose project like usually with stacks or use the -f option to specify the runtime path of Compose file: don’t ask me.

But actually some rare things might want -f to the Compose file and you can also run docker compose pull in the directory without any further options, which also doubles as a way to validate your Compose file contents.


But the reason I’m coming back to this thread is to report that TrueNAS 25.10 partially breaks this now:

The workaround is to prepend services: {} at the top above your include:

EDIT: Bug has been filed: Jira

2 Likes

In case anyone wanted to know how to add a button that links to the application (and/or add some notes to this application in TrueNAS):

If you install a new yaml using this Custom Config, you can add the following snippet and customize to your needs to show a button to your application.
This only appears to work at the time of creating the app. Adding OR changing the extra stuff after the fact did not add, or change, the button or Notes. You’ll have to recreate the application if you made a mistake.

include: - path: /mnt/<path/to/compose.yaml
services: {}
x-notes: |
# VS Code Server or whatever
Add as many lines of text as you want, but do mind the indentation
x-portals:
- host: 0.0.0.0 # replace this with FQDN or dedicated IP address if you like
name: Web UI # text on the button
path: /
port: 8880 # change to whatever port the service is listening on
scheme: http # change to https if the app uses HTTPS

2 Likes