Unifi controller in a jailmaker docker jail?

So I’ve pretty much transferred all my apps (arr, syncthing, jellyfin, webserver) over from k3s to docker in a jailmaker jail (thanks @ Stux!), including nextcloud. Lots of learning about paths & permissions along the way!

Now - here’s a challenge for y’all…the unifi controller.

The latest image from linuxserver.io needs a separate mongo container running.

I have got a working mongo install, accessible by mongoexpress, but I’ll be damned if I can get the needed ‘unifi’ db with its ‘unifi’ user set up as per the instructions by using a ‘mongo-init.js’ file which gets inserted and runs on first start up.

Basically, the init-mongo.js file doesn’t seem to have any effect, and the unifi database and user never get setup, so the unifi-controller then fails to connect to anything.

Hmmmm ?!?

So - have any of you managed to get this working in docker inside a jailmaker jail? There’s a virtual beer reward for anyone who reports success :slight_smile:

Doesn’t help you in any way shape or form … but I run UniFi 8 in a jail on Core.

I’m planning on migrating to SCALE at some point … so I’ll keep an eye on responses here

Is there not an example compose file to use somewhere?

Combining x with y is what compose was made for

Heh - lots - and I’ve tried quite a few of 'em, with various versions of mongo etc.

BREAKING NEWS: this compose from here works! I’m not knowledgeable enough to know why it works where others fail though:

version: "2.3"
services:
  mongo:
    image: mongo:3.6
    container_name: unifi_mongo
    restart: unless-stopped
    volumes:
      - ./db:/data/db
      - ./dbcfg:/data/configdb
  controller:
    image: dancarbone/jacobalberty-unifi:v8.2.93
    container_name: unifi_controller
    depends_on:
      - mongo
    init: true
    restart: unless-stopped
    volumes:
      - ./unifi/dir:/unifi
      - ./unifi/data:/unifi/data
      - ./unifi/log:/unifi/log
      - ./unifi/cert:/unifi/cert
      - ./unifi/init:/unifi/init.d
      - ./unifi/run:/var/run/unifi
      - ./unifi/backup:/unifi/data/backup
    user: unifi
    sysctls:
      net.ipv4.ip_unprivileged_port_start: 0
    environment:
      DB_URI: mongodb://mongo/unifi
      STATDB_URI: mongodb://mongo/unifi_stat
      DB_NAME: unifi
    ports:
      - 3478:3478/udp # STUN
      - 6789:6789/tcp # Speed test
      - 8080:8080/tcp # Device/ controller comm.
      - 8443:8443/tcp # Controller GUI/API as seen in a web browser
      - 8880:8880/tcp # HTTP portal redirection
      - 8843:8843/tcp # HTTPS portal redirection
      - 10001:10001/udp # AP discovery
networks: {}

Thanks to jacob albert - GitHub - jacobalberty/unifi-docker: Unifi Docker files.

EDIT: and now updated to the latest unifi controller version (8.2.93), thanks to dancarbone, and have migrated my site across.

So - I have now been able to shutdown the Arch VM which I had been using to run nextcloud and unifi. Well done docker. Well done. :clap:

EDIT 2: oh yeah - virtual beer to self! :grin: :beer:

2 Likes

The reason that one works is because the mongodb container is being created for you in that compose file on-the-fly, same as the controller container. Someone feel free to correct me on this, but I think the reason LSIO didn’t do it this way is because they always provide the docker run command in their setup guides in addition to docker compose, and there probably isn’t a way to state dependencies in docker run commands.

If you look at the 3rd line, that creates one container for mongodb with its own configuration and volumes, and the 10th line creates the container for the controller portion. The ‘depends on’ line states that unifi controller requires mongodb as a dependency, so it ensures that the mongodb container is started before unifi controller — if that line was omitted, there’s a chance the container would fail due to differing startup times for each.

And this is why compose is a good thing. It allows you to make “compositions” of multiple containers.

As a benefit its also just a really good way to document the “configuration” for running a single container too, otherwise you’re reduced to text files and scripts with magic docker incantations listed in them.