Josef Cacek created JCLOUDS-1014:
------------------------------------
Summary: Docker: Add possibility to change loginPort
Key: JCLOUDS-1014
URL: https://issues.apache.org/jira/browse/JCLOUDS-1014
Project: jclouds
Issue Type: Improvement
Components: jclouds-labs
Affects Versions: 1.9.1
Reporter: Josef Cacek
The SSH server in Docker container can run on different port than is the
default one (22). There should be a possibility for users to provide their own
implementation of the {{ContainerToNodeMetadata.getLoginPort()}} method.
{code:title=From IRC discussion}
<jcacek> nacx, Hi, could you please give an advice how to change port on which
SSH in a Node is running. I don't see such an option in the TemplateOptions.
<nacx> hi jcacek let me check
<nacx> jcacek, the login port is given by the NodeMetadata:
https://github.com/jclouds/jclouds/blob/master/compute/src/main/java/org/jclouds/compute/domain/NodeMetadata.java#L99-L102
<nacx> when the compute service creates a node, it should populate the right
login port when returning it
<nacx> translating this to Docker, right now always port 22 is returned
<nacx> this method should be changed:
https://github.com/jclouds/jclouds-labs/blob/master/docker/src/main/java/org/jclouds/docker/compute/functions/ContainerToNodeMetadata.java#L77-L104
<nacx> in order to properly populate the login port given a Container
<nacx> in fact, I see it is already populated:
https://github.com/jclouds/jclouds-labs/blob/master/docker/src/main/java/org/jclouds/docker/compute/functions/ContainerToNodeMetadata.java#L93
<nacx> I assume this is the piece of code that is causing trouble to you:
https://github.com/jclouds/jclouds-labs/blob/master/docker/src/main/java/org/jclouds/docker/compute/functions/ContainerToNodeMetadata.java#L120-L135
<nacx> it just looks for a port 22 in the container to get the port in the host
<jcacek> nacx, thanks for the details. Yes, it seems as a correct place. I need
to have the port configurable.
<nacx> perhaps that "port 22 lookup" should be based on the image, or something
like that
<nacx> which is your use case?
<jcacek> I'm running containers with networkMode=host (i.e. sharing network
stack with the docker host). So I have to use another SSH port in container
(e.g. 8822). And then I have to configure it in JClouds :)
<jcacek> nacx -
https://github.com/kwart/dockerfiles/tree/master/alpine-ext#32-ssh
<jcacek> nacx, docker run -it -e ROOT_PASSWORD=alpine -e SSH_PORT=8822
--net=host -it kwart/alpine-ext:3.2-ssh
<nacx> show does a docker inspect look like for such a container?, is there any
network config?
<nacx> s/show/how/
<jcacek> There is no info about the open ports - there's only "NetworkMode":
"host" attribute in the HostConfig
<jcacek> nacx, So I prefer configuration option in jclouds Docker provider to
override SSH port for a node.
<jcacek> nacx, it's also necessary in standard bridged network mode. Nobody
forces the image creators to start SSH on port 22.
<nacx> that's tricky
<nacx> agree
<nacx> the tricky part is that the loginPort mechanism should also work
<nacx> for nodes that haven't been created by the jclouds compute service
<nacx> that's why the contract in jclouds is that the compute service should be
able to just "list the nodes" and provide the login port for each
<nacx> having a first thought, it could make sense to have pluggable "port
lookup strategies", using the current method as the default one
<nacx> and allow to define "per-image" strategies
<nacx> if users are using images with particular ssh configuration, we could
allow them to provide their custom port lookup funcion
<nacx> (for example that looks t the container's env vars)
<nacx> we can extract this method:
https://github.com/jclouds/jclouds-labs/blob/master/docker/src/main/java/org/jclouds/docker/compute/functions/ContainerToNodeMetadata.java#L120-L135
<jcacek> nacx, Yep, nice idea, it should work then.
<nacx> into its own injectable function (Function<Container, Integer>)
<nacx> so users can propvide a custom guice module
<nacx> that binds that to a custom function
<nacx> in case someone needs specific port discovery
<nacx> that custom function could have specific lookup for the known images and
default to the current one, etc
<nacx> but the idea would be to make that port lookup function injectable
<nacx> the TemplateOptions is not an option here, as this must work even if the
user only does a listContainers to then ssh into one of them 8even if not
deployed with jclouds)
<jcacek> nacx Yes, i see it now.
<jcacek> nacx, I'll file a new Feature Request JIRA and paste also this
discussion into it. OK?
<nacx> ok
<nacx> I'm thinking that perhaps using Guice multibindings
<nacx> there is a clean way to do that
<nacx> so, we could have that default impl
<nacx> and if it does not find a port
<nacx> delegate to a per-image function
<nacx> we can introduce that Map<image id, Function<container, port>
<nacx> in jclouds
<nacx> and let users easily provide their own custom function for each image
<jcacek> nacx, I've never worked with Guice before, so I'm not able to comment
the options now. But I'll try to dive into it.
<nacx> the idea with my multibinding comments
<nacx> is that we could have in jclouds the current function
<nacx> and then a map of images names -> function (which would be empty)
<nacx> guice multibindings allow to add bindings to existing collections
<nacx> users could create the context providing a custom guice module (in the
modules list)
<nacx> a simple module with a single method such as:
<nacx> public void configure() {
<nacx> MapBinder<String, Function> imagefunctions =
MapBinder.newMapBinder(binder(), String.class, Function.class)
<nacx>
<nacx> imagefunctions.addBinding("redis, myRedisLookupFunction);
<nacx> imagefunctions.addBinding("kwart/alpine-ext", myAlpineLookupFunction);
<nacx> }
<nacx> that would add the custom functions for those images to the jclouds
image-to-function map
<nacx> so users have a relatively clean and easy way to provide their custom
lookup functions for each docker image
<nacx> they want to customizer
<nacx> then, any class in jclouds can have injected a: Map<String, Function>
<nacx> and that map will be populated with any key/value configured by the
users using the mapbinder
<nacx> perhaps this is too guice specific, but I think it could be a clean way
to address this issue
<jcacek> nacx, OK, thanks for explaining it.
<nacx> this is pretty straightforward to implement, so if you open a jira issue
I can take it and do it, providing the alpine example
<nacx> or feel free to go for the PR yourself :) I'll be happy to help
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
