jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ignasi Barrera (JIRA)" <j...@apache.org>
Subject [jira] [Assigned] (JCLOUDS-1014) Docker: Add possibility to change loginPort
Date Fri, 09 Oct 2015 14:43:26 GMT

     [ https://issues.apache.org/jira/browse/JCLOUDS-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Ignasi Barrera reassigned JCLOUDS-1014:
---------------------------------------

    Assignee: Ignasi Barrera

> 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
>            Assignee: Ignasi Barrera
>              Labels: docker
>
> 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)

Mime
View raw message