Flox
March 18, 2019, 4:55pm
5
Yes, although time has been very difficult to find for the past few weeks, I’ve been working on implementing docker networking for a little while now. I have the main mechanisms working, but still need to finish some important UI refinements (see the Github root issue and its links therein if you’re interested–your feedback would be more than appreciated).
That seems to be a nice simplified solution if that can be used for your rock-on. I’m wondering about potential conflict(s) with other rock-ons running their own dns server like pi-hole, however, but maybe a clear warning to the user may help (if there is such a risk).
Thanks for the feedback… I currently have most options for docker networks supported, so that may help this case. You can see more details of what I currently support in the corresponding issue below:
opened 10:18PM - 18 Jan 19 UTC
closed 01:11PM - 22 Dec 20 UTC
This is an issue dedicated to step 3 of the Docker networks (re)work (#1982), co… rresponding to the implementation of an interface for the creation of a docker network.
As discussed in #1982, this would be better integrated in the existing "_System > Network_" part of Rockstor's UI. My current idea would thus be to simply add a new option in the "_Add Connection_" section to create a docker network, as seen below:
In order to follow the same level of customization than what is offered for system connections, we can keep the same configuration method set as "Auto" by default, with the possibility of selecting "Manual" parameters. In the latter case, docker specific fields will appear, corresponding to the options offered by the `docker network create` command.
As per the [docker documentation](https://docs.docker.com/engine/reference/commandline/network_create), these are as follows:
```
--attachable Enable manual container attachment
--aux-address Auxiliary IPv4 or IPv6 addresses used by Network driver
--config-from The network from which copying the configuration
--config-only Create a configuration only network
--driver Driver to manage the Network
--gateway IPv4 or IPv6 Gateway for the master subnet
--ingress Create swarm routing-mesh network
--internal Restrict external access to the network
--ip-range Allocate container ip from a sub-range
--ipam-driver IP Address Management Driver
--ipam-opt Set IPAM driver specific options
--ipv6 Enable IPv6 networking
--label Set metadata on a network
--scope Control the network’s scope
--subnet Subnet in CIDR format that represents a network segment
--opt Set driver specific options:
com.docker.network.bridge.name bridge name to be used when creating the Linux bridge
com.docker.network.bridge.enable_ip_masquerade Enable IP masquerading
com.docker.network.bridge.enable_icc Enable or Disable Inter Container Connectivity
com.docker.network.bridge.host_binding_ipv4 Default IP when binding container ports
com.docker.network.driver.mtu Set the containers network MTU
```
In our case, we would need to support only the `bridge` driver (to begin with, at least), which leaves us with the following parameters:
```
--aux-address Auxiliary IPv4 or IPv6 addresses used by Network driver
--gateway IPv4 or IPv6 Gateway for the master subnet
--internal Restrict external access to the network
--ip-range Allocate container ip from a sub-range
--ipv6 Enable IPv6 networking
--subnet Subnet in CIDR format that represents a network segment
--opt , -o Set driver specific options, as follows:
com.docker.network.bridge.enable_ip_masquerade Enable IP masquerading
com.docker.network.bridge.enable_icc Enable or Disable Inter Container Connectivity
com.docker.network.bridge.host_binding_ipv4 Default IP when binding container ports
com.docker.network.driver.mtu Set the containers network MTU
```
As was also discussed in #1982, we can also allow the users to select one or more existing containers to add to the network at this step, although this may be the subject of a separate issue + PR.
@Luke-Nukem and @phillxnet, as you both participated in this prior discussion, thanks for your feedback on any of the parameters above. I don't think enabling anything IPv6-related would be useful, for instance, as I believe Rockstor's UI does not support it yet, for instance.
As mentioned above, I'm currently working on this issue and should be done hopefully quite soon. There are some elements in this work and the one described in #2003 that depend on a pending PR (#1999), however, so I'll continue working on these and refining them until then.
@nasrocket , if you want to give @HBDK ’s rock-ons files a try, you can do so using the instructions by @phillxnet linked below:
This wiki entry is intended as a overview of the process required to test a proposed Rock-on; ie one that currently exists within a GitHub Pull request. Please edit with care as you see fit as this wiki guide, like the rest of Rockstor, is a community focused effort. Comments should be constrained to content suggestions only. Thanks.
Rockstor’s Rock-on registry / repositor is almost entirely contributor populated and by way of due diligence each submission (pull request in GitHub speak) require…
Let us know how it goes if you decide to give it a try!
Thanks!
1 Like