Dockerizing OpenMole, question about workspace path using launch command

(Sebastien Rey C) #1

Hi guys,

I propose here a new multi-stage Dockerfile which separate compilation and binary for a smaller image.

docker build . -t openmole:latest
docker run --name openmole -p 8443:8443 -e UID=1000 -e GID=1000 openmole:latest

As you can see, volume are not present (-v mydata/openmole:/home/mole/, and this is the next step. I want to support the OpenMole workspace as a volume, directly readable/writeable from the user files explorer. But there is a well know problem with permission on Volume when the user created in the container and the user who run the container on the host are different.

I solve the problem of uid/gid mapping of volume using the small su-exec; similar to gosu. This solution is common in many project to resolve the shareable volume between user in & out of the container, as you can see for example in radicale, postgres alpine project, etc.

But i have a problem with the location of my data in the container, in this configuration OpenMole write to /root/.openmole by default, and not into /home/mole as i want.

Is there possibility to force the path of the workspace during launch command ?

#2

Yes there is an argument:

± openmole -h
OpenMOLE application options:
[-p | --plugin list of arg] plugins list of jar or category containing jars to be loaded
[-c | --console] console mode
[--port port] specify the port for the GUI or REST API
[--script path] a path of an OpenMOLE script to execute
[--password password] openmole password
[--password-file file containing a password] read the OpenMOLE password (--password option) in a file
[--workspace directory] run openmole with an alternative workspace location
[--rest] run the REST server
[--remote] enable remote connection to the web interface
[--http] force http connection instead of https in remote mode for the web interface
[--no-browser] don't automatically launch the browser in GUI mode
[--extra-header path] specify a file containing a piece of html code to be inserted in the GUI html header file
[--load-workspace-plugins] load the plugins of the OpenMOLE workspace (these plugins are always loaded in GUI mode)
[--console-work-directory] specify the workDirectory variable in console mode (it is set to the current directory by default)
[--reset] reset all preferences and authentications
[--reset-password] reset all preferences and ask for the a password
[--mem memory] allocate more memory to the JVM (not supported on windows yes), for instance --mem 2G
[--logger-level level] set the level of logging (OFF, SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST, ALL)
[--proxy hostname] set the proxy to use to install containers or R packages, in the form http://myproxy.org:3128
[--] end of options the remaining arguments are provided to the console in the args array
[-h | --help] print help
(Sebastien Rey C) #3

Thanks romain, it works now.

Another question, do you think it could be possible to give directly a let’s encrypt password to openmole, for example by using containers like jwilder propose ? I already use the nginx proxy + let’s encrypt container of jwilder and they works very well !

#4

Do you mean passing a lets encrypt certificate ?

(Sebastien Rey C) #5

Yes, passing certificate using command argument for example, it could be great.

#6

It should be fairly easy. I’ll look into it this weekend…

#7

After thinking about that I think a good solution would be to run apache or ngnix in the same container and make it proxy the requests to openmole (using the http mode with no encryption). There for we could have a proper support for http to https redirection and https certificates and we can configure a webdav server in the container for the user to access his/her files.

The scenario would be the following. We launch the container. The user goes to openmoleinstance.server.domain:port. He/she is redirected to an https session in https://openmoleinstance.server.domain:port/openmole which is a proxy to the local openmole instance. He/she is asked for a password an openmole writes the password in a format that could be used by the webdav server configured in apache/nginix. The he/she could go to openmoleinstance.server.domain:port/workspace using webdav to manage his/her files.

We might use the mod_dav module of apache https://httpd.apache.org/docs/current/fr/mod/mod_dav.html or the equivalent for ngnix. What do you think about that?

(Sebastien Rey C) #8

Yes that’s cool, so if i understand well, we have something like that in docker-compose :

  • nginx-proxy listening 80/443 configurated with the …
  • … let’s encrypt associated container
  • openmole container with nginx intern web server exposing 80
#9

This is the global scheme. Except that the ports exposed ouside would be chosen on launch. Ngnix/apache can proxy to openmole using an internal docker network so the openmole port doesn’t have to be exposed on the outside.

And a then I would configure a webdav server using the same password as openmole to enable a remote workspace access.