I don't know if Zeit Now (while really cool!) would work for NodeBB... NodeBB is a web application, and does lots of stuff in the background that relies on a server running. To have a service that spins up whenever a request comes in would be much too slow, if only because that first spin up would take many seconds!
Support for docker / docker-compose and out-of-date documentation
-
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/dbvolumes:
bbdata:And here's a link that helps understand the mongod.conf file changes:
How to Enable Authentication on MongoDB
Learn how to properly configure the most important and fundamental security feature that comes with MongoDB
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.
-
@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.
-
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.
-
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.
