Comments (13)
Docker containers are meant to be disposable, if you update one and then it goes away and you re-run the old one, your internal settings will be fore the new version, but your software will be old.
I've been using the same database and config through all the versions of the image, so I honestly don't understand the issues others have been having. :/
from unifi-video-controller.
I'm not sure I follow you. How would it just "go away"? I agree with you that they are disposable, and the usual procedure is to delete one and then run the new version.
But my side question was: Why can't I keep one container (and not make it "go away") and simply upgrade the firmware inside the container... Why isn't that working.
But, more importantly, can you tell me what procedure you are using to upgrade to a new version of the container once it is release.. while keeping your old camera settings and recordings. Maybe a bullet point list would help me very much.
Thanks
from unifi-video-controller.
But, more importantly, can you tell me what procedure you are using to upgrade to a new version of the container once it is release.. while keeping your old camera settings and recordings. Maybe a bullet point list would help me very much.
I think this question is not specific on this image but it's about Dockers basics.
By using bind mounts (as in the example for docker run
in the REAMDME.md) or volumes (both specified with --volume
or -v
) you can define a method (and location) for storing data outside of the container.
If the parameters are set properly, the data will be save, when the container is destroyed. And the new container will find the data and use them.
If this doesn't work with your setup, it would be useful if you post your complete run command with all parameters.
from unifi-video-controller.
Yeah, you need to be saving your config data outside the container which is what the example docker run
shows. My updates are just docker pull
the new one and then restart my container, because I use docker run --rm
which deletes the container every time it stops.
Show us your docker run
.
from unifi-video-controller.
Well, just to clarify, I've been using this image for the past 3,5 years on my Synogy NAS and it worked relatively well (including preserving videos and configuration) up until (I suppose?) version 3.10.X. Up until then, I was using 2 mounted drives, one for my data and another one for the videos.
To quote the documentation: "Starting with Unifi Video 3.10.x, in-place upgrades are not fully supported. It's best to generate and save a backup file, and remove your data folder. Then restore the backup from the web setup page."
From then on, it hasn't been smooth for me. At all. Including exporting the config (which is a pain because I would sometimes forget to do the export before deleting the container...) and then trying to restore it in the new image.
Here is my CURRENT docker run command:
docker run -tdi --restart=always --name unifi-video --security-opt apparmor:unconfined --cap-add SYS_ADMIN --cap-add DAC_READ_SEARCH -p 1935:1935 -p 6666:6666 -p 7080:7080 -p 7442:7442 -p 7443:7443 -p 7444:7444 -p 7445:7445 -p 7446:7446 -p 7447:7447 -v /volume1/docker/unifi-video/recordings:/var/lib/unifi-video/videos -e "TZ=EST" -e PUID=99 -e PGID=100 -e DEBUG=1 pducharme/unifi-video-controller
The way I USED to do it was with this command (preserving my settings):
docker run -tdi --restart=always --name unifi-video --security-opt apparmor:unconfined --cap-add SYS_ADMIN --cap-add DAC_READ_SEARCH -p 1935:1935 -p 6666:6666 -p 7080:7080 -p 7442:7442 -p 7443:7443 -p 7444:7444 -p 7445:7445 -p 7446:7446 -p 7447:7447 -v /volume1/docker/unifi-video/data:/var/lib/unifi-video -v /volume1/docker/unifi-video/recordings:/var/lib/unifi-video/videos -e "TZ=EST" -e PUID=99 -e PGID=100 -e DEBUG=1 pducharme/unifi-video-controller
from unifi-video-controller.
Your current docker run
isn't preserving your config folder, so every time it gets removed you'd lose all your config. Could it be as simple as that? And doesn't your -ti
mean it runs in console mode?
docker run --rm \
--name unifi-video \
--cap-add DAC_READ_SEARCH \
--cap-add NET_BIND_SERVICE \
--cap-add SYS_PTRACE \
--cap-add SETUID \
--cap-add SETGID \
-p 10001:10001 \
-p 1935:1935 \
-p 6666:6666 \
-p 7080:7080 \
-p 7442:7442 \
-p 7443:7443 \
-p 7444:7444 \
-p 7445:7445 \
-p 7446:7446 \
-p 7447:7447 \
-v /data/unifi-video/data:/var/lib/unifi-video \
-v /data/unifi-video/videos:/var/lib/unifi-video/videos \
--tmpfs /var/cache/unifi-video \
-e JVM_MX=2048M \
-e UMASK=002 \
-e PUID=957 \
-e PGID=957 \
-e CREATE_TMPFS=no \
-e TZ=America/Los_Angeles \
-e DEBUG=1 \
pducharme/unifi-video-controller:testing
^ This is mine, of note is that the config/db inside at /var/lib/unifi-video
is being saved somewhere and I'm using the new --tmpfs /var/cache/unifi-video
and -e CREATE_TMPFS=no
options. I also use the --rm
option because it really drives home the point that containers are disposable.
from unifi-video-controller.
Thanks for your response.
I USED to preserve the config... but a while ago I started having issues (don't remember what they were) so I went back to the documentation and this is when I saw the paragraph I quoted. The author specifically stated that I needed to EXPORT the config and IMPORT it again...
Now, thinking about it again, perhaps he meant that I only need to do this procedure ONCE (to go from 3.9 to 3.10)?!? I understood from that text that I needed to export and import my config EACH TIME a new image is available. that was a pain. Now, with your comments.. I'm thinking that I can go back to how I was doing things (2 mounted drives preserving config and recordings).
That would certainly be good news. I'll try it tomorrow.
As for the -ti, if I remember correctly, I think that it is because I run the contained from a SSH shell, and then I need to close that shell. If I don't use those commands, the shell needs to remain connected.
Thanks for helping me on this. Hopefully that settles it.
from unifi-video-controller.
Yeah, I think that was for the 3.9 -> 3.10 transition where they went from whatever the old mongodb format was to the new wired tiger format.
Why are you running it from a shell at all? I'm weird and like systemd .service
files, so that is how I run mine. Looks like...
# /etc/systemd/system/unifi-video.service
[Unit]
Description=Ubiquiti UniFi Video Server
After=network.target zfs.target docker.service
Requires=docker.service zfs.target
[Service]
Restart=on-failure
Type=simple
ExecStart=/usr/bin/docker run --rm \
--name unifi-video \
--cap-add DAC_READ_SEARCH \
--cap-add NET_BIND_SERVICE \
--cap-add SYS_PTRACE \
--cap-add SETUID \
--cap-add SETGID \
-p 10001:10001 \
-p 1935:1935 \
-p 6666:6666 \
-p 7080:7080 \
-p 7442:7442 \
-p 7443:7443 \
-p 7444:7444 \
-p 7445:7445 \
-p 7446:7446 \
-p 7447:7447 \
-v /data/unifi-video/data:/var/lib/unifi-video \
-v /data/unifi-video/videos:/var/lib/unifi-video/videos \
--tmpfs /var/cache/unifi-video \
-e JVM_MX=2048M \
-e UMASK=002 \
-e PUID=957 \
-e PGID=957 \
-e CREATE_TMPFS=no \
-e TZ=America/Los_Angeles \
-e DEBUG=1 \
pducharme/unifi-video-controller:testing
#fryfrog/unifi-video-controller:testing
ExecStop=/usr/bin/docker stop -t 30 unifi-video
[Install]
WantedBy=default.target
But obviously, you'd need to tune that to your own setup.
from unifi-video-controller.
Why are you running it from a shell at all?
Mostly because I didn't know any better. I would SSH to my NAS and from there I would create and delete containers.
Also, because it isn't running "standard linux" but Synology's DSM (their OS, based from Linux), I have been wary of changing things in system directories that can eventually get modified during an update. I've had bad experiences when I "reinforced" my openVPN (trying to harned the basic settings that comes in the Synology package). My custom settings would get deleted.
Are you also running your container on a Synology NAS?
PS: I can't believe this whole time I though I needed to export/import the config. Perhaps the readme note should be clarified. I'm probably not the only one who got confused.
Thanks.
from unifi-video-controller.
Oh, I see you're using Synology. Anything you do via CLI should get reflected in their GUI, you shouldn't need the -dit
I don't think. And ignore my systemd service suggestion, that'd be for a plain old Linux. Why not just use their GUI to get the image going? You could then use a neat Docker image to get the run command it uses! :)
https://old.reddit.com/r/usenet/wiki/docker#wiki_get_docker_run_command
I just run this on my Arch Linux server, not Synology. :(
from unifi-video-controller.
Why are you running it from a shell at all? I'm weird and like systemd
.service
files, so that is how I run mine. Looks like...
I think running containers as a service isn't usual (anymore?). Configured as a service Docker will take care that the containers are running, if you use a restart policy and @dolphinkite has already --restart=always
in his run command to use this feature.
If this is not cool enough, you can use docker-compose
. ๐
@dolphinkite I also start my containers from the shell and simply use -d
. Why do you use the -i
and ยด-t` options?.
from unifi-video-controller.
@thoschworks: Yeah, running containers from a systemd .service
file is super weird. I actually only use Docker for a couple things, most of my stuff is native. So for me using a .service
makes sense because I can control and set dependencies all the same.
I would totally not recommend it for most, docker-compose
or maybe Portainer or even the system a Synology uses would make way more sense in virtually all cases. :)
from unifi-video-controller.
Hi,
Thanks all for the input. A few comments and answers to the various questions:
I'm using the new --tmpfs /var/cache/unifi-video and -e CREATE_TMPFS=no
Can you explain the advantage of those options?
Anything you do via CLI should get reflected in their GUI
When I first started dabbling with Docker, over 4 years ago, the Synology GUI was very immature. Since this was new to me, I read a lot and it became clear that in my setup I needed to use the option --restart=always
but that specific options (and others I think?) was not available in the GUI. Basically, most people suggested at the time to create and manipulate the containers from a SSH shell and disregard the Synology GUI. This may have evolved quite a bit since (and I do see an "enable auto-restart" option in the GUI now) so I may revisit... but I'm now used to doing it command line style.
Why do you use the -iand ยด-t` options?
Again, it goes back 4 years ago. If I remember correctly, those options allowed me to "connect to the container" later and do things like edit files. For example, rereading my own documentation that I wrote while building those docker files, at some point (when I first created the container? I don't even remember) I needed to edit one of the files from within the container. The code in my notes is the following:
docker exec -ti unifi-video bash echo "is_default=true" > data/system.properties exit
But perhaps you are totally right and it is not required anymore (?).
Thanks all for your input.
from unifi-video-controller.
Related Issues (20)
- Unable to Manage - UVC G3 camera HOT 2
- Recordings eventually stop HOT 3
- Not an Issues but HOT 1
- Feature Addition: External Mongo HOT 2
- Inconsistent recording HOT 4
- Cannot view videos in client HOT 3
- Fresh install - video-controller creation script hangs. HOT 18
- Video doesn't start recording automatically after the unifi-video container restart. HOT 8
- java.io.IOException: Unable to create directory /var/cache/unifi-video/exports HOT 6
- UniFi-Video is writing video to a different location HOT 5
- Can only find camera if "--network="host" \" HOT 1
- UniFi Protect cannot discover Video Controller HOT 2
- tmpfs solution for /var/cache/unifi-video on kubernetes HOT 6
- cannot build image due to mongodb package error HOT 3
- Running network controller and video on the same machine HOT 1
- Custom build docker image produces broken unifi video controller HOT 5
- Need to specify specific OpenJDK version HOT 1
- Still usable? HOT 2
- Service exit with a return value of 4 HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from unifi-video-controller.