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

Apps and Virtualization
1

So, an earlier discussion noted the limitations of Eel regarding not being able to edit after uploading them via create custom app, inability to use .env files, and, needing to keep Dockerfiles elsewhere via a full path build context. I have solved all that, for the way I want to do it at least. Let’s see if anyone likes.

Here is a caddy reverse proxy setup with custom plugins (porkbun dns and labels) where I illustrate:

Dockerfile:

FROM caddy:2.8-builder AS builder
RUN xcaddy build \
  --with github.com/caddy-dns/porkbun \
  --with github.com/lucaslorentz/caddy-docker-proxy/v2
FROM caddy:2.8
EXPOSE 80 443
COPY --from=builder /usr/bin/caddy /usr/bin/caddy
RUN apk add --no-cache tzdata
CMD ["caddy", "docker-proxy"]

Compose file:

services:
  caddy:
    restart: always
    env_file: .env
    ports:
      - name: Reverse Proxy Ingress
        target: 443
        published: "443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /mnt/tank/Data/Caddy/Config:/config
      - /mnt/tank/Data/Caddy/Data:/data
    labels:
      caddy_0.email: "{env.EMAIL}"
      caddy_0.acme_dns: porkbun
      caddy_0.acme_dns.api_key: "{env.PORKBUN_API_KEY}"
      caddy_0.acme_dns.api_secret_key: "{env.PORKBUN_API_SECRET_KEY}"
      caddy_1: (encode)
      caddy_1.encode: zstd gzip
      caddy_2: "localhost:80, localhost"
      caddy_2.root: "* /usr/share/caddy"
      caddy_2.file_server:
    build:
      context: .
    healthcheck:
      test: ["CMD-SHELL", "wget --no-verbose -T3 --spider http://localhost:80 || exit 1"]
      interval: 1m
      timeout: 10s
      retries: 3
      start_period: 30s
      start_interval: 5s
    pull_policy: missing
    networks:
      - Caddy
      
networks:
  Caddy:
    name: fatula
    external: true

So, how you say does that work? I use include! So, on the custom app creation screen, app name is caddy. and the compose file is simply:

include:
  - /fullpathtocomposefile

Now, there is no need to edit the compose file in the UI as the compose file is in somedir on the NAS. Since env files and dockerfiles are relative to the compose file, those work fine in the same fullpathtocomposefile dir (somedir). Note that compose specifies env_file: .env so it knows what dir. And the build context is . so same somedir. This also allows me to use the same exact files on another machine to develop them, no paths to change. So, compose.yml, .env, Dockerfile all in one dir somewhere on the NAS.

This gets around not being able to simply use .env files in the UI custom app creator, or to easily do custom builds.

The reason same files on another machine is important to me is I develop them on a non Truenas machine for testing (desktop). I don’t have to want to have to change the files to test it.

5 Likes
2

Yo, using include is actually a genius idea. This also allows to keep an easy backup of the contents of Compose file itself and edit it directly there. If the relative paths work, seems that this has no cons basically. Thanks for sharing.

Btw, so I assume "{env.PORKBUN_API_KEY}" gets expanded to what’s in the .env file. Is this syntax needed, or would something like ${PORKBUN_API_KEY} also work or break? Wondering about this in relation to the issue I mentioned with env in the other thread: whether with include it’s different, or is the {env:...} syntax a workaround that allows using stuff from env_file: inclusion in both cases.

3

Exactly, easy backups, in your filesystem not .ix-apps, etc. Relative paths work as shown. I have many apps hooked in separate compose files to the caddy reverse proxy all automatic from labels.

Yes, it gets expanded from what is in the .env file. I believe it’s needed, not 100% sure. I believe that’s how compose works and your proposed syntax means something different, but am not sure, just the way I’ve always done it. The quotes are needed. I don’t think the include is any different as my desktop uses the same files without any include just fine.