primeval_god

If you are using a reverse proxy container and both it and the container you are proxying are connected to a custom bridge docker network for internal communication then there is no need to make map the application containers ports to the accessible ports on the unraid host. Without the port mapping the only way to access the application is through your secured reverse proxy.

This is not currently possible with this plugin.

The plugin is called compose manager. Just search for compose in the plugins category of community apps.

The first thing you will need is a reverse proxy app to route all of your applications through a single authenticated address. I personally use traefik with organizr as an authentication app. That said these are probably more complete alternative solutions .

Docker is the recommended way to install/use applications in unRAID. Its another one of the particulars of the unRAID system. Docker application containers (especially those available in community applications) allow applications to be somewhat isolated from the system so they can only access intended data and are isolated from compatibility issues with unRAIDs stripped down OS. Plugins on the other hand are more for things that require direct integration with the OS or webui.

Here is a plugin I maintain, i wont promise that it is the best designed plugin ever but i think the build scripts might be worth looking at https://github.com/dcflachs/compose_plugin. It was originally forked from Squids user.scripts plugin so at least the bones of it were created by someone competent in unRAID plugin development.

Technically yes though doing so may be challenging. The plugin system/architecture is poorly documented at best. Adding new pages/tabs of the webui is reasonably simple, modifying or extending existing ones is quite a bit more complex and more hacky. For prior art on displaying drive related info the source for the unassigned drives plugin or the zfs plugin might be a good place to start. As for why this was brought up, The unRAID OS is not really designed with the usage of traditional RAID arrays or other storage architectures beyond the core unRAID array (looking at you ZFS) in mind. The ability to use btrfs raid pools is a rather new addition and still designed in service of a main unRAID array. When questions pop up about other RAID levels and hardware RAID it tends to be from newer uses who dont really understand what unRAID is and how its is meant to be used.

It has been suggested earlier in this thread that counterfeit devices may end up intermingled with legitimate devices due to how Amazon controls products in their warehouses. See comment below.

At this time compose manager only manages stacks created from its interface. When you add a stack in the webui it creates a folder on the flash drive and populates it with a new compose.yml. You could try copying the contents of your obico-server folder into the folder created by a compose manager stack.

Are you aware of this plugin?

When you say they stick do you mean a docker inspect shows that the labels are not updated or that the webui doesnt pick up the changes and modify its links? What version of unRAID are you running? The translating of labels to webui links is a feature of the unRAID os rather than this plugin specifically, if thats the issue we may have to raise this to limetech. There should be no reason to reload the page, it should auto refresh when the editor closes. Also you shouldnt have to do compose down and then compose up again. Running compose up on an already running stack should recreate its containers if anything has changed in its config file.

This will not change if you switch to this plugin. Containers managed via this plugin can be updated via a button in the gui however their update status does not integrate with unRAID's native dockerman ui and so the "update ready" label will continue to be present.

Issues with booting from usb3 ports has been a somewhat common issue in the past. It was never clear to me if it was due to linux support for booting from usb3 controllers or if it was issues with some of the earlier usb3 controller hardware. It has been less of an issue recently but still crops up from time to time. Not sure if the qnap platform has issues with this. The recommendation for unraid is typically a usb3 drive in a usb2 port when possible for the best compatibility. There is a global help button, not sure if you have found it, that reveals help text throughout the webui. Much of the built in functionality has fairly robust help text in my opinion. While mirroring is supported in cache pools it is not really intended to be the primary method of redundancy. Unraid is built around the unraid array (which in my opinion is its star feature). The unraid array is parity protected with single or dual redundancy options while still allowing each data disk to be read independently.

It may be possible but its not really what docker was designed for. For os containers i think LXC is a more likely path, though I dont know if/how GPU's integrate with it. LXC is not a built in option for unraid but there was a plugin recently released to add it. It may be worth looking in to.

This is expected behavior currently. The "update ready" notification in the unraid webui does not work correctly for containers created with compose. Additionally the compose pull functionality does not remove dangling images the way dockerman does. It is unknown if or when these issues will be addressed.

Autostart works just fine. The scripts in the event directory are triggered by unRAID system events. This is not the case. The compose.manager plugin stores stack names in a file called "Name" in each stack directory. "$(cat $dir/Name)" reads the stack name.

@OFark @bergi9 @spychodelics A new version is available that fixes the terminal style output for 6.10.0. A big thanks to @bergi9 for helping me track down the issue.

This is already planned but not yet implemented.

This plugin has a settings page, there should be a listing for compose.manager under the unraid setting tab.

@OFark @spychodelics This plugin has not yet been updated to work correctly with 6.10. Until it is, set the terminal output style to "Basic" in the settings page that should restore functionality. I hope to have an update made in the next couple of days.

Does /root/.docker/config.json exist on your system? From what i can see compose should grab credentials from that file, which is where docker login caches them.

Thanks good to know, i havent yet tested against 6.10 as I still run 6.9. I cant find a good reason that this should be the case. Are any errors reported in the compose log?

It just issues compose pull for now. At the moment this plugin doesn't really have any considerations for the build aspect of compose.

I am aware of that option, though there is still the matter of the display discrepancy in the port listing. Overall this is not a major issue, but I still would like to see it as an improvement to dockerman.

This is not necessarily true. If a host has more than 1 ethernet ports with separate IP addresses for each the docker port publishing syntax can be used to expose a port on a specific ip address. If no IP address is specified in the port mapping then the port is exposed on all interfaces. In a new setup i am trying i have the 2 ethernet ports with separate IP addresses. eth0 the primary host port on which the unRAID webui is exposed 192.168.0.44. And eth1 192.168.0.55 which the unRAID webui is not accessible on. Custom bridge networks are setup for each interface. If I spin up a container with a port mapping of 8080:8080 and connect it to either bridge network, the container is accessible from both 192.168.0.44:8080 and 192.168.0.55:8080. If I use a port mapping of 192.168.0.55:8080:8080 then the container is only accessible via 192.168.0.55:8080 and not 192.168.0.44:8080. Additionally specifying 2 containers with 192.168.0.55:8080:8080 and 192.168.0.44:8080:8080 respectively is possible with each being accessible from the specified IP address through the matching ethernet interface. I am not sure if this is a newer docker feature or if it has always been this way but it is definitely in the current version https://docs.docker.com/config/containers/container-networking/