OMV Docker GUI vs Docker Compose

  • Is there any guidance on using Docker compose with or instead of the the OMV Docker GUI.


    I seem to run into many issues with the GUI and end up constantly losing container configuration when something fails or goes wrong.
    I don't know much of anything about Docker compose yet, but its something I'd like to learn. Is it compatible with the OMV docker gui? (e.g if I make docker compose files would they show up in the GUI?)


    Is there any instructions or guidance on how to interact with the builtin OMV docker plugin via CLI?



    Thank You!

    • Offizieller Beitrag

    Docker on the command line is usually about setting up one container. Docker compose, on the other hand, can setup multiple containers. It's used to create 2 or 3 containers that support a single function. (A downloader front end container, with a storage backend container, etc.)


    If you pull a Docker image and set up a container, on the command line, it will show up in the GUI.
    For more info, and a CLI Docker tutorial look -> here.



    I've never lost the configuration of a Docker in the GUI. However, a single edit of a running container, restarts the container as if it is brand new and being run for the first time. (There's a clear warning dialog box, regarding this, in the GUI.)

  • as reply on other thread; you have problems because UnionFS, use a persistent PATH that point to a single disk and your problems are gone.

  • Thank you for the explanation that helps a bit. I'll look more into the CLI, but its the same as setting things through the GUI then I'm still a bit worried about losing my container configurations.


    I understand that when containers restart its being completely recreated. Thats not what I mean. Usually if I edit an existing container and make a mistake (e.g. incorrect syntax for Extra arguments or commands. Or accidentally adding / having reference to a volume mapping for a container that no longer exists) then some sort of catastrophic error occurs.


    Afterwards if I ever try to edit that container configuration again I receive the following error. Or I've also had the container switch to a read-only mode which I couldn't recover.



    Any ideas on these types of situations? That's what I'm most concerned about and would love to have some kind of record/backup of my container configurations.


    as reply on other thread; you have problems because UnionFS, use a persistent PATH that point to a single disk and your problems are gone.


    I'm not sure what you mean? I don't believe I'm using UnionFS anywhere.

    • Offizieller Beitrag

    Any ideas on these types of situations?

    Not sure exactly what's happening, but note that the Docker GUI plugin is a convenience tool. If you do something in the GUI that's not allowed by Docker, on the command line, you'll get an error. Further, if a volume or mount point is malformed, you'll get another type of error. In both instances, the container won't start.


    For example, consider a mount point:


    Host path _______________________ Container Path
    /dockerparms/pihole______________/etc/pihole


    If there's a space in front of the slash ("/") in /dockerparms/pihole or /etc/pihole, you'll have an illegal mount point. You'll get an error every time and the container won't start. This particular error is easy to do and not notice.
    ___________________________________________


    On the other hand, I do know that if you don't hit the modify button, in the Docker GUI, a running container will continue to work fine.


    Afterwards if I ever try to edit that container configuration again I receive the following error. Or I've also had the container switch to a read-only mode which I couldn't recover.

    I've never had a container switch to read only mode (mount points), to where I couldn't change it. I have made mistakes in containers where, after digging out the error, it worked fine. What platform are you running? Is it an SBC?


    I'm still a bit worried about losing my container configurations.

    There's no easy way to backup individual Docker containers. A container is a composite of folders and files, that works in a manner similar to OverlayFS and the UnionFS plugin. It's merged together in such a way to where the containers look like the root filesystem of a Linux machine, but it you run it down, you'd see that the various folders are scattered.
    ((If you want to take a look at this, look under /var/lib/docker. Look around a bit - you'll get an idea.))


    In the bottom line, when a container is up and running (which can take some doing), I see that container as part of my baseline system - an integrated part of my boot drive. This is one of the reasons why I use USB thumbdrives as boot drives - so that I can clone them easily. Once all is working as it should, clone the boot drive.
    If you're interesting in that process, look in this -> Guide under OS backup. Note that you'd need to install the flashmemory plugin to use thumbdrives as a boot drive. That's another topic in the guide.


  • Your example of the invalid mount point error is exactly what I’m talking about and experiencing. Is there a way to recover from that type of simple mistake? I’m assuming it has to be done from the CLI? So many times I’ve just deleted the container and made a new one, re-imputing all the settings / env variables.


    I’ve been using a raspberry pi 2.


    The read-only error did not occur with mount points, instead that one came from invalid extra arguments. Accidentally separating arguments by comma instead of spaces (e.g. —arg1=abc,—arg2=efg).


    If there is a way for me to salvage the containers from these situations that would be awesome.


    Thanks for making and linking that guide! Definitely something I’ll ready through.

    • Offizieller Beitrag

    Is there a way to recover from that type of simple mistake? I’m assuming it has to be done from the CLI? So many times I’ve just deleted the container and made a new one, re-imputing all the settings / env variables.

    In cases where I've "fat fingered" a container, I looked for and found the error using the GUI modify button. After fixing the error, it was good to go.
    Doing operations on the CLI are no different from working in the GUI - it's the same thing. The GUI simply constructs the container creation command, that's executed on the CLI. Attention to detail is required, just as it would be on the CLI. All it takes is one mistake.


    I’ve been using a raspberry pi 2.

    An R-PI... :) I suspected as much.
    As odd as it may sound, your SD-card may be the problem. (This comes to mind when you mention "read only" settings that can't be changed.) SD-cards can be a real PITA which makes starting with good cards and backing them up (cloning them) important. If you only have the one card, the cloning process in the guide shows you how to read and create a *.img file of your working card. You really should test it for errors.


    And realize this - your card might test error free and still have issues. It happens. The best thing to do is buy a new pair of SD-cards, get good ones like Sandisk (no generics), and rebuild.
    The last thing R-PI's are notorious for is under voltage with their USB power supplies. All sorts of odd things happen with a cheap PS, with a long cord, which results in voltage drop.


    (Maybe consider getting an X64 platform where these issues simply disappear? :) Almost any X86 box would be more reliable and out perform an R-PI.)

  • In cases where I've "fat fingered" a container, I looked for and found the error using the GUI modify button. After fixing the error, it was good to go.
    Doing operations on the CLI are no different from working in the GUI - it's the same thing. The GUI simply constructs the container creation command, that's executed on the CLI. Attention to detail is required, just as it would be on the CLI. All it takes is one mistake.

    When I hit the modify button in the GUI after I make a mistake with the container I receive the error I showed above. It does not allow me to ever actually edit the container.


    An R-PI... I suspected as much.
    As odd as it may sound, your SD-card may be the problem. (This comes to mind when you mention "read only" settings that can't be changed.) SD-cards can be a real PITA which makes starting with good cards and backing them up (cloning them) important. If you only have the one card, the cloning process in the guide shows you how to read and create a *.img file of your working card. You really should test it for errors.


    And realize this - your card might test error free and still have issues. It happens. The best thing to do is buy a new pair of SD-cards, get good ones like Sandisk (no generics), and rebuild.
    The last thing R-PI's are notorious for is under voltage with their USB power supplies. All sorts of odd things happen with a cheap PS, with a long cord, which results in voltage drop.


    (Maybe consider getting an X64 platform where these issues simply disappear? Almost any X86 box would be more reliable and out perform an R-PI.)

    I have heard this before about the SD cards. It does seem very odd to me though that I would cause such isolated and specific issues like this. I have a good quality samsung sd card, but still yes, my plan is to eventually build an actual quality server. I would like to get a solid grasp on everything though using the RPI, surprisingly so far its been perfectly fine except for the lack of transcoding power and backup limitations.

    • Offizieller Beitrag

    How old is the card and was it new when you built it?
    If the same error repeats, exactly in the same way, that's pretty specific. In any case like this, really, the only sure way to be sure that the issue is corrected is to rebuild.


    You could read the contents of the SD-card, to a *.img file, per the Guide (in the OS backup section). After that's complete, if the image file fails to pass verification, that's a strong indicator (in itself) that there's something wrong with the card. If verification completes successfully, you'd have the ability to recreate the boot drive (SD-card) exactly as it was.
    At that point, fully testing the card with H2testw (page 25 in the current guide version) would be a low risk proposition.
    __________________________


    Edit:


    BTW, I started off with OMV, on an R-PI 2, so some of the above comes from direct experience. The R-PI worked fine but SD-card issues wore me out over time, even when using good cards.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!