Allow apps to have their own IP

Not sure either how “double management” would play out.
The safe choice is likely to install Portainer from TrueNAS catalog, and then install and manage further containers from Portainer.

Is not the traffic then router through your main interface?

That was what I found out, trying to achieve that I have a Custom App in TrueNAS Scale which would be utilizing a subnet on my network which is strictly through VPN.

I have tagged VLANs coming in to an interface on my baremetal TrueNAS Scale installation (enp4s0), and I have configured this Custom App for qBittorrent:

services:
  qbittorrent:
    container_name: qbittorrent
    image: qbittorrentofficial/qbittorrent-nox:latest
    hostname: qbittorrent
    environment:
      - QBT_LEGAL_NOTICE=confirm
      - QBT_VERSION=latest
      - PUID=850
      - PGID=1002
      - TZ=Europe/Paris
      - TORRENTING_PORT=6881
      - QBT_WEBUI_PORT=8090
    volumes:
      - /mnt/Tank/Docker/qbittorrent:/config
      - /mnt/Tank/Torrents:/downloads
    ports:
      - 8090:8090/tcp
      - 6881:6881/tcp
      - 6881:6881/udp
    restart: unless-stopped
    stop_grace_period: 30m
    tmpfs:
      - /tmp
    tty: true
    networks:
      vlan60_macvlan:
        ipv4_address: 192.168.60.30  # <-- Choose an unused IP from your subnet
    dns:
      - 192.168.60.24  # <-- DNS
      

networks:
  vlan60_macvlan:
    driver: macvlan
    driver_opts:
      parent: enp4s0.60                   # <-- match your parent interface name
    ipam:
      config:
        - subnet: 192.168.60.0/24     # <-- match your LAN subnet
          gateway: 192.168.60.2       # <-- match your router gateway

My greatest fear is creating a feature request on the forums, but not getting any votes. :pensive:

My second greatest fear is creating a feature request on the forums, getting a record-breaking number of votes, popping a bottle of champagne to celebrate, and then this happens. :sweat_smile:

Stay strong, @victor. I will inject another batch of votes from my bot army to help you out.

1 Like

Thanks a bunch! I was struggling to figure out how to get my pi-hole to point to my nginx proxy manager for multiple hours and this was the comment that finally got it all working.

Wait, wasn’t this already accepted?
Or is the devil in the details, this feature request asks for it to be changed in EE, but the planned change is coming in Fangtooth?

Apps with Configurable IP addresses: Apps in Electric Eel use TrueNAS’s host IP address. Fangtooth enables IP alias addresses to be created and assigned to one or more Apps.

This was accepted:

It’s a simpler thing to provide which accomplishes much of what’s desired.

The key difference is “allow app to have its own ip” vs “allow app to bind to a specific ip alias on the host”

Ideally, TrueNAS should also support creating, utilizing macvlan ips with apps, which is more or less what this request is for.

3 Likes

I agree that this is a pretty glaring missing feature. I’ve been putting of my migration for quite some time now and really want to move to scale, but there are a lot of quirks that have held me back. This may be the last feature holding me back at this point. I have a bunch of apps that I assign different IPs for VLAN access and various automations that work much better (or in some cases only work) with assigned IPs rather than port mapping apps on the host.

I will try portainer as a workaround for now, but I am probably going to hold off on my migration a little longer until this feature is included in scale

2 Likes

We are targetting early June for most/all Apps. Some of the newer Apps have the capability now.

1 Like

Same boat, Captain. Want to migrate from Core but this is a hold back for me too.

Is there any way we can track an app list of apps that have been modified like this, especially if we are running Fangtooth?

Just as a follow-up, I still think this is an important feature, but decided to make a backup and try out things through Portainer adding a MACVLAN and I am happy using the built-in Portainer app and setting up my stacks/containers that way. It was a bit frustrating getting used to things in SCALE at first, but it much more polished overall than CORE. I think the IX devs have done a very nice job so far. I do look forward to seeing a few more of these types of features added soon, as you mentioned.

2 Likes

At a simple level, Apps that were available in Dragonfish will have to wait until June 1. The delay helps Dragonfish users migrate seamlessly.

That will be most of the popular Apps so it does probably delay a migration. The good news is that Fangtooth will be more mature by then.

1 Like

Thanks for the constructive criticism. We’d like to move faster, but would prefer not to strand the Dragonfish users.

Now if all Dragonfish users could migrate quickly, we could change the schedule.

1 Like

I only use custom apps on my Dragonfish install. They are tied to a bridge that is in turn tied to a different IP alias than the TN GUI.

Will any of the new functionality be helpful in that scenario? Can I set up something similar using the Custom app GUI or failing that, Custom app YAML? Or will I need to use something like Portainer or Dockage to achieve feature parity?

I think you can do what you need with custom Apps, Dockge and Portainer in Electric Eel.

Fangtooth makes it simpler for standard Apps. (After June 1st)

Okay, good to get clarification on that.
I hope the goal is to achieve feature parity eventually, to allow for IP aliases to be tied to Docker containers (even custom containers) in the same/equivalent way as is possible in Dragonfish right now.

Dockage and Portainer are not that appealing to me as rather not have yet another GUI to manage (some) of my apps.

2 Likes

Lawrence Systems did a video on this recently and he shares our sentiment on this. Are there workarounds? Yeah but a clean, baked-in implementation is way nicer and we’re headed that direction already. Homarr, Heimdall and open speed test already support this.

1 Like