I have upgraded and none of my custom apps migrated.
I have several vlans on my truenas server and I want some to be on a different vlan.
How can i do this, at the moment it says they are configuration only networks.
There’s an open issue on the Apps repo on GitHub, so right now you can’t do it
this right here is what’s stopping me from updating my main TrueNAS box…
I have multiple internet connections with certain containers needing a specific connection. and the easiest way to accomplish this is to have a separate IP (but you still have to set the route in the container, irritatingly enough)
EE doesn’t support this right now, so my apps would break horribly.
Lots of people are using Install via YAML aka Docker-Compose files or flat out Portainer/Dockage to run their apps for that reason.
They’ll add more and more to custom-apps and the standard catalog but it’ll take time and never be on par to a “docker-compose” file for sure
Not enough information:
Specific VLAN configuration?
(IP assigned to the vlan interface, or did you create a bridge and assigned the IP there?).
You can do it if you understand Docker networking.
You could do it with network_mode: host (if you have an IP assigned on the vlan).
Otherwise you need a MAcvlan network and you will need to do it in docker compose in the command line, or through a docker compose app.
For this, you would use Macvlan and link it to a bridge.
(You create your VLAN and then a bridge with the vlan).
networks:
macvlan_network:
driver: macvlan
driver_opts:
parent: br30
ipam:
config:
- subnet: 192.168.3.0/24
ip_range: 192.168.3.75/32
gateway: 192.168.3.254
1 Like
Ok the reply to post is acting but for me, but yeah none of those methods are clean like the old way with Custom-App was, def got options (I prefer not giving my apps Host-Networking for example), so ideally like you said if he wants he should do a docker-compose
Clean?
That’s only an opinion.
IX-Systems can certainly code the GUI to “make it clean again”.
But if people don’t understand and don’t care to seek, read, learn, do, test, compare, change, test again…
That can allow lots of unintended issues/complains, depending on the amount of validation, logic and checks that IX can/will do.
Specifically the big (default) networking differences between kubernetes (routed subnets) and docker (NATed subnets), maybe that’s what most of us want, to separate the real geeks from the posers.