Open rattai opened 4 years ago
Hi @rattai ,
The use-case you describe, though potentially feasible, may have some significant impediments and side-effects. The user's home directory, mounted in the container, could potentially make changes that the host would not be happy about. Think for example if you run Ubuntu 18.04 on your host and Alpine
in the container: would you trust that Alpine
's changes to the home directory would be compatible with Ubuntu's?
Maybe if the user in question is not actually used from the host, this could be workable.
That being said, I do not think there is anything preventing us from storing the Theia application elsewhere than /home/theia
. Maybe we could use /theia-app/
instead, for example.
Would you care to propose a PR to do this?
P.S. some related reading: https://jtreminio.com/blog/running-docker-containers-as-current-host-user/
Thanks, @marcdumais-work I'll think about a PR. Not sure when I'll have time to work on it though.
I'm not talking about sharing users or directories with the host machine. I really just want a persistent container home dir that I can keep using each time I upgrade my theia-app docker image. I don't need it to be accessible anywhere but from inside the theia-app container.
Can you clarify what happens when you upgrade your Theia image that conflicts with this?
@echuber2 I want both: (1) A persistent home dir and (2) A home dir I can use across upgrades.
Unless I'm missing some trick, I can only have one of those, not both. I've tried to achieve (1) by creating a persistent docker volume as my container's home dir. The contents of the image's home dir are copied to the volume when it is created. However, if I use the same volume with a newer image, it will still contain the theia-app from the old image.
I'm not talking about sharing users or directories with the host machine.
Understood, thanks for the clarification @rattai . I think we'ill enable your use-case if we move the Theia app and its default vscode extensions to an alternate folder. No worries if you do not have time to submit a PR- we'll get to it eventually. We're planning an update of most images soon, to go with multi-stage build, and might include a fix for this too.
cc: @vince-fugnitto
Maybe we also move our workspace folder from /home/project
to somewhere in the file-system root, like /workspace
? It's probably not good form to use /home
for anything other than user accounts.
@marcdumais I don't personally understand the need for a separate workspace folder like /home/project
or /workspace
. If /home/theia
works the way we've discussed, I would probably place my workspace in a sub-folder like /home/theia/ws
. Maybe separate mounting locations are useful for the way other people work? I guess it doesn't hurt to provide it.
@marcdumais I don't personally understand the need for a separate workspace folder like
/home/project
or/workspace
. If/home/theia
works the way we've discussed, I would probably place my workspace in a sub-folder like/home/theia/ws
. Maybe separate mounting locations are useful for the way other people work? I guess it doesn't hurt to provide it.
Yes, that can work too but will require you to explicitly navigate and open that folder as your workspace, at least the first time. The main advantage to having a default workspace is that you can have it opened by default at first launch, when specified launching the Theia app:
https://github.com/theia-ide/theia-apps/blob/master/theia-docker/Dockerfile#L36
For what it's worth, Theia doesn't seem to work like any other Docker image I run. I run a homelab that is mostly focused around my smart home setup (Home Assistant, Mosquitto, and associated subsystems) and entertainment ecosystem (Plex and associated subsystems). I was hoping to use Theia like I previously had used Cloud9 (before it became too defunct to continue using) as a means of editing .yaml files, various config files and having a terminal to send commands to Docker to restart containers and the like. Being the sole user logging into my system, I keep all of my images and associated files in /Dockerconfigs/ and I had expected to be able to setup /Dockerconfigs/Theia_IDE/ as the location for storing Theia's configuration files and anything else it needs external to its image and then set the /Dockerconfigs directory as the "home" or working directory. But try as I might, it doesn't seem to like this idea and I can't seem to get it working where I can see the directories in /Dockerconfigs/ muchless edit the files therein. And the established documentation of how to get started with Docker doesn't even seem to support a docker-compose.yml file, much less a typical here-are-the-volumes-I-want-mapped-and-how-they-should-appear-inside-the-container.
I think these docker images are great and I've been using them a lot, but I really want to attach the user's $HOME dir (/home/theia) to a persistent external volume. The usage guide suggests doing this for /home/project and that's great, but many things are written to $HOME by default (like git config or npm caching). These are lost when the container restarts.
I have tried using a docker volume for /home/theia. It will copy /home/theia from the image into the volume when the volume is first instantiated. However, that means I can't reuse this volume across docker image upgrades because the theia app is inside /home/theia. I think it would make sense to move the theia app out of /home/theia and have an image that starts with basically an empty $HOME dir (or one similar to what you'd have on new system).