I’m just starting to get to grips with rockons, it’s likely that I’ll be contributing a few when I’m done. The one big issue I see is that there doesn’t seem to be an option for giving a rockon it’s own ip address. I know this is possible with containers, has this been intentionally excluded to avoid complication or is it on the roadmap?
@paulsmyth
Hi - as an amateur - I don’t know what this “docker0” is within the network interface menu, which has a different IP
It’s a network bridge that allows the containers to communicate with the network.
I think exploring a 2nd IP on a hardware interface (such as a 2nd IP on the same NIC) and then using iptables/firewalld to limit communications to that IP on either the rockstor OS or the docker container could do it.
You could also play around with docker networking, this requires some steps outside the rockon and could impact other containers - see the 2nd post here - http://stackoverflow.com/questions/27937185/assign-static-ip-to-docker-container
You’ll see some issues people encountered and discussed here - https://forums.docker.com/t/public-accessible-ip-in-container-like-bridge-network-in-virtualbox/3668/4
Finally, you may want to just look into nginx, haproxy or even a L4-L7 load balancer with rewrites. That’s a very common use case (to hide IPs).
What is the main use case for a separate IP?
A seperate IP address is just simpler to use and track than a port.
You may want to look into some recent additions to the Linux kernel specifically for giving containers IP addresses: IPVLAN and MACVLAN.
Containers have been able to have an independent ip for some time. I assume this isn’t implemented by Rockstor for simplicity. It’s something I’d very much like to see implemented within Rockstor. There’s nothing to stop you manually doing it.
To bring back an older thread, because I am looking to go to rockstor in the next week or two, dockers can support their own ips since 1.10. Is this supported on the rockons?
@paulsmyth, @magicalyak, @lukerussell
Pretty much actually. Initially it seems that it was more complicated than apparently it is now ie:
@Jeffwcollins
I think this ability would be a great addition. The main concern is how we go about it, ie from my rather cursory look at the problem it seems that we must first create a docker network ie:
docker network create --subnet 192.168.128.0./24 --gateway 192.168.128.254 rocknet
And then each rockon is to be started with an additional (if not used already) “–net” but with a “rocknet” parameter along with a new “–ip” switch containing a valid and presumably unique ip within that range.
So by way of an attempt to hash out where we put all of these extra settings lets start with defining the network:
At present we have a recently reworked System - Network page; but do we best place the definition of this docker/rock-on network there as an additional section or should it go with the rock-on config section? My initial thought is that we present the full editable section of this docker/rock-on network config under networks as another section but present a read-only report of this same network (with a link to the System-Network section) within the Rock-on service spanner section.
I’m also keen on not breaking any existing installs, some of which already make use of the --net docker option but without any parameter. So I’m guessing that we establish/handle an ‘undefined’ default which essentially represents our current setup. There after on all future rock-on installs the install wizard would query if one wishes to use the host machines IP or one from the rocknet. Again we have a usability issue to address here, currently one needs to know little to accomplish a successful install of a rock-on, we don’t really want to exclude install to only those with advance network knowledge. Ie do we even offer the option if the custom rocknet has not been configured: but then it could never surface. So maybe we can introduce the possibility with a sane and working default, ie just offer “Use Host IP” in a drop down with maybe a link to all other available IP’s also presented if the rocknet is defined. If it is not defined then we indicate by maybe a link within a tooltip to where it can be defined (the proposed rocknet section of System - Network). That way if one is not familiar with such a facility or can manage without indulging in reserving dhcp ranges on their router prior to setting up their custom rocknet range, they can proceed as is currently the case. That way we can present such preparatory advise when, and if, a user chooses to go the ‘advanced’ route of defining the ‘rocknet’.
We would of course then have to indicate the ip used by each rock-on and modify it’s “Web-UI” button link accordingly. And presumably allow for an edit of this element, unless of couse we go the uninstall, re-install (with fresh choices) route that we currently have (bar the share additions element).
Often the nature of the user interface intergration is a larger issue than supporting a number of additional docker switches and if we first define the general (and considered) opinion on how this might best be done without affecting usability then I think we are ‘on route’.
So short and long of it is, not that easy to extent but well worth it in this case but only if done nicely and in an intuitive / non exclusive manner. So yes I’m definitely in favour of this feature but not as a whole sale move as to require users to first learn about netmasks and dhcp exclusion etc: it’s just too much as a default, and currently we don’t force that level of knowledge. If of course a re-install of a rock-on is required to enable a more full function (where needed) then sure this would be great to accommodate as in that case the need for the more advanced config is then clear and contextual.
This post is an invite to discuss how this feature might be sensibly implemented with my somewhat trivial contribution on a starting point. Please chip in with any ‘hopefully more considered’ suggestions so that we might get a consensus on ‘a good way’ to go about this. The vast majority of Rockstor’s hundreds of files are dedicated to user interface so starting out in the right direction would help enormously with this features development. The fact that something is possible on the command line is really the very beginning of presenting an appliance level of function.
@Jeffwcollins Thanks for waking this thread up: I am in agreement that it would be a great feature, whose time has hopefully come, but only have my initial thoughts, as laid out above, to contribute initially on how it might be integrated.
Lets call this thread a Ready For Comment (RFC) and hopefully we can hash out how and where to put ‘all the things’ so that we can then move onto the issue stage, ie once we have a working hypothesis on how to go about it.
So please contribute any suggestions re my above sketch-out, and I accept that given it is only a few minutes thinking that it may simply be a bad way to go about implementing this docker capability (UI wise). Please also keep in mind that not all users are aware of what a sub net, sub mask, or an IP even is, and if we can cater to such users then we are maintaining our ‘ease of use’ standing.
Hope that helps and lets try and get this desirable feature off the ground, though it may take a while it will only get closer, and be all the better, with this collaboration.
Not just yet 
, but if you take a look at what we have already it might help with suggesting how, in your opinion, it might best be integrated.
Thanks everyone for your suggestions so far. Lets get this one pinned down and then one or more of us can code it. UI mockups / descriptions most welcome. We also encourage the use of the Wiki to more exactly define the ‘user story’ / implementation detail once we get that far. Any article there can be used as an example but lets try and keep the general discussion here and the hard implementation details there as it’s one step away from the code once on the wiki.