Where's the Dockerfile?

[fakuivan]

I know there's scottlamb/moonfire-nvr in dockerhub, and also mentions of someone having contrubuted a Dockerfile at some point. I'd like to try out moonfire and docker makes it really easy to deploy something without comitting a full pi to this just yet. Can anyone please point me to that file so I can build the image?

[scottlamb]

I deleted it, in favor of baking everything into a single statically-linked binary with embedded UI files. IMHO, even for Docker-savvy folks, this is easier, because you don't have to edit a wrapper script (with volume mounts and such). It also better handles the dependency on the HDD mount and such (systemd is good aat this). With the recommended deployment, you end up with these Moonfire-related paths on your Pi:

1. /usr/local/bin/moonfire-nvr
2. /etc/systemd/system/moonfire-nvr.service
3. /etc/moonfire-nvr.toml
4. /var/lib/moonfire-nvr
5. /media/nvr

You needed 3, 4, and 5 with the Docker setup before (exposed to the container through volume mounts). 1 and 2 replace state in Docker.

If you find this harder than the Docker setup (or find that it requires committing the full Pi where the Docker setup doesn't), I'd like to understand why and address it.

[scottlamb]

Would it be fair to say this boils down to familiarity? In particular:

• "it's just a matter of stopping the container and removing the images" seems conceptually the same as "it's just a matter of stopping the systemd service and removing those files")
• "the level of containment" possible with Docker is the same as what's possible with systemd services IIUC:
  • docker volume mounts = systemd's ReadWritePaths=, ReadOnlyPaths=, InaccessiblePaths=, ExecPaths=, NoExecPaths=
  • docker --security-opt = systemd's SystemCallFilter=. btw, note in previous Docker-based releases, the install instructions recommended --security-opt=seccomp:unconfined because many Pis were affected by Seccomp blocks install of "libc6" in Ubuntu 20.04 "focal" image on armhf (arm32v7) moby/moby#40734.
  • likewise, systemd has options for restricting the network, and my previous instructions suggested --network=host (though something like --publish=8080:8080 should also work, assuming the port numbers match your /etc/moonfire-nvr.toml).

You're right that we could still make a Docker image/tag. It wouldn't be hard to add that step to the release CI workflow.

I'm not sure it's the best of both worlds, though; I'm afraid that maintaining two parallel sets of install instructions will lead to mistakes:

• my not testing them both and breaking one or the other by accident
• users spending extra brainpower picking the right instruction set for their install / getting confused when picking the wrong one

So I'm not sure how to please everyone. It seems to me there's a significant population for whom Docker is harder because they're not already familiar with / running it, and just because it's an extra layer. And I'm not even sure there's one nice Docker instruction set that will please everyone. I had a shell script wrapper before that would handle the various operations (starting the long-running service vs running an interactive moonfire-nvr config or the like), but at least some folks would prefer docker-compose instructions (#265), and I think switching to that would introduce some duplication (run service vs config service vs ...), and I'm not aware of a way to share stuff between them like my script did with its common_docker_run_args. [edit: this was wrong, see this comment from fakuivan]

[fakuivan]

I'd argue that if you know both systemd and docker, doing a docker deployment is easier. By "it's just a matter of stopping the container and removing the images" I ment two commands: docker stop <container name> and docker rmi <image name>, as opposed to having to remember where install files are located, unless you're planning on packaging the app on a deb and different packages for each platform. Docker gives you the guarantee that changes to the system are limited to the permisions you explicitly set and the images/volumes you create or download, as opposed to systemd where you need to specify restrictions (opt in vs opt out), docker of course does not provide anything that the linux kernel doesn't and is possible from systemd, it just makes it easier.

About having two separate ways of installing. I'd say that the docker images would be more of a specific case of the manual install. The image can be used to test the install script to at least get a pass/fail in case there's a bug there. I'm not familiar with the testing setup that you have here so maybe what I proposed doesn't apply.

I'd start by making a simple image, set the main cmd to the daemon and leave it running in the foreground.

[scottlamb]

All right, I'm sold. When I get a chance, I'll add docker builds to the CI, with a zippy in the install instructions mentioning it for Docker/Kubernetes-inclined folks with a brief example docker compose setup. It will just mention you're on your own in terms of adapting the rest of the instructions to it, e.g. how to navigate logs...

...or if you'd like to send a PR, it'd be most welcome (and probably get it done faster).

[scottlamb]

I just released v0.7.10. It builds multi-arch docker images again, with an aside in the instructions that has an example docker compose setup.

The images have moved to ghcr.io/scottlamb/moonfire-nvr. ghcr.io is particularly easy to deal with from GitHub Actions, and last I checked docker.io has gone a bit nuts anyway.

[scottlamb]

Hmm, not sure the new instructions are working out: #296

[dolfs]

I would deploy on pi’s in a Kubernetes cluster I use for purposes like this so I would also second a docker image as well. Sent from my iPhone+1 (415) 613-7229 (US)On Nov 22, 2023, at 14:16, Scott Lamb ***@***.***> wrote: Would it be fair to say this boils down to familiarity? In particular: "it's just a matter of stopping the container and removing the images" seems conceptually the same as "it's just a matter of stopping the systemd service and removing those files") "the level of containment" possible with Docker is the same as what's possible with systemd services IIUC: docker volume mounts = systemd's ReadWritePaths=, ReadOnlyPaths=, InaccessiblePaths=, ExecPaths=, NoExecPaths= docker --security-opt = systemd's SystemCallFilter=. btw, note in previous Docker-based releases, the install instructions recommended --security-opt=seccomp:unconfined because many Pis were affected by moby/moby#40734. likewise, systemd has options for restricting the network, and my previous instructions suggested --network=host (though something like --publish=8080:8080 should also work, assuming the port numbers match your /etc/moonfire-nvr.toml). You're right that we could still make a Docker image/tag. It wouldn't be hard to add that step to the release CI workflow. I'm not sure it's the best of both worlds, though; I'm afraid that maintaining two parallel sets of install instructions will lead to mistakes: my not testing them both and breaking one or the other by accident users spending extra brainpower picking the right instruction set for their install / getting confused when picking the wrong one So I'm not sure how to please everyone. It seems to me there's a significant population for whom Docker is harder because they're not already familiar with / running it, and just because it's an extra layer. And I'm not even sure there's one nice Docker instruction set that will please everyone. I had a shell script wrapper before that would handle the various operations (starting the long-running service vs running an interactive moonfire-nvr config or the like), but at least some folks would prefer docker-compose instructions (#265), and I think switching to that would introduce some duplication (run service vs config service vs ...), and I'm not aware of a way to share stuff between them like my script did with its common_docker_run_args. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[dolfs]

Regardless of the other reasons presented, Kubernetes deployment is only possible through docker images. Dolf Starreveld — Mountain View, CA www  <https://starreveld.com/>| map  <http://maps.google.com/maps?q=Mountain+View,+CA>| email ***@***.***>

…

On Nov 22, 2023, at 16:20, fakuivan ***@***.***> wrote: I'd argue that if you know both systemd and docker, doing a docker deployment is easier. By "it's just a matter of stopping the container and removing the images" I ment two commands: docker stop <container name> and docker rmi <image name>, as opposed to having to remember where install files are located, unless you're planning on packaging the app on a deb and different packages for each platform. Docker gives you the guarantee that changes to the system are limited to the permisions you explicitly set and the images/volumes you create or download, as opposed to systemd where you need to specify restrictions (opt in vs opt out), docker of course does not provide anything that the linux kernel doesn't and is possible from systemd, it just makes it easier. About having two separate ways of installing. I'd say that the docker images would be more of a specific case of the manual install. The image can be used to test the install script to at least get a pass/fail in case there's a bug there. I'm not familiar with the testing setup that you have here so maybe what I proposed doesn't apply. I'd start by making a simple image, set the main cmd to the daemon and leave it running in the foreground. — Reply to this email directly, view it on GitHub <#294 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKFJVM7QOM3HTWY4EQNSULYF2JE3AVCNFSM6AAAAAA7WXJUAWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TMNBXGMYTM>. You are receiving this because you commented.

[fakuivan]

Here's a dockerfile that builds and bundles the backend/frontend into a single alpine image.

FROM rust:buster AS backend

RUN apt update && DEBIAN_FRONTEND=noninteractive apt install -y musl-dev libsqlite3-dev git
COPY ./ /repo
WORKDIR /repo/server
RUN cargo install default-target
RUN cargo test
RUN RUSTFLAGS='-C target-feature=+crt-static' cargo build -r --target "$(default-target)"
RUN cp ./target/"$(default-target)"/release/moonfire-nvr /moonfire-nvr

FROM node:alpine AS frontend

COPY ./ /repo
WORKDIR /repo/ui
RUN npm install
RUN npm run build

FROM alpine AS final

RUN mkdir /usr/local/lib/moonfire-nvr
COPY --from=backend /moonfire-nvr /usr/local/bin
COPY --from=frontend /repo/ui/build/ /usr/local/lib/moonfire-nvr/ui

ENTRYPOINT [ "/usr/local/bin/moonfire-nvr" ]

Image size is about 110MB for the current release.

[scottlamb]

You could also reuse a release binary rather than doing your own build, e.g.:

FROM scratch
COPY ./moonfire-nvr-v0.7.9-aarch64-unknown-linux-musl /usr/local/bin/moonfire-nvr
ENTRYPOINT ["/usr/local/bin/moonfire-nvr"]

...you will need to mount /usr/share/zoneinfo from the host, and set TZ.

[fakuivan]

This is the dockerfile I used to test it:

services:
  moonfire:
    image: moonfire-nvr
    build: ./source
    command: run
    volumes:
      - "./config/db:/var/lib/moonfire-nvr/db"
      - "./config/config.toml:/etc/moonfire-nvr.toml:ro"
      - "./media/:/mnt/media/"
      - "/etc/timezone:/etc/timezone:ro"
    ports:
      - 8080:8080

from there it's possible to init, config and start it using:

docker compose run moonfire init
docker compose run moonfire config
docker compose up -d

I haven't tried adding any cameras yet

[scottlamb]

Oh, that's more slick than I'd realized, being able to do just docker compose run moonfire init vs docker compose up -d. I take back what I said before about needing multiple services in the docker compose file...

[fakuivan]

compose run even assumes the -ti arguments you'd usually need to pass to make an ncurses app work, so the interactive config works without any issues, at least on Windows Terminal via SSH.

[fakuivan]

Here's a more simplified version that just downloads the files from the gh releases:

FROM rust:alpine AS downloader

ARG VERSION="v0.7.9"
RUN cargo install default-target
WORKDIR /download/
RUN wget https://github.com/scottlamb/moonfire-nvr/releases/download/"$VERSION"/moonfire-nvr-ui-"$VERSION".zip -qO- | \
        busybox unzip -d ./ui/ -
RUN wget https://github.com/scottlamb/moonfire-nvr/releases/download/"$VERSION"/moonfire-nvr-"$VERSION"-"$(default-target)" -O ./moonfire-nvr && \
    chmod +x ./moonfire-nvr

FROM alpine AS final

RUN mkdir /usr/local/lib/moonfire-nvr
COPY --from=downloader /download/moonfire-nvr /usr/local/bin/
COPY --from=downloader /download/ui/ /usr/local/lib/moonfire-nvr/ui/

ENTRYPOINT [ "/usr/local/bin/moonfire-nvr" ]