Home of the Squeezebox™ & Transporter® network music players.
Page 11 of 12 FirstFirst ... 9101112 LastLast
Results 101 to 110 of 111
  1. #101
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,422

    'Official' docker container for LMS?

    > This is only for ARM, right? I haven't looked but I guess the ARM deb
    > isn't including all the CPAN versions that the x86 one does, it is 47Mb
    > compared to 139Mb.


    Once we had a documented "standard" image I could build optimized
    packages for these. We would know what Perl was used, thus could create
    a package with only those binaries required for this version.

    --

    Michael

  2. #102
    Quote Originally Posted by justi View Post
    This is only for ARM, right? I haven't looked but I guess the ARM deb isn't including all the CPAN versions that the x86 one does, it is 47Mb compared to 139Mb.
    Yes, I should probably have been clearer.

    The specific architecture .debs are all under 50Mb, though; it's only the multi-arch that gets up to nearly 140Mb. I don't have any experience building for other architectures, but given that the LMS packages are similar in size and the base Debian package (debian-slim) is also around 20Mb in each case, perhaps the other architectures wouldn't be much bigger than my 283Mb final image, if built with the arch-specific .debs. Also, aren't Dockerhub images compressed? The download size for the stretch-slim image listed on Dockerhub is 18.4Mb, but the image on my Pi is 41.5Mb. I'm not sure the image download would necessarily be quite the size you're imagining.

    To avoid confusion for others in what you and epoch1970 have said, images are always immutable, they are used to create containers. Containers have a rw top layer filesystem, and would rarely if ever work if they were not allowed to write to the filesystem.

    So your concern is over how much writing containers are allowed to do, and whether patching parts of the software installed in the container is too much or objectionable for philosophical (not techincal) reasons. I'm suggesting this is a perfectly reasonable thing to do for minor/patch updates. But I'm not trying to force it on anyone -- you don't have to download server updates in LMS and you can remove and recreate the container if you want to start from a clean slate, no problem. And I would still suggest that major/stable releases have their own images built.
    Yes, you're right, it is a philosophical point rather than technical and I have also been guilty of confusing image and container in my text. I meant to say that (philosophically!) containers should be immutable. This is a point of view, admittedly, but I would humbly submit this blog post on the official Docker blog as both an explanation of the "official" wisdom (for what it's worth) and a reason why several (even prominent) images may not fully embrace that philosophy (spoiler: it's because people erroneously - according to the blog author - see containers as lightweight VMs). As you've said, of course containers aren't actually immutable or the software running within them would usually not work.

    A question: is it likely to cause a problem if a patched container is replaced for whatever reason by a new container made from the less up-to-date original image, but keeps the updated prefs / cache folders which are stored in docker volumes outside the container? If so, this may not be a purely philosophical discussion as that is bound to happen at some point.

    I very much agree with you that the aim should be a reliable image that users can just pull and use without any messing around with Dockerfiles etc. Done right, this should make installing LMS easier than it is at present, particularly for those who already have Docker up and running.

  3. #103
    Quote Originally Posted by mherger View Post
    Once we had a documented "standard" image I could build optimized
    packages for these. We would know what Perl was used, thus could create
    a package with only those binaries required for this version.
    The Docker base image I have used (the one in the Doliana Dockerhub image) is a diet version of Debian, a 20Mb download called debian:stretch-slim and it seems to be an official Debian-released image, so seems like a good choice (unlike the properly micro Alpine image, it uses glibc rather than MUSL). "perl -V" reports v 5.24.1 and then (as you're no doubt aware) a very long list of compile and config options.

    I'm not going to take a guess at which, if any, of these might help you estimate a slimmed-down package size, but as the LMS download is about 2.5x the size of the Debian download when building from this Dockerfile, if it's possible to reduce the LMS size it's clearly likely to have a large effect %age-wise on the final Docker image size.

  4. #104
    Senior Member
    Join Date
    Apr 2008
    Location
    Paris, France
    Posts
    2,241
    Trying to put the idea of in-container updates to rest.

    With containers soon come clusters, distributed computing.
    If one machine in a cluster runs container foo version 8, goes away and gets replaced by a machine that starts container foo version 5, the cluster will fail soon.
    Shared images have to be the starting point. Container reuse is an anti pattern.

    A recipe for building (publishing?) an image is whatÂ’s needed. With the update plugin disabled in it.
    2 SB 3 • 1 PCP 6 • Libratone Loop, Zipp, Zipp Mini • iPeng (iPhone + iPad) • LMS 7.9 (linux) with plugins: CD Player, WaveInput, Triode's BBC iPlayer by bpa • IRBlaster by Gwendesign (Felix) • Smart Mix, Music Walk With Me, What Was That Tune? by Michael Herger • PowerSave by Jason Holtzapple • Song Info, Song Lyrics by Erland Isaksson • AirPlay Bridge by philippe_44 • WeatherTime by Martin Rehfeld • Auto Dim Display, SaverSwitcher, ContextMenu by Peter Watkins.

  5. #105
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,422

    'Official' docker container for LMS?

    > A recipe for building (publishing?) an image is whatÂ’s needed.

    Exactly. Because all the political, philosophical and theoretical
    arguments won't take us anywhere :-D.

    --

    Michael

  6. #106
    Junior Member
    Join Date
    Nov 2012
    Posts
    15
    Quote Originally Posted by mherger View Post
    > A recipe for building (publishing?) an image is whatÂ’s needed.

    Exactly. Because all the political, philosophical and theoretical
    arguments won't take us anywhere :-D.
    But we have these recipes already.

    For someone who has a burning desire to make docker images on *nightly* releases automatically (because they are trying to run a redundant cluster of LMS servers that must be updated to nightly releases in unison, really!?) it would be pretty easy: fork my repo or one of the others, add your patch to turn off updates in the preferences, make a Docker hub account and add triggers to run a rebuild from LMS git commits. Job done.

  7. #107
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,422

    'Official' docker container for LMS?

    > But we have these recipes already.

    I'm still low in the learning curve. But last time I tried to use LMS
    inside Docker (I believe incl. your image), it didn't work for me. But
    that's probably been a year ago.

    I'd have quite a few questions wrt. to your image I'd be happy to
    discuss with you. And yes, I'd consider building images whenever builds
    are run. Just make them part of the build pipeline I already have to
    create the other builds. Because why not? :-). And because it would also
    allow us to not have to download 200MB of mostly unused binaries. If we
    settled for one linux base image, we'd know the binaries required for
    eg. x86_64 and aarch64, and could strip out all the rest.

    So, if I may:

    - locale: can this be defined based on the host system's locale instead
    of setting it in the dockerfile?

    - do I understand correctly that your image would run on "any" hardware
    platform that LMS and Docker support, because you pull in the full fat
    _all deb image?

    - you install a bunch of tools like espeak, faad, faac, ffmpeg etc.
    which either are not used by LMS, or come shipped with LMS. Why are they
    required?

    - you open up ports 9005, 9010 - what are they needed for?

    - would Spotty work inside such an image? I see that you forward 5353
    which might be part of what's required.

    - what about popular plugins like philippe_44's, which expose virtual
    player? Would they be working, because the helper would run inside the
    container (while talking to devices outside)? Or would they fail to eg.
    find speakers, because they're on a different network?

    - I left a comment on github about the MIP patch you apply. I'd be happy
    to merge it to LMS if you provided a PR.

    --

    Michael

  8. #108
    Quote Originally Posted by mherger View Post
    >I'd have quite a few questions wrt. to your image I'd be happy to
    discuss with you.
    I realise these were questions for justi, but some of the following may be useful:

    - locale: can this be defined based on the host system's locale instead
    of setting it in the dockerfile?
    The Docker image I'm using has the following in the accompanying docker-compose.yml file:
    Code:
        volumes:
          - /etc/localtime:/etc/localtime:ro
          - /etc/timezone:/etc/timezone:ro
    which seem to solve this problem quite well - if it's not clear, the host's copies of these files are mapped (read only) to the container.

    - would Spotty work inside such an image? I see that you forward 5353
    which might be part of what's required.
    I'm using Spotty and it works fine... but I'm not necessarily using the ideal configuration - see the next point.

    - what about popular plugins like philippe_44's, which expose virtual
    player? Would they be working, because the helper would run inside the
    container (while talking to devices outside)? Or would they fail to eg.
    find speakers, because they're on a different network?
    I spent some time trying to get Philippe's Shairtunes 2W plugin to work (not sure if this is the one you mean) and although it's working successfully, I am currently cheating by using the container in "host" networking mode (in other words, it shares the network stack with the host, rather than having its own bridged to the host's interface). This wasn't strictly necessary, but (after trying several potential workarounds with relatively complicated networking arrangements), it looked like I would have had to disable the host's mDNS server.

    The problem is that Shairport needs to advertise on mDNS. It does this by looking for some CLI tools used by popular mDNS systems and, if it doesn't find them (which it obviously can't in a container, even if they are present on the host), it starts its own server. Avahi, which is the mDNS daemon that comes with Raspbian (and probably many other distros), will share the mDNS port with other servers, but Docker needs to get exclusive use of a port to forward it to a container and this fails. From what you said about Spotty and port 5353, I assume this also needs access to mDNS, presumably for Spotify Connect. I can confirm that this works with the arrangement that I am using.

    Using host networking is not the end of the world, but it's not the recommended approach.
    Last edited by BobSammers; 2020-05-29 at 14:58.

  9. #109
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,422

    'Official' docker container for LMS?

    >> - would Spotty work inside such an image? I see that you forward 5353
    >> which might be part of what's required.
    >>

    > I'm using Spotty and it works fine... but I'm not necessarily using the
    > ideal configuration - see the next point.


    Is local discovery working? Eg. can any Spotify user in your network see
    SB players?

    > successfully, I am currently cheating by using the container in "host"
    > networking mode (in other words, it shares the network stack with the
    > host, rather than having its own bridged to the host's interface). This


    How is this cheating?

    > The problem is that Shairport needs to advertise on mDNS. It does this


    Spotty would try to do so, too. That's actually why I was asking these
    questions: I've had a few reports from Spotty users having problems
    running it inside docker.

    --

    Michael

  10. #110
    Senior Member
    Join Date
    Apr 2008
    Location
    Paris, France
    Posts
    2,241
    If you want broadcasts AFAIK there are 3 solutions w/ Docker:
    • "network=host". Exports all interfaces in the container, including some you might prefer not to be.
    • "network=none". Just lo in the container. Then with something like pipework (slightly obsolescent, but it's just a script, look at what it does; or look at this) pick an interface and export it to the network namespace of the running container. Has to be done on the host. The container has somehow to wait until an interface shows up.
    • Your own network. A Docker named bridge could be a good start. From the host you can add interfaces to the bridge. Docker provides its own name resolution and IP address distribution so to coexist w/ regular DHCP and DNS services some extra launch parameters for the container (and bridge definition) would be required.

    AFAIK in other modes Docker uses either NAT/filtering heavily, or with network plugins it does stupid tricks w/ IP or MAC addresses that break LMS discovery. (Problems become apparent with either 2 containers or 2 hosts running one container.) Last time I looked at it closely was when CE v. 18 was released.
    Last edited by epoch1970; Yesterday at 01:19.
    2 SB 3 • 1 PCP 6 • Libratone Loop, Zipp, Zipp Mini • iPeng (iPhone + iPad) • LMS 7.9 (linux) with plugins: CD Player, WaveInput, Triode's BBC iPlayer by bpa • IRBlaster by Gwendesign (Felix) • Smart Mix, Music Walk With Me, What Was That Tune? by Michael Herger • PowerSave by Jason Holtzapple • Song Info, Song Lyrics by Erland Isaksson • AirPlay Bridge by philippe_44 • WeatherTime by Martin Rehfeld • Auto Dim Display, SaverSwitcher, ContextMenu by Peter Watkins.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •