clewsy
A work-in-progress
Here are some projects that are not mine, but have accepted contributions I have suggested. This is what I love about the open source community. :)
| Project | Contribution | Pull Request |
|---|---|---|
| nextcloud-cronjob | Decrease container image size by 75%. | apk add docker-cli instead of docker. #4 |
| addon-motioneye | Add ability to implement motioneye action buttons. | :sparkles: Add action buttons #75 |
Nextcloud is a fantastic tool. My self-hosted delpoyment of Nextcloud is implemented with a Docker container image.
A Nexcloud installation requires a cronjob to execute a php script "cron.php". The script is needed to run any background tasks for installed Nextcloud apps. For a containerised version of Nextcloud, there are a few possible methods for the routine execution of cron.php.
The method I went with was another container image called "nextcloud-cronjob" (dockerhub link) created by Robert Dailey. I liked this solution mostly becuse I understood how it worked at a time when I was just beginning to learn about Docker. It also has the benefit of not requiring the Nextcloud container to be run by the root user.
I used the nextcloud-cronjob source dockerfile as a starting-point when I wanted to learn how to create my own docker image for ncbu. My project had similar requirements - run a command at defined intervals, and access other containers.
After getting ncbu working, I began investigating techniques to improve the efficiency by reducing both the image size and the build time. Initially my ncbu dockerfile would install the "docker" package to facilitate accessing other docker containers via scripted "docker exec" commands. I learned that instead of installing the docker package and all its dependencies, all I needed was one of said dependencies - a package called "docker-cli" which provides the "docker exec" capability. This change reduced the size of the ncbu image by over 200MB.
After this revelation and improvement, I decided to fork nextcloud-cronjob and test the same change for that image. It appeared to work with no issues so I submitted the pull-request. After some discussion with rcdailey, the simple commit was accepted and the PR merged which reduced the nextcloud-cronjob image size from 324BM to 83MB (~75% reduction).
At home I use a few IP cameras, mostly for remotely monitoring animals. I have a combination of proprietary dedicated IP cams (stock and modified) and raspberry pis with either a pi-cam or a usb web-cam.
After trialing a few options, I settled on motioneye as my preferred method of wrangling all of the camera feeds into a single interface.
A useful feature of motioneye is the ability to create "action buttons". Once configured, action buttons take the form of icons overlayed on the camera video feed. When pressed, they can execute arbitrary scripts. Some examples of my use-cases include:
For a while I used motioneye installed on a dedicated raspberry pi. Later though, I began experimenting with Home Assistant with the intention to integrate some services and automations I had scattered across multiple machines/devices.
A feature of Home Assistant is the ability to install "Add-ons" - both official and community developed - which effectively install containerised versions of independently available applications. Motioneye is available as one such add-on.
Rather than run Home Assistant and motioneye on separate boxes, I decided to migrate my motioneye configuration into the containerised Home Assistant add-on version.
This worked well in every way except one; I lost the ability to implement action buttons. For action buttons to work, specifically named script files must be stored within a specific directory of the motioneye host. This isn't possible for a Home Assistant add-on containerised image since the scripts are user-specific. A more traditional container would allow you to bind the action button scripts directory so that they remain persistent even after rebuilding the container. However, binding arbitrary directories isn't practical for the standardised Home Assistant add-on format.
After some initial conversation via an issue raised on GitHub and suggestions made by the maintainer Franck Nijhof, I forked addon-motioneye to experiment and see if I could add the ability to implement action buttons.
The solution was to define the action button names and script commands within the existing add-on configuration yaml file via the Home Assistant interface. Modifications to the motioneye initialisation cause it to generate the action button script files when the container is started.
I also updated the add-on documentation with a section explaining to users how to configure the add-on to make use of action buttons.
After some testing and incorporating feedback from frenck, the pull request was merged and the commits incorporated into the next addon-motioneye release.
