-
Notifications
You must be signed in to change notification settings - Fork 180
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dynamic ENV vars during Container Startup of rstudio-based images (solution) #170
Comments
What about just using edd@rob:~$ echo FOO123RANDOM=bar > .demo.Renviron
edd@rob:~$ docker run --rm -ti -v ${HOME}/.demo.Renviron:/root/.Renviron r-base Rscript -e 'print(Sys.getenv("FOO123RANDOM"))'
[1] "bar"
edd@rob:~$ |
@eddelbuettel Thanks for the comment. In case of r-base or r-ver or something other than RStudio Server that will work. In these cases there will be no problem with dynamic ENV vars set during startup, because normal R and Rscript inherits the ENV-Vars correctly from the bash shell context it gets launched. Side note: If you write some env vars in a user related ( I will update the Title that this specific issue is related to rstudio based images. |
I think you may have misunderstand my point. We at the Rocker Project are acutely aware that RStudio Server 'swallows' environment variables. What I showed was NOT an export of a shell variable but rather provided (from the outside) a file which will be by R on startup due to the way R behaves (so that Rstudio cannot block it, |
Okay, well... I think we are coming from two perspectives onto that point. If one is using the rocker images (which are great work, no doubt) manually for local development in a container, your approach is working just fine. This is a usecase lot of users have. The other perspective on that is, if you are using an orchestrator or even want to set env-vars on container startup it should be more easy to achive that task. For example: If you are using a CI-Pipeline with three tears (dev, test and prod) you will load different configuration upon a specific value of an env var set in the pipeline. It would be convenient to provide a solution for that usecase in addition. My goal was to bring the discussion for a solution of the second usecase to the public and preventing many members of the community to solve the same issue multiple times. I should have made that more clearly in the first place. ✌ What do you think of the solution for |
"It's complicated" with the env vars. I understand where you are coming from, I am just wary of unintended consequence when altering startup sequences or general configuration. I think that is best done locally so I would lean towards wiki writeups or vignettes rather than PRs. But it is Carl's and Noam's call, really. By the way I have absolutely no issues with CI which I based for several 'heavier to build' projects off containers from the Rocker r-base corner. |
I found a really cool solution for the dynamic env vars. We can use the S6 cont-environment dir to write variables and their values to
this is a really less invasive solution. I do have some checks for the TZ and LANG configuration, but it all works in general. PR is coming soon. |
@Pit-Storm yes, I think using S6-init is reasonable here. Of course it will only run when the default (Not directly related, but we also need to adjust the current scripts that are writing env vars to PR welcome! |
resolved in #186 |
Hi folks!
As we discussed in #151, there are problems with updating timezone and locale settings dynamically through container runtime env vars. For that I am preparing a fix in my fork.
It contains two parts:
TZ
orLANG
differ from the default.The first point is done by providing two conditions in the userconf.sh those check if
$LANG
or$TZ
differ from default. If so, the commands to update those settings on the container OS are executed.So You are able to do e.g.
docker run --rm -e PASSWORD=mypass -e TZ=Europe/Berlin -e LANG=de_DE.utf8 -p 8787:8787 --name rstudio rocker/rstudio
and after that in the RStudio frontendSys.timezone()
andsessioninfo()
will return the values set through the-e
options.This can be seen as a leap forward to automatically provide localization configuration to the users.
The second part is done through a dynamically generated update for the
Renviron.site
file on startup. The reason why we have to set env vars inRenviron.site
is, because RStudio Server int he community edition does not pick up any env var from the bash context it starts from. This is not well documented in official docs but they giving hints with the PRO label. There are many issues and discussions not being resolved on this. E.g. on Stack Overflow or the RStudio community. The latter one pointed me to the solution I am providing here. This issue takes effect if you want to deploy an rstudio based image with an orchestrator or you want to dynamically pass env vars to rstudio during container startup by using the native-e
Option.It works as follows:
ENV MY_VAR default_value
andRUN echo "MY_VAR=$MY_VAR" >> /etc/environment
. (The Value set in the Dockerfile can be seen as a default value, because on startup theuserconf.sh
overwrites the value with the one you defined during startup.)userconf.sh
will pick up the new line in/etc/environment
and adds it toRenviron.site
so that RStudio will add the env var to the environment of the rsession.A solution where one do not has to create an downstream dockerfile would be better, but as far as I investigated, this is not possible at the moment.
Maybe someone can help with the second part. It should look like that:
/etc/environment
An other way could be to pick up all that is stored in
/var/run/s6/container_environment
and writeFILENAME=content
to$R_HOME/etc/Renviron.site
during startup.If something should be not clear or you have suggestions, don't hasitate to let me know.
If all this is done, I will send a Pull Request :-)
Kind regards!
The text was updated successfully, but these errors were encountered: