Support for docker / docker-compose and out-of-date documentation



  • I've been doing some comparisons between nodebb and discourse. Both appear to be very good solutions but discourse appears to have better documentation for Docker.

    I've searched through the forum here and most posts seem to indicate a general dislike of docker. I did find what appears to be a link to old official documentation providing steps for installation with docker.:

    However, the latest documentation doesn't appear to have a section for docker:

    I have a decent amount of experience with docker / docker-compose and recognize it's not perfect but find the advantages outweigh the disadvantages. Is there any official guidance for nodebb with docker? Is there any official documentation / installation guides or docker-compose files?

    EDIT: I found what looks to be an official nodebb Docker container on dockerhub:

    The instructions on the page just refer to the github page which doesn't really discuss docker or docker-compose. However, there is a docker-compose.yml in the repo that looks like a potential example. I'll follow this and see how it works out. If this intended to be officially supported, it would be helpful to update some of the documentation to point to them. If that's what's intended, I'd be willing to modify and put our a PR if desired.



  • Actually i signed up here just to discuss this issue. There is not only no documentation on the "official" nodebb docker, it is impossible to see who maintains it.

    also, the docker image is not persistent, doing a docker pull overwrites the database, which is pretty much unacceptable, so there is some work that needs to be done. i would be willing to chime in here with my limited knowsledge of both docker and nodebb but i think it would be good to know first who maintains the docker...



  • @evgenymagata "docker image is not persistent, doing a docker pull overwrites the database"
    You have to mount volumes in the DB container. It is the basis in Docker.



  • @Per0x @evgenymagata ,

    It's typical to mount a volume for your DB so the data persists. I typically use docker-compose as it's easier to execute and maintain. I was able to get this working but I had to modify a docker-compose file and modify the mongod configuration file change in the container to enable mongodb authentication.

    I'm currently evaluating nodebb and discourse for use by a client. The config change I made won't be persistent as I modified the file in the running container. That's obviously not the correct way to solve the problem.

    In case it's helpful, here's the docker-compose I used:
    version: '3.5'

    services:
    node:
    image: nodebb/docker
    restart: unless-stopped
    depends_on:
    - db
    ports:
    - "4567:4567"

    db:
    image: mongo:bionic
    restart: unless-stopped
    ports:
    - "27017:27017"
    environment:
    MONGO_INITDB_ROOT_USERNAME: root
    MONGO_INITDB_ROOT_PASSWORD: root
    volumes:
    - bbdata:/data/db

    volumes:
    bbdata:

    And here's a link that helps understand the mongod.conf file changes:

    Additionally, when running the web installer for nodebb, you'll need to tell it the database is at the host specified in the docker-compose (e.g. 'db'), not localhost.



  • I advise you to also mount the /uploads folder in nodebb container. As well as the config.json file.



  • @Per0x Yup, I know & I have a volume for the redis database. That's not the problem. The point is that after doing a "docker pull" the nodebb installation does not check if it's already configured and has a database, but starts the web installer, which overwrites the existing database at some point. At least that's what I guess is happening. Did you try it yourself or are you talking about how it should work in theory, because I tried several times... Obviously you can backup your DB before updating, but a "docker pull" should not result in triggering the web installer - if the instance is already configured. And if it triggers the web installer, it should never overwrite an existing database.

    I would assume (haven't checked yet), that the docker Image does not check if there is a config-file and database after a "docker pull" in which case it should run an upgrade and not the initial installation routine.

    Maybe to clarify: typically you don't update any docker Microservice by using the softwares built in update mechanisms, but you just pull a new docker file with the most recent version, which then should be aware of any prior existing config and database and run any necessary upgrades but NOT act like a fresh installation.



  • So, who made the Dockerfile of the official Docker image and did he/she implement some kind of upgrade check?



  • @evgenymagata "you don't update any docker Microservice by using the softwares built in update mechanisms, but you just pull a new docker file with the most recent version"

    Yes, that's what I did the last time. But my last upgrade was several months ago, so I can't say for sure what I did exatly.
    If it wasn't that, I probably had to docker pull a similar version, restore the DB and do a ./nodebb upgrade.
    However, I use redis as DB, not Mongo (that I never used), so maybe it's different. I just restore the dump.rdb, and it's good.



  • @Per0x I am using Redis as well and like i mentioned, it is no problem to restore the db, if you KNOW its going to be overwritten on a docker pull. But since this is something a properly made docker would NEVER do, i didnt take the precaution of backing it up. Now i do. In any case, its just not good style to overwrite things in persistant directories, it completely contradicts how docker logic works and besides, its very easy to do properly, there are literally THOUSANDS of example Dockerfiles to see how its done. So my question is who maintains the official docker image so to maybe help make a properly configured image.



  • @evgenymagata In that case, make your own Dockerfile rather than complain, you don't need the maintainer's name, it's open source and "very easy to do" as you said...



  • I really dont get what your problem is. I can do this for myself or i could help the person responsible for the NodeBB docker to make a proper container for everyone. One that doesnt overwrite persistent data. If i was the maintainer, the choice would be clear. So, what IS your problem, are you the maintainer and dont know how to make a proper docker container but too proud to let someone help you ;)?

    You are weird.



  • No, I'm not the maintainer just a random user, and I don't have any problems whith my containers in production. You're the one who complains and seems to have problems with your containers here...



  • Forget it buddy. I think your reading skills a flawed. As i said before i dont have problems with my containers. The official NodeBB docker container does not adhere to essential docker rules, which are: do not mess with persistant data. But i doubt you are able to grasp that. Lets leave it here.


Log in to reply
 

Suggested Topics

| |