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
Docker: Allow file based declaration of active modules #10036
base: master
Are you sure you want to change the base?
Conversation
If I am reading this correctly, you are specifying that specific plugins be activated when the Dockerfile is run. However, plugin activation states are stored in the database, even though they can be modified via the command line. So this change does allow you to specify active modules via file, but it would cause side effect like accidental re-activation of a plugin that had been deactivated during the normal running of the instance. There also shouldn't be any need to repeatedly activate already active plugins, although there's no real harm in doing so. |
Yes. They are installed via npm and then activated.
Yes, this is correct and that's how I do it in my current docker-compose setup. But there I mounted the node_modules folder so I don't lose installed plugins. In a stateless container setup you don't want to mount such a thing. Also you usually don't want to activate or deactivate features at runtime. If you don't want any plugins leave the file empty (which is the default behavior). If you no longer want an addon remove the plugin from the file (and deactivate it via command line or frontend).
Correct. If a user does not want this feature, he can just leave the file empty which would keep the current behavior.
Yes, that's the point why I'm doing this. It does no harm, but it makes the container predictable. You specify that you want to use a plugin in the container config and you will get it. |
a0d0cb0
to
6961a43
Compare
@julianlam What is the status on this? I noticed that #10767 implemented a "similar" feature, however it does not solve the issue of installing the desired module via npm install (my solution does). This makes installing it in Docker and/or Kubernetes quite complicated. Also: activating the module could be removed as this is possible from the config now. Or I read all active modules from the config but then I need to install jq into the container for parsing. |
So as the author of the PR with plugin state in configuration:
There is definitely an issue with there not having any way to actually install plugins before container startup. However, NodeBB does have a facility for doing setup before starting for the first time already. And it's even included in the |
Yes I think this is actually the core of my problem. |
By default, the file is empty but a user can mount a different file into the container. In K8s it is unsafe to first run the container and then later on activate modules. This should be done before nodebb is started. Activating modules for each pod is safe as it is an idempotent operation.
So I noticed an issue with both my approach an @oplik0 PR: It ignores the version restriction of a plugin and just grabs the latest version. If I'm not 100% mistaken the NodeBB plugin panel only pulls supported version. 😞 |
By default, the file is empty but a user can mount a different file into the container.
In K8s it is unsafe to first run the container and then later on activate modules. This should be done before nodebb is started.
Activating modules for each pod is safe as it is an idempotent operation.