Docker GUI - Failure to fully enumerate Environment Variable

1st Official Post

    I've got a new issues I've run into with some images. I say some, as I only have one case specifically where it is a problem, but it could be happening elsewhere.


    Short Explanation: Somehow the Docker plugin is truncating or removing or otherwise NOT fully enumerating an Environment Variable that has been declared in a Docker file.


    Long Explanation: GitHub Issue 105
    Basically it seems that if I create the Plex container from the LS.io container listed inside the OMV Docker Plugin GUI, it fails to properly enumerate the URL that is listed for the PLEX INSTALL path variable. If however I manually run a docker run command on the CLI (not different images, options, etc) - it runs as expected. At this point, to get around the issue, I've manually created the container to run via the CLI. My fear however, is the next image update that comes along will cause it to fall back to the same issue again as the OMV GUI would be used to "update" the image by re-creating the container and the options would likely be pulled fresh again. Specifically, this comment outlines the specific issue being seen.


    As illustrated in the issue, if I manually set this up - no issue. If I create it via the GUI - issue. I'm not sure where in the code this could be getting cut or improperly grabbed, but it seems to be an issue in this case for properly getting the container setup. Happy to provide any logs that could be used to help isolate the issue.


    EDIT:
    Ok some new information. It appears that if I create the container from the Docker Images Repo tab in the docker plugin, it will properly enumerate this field. If I create the container from the main tab by just selecting an image and hitting the Run Image button, it will not enumerate properly. Additionally, if I did create it from the Images Repo tab, but then Modify or re-create the container - it will then again remove the full variable entry.


    So this seems a bit odd and troublesome behavior, that I'm hoping isn't creeping into too many images. At this point for me, it is creeping into causing an issue with my Plex container and being able to get the latest PlexPass version. The workaround for the moment seems to be - to input the ACTUAL version of the latest PP version number so you can get the newer update if the PLEX INSTALL variable gets broken. For me this was necessary as I'm now testing out the new Live/DVR function for OTA broadcast recording.

    • Official Post

    This function is used to parse the image variables



    PHP
    if (isset($imageData->Config->Env)) {
            foreach ($imageData->Config->Env as $eVar) {
                $eVarAry = explode("=", $eVar);
                print_r($eVarAry);
                $this->_envVars[$eVarAry[0]] = $eVarAry[1];
            }
        }

    The splitting character is "=" so is processing this variable


    PLEX_INSTALL=https://plex.tv/downloads/latest/1?channel=8&build=linux-ubuntu-x86_64&distro=ubuntu


    which has three "=" symbols in the content, that's why is not parsed correctly and splitting. The explode function needs a limit for the delimiter char. I'll update it in the testing package

    Coming back around to this. @flvinny521 asked me if I opened an issue. I guess I did!


    Interestingly though, it seems either this isn't working any longer, or there is something broken when using the Modify option in the plugin. I'm seeing that if I attempt to modify the Plex container, it's again stripping this down improperly. Are you able to check if this would happen according to the code @subzero79?

    Thanks @subzero79. I believe I had this error even before I had modified the container, but I may be wrong. I can test again, if necessary.


    Also, if you both don't mind me asking an off-topic question: what is the proper method to update a container if I have an instance running? Stop the container, delete it, pull it again, and re-run?


    I tried just pulling the container again manually without deleting the original, but that ended up giving me duplicates, the older of which I can't delete now.

    • Official Post
    Quote from subzero79

    I've already committed in github, waiting from PR review/approval.

    Approved.

    omv 7.4.14-1 sandworm | 64 bit | 6.11 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.15 | compose 7.2.16 | k8s 7.3.1-1 | cputemp 7.0.2 | mergerfs 7.0.5 | scripts 7.0.9


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    @subzero79 & @ryecoaaron - awesome, thanks for the quick work whipping this into shape - it was a minor issue I think, but nice to have it resolved. Now I don't have to keep checking the variable :D


    @flvinny521 - are you talking about when you need to update the image for the running container, i.e. new update comes down and you want to run the updated version? As subzero hinted, there is a bit of some juggling to clean it all up properly. I've opted for using the Watchtower container to auto-update my images. As an example, I'm currently running the following:

    As you can imagine pulling, restarting, cleaning up, etc - becomes a difficult task with this many containers. The container that has been running the longest, is the watchtower container. It's been configured to every sunday night at like 2AM or something, runs a process to check if there is an updated image, if there is then pull it, and it will automatically update current running images by restarting them with the new image. I then have a scheduled task that runs at say 3AM, set to just run
    docker system prune -f
    This will do a cleanup for you in automatic fashion. So each weekend on Monday morning/Sunday night, i'll get an output (I set the scheduled job to email output) of the cleanup, and I'll often see the updated containers with created dates in a shorter window than when they were originally setup inside OMV to run.


    Just wanted to share my two cents as this has proved to be the easiest to handle in terms of regular upkeep. I've been running my containers solidly for many months on OMV this way.

    Quote from 1activegeek

    @flvinny521 - are you talking about when you need to update the image for the running container, i.e. new update comes down and you want to run the updated version?


    Yes, this is exactly what I mean. I installed Watchtower briefly a few days ago but I couldn't figure out how to make it work. To be fair, though, I only had about 10 minutes to play with it. I'll try again.

    If it helps, here is a shot of my config for the container. This is set to run the cron job as shown in the schedule field. You can adjust this to meet your required timeframe. The other thing to be sure is that you map the docker socket to run the api commands locally. If you have these 2things, you should be all set. If you want to make other changes of course then you may make some other changes or add other variables. But this is the default way to get up and running quickly, and performs the basics.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login