Update Mongo DB

[jacobalberty]

As of right now Unifi supports up to Mongo DB 3.6, we are still on 3.4 for AMD64/ARM64 and 3.2 for ARM32.

At the very least we need to move Mongo DB to 3.6 for AMD64 or ARM64

This does not appear to require any changes to our base image.

If possible we should build Mongo DB 3.6 for ARM32 so it can upgrade as well.

[jasonmp85]

I was just looking into this, as I was wanting to move away from standalone use myself, but… upstream seem to (in their deb package) restrict Mongo as follows…

mongodb-server (>= 2.4.10) | mongodb-10gen (>= 2.4.14) | mongodb-org-server (>= 2.6.0),
mongodb-server (<< 1:4.0.0) | mongodb-10gen (<< 4.0.0) | mongodb-org-server (<< 4.0.0),

Mongo's own lifecycle policy reflects that the 3.6 line was EoL'd in April 2021, which is also reflected by the "supported tags" in the official Docker image only going back to some 4.x release or other.

Shouldn't upstream be improving their own product baseline? It's been over a year since 3.6 has fallen out of any support.

[jhenstridge]

@jasonmp85: it seems likely that they're intentionally picking the earlier versions to avoid the MongoDB license change (AGPL3 to SSPL).

[gertvdijk]

7.5.x (now release candidate) has these requirements in the debian/control file:

Package: unifi
Version: 7.5.172-22697-1
[...]
Architecture: all
Depends: [...]
 mongodb-server (>= 1:3.6.0) | mongodb-10gen (>= 3.6.0) | mongodb-org-server (>= 3.6.0),
 mongodb-server (<< 1:5.0.0) | mongodb-10gen (<< 5.0.0) | mongodb-org-server (<< 5.0.0),
[...]

This means we could upgrade to a 4.x version. However, with the new Java == 17 requirement that's tricky to select the OS version that ships with both Java and MongoDB versions compatible with the application.

See also #673 (comment)

[jokay]

Why not making your lives easier and decouple the dependencies by having two separate containers, one for the app and one for the database?

services:
  app:
    image: jacobalberty/unifi:v7.5.176
    ports:
      - 3478:3478/udp
      - 8443:8443 # better use traefik
      - 8080:8080
      - 10001:10001/udp
      #- 1900:1900/udp # optional
      #- 5514:5514/udp # optional
      #- 6789:6789 # optional
      #- 8843:8843 # optional
      #- 8880:8880 # optional
    volumes:
      - ./data/app:/unifi/data
      - ./data/log:/unifi/log
    environment:
      - RUNAS_UID0=false
      - UNIFI_UID=999
      - UNIFI_GID=999
      - LOTSOFDEVICES=true
      - DB_URI=mongodb://unifi:{my-mongodb-pw}@db/unifi?authSource=admin
      - STATDB_URI=mongodb://unifi:{my-mongodb-pw}@db/unifi_stat?authSource=admin
      - DB_NAME=unifi
    networks:
      - default

  db:
    image: mongo:4.4.18
    volumes:
      - ./data/db:/data/db
      - ./data/configdb:/data/configdb
    environment:
      - MONGO_INITDB_ROOT_USERNAME=unifi
      - MONGO_INITDB_ROOT_PASSWORD={my-mongodb-pw}
      - MONGO_INITDB_DATABASE=unifi
    networks:
      - default

networks:
  default:

---

An additional important information for the RaspberryPi 4. Any MongoDB version >4.4.18 will not work.

MongoDB requires ARMv8.2-A or higher, and your current system does not appear to implement any of the common features for that! applies to all versions ≥5.0, any of 4.4 ≥4.4.19

• Update ARM builds to target armv8.2-a on older branches
• Bump the aarch64 minimum required architecture to armv8.2-a
• ARMv8 Extensions and Processor Features
• Mongo 5.0.0 crashes but 4.4.6 works

[runepiper]

Looks like UniFi Network Application 8.0 (not released yet) will require MongoDB 3.6 upwards: https://community.ui.com/releases/UniFi-Network-Application-8-0-7/7818b9df-4845-4c82-ba3c-1218e61010d4

[jokay]

Seems the maintainers of other UniFi Controller Docker images realized it as well, see here.

I switched to linuxserver/unifi-network-application to finally get a clean "mongoless" Docker image 😉

services:
  app:
    image: linuxserver/unifi-network-application:8.0.7
    ports:
      - 3478:3478/udp
      - 8443:8443 # better use traefik
      - 8080:8080
      - 10001:10001/udp
      #- 1900:1900/udp # optional
      #- 5514:5514/udp # optional
      #- 6789:6789 # optional
      #- 8843:8843 # optional
      #- 8880:8880 # optional
    volumes:
      - ./data/app:/config
    environment:
      - TZ=Etc/UTC
      - PUID=1000
      - PGID=1000
      - MONGO_USER=unifi
      - MONGO_PASS={my-mongodb-pw}
      - MONGO_HOST=db
      - MONGO_PORT=27017
      - MONGO_DBNAME=unifi
      - MEM_LIMIT=1024 # optional
      - MEM_STARTUP=1024 # optional
      - MONGO_TLS= # optional
      - MONGO_AUTHSOURCE= # optional
    networks:
      - default

  db:
    image: mongo:4.4.18
    volumes:
      - ./data/db:/data/db
      - ./data/init-mongo.js:/docker-entrypoint-initdb.d/init-mongo.js:ro # only for first run
    #environment:
      #- MONGO_INITDB_ROOT_USERNAME=unifi # unsupported, use init-mongo.js instead
      #- MONGO_INITDB_ROOT_PASSWORD={my-mongodb-pw} # unsupported, use init-mongo.js instead
      #- MONGO_INITDB_DATABASE=unifi # unsupported, use init-mongo.js instead
    networks:
      - default

networks:
  default:

And do not forget to use init-mongo.js and set your MongoDB password in {my-mongodb-pw}:

db.getSiblingDB("unifi").createUser({user: "unifi", pwd: "{my-mongodb-pw} ", roles: [{role: "dbOwner", db: "unifi"}]});
db.getSiblingDB("unifi_stat").createUser({user: "unifi", pwd: "{my-mongodb-pw} ", roles: [{role: "dbOwner", db: "unifi_stat"}]});

[runepiper]

I also switched to a very similiar setup and it works flawlessly. Would recommend @jokay setup 👍

[trustno1foxm]

Seems the maintainers of other UniFi Controller Docker images realized it as well, see here.

I switched to linuxserver/unifi-network-application to finally get a clean "mongoless" Docker image 😉

services:
  app:
    image: linuxserver/unifi-network-application:8.0.7
    ports:
      - 3478:3478/udp
      - 8443:8443 # better use traefik
      - 8080:8080
      - 10001:10001/udp
      #- 1900:1900/udp # optional
      #- 5514:5514/udp # optional
      #- 6789:6789 # optional
      #- 8843:8843 # optional
      #- 8880:8880 # optional
    volumes:
      - ./data/app:/config
    environment:
      - TZ=Etc/UTC
      - PUID=1000
      - PGID=1000
      - MONGO_USER=unifi
      - MONGO_PASS={my-mongodb-pw}
      - MONGO_HOST=db
      - MONGO_PORT=27017
      - MONGO_DBNAME=unifi
      - MEM_LIMIT=1024 # optional
      - MEM_STARTUP=1024 # optional
      - MONGO_TLS= # optional
      - MONGO_AUTHSOURCE= # optional
    networks:
      - default

  db:
    image: mongo:4.4.18
    volumes:
      - ./data/db:/data/db
      - ./data/init-mongo.js:/docker-entrypoint-initdb.d/init-mongo.js:ro # only for first run
    #environment:
      #- MONGO_INITDB_ROOT_USERNAME=unifi # unsupported, use init-mongo.js instead
      #- MONGO_INITDB_ROOT_PASSWORD={my-mongodb-pw} # unsupported, use init-mongo.js instead
      #- MONGO_INITDB_DATABASE=unifi # unsupported, use init-mongo.js instead
    networks:
      - default

networks:
  default:

And do not forget to use init-mongo.js and set your MongoDB password in {my-mongodb-pw}:

db.getSiblingDB("unifi").createUser({user: "unifi", pwd: "{my-mongodb-pw} ", roles: [{role: "dbOwner", db: "unifi"}]});
db.getSiblingDB("unifi_stat").createUser({user: "unifi", pwd: "{my-mongodb-pw} ", roles: [{role: "dbOwner", db: "unifi_stat"}]});

thx, looks very nice, I really tried to setup the same but I always get that error on the mongo db container and I am sure that's the reason why the unifi container won't start up:
AuthenticationFailed: SCRAM authentication failed, storedKey mismatch"}

What's wrong? :/ thx!

[esand]

Unifi Application v 8.1 and newer now support up to MongoDB v7.0.

[buckaroogeek]

I installed unifi 8.1.113 using this container image. A few days later I updated mongo db from 3.6 to 4.4. I use docker-compose to manage my containers. A few points to consider:

1. Starting with v 5, mongo requires the AVX support in the host cpu(s). My older Synology (ds 218+, INTEL Celeron J3355) does not provide AVX instructions so 4.4 is the most current mongo version I can install.
2. With containers for both unifi and mongo, securely updating is all about making sure the mongo data files can be restored at each step in case of failure. If you run mongo as an installed application, complexity of the update process would significantly increase (IMHO).
3. In the docker-compose.yml file the mongo container has 2 volumes. In my instance dbcfg is empty. So data protection is making sure the db volume is properly copied or saved in case of failure.

    volumes:
      - db:/data/db
      - dbcfg:/data/configdb

4. I was able to go directly from 3.6 to 4.4 using mongodump and mongorestore at the command line in the running mongo container. There are other methods available too. Using mongorestore to update mongo versions is apparently not officially supported (more of a backup solution) but mongo employees on their forums say to try it.
5. mongodump and mongorestore use dump files stored in /dump in the container. This /dump directly needs to be mapped to a docker volume for persistance as the old mongo version is stopped after the dump and the new version started before restore.
6. While Jacob's image does have mongo included, if configured to use a separate mongo instance, the container mongo is not started.
7. The process I used is a bit tedious but straightforward and also done via the command line. Familiarity with ssh and working at the linux command line is very helpful.

[jokay]

Seems to be a similar limitation as for a RaspberryPi 4:

WARNING: MongoDB requires ARMv8.2-A or higher, and your current system does not appear to implement any of the common features for that!
applies to all versions ≥5.0, any of 4.4 ≥4.4.19
see https://jira.mongodb.org/browse/SERVER-71772
see https://jira.mongodb.org/browse/SERVER-55178
see also https://en.wikichip.org/wiki/arm/armv8#ARMv8_Extensions_and_Processor_Features
see also docker-library/mongo#485 (comment)

You may consider using a RaspberryPi 5 which allows you to run the UniFi Network Application 8.1.x together with MongoDB 7.0.x.

Btw creating a backup for e.g. MongoDB 4.4.29 and restoring it on MongoDB 7.0.7 using the UniFi Network Application did work without any problems.