Author Topic: openLuup on Docker (Hub)  (Read 1297 times)

Offline Stuart

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 728
  • Karma: +71/-2
Re: openLuup on Docker (Hub)
« Reply #15 on: October 06, 2018, 02:23:16 pm »
So - we are on the right track, this from the official openluup documentation

Quote
openLuup also maintains another log, which is a subset of the main one, and contains only device variable changes, scene invocations, and workflow messages. Those entries are written to a log file, if the /var/cmh/ directory exists, in /var/cmh/LuaUPnP.log,

One other thing that would likely be helpful:  set up /etc/cmh-ludl as a docker volume so that updates to the image do not over write that directory (there may be others ...)  or instructions on how to copy from that directory to a folder on the host and then mount the host directory to the image (I can do that tomorrow).  I kinda prefer the later since it will survive an accidental docker reset.


Offline vwout

  • Beta Testers
  • Newbie
  • *****
  • Posts: 12
  • Karma: +6/-0
Re: openLuup on Docker (Hub)
« Reply #16 on: October 06, 2018, 03:08:41 pm »
Not yet sure how to get to the vera logs from here  :o

Well, there is no Vera in scope of the openLuup container. openLuup could be linked to your Vera, but the Vera logs won't be in the container on /var/log/cmh, but on your Vera. To access them from altUI running on openLuup that is on another box, you need to mount the folders from your vera. sshfs could be an option there.


So - we are on the right track, this from the official openluup documentation

Quote
openLuup also maintains another log, which is a subset of the main one, and contains only device variable changes, scene invocations, and workflow messages. Those entries are written to a log file, if the /var/cmh/ directory exists, in /var/cmh/LuaUPnP.log,
I can add the volume /var/cmh to have the Vera-like openLuup logs. Since you already have the full log, this may not add much other than the fact the removing information makes the remain stand out more, which could be usefull.

One other thing that would likely be helpful:  set up /etc/cmh-ludl as a docker volume so that updates to the image do not over write that directory (there may be others ...)  or instructions on how to copy from that directory to a folder on the host and then mount the host directory to the image (I can do that tomorrow).  I kinda prefer the later since it will survive an accidental docker reset.

This is something I discussed with akbooer in the prelude to publishing the image, see https://github.com/akbooer/openLuup/pull/13. Detaching openLuup from the image could reduce the image to basically a lua image with some plugins. The directory /var/cmh-ludl is a volume already. It means that docker creates the volume when the image is started first time, Docker will copy the contents of the folder to the newly created volume in that case. Using a pre-created (e.g. named) volume won't work, since it will remain empty.
« Last Edit: October 06, 2018, 03:49:20 pm by vwout »

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 6343
  • Karma: +288/-70
  • "Less is more"
Re: openLuup on Docker (Hub)
« Reply #17 on: October 06, 2018, 06:27:46 pm »
FWIW, I generally add a sym link from /var/log/cmh to /etc/cmh-ludl/logs, and then the AltUI tail logs command works as is.
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P, 9x Philips Hue,
Razberry, MySensors Arduino, HomeWave, AltUI, AltHue, DataYours, Grafana, openLuup, ZWay, ZeroBrane Studio.

Offline vwout

  • Beta Testers
  • Newbie
  • *****
  • Posts: 12
  • Karma: +6/-0
Re: openLuup on Docker (Hub)
« Reply #18 on: October 07, 2018, 08:50:55 am »
The images at vwout/openluup on Docker Hub are updated.

I applied the following changes:
- Providing /var/log/cmh Vera-style log folder (symlinked to openLuup logs)
- Debian based image: New tag (next to latest): 'slim'
- Alpine based image: Enable timezone configuration via TZ environment variable
- Update to compose-file

Offline Stuart

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 728
  • Karma: +71/-2
Re: openLuup on Docker (Hub)
« Reply #19 on: October 08, 2018, 08:03:58 pm »
Looking very good !

I was getting errors from the Alpine version, basically complaining about syntax errors.  I did not check the debian version.

I believe the error is in  the file  openLuup_reload_for_docker   Specifically the line

Code: [Select]
function openLuupShutdown {

should be

Code: [Select]
openLuupShutdown(){

at least when I make that change, all seems well  :o
« Last Edit: October 08, 2018, 08:06:12 pm by Stuart »

Offline vwout

  • Beta Testers
  • Newbie
  • *****
  • Posts: 12
  • Karma: +6/-0
Re: openLuup on Docker (Hub)
« Reply #20 on: October 09, 2018, 04:11:16 pm »
When/how did you get any errors? I can't reproduce them.

I did notice that the shutdown script does not work how it should ... it no longer prints to log to stdout for tracing by `docker logs`

Offline Stuart

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 728
  • Karma: +71/-2
Re: openLuup on Docker (Hub)
« Reply #21 on: October 09, 2018, 04:45:18 pm »
The errors occurred when I tried to start a new container or restart with different runtime parameters.  Cannot remember exactly.  I was grinding through and not paying as much attention as I should.  I mostly use a docker-compose file to create the container.  It's possible that I fat fingered something procedurally and 'fixed' something that did not need fixing.

I can go back and try again with the original syntax later tonight / tomorrow and see if I can reproduce.   The error message was something about unexpected } -- and mentioned the file openLuup_reload_for_docker so that's what led me to suspect the syntax on the function definition.

One other thing - and I need to dig a little more:  the volume declarations in the Dockerfile .....     My understanding (could easily be flawed) is that they end up being created at container creation time with a random named (for the volume).  But what happens if you later delete the container and create a new one - do not these volumes get recreated?  If that's the case the date (from the previous container ) would not carry over to the new one.   So I'm thinking it may be better to create named volumes the docker run command, or mount bind to folders on the host.  Thoughts?

Offline vwout

  • Beta Testers
  • Newbie
  • *****
  • Posts: 12
  • Karma: +6/-0
Re: openLuup on Docker (Hub)
« Reply #22 on: October 09, 2018, 05:39:06 pm »
Nevermind, I linted the script(s) and they had errors anyhow. No curly braces though.

Your understanding of volumes is more or less correct. Volumes are created automatically by Docker when the container starts - at least for the volumes specified in the Dockerfile, unless a mount or bind is specified for the volume. This is a so called unnamed volume. The volumes however are not deleted when the container is removed.
So your data will be preserved. Just hard to find.

Thing is that the volumes that are created by Docker at startup of a container, are unnamed, so hard to recognize. You can, as I do in the composefile (or using `docker volume create`) manually create a named volume to mount with a container. The difference is that Docker only copies the data from the image to the volume in case of creation of an unnamed volume. When you bind or mount a volume, Docker does not do this.
At least, that was the case. Apparently, recently Docker changed. It also copies data to a newly created empty volume.

And that is what the composefile is using. It creates empty volumes for ludl (/etc/cmh-ludl/), logs and backups. At startup, the contents of the openLuup image is copied into the ludl volume. As long as this volume is used with a container, the data should be preserved. Updating openLuup in that case should happen via the auto-update feature of openLuup itself, not by installing a new image. A new image is only required to get environment bufixes and security updates.


Offline Stuart

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 728
  • Karma: +71/-2
Re: openLuup on Docker (Hub)
« Reply #23 on: October 09, 2018, 05:45:16 pm »
Nevermind, I linted the script(s) and they had errors anyhow. No curly braces though.

The script openLuup_reload_for_docker had curly braces in the function declaration.  Are we talking at cross purposes ?

Quote
You can, as I do in the composefile (or using `docker volume create`) manually create a named volume to mount with a container.

I was not using your compose file -- so I best go take another look !

Again - thanks for taking this on and doing such a great job !!!!

Offline vwout

  • Beta Testers
  • Newbie
  • *****
  • Posts: 12
  • Karma: +6/-0
Re: openLuup on Docker (Hub)
« Reply #24 on: October 10, 2018, 03:01:23 pm »
Are we talking at cross purposes ?
I meant to say that the linter did not complain about curly braces, but that there were a few other issues. One of which was the use of the keyword 'function', which apparently is allowed in bash, but not in sh.

Offline parkerc

  • Beta Testers
  • Sr. Hero Member
  • *****
  • Posts: 2474
  • Karma: +35/-48
  • Life Moves Pretty Fast....
Re: openLuup on Docker (Hub)
« Reply #25 on: October 20, 2018, 03:10:18 am »
Hi @vwout

Looking at your username it?s clear which one is yours,  but it was interesting to see other Docker options for openluup listed too.

slightlyaskew/openluup
DOCKER - openLuup Container

vwout/openluup
DOCKER - Automated Build Ready to use openLuup environment with AltUI based on Debian with mountpoints for custom plugins.

airedale/openluup
DOCKER

Offline parkerc

  • Beta Testers
  • Sr. Hero Member
  • *****
  • Posts: 2474
  • Karma: +35/-48
  • Life Moves Pretty Fast....
Re: openLuup on Docker (Hub)
« Reply #26 on: October 20, 2018, 03:15:33 am »
I'm going to use Container Station on my QNAP NAS to install the Docker image, I believe the approach will be similar to Synology's Container Station too ?

Are there any specific commands I should look to enter when creating the Openluup container?
« Last Edit: October 20, 2018, 03:21:35 am by parkerc »

Offline vwout

  • Beta Testers
  • Newbie
  • *****
  • Posts: 12
  • Karma: +6/-0
Re: openLuup on Docker (Hub)
« Reply #27 on: October 21, 2018, 05:40:12 pm »
Looking at your username it?s clear which one is yours,  but it was interesting to see other Docker options for openluup listed too.
Yep :) I decided to roll my own image since the others are big, undocumented and not updated recently.

Are there any specific commands I should look to enter when creating the Openluup container?

The image is usable without any particular configuration, though you do want to map at last the exposed port 3480 to be able to access AltUI.
I don't see this being configured in the screenshots. Maybe it is automatic on Qnap (I don't own one), but you might want to check this in the advanced settings. The container does not have any other configuration that you must set. And I think you can reduce the amount of memory. OpenLuup does not need 8GB :)

There should not be that much difference between using it on any Docker host. The only thing is that to use persistent data stores for openLuup, logs and backups, you probably have to use the command line, just like on Synology. Qnap also does not seem to offer the use of named mounts via their UI.

Offline RHCPNG

  • Full Member
  • ***
  • Posts: 191
  • Karma: +6/-0
Migrate openluup to docker
« Reply #28 on: December 29, 2018, 10:14:12 am »
Hi guys,

I'm running openluup in vbox now and want to migrate to docker, because of some strange behavior in openluup/AltUI. What is the easiest way to restore my setup in the docker container?

I don't want to copy all files, because then I will probably have the same issues? The issue seems related to AltUI.

I know I need the user_data.json of course, but that is probably not enough.

Any suggestions?

Offline vwout

  • Beta Testers
  • Newbie
  • *****
  • Posts: 12
  • Karma: +6/-0
Re: openLuup on Docker (Hub)
« Reply #29 on: January 03, 2019, 02:56:18 pm »
Most likely reason for strange behavior is a rogue plugin. Do you have plugins installed?

Migrating configuration is the easy part, your dependency on plugins is the complicating part here since there is no way to automatically install plugins.
When you have the user_data.json, you can provide this to docker when you start the container for the first time, see the documentation on https://github.com/vwout/docker-openluup, or in the docker-compose file at https://github.com/vwout/docker-openluup/blob/master/docker-compose.yml.
Openluup will import the data provided by the user_data.json as specified in the environment variable USER_DATA_JSON into its configuration. Any functionality depending on plugins won't work until the plugins are installed.

I don't know whether configuration related to not available plugins will survive, or when the configuration is kept when plugins are installed. This will require some experimentation.
If you know which plugins you need and which files are related to these plugins, you can try exporting these from vbox and storing them in a directory. Bind this directory as /etc/cmh-lu/ and openluup will load the plugins right from the start.

The good news is that you can try as many times as you want. As long as you keep your vbox configuration as is, you can recreate the openluup container as many times as you want.
I would recommend using a volume for at last the openluup environment, that is /etc/cmh-ludl/.