[ACCEPTED] Allow apps to have their own IP

Feature Requests
41

Its not quite that simple unfortunately. When you’re talking about a “custom app” added through the GUI in Dragonfish, that is still technically a catalog app, since it uses the underlying catalog app to convert your configuration into a kubernetes chart. So your custom apps will still need the migration job to automatically transfer to Electric Eel.

There is a lot more detail about the change, why, and how here: https://www.truenas.com/docs/scale/25.04/gettingstarted/scalereleasenotes/#truenas-apps.

In your case, if you’re using only custom apps with unique IPs, you have a few options.

  1. Wait until after June 1 to migrate, accept that your app configurations will not migrate, but your host path storage will (I’d recommend looking to migrate any ixvolumes you have to host paths now regardless of the option you pick–which might require a redeploy of the app in DF but will be a more persistent storage method). That will allow you to redeploy the apps in EE, point storage to the existing locations, and get things back up and running with assigned IPs.

  2. Migrate whenever, take advantage of the automatic migration, and just use ports assigned on the host IP until after June 1 when you can assign an IP.

  3. Migrate closer to the June 1 deadline to still use automatic migration then have a shorter period using ports or simply do not use those apps until after the deadline and you can update IP assignments.

  4. Migrate whenever and ignore the automatic migration. Redeploy the apps as Compose files using the Deploy as YAML option in the UI or manage them with dockge or portainer and apply custom networking that way. There are threads on the forum talking about how to do that.

2 Likes
[Feedback Captured] Bring Back the Classic Setup Wizard for Pool and Share Creation
42

FYI there is a bug which doesn’t allow re-use of some TCP ports from other IP addresses.

This is being worked and we’ll update when we know how and when it can be resolved.

https://ixsystems.atlassian.net/browse/NAS-135842

5 Likes
43

Lets mark this on as accepted

Its is 24.10.2.2 and 25.04

1 Like
44

I don’t think it is.

The keyword is their “own” IP

What is is there is IP Binding, which should work in some cases and is a good step.

The next step is to allow apps to be able to act like little virtual machines, complete with their “own ip”, and in docker, this means using the macvlan or ipvlan network config

1 Like
45

Yes, but there is a separate feature request for macvlan… shouldn’t we focus on that one (or delete it)?

46

That is for the next next step which is to allow TrueNAS itself to use macvlan so that if can communicate with the little vms

47

I’ll let @victor make the final decision.

The original request did not include macvlan and the title did not require it.

If we created macvlan interfaces as you suggested in the other Feature Request, then wouldn’t Apps automatically have access to the same capability?

48

  1. you need to create a docker macvlan network

  2. you need to be able to pick that network for an apps network, and specify an ip

Which leads to an interesting feature… which is the ability to create/delete any docker networks and assign them… not just macvlan… good for proxies etc

Then you have another issue which is the host/app can’t communicate.

The traditional TN way to solve this is to put a bridge in (to be honest, I forget if this works, its been a while since I tested it)

An alternative, is to add a macvlan interface to the host, and if desired setup routing, but its not needed if the host itself is on the macvlan.

49

I’d prefer you expand on this in the macvlan request… it becomes a whole requirements doc if you identify all the steps and the benefits.

50

Even though I don’t use TrueNAS anymore, I think what I did originally intend has been added.

Probably best to start a new request.

1 Like