Hello @rsoika
Local.json file is generated when container is started. So there’s no way to map it on the host.
In general, mapping these config files to the host is not a good idea. Sometimes we change these configs due to update process. This way you can break your installation with your old customized config files due to the update process.
Thanks for your feedback. Yes I think that setting environment variables is the best way. I was not aware of the helpcenter page.
For example I already set the variable WOPI_ENABLED=true.
This variable is mapped to
"wopi": {
"enable": true
}
which is surprising as you would guess that this JSON setting maps to a variable like WOPI_ENABLE.
For example: what if I want to set wopi: {host:....}? I already tried setting WOPI_HOST but this did not work - now I understand that this seems not to be a supported configuration parameter.
Why do you not use a kind of parser, checking all environment variables and if it matches a JSON structure from the default.json than overtake this into the local.json. This would be super cool as this gives me more control about the configuration details running OnlyOffice in docker-compose or Kubernetes?
Hi @Alexandre - no problem if this feature is not implemented.
But to come back to my initial question: This means the only way to configure OnlyOffice running in a Docker Container is to overwrite the default.json file and map it via a local volume. You did not recommand it in your first answer, but there is no other way - right?
Yes, we do not recommend it. You have to keep in mind that config file can be changed due to update process.
So, for container deploying you can use environment variables.
But there’s a workaround solution for parameters which cannot be set via environment.
As we know default.json file can be overwritten during an update and the changes will be lost. If you wish to avoid that, you can create a file named local-production-linux.json in the same folder and paste the required parameters from default.json there. It will have priority over any other configuration files. Note that the structure of default.json needs to be strictly preserved, but you only need to paste the parameters you need, not the full contents of it.
Since you’re using Docker, you will also need to mount the file from the host machine so that any new container could use it.
Ok, thanks for your reply again. But when I use Docker in a productive Environment I would not take the :latest image but a specific version. And so there is not need to worry about updates because this will always launch the same version. So I can use the corresponding default.json config and overwrite it to my needs. With the separate file brings no advantage at all.
Each new version contains new features and fixes for known bugs. For example, if you face any issue, I will ask you to update DS to the latest version first. It’s better to troubleshoot situation on the actual version.