Docker GUI plugin now stable

    • Offizieller Beitrag

    @subzero79 I noticed that the changelog looked "strange". Did you use omv-dch to increment it or the "standard" dch program? The omv-dch script wraps the dch program and adds some standard text to the changelog.
    The wrapper can be found here: https://github.com/OpenMediaVa…b/master/usr/sbin/omv-dch


    Yes, at the beginning i added a changelog, then i realized that I shouldn't do it, since is the maintainer or builder job to add it to the debian folder

    I can't make macvlan work on my VirtualBox dev environment (in Ubuntu). Anyone have this working?


    EDIT: The network interface gets created ok withing the container. However I can't access the outside.


    I'm using the PCnet Fast III adapter in promiscuous mode and have tested both bridged and NAT mode... Running out of ideas :(

    I am having trouble also with this, my testing is in proxmox. The vm i develop resides in a separate vlan, but there is intervlan routing in my lan, pretty sure this was working, no idea why it stopped now. As for now i am only getting inter container communication only, i cannot ping router, or any other lan resources even on the same vlan

  • ok... I will try to fire up a new system inside Hyper-v and see if that works. I have macvlan working fine on my "production" server though.


    EDIT: Hyper-V works after enabling "MAC spoofing" on the network interface.

  • Nonetheless, one of the main features that have to be working so the "network" can be called OK, in my opinion, is that each container can reach other container via it's name, not raw IP.

    I don't understand this part. Could you elaborate on how this could be accomplished? Myself I run almost all my containers in macvlan mode and give them names via my DNS server.

  • I don't understand this part. Could you elaborate on how this could be accomplished? Myself I run almost all my containers in macvlan mode and give them names via my DNS server.


    I don't have a DNS server and today am forced to use "--link" so they can reference each other without using IP, because it can change every Docker restart.


    Of what I've read of Docker networks, any non-default bridge network creates a internal DNS server for those containers, making transparent this job of managing names.


    So, I don't know if macvlan are required or just other network creations, but my goal is to reference containers by name without creating a whole DNS server outside just for that.

  • I don't understand this part. Could you elaborate on how this could be accomplished? Myself I run almost all my containers in macvlan mode and give them names via my DNS server.


    I don't have a DNS server and today am forced to use "--link" so they can reference each other without using IP, because it can change every Docker restart.


    Of what I've read of Docker networks, any non-default bridge network creates a internal DNS server for those containers, making transparent this job of managing names.


    So, I don't know if macvlan are required or just other network creations, but my goal is to reference containers by name without creating a whole DNS server outside just for that.

  • I don't have a DNS server and today am forced to use "--link" so they can reference each other without using IP, because it can change every Docker restart.


    Of what I've read of Docker networks, any non-default bridge network creates a internal DNS server for those containers, making transparent this job of managing names.


    So, I don't know if macvlan are required or just other network creations, but my goal is to reference containers by name without creating a whole DNS server outside just for that.


    Sent from my ASUS_Z017DA using Tapatalk

  • i was not aware of that feature to reference by name within the same network. According to the docs it should probably work if you specify a new bridged network too. Could you try this out and report back?


    Not very soon. It may take a while. Busy.


    Sent from my ASUS_Z017DA using Tapatalk

  • Adding in to what @anderbytes mentioned - this is true. This backend communication mechanism is used to ease communication between containers. It's a non-external accessible network. So as to say an external system isn't able to reach the containers by their names, but inter-container communication is easily facilitated this way. This is intended to simplify the task of networking/linking containers that rely on each other (such as a DB with an App, etc).


    @SubZero - you are correct, host-container communication is not allowed. This is what I was meaning to illustrate in my earlier post. I'm not sure of a testing version which allowed communication, but then again I don't think i tested it when it was in testing! ^^


    Glad to hear though that you got it working. By the looks of what you included for code, I believe that may have been your missing piece. You did need to give it a parent interface to get outbound communication. It is a tricky configuration overall to get ironed out properly. But when you get it right, it does provide a valuable functionality. For some time I actually used this to stop my smartphone system (OpenHAB) and Plex from contending with each other on ports trying to be established. I know generically you would think assigning ports via mappings would help, but not when they're not flexible and contend with UPnP requirements.


    Long story short - it has its uses at times. So thanks for getting this etched out. It should provide valuable use for anyone deciding to leverage it.

    • Offizieller Beitrag

    It was never in the code by the way. My work only involve containers using macvlan networks, I had problems using creating the network using cli with a typo.


    You can find in google some blog post about using macvlan network dated mid2016. I don't think is working any longer since they blocked at docker level.


    @nicjo814 the tab looks ok to me. I am thinking of adding a "docker network connect" and disconnect button on the toolbar. i need to do more testing, to see if those are persistent changes.

    • Offizieller Beitrag

    Nonetheless, one of the main features that have to be working so the "network" can be called OK, in my opinion, is that each container can reach other container via it's name, not raw IP.

    I think you mean hostname, you're correct they can reach via hostnames in the same non-bridged network without this hostname registered by dhcp or statically mapped, but not by their names which is a property outside of the container.


    The domain string is the network name


    / # nslookup 7de8ca989fa2
    nslookup: can't resolve '(null)': Name does not resolve


    Name:7de8ca989fa2
    Address 1: 172.19.0.2 7de8ca989fa2.text123
    / #

  • I have a small feature request...
    When creating a container it would be useful and a good way of getting insight/learning how docker container commandlines are built if there was a button to "View command line" that would show how the command is about to be built/run based on the setup the user has just built using the interface.

  • I have a small feature request...
    When creating a container it would be useful and a good way of getting insight/learning how docker container commandlines are built if there was a button to "View command line" that would show how the command is about to be built/run based on the setup the user has just built using the interface.


    Indeed


    Sent from my ASUS_Z017DA using Tapatalk

  • @subzero79 I've merged my code now to github (the networks tab). How about we release the new version to bintray when you feel comfortable with your changes to the tab (including connect/disconnect to network). I think there are quite a lot of nice features introduced by you that people would welcome.

Jetzt mitmachen!

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