Shairport-sync: Upstreaming containerized Shairport Sync for Docker

[rgov]

Docker provides an easy way to deploy Shairport Sync without needing to compile it yourself. The container takes only a few megabytes, and can be published for multiple architectures including ARM, making it appropriate for deployment on platforms such as the Raspberry Pi.

Currently, there are over 30 published third-party images on Docker Hub: https://hub.docker.com/search?q=shairport-sync&type=image

The most popular, by @kevineye, has over 1M downloads, demonstrating the popularity of this distribution method. But it has not been updated in 2 years.

I have worked with @Rohmilchkaese to create a GitHub Actions workflow that automatically builds and publishes a multi-architecture Docker image on every commit and tagged release.

I'd like to discuss the possibility of upstreaming this work and creating an official mikebrady/shairport-sync or shairport-sync/shairport-sync image repo on Docker Hub where up-to-date images can be published. This way, Docker users can have confidence that they are getting an officially-built image, and don't have to worry about the maintainer losing interest and stopping updates.

[kevineye]

I'd be happy to redirect users to your image @rgov, or even happier to redirect to an official build. I honestly don't know how my shairport-sync docker image became the most popular one. I guess it was one of the first.

[mikebrady]

Thanks for this very interesting post. It looks like a good idea alright. I don't really know too much about Docker, so your assistance and guidance would be very important. Also, with the current situation, I'm rather busy at work. So let me play around with Docker over the next few days, so at least I might have a vocabulary, and then let's see what we can achieve together.

[rgov]

@mikebrady Sounds good, let me know if I can help.

Here is the Docker Hub page for the image we worked on: rohmilkaese/shairport-sync

Basic instructions: Install Docker on a Linux host, create a directory containing a shairport.conf file, and from within it run:

docker run \
    -v $PWD:/conf/ \
    --net host \
    --device /dev/snd \
    --name shairport-sync \
    rohmilkaese/shairport-sync \
        -vu -c /conf/shairport.conf

This will automatically download a built copy of Shairport Sync (only ~7 MB) and start it.

Hypothetically speaking if we had tagged releases you could write rohmilkaese/shairport-sync:3.3.6 to get a particular version.

This could also work on macOS hosts but it is a little more complicated, requiring installing a pulseaudio server (see here). I've read sound output from Docker doesn't yet work on Windows.

[mikebrady]

Great, thanks for this. I'm behind in my attention to this, I'm afraid...

[rgov]

One question for others who know more about Linux audio—it is enough to mount /dev/snd or do we also need to mount the ALSA config file?

[bedrin]

rohmilkaese/shairport-sync works great. Would be great to have it as an official image

[mikebrady]

One question for others who know more about Linux audio—it is enough to mount /dev/snd or do we also need to mount the ALSA config file?

Sorry, a bit late – still learning about Docker... By default, Shairport Sync will look for the "default" output device and this is determined by the content of the ALSA config file. However, it is usually better to specify the output device (and mixer, if available) directly to Shairport Sync, in which case the ALSA config file is not used.

[orbsmiv]

I'm happy to contribute to this too – I've been maintaining an Arm version of _shairport-sync_ for Docker (originally forked from @kevineye's) since 2017, and was auto-building with Jenkins but have recently moved everything to GitHub Actions. (Currently it has around 180k pulls so not as popular as @kevineye's!)

A couple of adjustments I made to the original Dockerfile:

• Utilises multi-stage builds, compiling in one and then pulling the binaries etc. into a runtime image for distribution. This is now the recommended method for obtaining smaller images, rather than stringing together a single RUN command.
• Compiles with some of the newer features, e.g. MQTT support.
• Drops privileges for running the actual shairport-sync executable. (This has to be done in the entrypoint file as dbus needs starting as root. I've been working on a version without dbus/Avahi, using _tinysvcmdns_, but have been running into odd mdns issues and haven't had time to look at them in detail.)

[mikebrady]

Thanks. I'm making very slow progress on this, but am interested. Hopefully in the next week or so, I might be able to ask sensible questions and help out.

[mikebrady]

Hi everyone -- @rgov, @kevineye, @orbsmiv, @bedrin. Many thanks for all your suggestions, encouragement and offers of support. I have to admit that I had to educate myself on Docker, and I'm still a long way back.

Anyhow, I have been able to upload a multi-architecture shairport-sync container at https://hub.docker.com/r/mikebrady/shairport-sync. I'm still experimenting with the content of the image and with the Dockerfile build instructions, which are at https://github.com/mikebrady/shairport-sync-docker.

The build is done "manually", so to speak. (I left out the 386 architecture by mistake -- I'll correct it soon.)

It turns out, if I'm not wrong, that Docker Hub autobuild does not easily support multiple architectures, so @rgov's offer to share the Github Actions would be welcome at this stage -- I might be able to make sense of it :)

[rgov]

Awesome! Thanks for finding the time.

This is the GitHub Actions workflow: https://github.com/Rohmilchkaese/shairport-sync/blob/master/.github/workflows/docker.yml

Unfortunately the Docker tooling has a number of shortcomings, and it's a little complex to cross-compile for multiple architectures. You need to use a subcommand called docker buildx build in two stages (build and push) with the same arguments.

[mikebrady]

This is the GitHub Actions workflow: https://github.com/Rohmilchkaese/shairport-sync/blob/master/.github/workflows/docker.yml

Thank you so much, @rgov, for the workflow! I've been experimenting with it on a small project, trying to get a better understanding of it before I switch over to Shairport Sync.

[mikebrady]

Finally, I have embedded the workflow into the Shairport Sync repository and set up a Docker Hub repository. It seems to be working well. I think the workflow will be inactive in any cloned copies of the repository. Suggestions / comments welcome. For example, is it better to keep the workflow in a separate repository? (Maybe it is...)

[rgov]

Switched my Raspberry Pi over to mikebrady/shairport-sync:latest and it seems to be working.

One thing I encountered was that I started the container before I turned on the speakers, and it didn't like that. Had to restart the container for it to be able to see the configured hw:1.

[rgov]

@mikebrady I noticed that the GitHub workflow is no longer enabled (per 8e46117c7cfe3c1fb97661b883b28786f8a46a6a). What was your experience?