[BUG] docker-compose configuration incompatible with Discovery Plugin

[JeWe37]

Describe the bug With the current docker-compose file bonjour/avahi/zeroconf auto-discovery does not work.

Container Details

Don't think this matters here: 2021-11-02T17:31:14.962Z

To Reproduce Steps to reproduce the behavior:

1. Create a container with the docker-compose file
2. Observe that say Cura's Octoprint plugin or Windows Explorer's network tab won't show Octoprint.

Expected behavior They should show up I guess?

Additional context I have solved it: For similar SSDP problems you usually see using host networking(network_mode: host) suggested. On my RaspberryPi that did not work though, I instead had to set up a macvlan network, which for some reason then did work just fine. Further investigation may be required, which is why this isn't a pull request.

version: '2.4'

services:
  octoprint:
    image: octoprint/octoprint
    restart: unless-stopped
    # required for using discovery
    networks:
      octoprint_vlan:
        ipv4_address: 192.168.0.242
    # ports:
    #   - 80:80
    devices:
    # use `python -m serial.tools.miniterm` to see what the name is of the printer
    #  - /dev/ttyACM0:/dev/ttyACM0
      - /dev/ttyUSB0:/dev/ttyUSB0
    #  - /dev/video0:/dev/video0
    volumes:
     - octoprint:/octoprint
    # uncomment the lines below to ensure camera streaming is enabled when
    # you add a video device
    #environment:
    #  - ENABLE_MJPG_STREAMER=true

  ####
  # uncomment if you wish to edit the configuration files of octoprint
  # refer to docs on configuration editing for more information
  ####

  #config-editor:
  #  image: linuxserver/code-server
  #  ports:
  #    - 8443:8443
  #  depends_on:
  #    - octoprint
  #  restart: unless-stopped
  #  environment:
  #    - PUID=0
  #    - GUID=0
  #    - TZ=America/Chicago
  #  volumes:
  #    - octoprint:/octoprint

volumes:
  octoprint:

networks:
  octoprint_vlan:
    driver: macvlan
    driver_opts:
      parent: eth0
    ipam:
      config:
        - subnet: 192.168.0.0/24
          gateway: 192.168.0.1
          ip_range: 192.168.0.240/28

[LongLiveCHIEF]

This isn't a bug, its expected behavior with docker. docker isolates the app from the host, so any host-dependent features won't work without additional work that a docker user should know to expect.

[JeWe37]

Given that altering this behavior took me a bit and that I am likely to not be the only one that will encounter this I would argue that at least stating that this functionality won't be available explicitly and offering the option to enable it by circumventing said isolation would be the proper way to fix this. I didn't mean to suggest that the default be changed.

[LongLiveCHIEF]

In our main docs, we state that octoprint is not the best candidate for containerization. It is also assumed that if you've chosen to use docker, you have a very specific reason to do so, and know docker well enough to handle your use case. Any device based docker image is an advanced docker usage. If you're just using this image as a way to quickly install OctoPrint, you're going to run into a lot of issues that will require docker skills and knowledge to fix.

This is basic docker knowledge, and there are so many host dependent features in Octoprint, that we'd basically be duplicating significant pieces of docker documentation.

Docker also changes these interfaces from version to version, and everyone's host network, ineterfaces, etc... are unique.

The entire premise behind dockerization is that the app developer doesn't have to do stuff like this because it will be the system admin's responsibility (because docker will run on any linux kernel and it's impossible to know what each host would need to make the plugin work).