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

Apps and Virtualization
,
50

The difference is flexibility. With Portainer, switching between Git sync and local editing isn’t seamless : you’re either in one mode or the other.

With a local compose file and a cron job handling Git sync, I can just pause the cron, edit freely, iterate, then commit and push when I’m happy. Same end result, but the workflow feels a lot more natural.

As for the TrueNAS backup point, fair point and good insight, and as they are git backed-up it doesn’t even matter much so let’s get that out of the way then :+1:

51

Well, if you really need git for compose files (for versioning GUI, I suppose), you can just version portainer’s volume directory by git with a kinda same result (I personally won’t do it).

Seems like the tradeoff is

  • Having the better UI for management. Portainer is definitely better than SSH; it’s debatable for VSCode.
  • —OR—
  • Having the better UI for compose versioning. With proper snapshot schedule, you would be able to view/restore a particular compose file. Although, it isn’t as convenient as github/gitlab/gitea.
2 Likes
52

I’d think VScode with some github plugins using a git setup on TrueNAS could work.

Personally my stack is using Arcane with git pull every 5 mins and renovate is running on GitHub, you can even set Arcane to use a specific directory / dataset and make snapshots locally also, but I mean, once you’re into gitops, there’s tons of options

1 Like
53

That’s great! Do you know if there are other options like this that we can use to further customize it?

Isn’t there an option to add the icon line directly to the metadata?

Then we wouldn’t even need to edit the metadata.yaml file.

54

Thanks all for the excellent information in this post! A few things I thought might be useful for folks:

  1. This actually doesn’t seem to be necessary, thanks @swc-phil!
  1. Don’t forget services: {} in the custom yaml box:

25.10 RC1 Custom App YAML Input Bug? - #5 by Rocketplanner83

include:
  - path: /path/to/your/compose.yaml
services: {}
  1. Updating container images via the Apps interface is not straightforward in my experience (compared to the regular docker compose pull and docker compose up -d approach). However, you can add pull_policy to each service to trigger a pull when you restart the app from the Apps interface. I have tested and confirmed that pull_policy: always works, and I currently have everything set to either daily (most things) or build (Caddy built with the Cloudflare module, I have it commented so it doesn’t re-build on every restart, see below).
  1. One other thing that seems useful that I don’t see mentioned elsewhere, you can create external networks as normal, just access the shell and sudo docker network create caddy-nextcloud-net (before you start the container for the first time). Add the network to your compose file as normal:
services:
  caddy:
    ...
    networks:
      - nextcloud
    # uncomment and restart via Apps interface if an update is needed
    # pull_policy: build

networks:
  nextcloud:
    name: caddy-nextcloud-net
    external: true
55

Mine works just fine without it…

1 Like
56

Same, actually! I spun up a quick code-server instance to test and the services: {} addition wasn’t necessary. Edited the post, thanks!

1 Like