Improve Docker setup

[ebekebe]

I would like to suggest a couple of improvements with this PR:

• use alpine base image to reduce size and add armv6l architecture for pi zero
• add example docker-compose.yml
• bake rpi.gpio dependency into docker image

This PR is based on my own requirements, which are

• must run on Raspberry Pi Zero with armv6l architecture
• will be managed via docker-compose
• the pi doesn't not have internet access, so it cannot install the rpi.gpio dependency on first startup

My experience with Python is very limited, so please forgive my crude attempt here. I saw #55 and figured alpine support is something that is wanted, so here is a draft.
I hope there is a better way to add the rpi.gpio and other optional dependencies in the Dockerfile. I would love a Docker image that has optional dependencies pre-installed, so I can be sure it works everywhere where I can pull the image. Maybe we could invoke a script in the Dockerfile that pulls all the optional dependencies?

Additionally I created a multi-architecture image and pushed it temporily to ebekebe/mqtt-gpio:latest.
It should support (I only tested arm/v6):

• linux/amd64
• linux/arm64
• linux/arm/v6
• linux/arm/v7

I would love to see such multi-architecture builds for flyte/mqtt-gpio, too, so I don't have to select the appropriate tag manually.

The PR is a draft, because for example I added rpi.gpio to the Pipfile, which I expect to be solved in another way. However, I cannot do this myself, since I lack the expertise with this project and the Python ecosystem.

[flyte]

Hey, thanks for the input! I haven't spent a lot of time on the Docker side of this project and some of your ideas sound like good ones!

The issue of installing requirements before runtime is an interesting one. I'm not sure Tags for preinstalled dependencies is the way to go, since there can be so many permutations, and potentially conflicts. I wonder if we could just include a way of reading the config file and installing the required deps as part of a second stage docker image build. Then a custom image for that config can be made for each individual installation that wouldn't require an Internet connection.

Including RPi.GPIO in the main requirements is a no-go since (despite the project's current title) we're not actually tied to Raspberry Pi.

Ill certainly look at multi arch builds, and the work you've done to support them.

Does your Pi Zero have a network connection at all? Interested to know what use this project is without that!

[ebekebe]

The issue of installing requirements before runtime is an interesting one. I'm not sure Tags for preinstalled dependencies is the way to go, since there can be so many permutations, and potentially conflicts. I wonder if we could just include a way of reading the config file and installing the required deps as part of a second stage docker image build. Then a custom image for that config can be made for each individual installation that wouldn't require an Internet connection.

That would certainly be a welcome improvement.

Including RPi.GPIO in the main requirements is a no-go since (despite the project's current title) we're not actually tied to Raspberry Pi.

Interesting, I didn't know that. I think if there is a large enough user group it could be worthwhile creating a separate tag that includes RPi.GPIO. It would have made at least my live easier.

Ill certainly look at multi arch builds, and the work you've done to support them.

Great!

Does your Pi Zero have a network connection at all? Interested to know what use this project is without that!

It is actually a Pi Zero W that has Wifi on board. I use it to control a relay board for home automation. It sits in an isolated VLAN and can only talk to the MQTT server.

[flyte]

Is there a reason you've added this to the main requirements file? It should get installed at run-time, since this software (despite its name) is not specific to the Raspberry Pi. Is this not happening for you?

[ebekebe]

@flyte You are right that it should get installed automatically. As mentioned above, I put it here mainly, because the pi I am running this on doesn't have internet access.

The second reason is that I personally consider pulling requirements into docker containers at runtime is an anti-pattern. These dependencies are not part of the image and cannot be audited by conventional static analysis for docker images. They also require the servers that provide the dependency to be highly available or one would risk that a fresh container cannot start. There are other reasons why in general Docker images should not pull dependencies at runtime. For example they won't play nicely in Kubernetes, but I don't think someone wants to create a HA Kubernetes cluster to run mqtt-gpio 😉.

As a compromise you suggested already that you could provide a CLI option to just install the dependencies for a specific config, so I could easily generate my own Docker image without knowing the internals of this project.

[flyte]

Oh sorry, I sometimes lose track of who I spoke to about what!

Yeah, the CLI option would be best. I'll update this ticket once I've got around to doing something like that, but I've also got a few other bits in the pipeline that I'm working on for this project, so I'll have to add it to the list.

[BenjiU]

Hi @ebekebe,

I'll close this PR, as it is over 4 years old and a lot changed already for the docker setup.

Thanks!
Benni