Docker GUI plugin now stable

Zitat von nicjo814

Add the flag in the extra args field just as you wrote it and it should work.

Is there a difference between adding it to the environment variable section vs the extra arguments? I've been using linuxserver containers and just plugging the PUID and PGID as new environment variables.

Zitat von nicjo814

A really good question. If you add a variable in the GUI as "environment variable" the plugin will add the following to the command being executed "-e <KEY>=<VALUE>", which will tell Docker to add a new environment variable. The extra arguments field is used for Docker parameters that are not supported in the GUI, such as the "--cap-add" parameter. When I designed the plugin I tried to add as few configuration items as possible and still cover as much of "daily use" as possible. Docker comes with a ton of parameters...
EDIT: The PUID and GUID environment variables are things introduced by the linuxserver.io team and is not a part of the Docker framework in itself.

That's a good point, I am very much new to Docker and so far the only arguments I find myself using are "-e" variables. I found that when I put them in the extra arguments field, they just ended up being added to the environment variable section later, so i've just been putting them there myself. That makes sense, thank you.

And I originally thought those variables were required for all containers, but another member here mentioned he used only linuxserver containers and they were specific to them.

Zitat von nicjo814

variables are things introduced by the linuxserver.io team

It's actually funny to me that almost everyone on these forums and others that are running things like Plex, downloaders, and most home enthusiast types - are running LS.io containers! I mean it's fantastic what they've done, no doubt, but it's amazing how wide spread their containers and methodology really are. I've seen other replicate the functionality (maybe not exactly the same) by introducing variables for the user/group of the user inside running the service. Welcome to the fold flvinny, docker is a lot of fun once you understand and get a hang of it. It's my go-to platform to search for new apps I want to try out since I can spin it up/down quickly, easily, and not impact my systems.

Zitat von 1activegeek

It's actually funny to me that almost everyone on these forums and others that are running things like Plex, downloaders, and most home enthusiast types - are running LS.io containers! I mean it's fantastic what they've done, no doubt, but it's amazing how wide spread their containers and methodology really are. I've seen other replicate the functionality (maybe not exactly the same) by introducing variables for the user/group of the user inside running the service. Welcome to the fold flvinny, docker is a lot of fun once you understand and get a hang of it. It's my go-to platform to search for new apps I want to try out since I can spin it up/down quickly, easily, and not impact my systems.

I had set up OMV about 6-8 different times in a virtual machine playing around with different plugins and methods, but in the end, when it was time to install on a system, I decided to use Docker for everything. Since linuxserver.io is so well documented and tested by thousands, I am using their containers for everything that's not in base OMV (well, besides mergerfs, SnapRAID, flashmemory, etc.). I'm sure there are probably more optimized containers out there, and I'll get around to trying them eventually, but first I need to get my server up and running at full speed again before my friends and family go berserk.

Is there any downside to keeping these apps running instead of switching out to "native" installations at some point in the future? Seems like they run just as well as if I had installed a plugin.

I would agree with @nicjo814 - I've done the same thing for some time now. I switched around running different VM's on an ESX host, I've fiddled with running services locally, I tried running plugins - in the end, Docker tends to have more universality to it allowing you to run anywhere. I also dug in a bit deeper and even created alternative containers that LS.io hadn't offered at the time, but used their core images (a little github searching and you can find the relevant pieces) - scrapped together and ran some apps I needed. I too love the flexibility of it NOT modifying my core system to setup the runtimes and components it needs. It's only flaw, which I believe has been overcome now, is that you couldn't run windows based apps before. I don't have any I cared about, but I know there are lots of windows only based things in the world. There is fresh support for that though, I just never cared to test the waters with it.

I'd say if you already have the containers running, focus on that. If nothing else it's a useful skill to understand how they work more so than just using plugins to OMV which are more or less just apps being installed onto OMV with some type of a GUI management plugged into the OMV interface. At the root of it all, you're usually still running a core linux app under the hood. Docker can be quite useful to know.

Just a question regarding the containers and what I assume are the filesystems docker creates..
which leads me to...

Docker creates a 10Gb filesystem(xfs) for each container... at least it does on my install of OMV/docker.
Is there anyway to change this size? All my containers use under 1Gb and thus I loose 9Gb pr. container...

hm... so maybe not docker.. but then... what?

I honestly just assumed it was docker :-|

hi Subzero79 and thanks.
So it IS docker... it's not that I mind it as such - just finding it a waste but if it's using thin-provisioning then I guess I'm not loosing storage
I don't think switching to another fs is worth the hassle.

Just wanted to jump in and point out a few things I noticed recently in testing/using the docker plugin:

• Clear log - extremely useful!! Thank you for this.
• I think it's related to the macvlan usage - I can't seem to get the hostname variable to take when using macvlan - I setup a container using a macvlan and for some reason the hostname is resorting to the contianerID
  
  
  • When I try to "modify" the container, it will then show me the replaced hostname field with the ContainerID - edit, and same thing still uses the new containerID instead of assigned hostname
  • All other containers NOT using macvlan are working as expected with the hostname setting
• Support for non docker hub sources - it seems (or I couldn't find) a way to import images from outside of the usual docker hub repositories.
  
  
  • Thought here is some extra logic to assume if given just a <source>/<project> format, then query docker hub. If receiving extra input like: fqdn.host.domain/source/project - then query the actual domain supplied.
  • Not sure if it's as simple as that, but ti would be nice to support external sources as well as hub.docker.com
  • It seems more companies offering official images like to use this - not sure why
  • Solution for now was manually pulling the images via the CLI then they showed in the console - updating them though, also causes the same issue, so will need to do this manually as well
  • Info button also defaults to opening the project on docker hub, vs the domain supplied

Zitat von subzero79

Can you source me a link to external repo to test? this is new to me, is it just docker pull fqdn.host.domain/source/project

Yes I believe that is all that should be needed. This is referred to as a different Docker Registry. The default registry most use is hub.docker.com. Official Docker Registry Docs - this should cover the basics of the allowed formatting. As an example, this is the container I was trying to pull with reference documentation - ElasticSearch Container. Working on building an ELK stack using the official images. They have options available in Docker Hub, but as of the next revision, they will only support their private registry, so I'm starting with the private option now rather than migrate later. As seen at top of the page, the command is:
docker pull docker.elastic.co/logstash/logstash:5.5.1
So resulting format is just the same, but requires support of fqdn:port/source/project