Choose to install npm packages at startup on Docker.

Feature Requests
  • On docker image, we might choose wich npm packages (plugins, themes, etc) we want to install during the first build (by environment variable for instance).
    It would prevent restore issues when theme or plugins are not present on the new container and would speed up deployment time of docker containers for upgrades and restore.

    For example: I prepared the backup of my database, and I mounted the /uploads volumes and the config.json file but my docker container fails because it can't find the themes and displays errors for missing plugins.
    But if upstream, I tell the docker container to install the right npm packages associated on my nodebb database, my nodebb forum is restored immediately.

  • Are you referring to our Dockerfile?

    Again, I should preface that we are unfamiliar with Docker as we do not use it ourselves. We maintain the Dockerfile purely as a service to our users who want to use Docker 🙂

    I don't think it is possible to specify plugins in the Dockerfile or image simply because each separate instance contains their own plugins and so on. What one site wants is not what another site would want installed.

  • Yes I'm referring to the Dockerfile. I'm no expert with Docker either, but I must admit that it's extremely handy for creating forums on the fly with different versions at the same time, and saves a lot of time.

    If you're not focused on this tool I completely understand and appreciate you already providing up-to-date docker images, so I'll try to see what I can do myself and share it if it works well. This is possible by manually modifying the dockerfile but I think it's also possible in a more elegant way and easy to use, with env variables 😉

Suggested Topics

  • 0 Votes
    11 Posts

    @pitaj said in NodeBB Installation as Module(s):

    I am not entirely convinced about the whole overwriting story

    npm deletes the old version of the module before installing the new module version. So any changes you make inside a module directory that is managed by npm will be deleted.

    Ok but why not let npm do the management and add the entries in such a place that it is managed correctly?

    even if that was the case, what would prevent simply reinstalling the plugins as well?

    The package.json defining installed plugins would be deleted.

    Ok I see your point but this is precisely the case because NodeBB insists to run in its source code directory. Indeed, NodeBB should look for package.json in the parent directory and further up the directory tree and add the plugin entries there prior to running npm install.

    plugins to require('nodebb/src/...') instead of require.main.require('./src/...') which in turn would open way to proper unit testing for plugins

    Unit tests shouldn't need to connect to NodeBB, as units are small pieces of code that can be isolated from the rest, including NodeBB. You can set up your unit tests however you want for your plugins.

    That is true, I just mean that plugins notoriously use NodeBB internals by means of require.main.require('./src/database') etc. it would be cleaner if NodeBB actually came as a set of modules and one could simply require('nodebb-database');

    As for higher level tests:

    Again, NodeBB requires a connection to a database, even while testing. Your plugin test harness would still need to initialize the database as they do now.

    Well ok that is true, I guess the main points are the ones before.

    run multiple instances without copying the entire source code directory

    That would be a nice result of rearchitecting, except then every NodeBB instance must be at the exact same version.

    True but it is usually fine to just run the most recent version.

    be more in line with how Node apps are installed generally

    Again, I'm unaware of any node applications like NodeBB, that must connect to a database to function, that work the way you describe. Please provide an example.

    I don't think that connecting to a database somehow "excuses" applications writing inside of their own source code directories. It just feels very much not right.

    Among bigger applications I guess ESlint still nicely provides a binary. But it would be great if NodeBB was a pioneer and the first one to do it "right" among the Web apps 🙂

  • 0 Votes
    4 Posts

    if the issues are not with your installation then I think the dev team prefers the github issue tracker so that they don't get lost in here.

  • 0 Votes
    8 Posts

    Yeah, I just took a look at my ~, I have the gits for nodejs 0.10.35, redis 2.8.19, and nodebb 0.6.0 that I built from source. These are not the legacy versions suggested on the docs, but they are the ones I got working on my Debian Wheezy. (I built them with the instructions from their gits, not the nodebb docs)

    I just noticed there was a sections about using a dot-deb for install, I don't remember if I tried it that way, but it might be easier if it works.

    I hope this helps in some way, I'm a bit of a newb myself. 😉

  • 0 Votes
    2 Posts

    We'd probably have to roll our own upgrade script that calls npm install with a version number. npm upgrade is too risky, since it downloads the latest version of a module, irrespective of any configured versioning in your package.json.

    Our themes and plugins aren't comparible with older versions, so they might end up installing a version that is too new and break their forum...

  • 1 Votes
    17 Posts

    Okay handing out 1 week bans to all. One month for @julian I need to catch up too.