Closed moogle19 closed 8 years ago
@moogle19 Thanks! I've opened an internal bug on this here.
The root cause of your specific problem is that when we map firewall rules to the docker port list, we aren't ensuring that we're displaying only int
s for ports, which is what's required by the docker Port type.
Unfortunately, this also means that there aren't any extremely pleasing solutions to the problem of what to do for all
. A list of 65k published ports (what docker does for port ranges) would likely be problematic for everyone (at least if you don't expect it). An int outside the normal port range (like '-1') that had special semantics in SDC would work on the SDC end, but making sure it didn't break anything in the docker client would be quite difficult (not to mention creating a portability problem).
So the best idea we have at the moment is probably not to translate firewall rules that don't have good representations in the docker container format. You would still be able to apply them via the SDC UI or APIs, but they wouldn't be reported by the docker client. Would that work for your usecase?
thanks, matt.
I don't know about the OP, but that would work for me. At the moment any client listing containers dies because it can't parse "all" as an int, so it'd be better for that to work at the expense of not neccesarily knowing which ports were open.
This is fixed in 3e42224 which is in this week's release.
If you create a docker container and add a Firewall rule that allows traffic from "any" to the docker vm on "tcp PORT all" the docker container is reachable from the outside, but the docker ps command fails with
Firewall rule:
That is because the values in the ports array for PrivatePort and PublicPort are
"any"
, but the docker client expects an integer.curl output for
/containers/json?all=1