hyperion-project / hyperion.ng

The successor to Hyperion aka Hyperion Next Generation
https://hyperion-project.org/
MIT License
3.14k stars 387 forks source link

Doc for running hyperion.ng inside docker #1470

Open psychowood opened 2 years ago

psychowood commented 2 years ago

Feature request

What problem does this feature solve?

Run hyperion.ng service inside docker without relying on third parties/closed sources images

How should this be implemented in your opinion?

Add a docker-compose sample file inside the repository.

Are you willing to work on this yourself?

Yes I did :)

I've been using a third party image for a while, but the fact that it was not open source wasn't really something I liked, so I created a new docker compose file.

I just wanted to share a sample docker-compose file to run hyperion as a service inside an headless docker host. You can find the documentation in this repo, hopefully this can be useful to someone.

Lord-Grey commented 2 years ago

@psychowood Thanks for sharing! It works quite well.

I am not too detailed into docker and docker compose, but you might want to consider the following feedback/questions:

a) You might want to add how a user gets a serial device exposed to the docker image (in case they do adalight)

Two additions are required:

  1. Add the dialout user-group to the user (after the first adduser command) adduser -q hyperion dialout &&
  2. Expose the serial device:
    devices:
      - /dev/ttyACM0:/dev/ttyACM0

b) If one would like to run Philips Hue in Entertainment mode, the following UDP port mapping is required in addition: - "2100:2100/udp"

c) Hyperion exposes its mDNS and SSDP services... How can this been done? Have you tested it?

d) Hyperion tries to discover devices via mDNS (e.g. WLED, PhilipsHue, Cololight, Yeelight and other Hyperion installations) or via SSDP. Have you tried that too? I might have been not successful, as I tested in a VM with bridged network.

e) It might be interesting having one compose file that can build a stable or nightly docker. That would allow users to savely test a nightly build.... Not sure how this can be achieved easily besides having two compose files and what is best practice here.

If you are ok, we might integrate the docu into the official one? What do you think?

psychowood commented 2 years ago

a) You might want to add how a user gets a serial device exposed to the docker image (in case they do adalight)

Sure, I'll expand the compose example with all the passthrough options possible.

b) If one would like to run Philips Hue in Entertainment mode, the following UDP port mapping is required in addition: - "2100:2100/udp"

Are there other ports that could be added

c) Hyperion exposes its mDNS and SSDP services... How can this been done? Have you tested it?

Interesting question, I honestly don't have the answer when using mapped ports on the docker host.

d) Hyperion tries to discover devices via mDNS (e.g. WLED, PhilipsHue, Cololight, Yeelight and other Hyperion installations) or via SSDP. Have you tried that too? I might have been not successful, as I tested in a VM with bridged network.

What I'm doing on my setup is something a little bit different than the documented example: the hyperion container is connected to a custom network bridged with the physical network using the macvlan driver. This is probably the easiest way to allow every different network configuration to work, since it puts the container in a vm-like configuration. I can confirm that it has discovered automatically a WLED device in my network (see below), which other tests can I do to see if mDNS or SSDP is working?

image

e) It might be interesting having one compose file that can build a stable or nightly docker. That would allow users to savely test a nightly build.... Not sure how this can be achieved easily besides having two compose files and what is best practice here.

It should be possible to parameterize the repo with env variables, I'll look into that. I'd like to publish the images too, if I find the time to study github actions :)

If you are ok, we might integrate the docu into the official one? What do you think?

Of course, I'd be proud of that :)

foorschtbar commented 2 years ago

Run hyperion.ng service inside docker without relying on third parties/closed sources images

I have done the same for the same reasons (hyperion-docker) a few months ago. Maybe it make sense for a offical repo?

psychowood commented 2 years ago

I updated the repo with a macvlan example (that should make available all the options related to more generic cases as mDNS) and with a build file with the nightly repo.