Inconvenient directory structure for Docker use

[MrGreaterThan]

Currently there are 11 folders in the same directory as the executable. This is nice for simplicity but it makes using the server as a docker container more difficult. Typically I would expose a volume for saved data and usually also configuration files so they are accessible on the host and persist even when the container is destroyed and recreated. This prevents you from losing your data when the image changes after an update.

If I persist the entire rimworld-together folder then the executable will also persist and will not update when the image is updated to a new version. Because of this I have to persist each folder separately. I would like to see the folders organized into categories based on function. One for data which will always need to be persisted. One for configs which would need to persist if the admin wants to change them and doesn't want to build his own container. And one for logs which could optionally be persisted.

Here's an illustration for reference.

#---------Current Structure---------#
/opt/rimworld-together
│
├── Backups
├── Caravans
├── Core
├── Events
├── Factions
├── Logs
├── Maps
├── Saves
├── Settlements
├── Sites
├── Users
└── GameServer.exe

#---------Proposed Structure---------#
/opt/rimworld-together
│
├── GameServer.exe
├── Logs
│
├── data
│   ├── Backups
│   ├── Caravans
│   ├── Factions
│   ├── Maps
│   ├── Saves
│   ├── Settlements
│   └── Sites
│
└── configs
    ├── Core
    ├── Events
    └── Users

Cheers!

Proposed task list:

• [ ] Edit Main.cs Line 44 to change file paths e.g. "Saves" > "Data/Saves"
• [ ] Update Dockerfile to use new paths
• [ ] Add migration for old directory structure so existing users won't be disrupted

[salco]

For what I can look you will need to change: https://github.com/Byte-Nova/Rimworld-Together/blob/development/Source/Server/Core/Main.cs#L63 .

But your statement is not really correct:

Currently there are 11 folders in the same directory as the executable. The folders are created where you call the executable.

Check the PR #195 if it solve your main issue related to volumes and docker

[MrGreaterThan]

I did see that PR but I didn't see where it addressed my concerns about the directory structure. Cirune also seemed to confirm that it doesn't change the paths when I asked about it.

I could be misunderstanding. Does changing the workdir in the dockerfile change where the save data and config folders are created?

[salco]

Like Cirune said it already in separated folder. The binary is in /App/Server and all the generated folders will be in the workdir /Data

Look at the current Dockerfile, the binary is called from /Data and so it will generate all the folders (map, config, etc.) under the volume called Data.

[MrGreaterThan]

Thanks for explaining. I wasn't sure how the executable was choosing the directory and didn't realize it was as easy as changing the working directory but it makes sense in retrospect.

I believe it would be enough to change the paths here: Main.cs Line 44

e.g. "Saves" > "Data/Saves" I may try my hand at doing so in a pull request.

I am satisfied and this issue can be closed unless you'd rather keep it open. Thanks!

[salco]

I agree if for this part the objective is only to refactor the file structure. That way if we assume the "current" container setup it will generate Data/Saves under the volume Data so the Complete path inside will be: /Data/Data/Saves. It could be better to rethink the name of the sub-folder maybe or the volumes, just to avoid confusion.

Plus on that aspect I will leave the owner veto about the folder about changing the file structure 👼.

[MrGreaterThan]

You're right, the /Data/Data/Saves issue would also require containers to be updated but that was the plan anyway. i.e. to have three folders (Logs, Data, Configs) that could be exposed if needed. I wasn't using the Dockerfile from this repo but if a PR changes those paths then it should make sure to update the Dockerfile as well.