Moving to Docker

[akbooer]

@rhcpng

Thanks for that. I guess my question is why these have to be done separately, rather than just making cmh-ludl/ (and all its sub folders) external (which, effectively is what I’ve done for WSL.)

I was trying to do it on the command line, since Portainer seemed to be several hundreds of megabytes, which seemed a bit of overkill just for this task (which, I think, is all I need it for.)

[RHCPNG]

You mean not splitting it up in backup, log and cmh-ludl? That's a choice of vwout. To be able to be flexible with what you store where, probably. You can do it with the command line too, but I'm not familiar with that. I don't think you have to do all mappings. Probably the cmh-ludl is enough, but I'm not sure.

[mrFarmer]

@akbooer Well, if I have a complete openLuup setup, except my data, in a Docker and I need to rebuild a system from scratch I can just run a script, restore my data and be back up and running. Creating a complete new system from scratch takes a lot more. Especially if you need to do Grafana, DB, webserver, ... All the packages I need to install again (i never document that well for the next time) etc.

[akbooer]

@mrfarmer

Ah, I see. More of a backup, than anything else, then.

[mrFarmer]

@akbooer a quick restore from a fatal crash of the Pi (SD/SSD) yes.

[vwout]

@akbooer As @RHCPNG said, you can easily do this, once you have a running setup by copying the contents of /etc/cmh-ludl/ to a local folder, restart the container with that folder mounted to /etc/cmh-ludl/.

The difference between using a volume and a folder mount is (amongst other details) how Docker handles this at first startup. When using a volume, Docker copies the contents of e.g. /etc/cmh-ludl/ when it is started with a empty new volume, to that volume. As of that moment all changes are kept in the volume and survive container restarts and updates.
A mounted folder also preserves all settings, but in contrary to volumes, Docker does not copy the original contents of the mount target to the folder at first startup. This means you need to store create the files needed in /etc/cmh-ludl/ yourself, which makes it harder to initially get start (except for one who masters openLuup ).

[PerH]

I thought i'd give this a stab, as i have some dependency issues.. Found an old laptop and installed Debian to test with.

I want the following apps to run on the machine:
openLuup
Z-Way
Domoticz
InfluxDB
Grafana
Miio Server (stupid implementation of domo plugin for my vacuum)

Any reason not to just have one docker each? They all use TCP/UDP for all communication (i use ser2net for usb ports)..

I've had to install python on the domoticz image i have, and therefore saved a new image. Where is this image stored?

[PerH]

@vwout: There is a choice between Debian and Alpine in your image, why? is there advatages to one or the other? If its just interface/packages in the container there wouldn't be a difference if you're not doing changes to it right? (which ideally is not nessecary)

[RHCPNG]

@perh I think the main point of dockers is to put every service in it's own docker. This way it is easier to manage with as less dependence as possible.

[akbooer]

@perh said in Moving to Docker:

There is a choice between Debian and Alpine in your image, why?

The Alpine image is somewhat smaller. It comes with a more limited set of Linux installed utilities, but who cares about that in the openLuup environment?

[PerH]

As long as it works..

New question: I've set up two containers (domoticz and miio server), and by default - they are on the same network. This network will however give the containers an IP at startup, and it seems to be first come - first served. Is there a way to give them static IP's in this internal docker network?
I tried docker run --IP=<IP> without success..

The plugin in Domo reaches miio server with that IP, so i need it to be the same after restarts!

[akbooer]

OK, now I have a problem.

It was all going so well until I realised that all incoming IP addresses were being mapped to 172.17.0.1by the LuaSocket library.

Reading the Docker docs: https://docs.docker.com/config/containers/container-networking/

"By default, the container is assigned an IP address for every Docker network it connects to. The IP address is assigned from the pool assigned to the network, so the Docker daemon effectively acts as a DHCP server for each container. Each network also has a default subnet mask and gateway."

But I don't understand, yet, how this works if I want a straight-forward mapping of IPs from my LAN into the Docker container.

It may be that the Synology Docker interface is not adequate for this and I have to revert to the command line?

Any advice/clarification much appreciated.

[PerH]

ok, i got the IP stuff figured. A custom network must be made in order to choose IP, then connect the container.

sudo docker network create -d bridge --subnet=192.168.0.0/16 --ip-range=192.168.0.0/24 --gateway=192.168.0.254 <Network name>
sudo docker network connect --ip=<IP> <Network created by you> <container name>
sudo docker network disconnect bridge <container name>

Still struggling with getting openluup to work as i want it.. tried to copy the cmh-ludl folder from my prod. system to the _data folder for my volume, but can't seem to overwrite user_data.json..

Tried to bind to a folder instead, but then it won't start, as the folder is missing the "openLuup_reload_for_docker" file..

what do i do next?

[akbooer]

@perh said in Moving to Docker:

but can't seem to overwrite user_data.json.

You can't do this when the system is running, because it gets overwritten with the current system state on restarts. Stop openLuup with a /data_request?id=exit request, change the file, then stop and restart the container (to restart openLuup.)

[PerH]

offcourse.. its getting late! thanks.

[PerH]

My plan for USB devices was to have ser2net on host for all usb's, and then bind the dockers to the ser2net ports for the devices. If however ser2net is sending on ie. port 3485, the docker can't bind to that port.

How can I do this?

[PerH]

Solution: Don't bind the port at all in the docker, and call the IP of the host in the application running inside container..

EDIT: Or even better, use the "gateway" IP in the internal docker network, this way its easier to move the whole setup to hardware with a different IP address without editing this attribute.

[LibraSun]

For funsies, I decided to hop on board with OpenLuup by running @vwout 's pre-built container (excellent piece of work, by the way, sir!) on my Synology NAS using Docker's wizards.

It took some convincing by others more experienced than myself (both with OpenLuup and Docker), NOT to change anything in the Synology NAS GUI before simply LAUNCH-ing the Image. The only thing I set manually were the ports - changing from 'Auto' to numbers matching those in the right column under Advanced Settings > Ports, then clicking "Apply".

From within DiskStation on your Synology NAS:

1. Open Docker (install from Package Center if not installed)
2. Registry > search for "OpenLuup" > select 'vwout / openluup' (alpine)
3. Click Download.
4. Images > select 'vwout / openluup' > click Launch.
5. On Advanced Settings tab > 'Advanced Settings' > check 'Enable auto-restart'
6. On Ports tab:
   • Change each port from "Auto" to match right-hand #.
7. On Environment tab:
   • Change (if desired) the 'Value' field next to TZ, from 'UTC' to your time zone (e.g. GMT-5)
8. Click Apply

Your new OpenLuup container will now start.

Head over to http://<nas_ip>:3480/console for some fun with OpenLuup!

BONUS: For step-by-step instructions on linking your Vera(s) to OpenLuup, see this reply below.

THANKS!

[akbooer]

My first foray into Docker was with this image, on Synology NAS, but I didn’t mount external volumes. It’s worked flawlessly, which is just as well because I know very little about Docker, although I’m learning a bit because I’m creating my own version from a raw Alpine base.

So I’ve not seen this issue, ever... which doesn’t really help you at all, except to know that it can work.

[toggledbits]

On the NAS, open Docker, then click on the container in the Container list, then click the Details button. A dialog will pop up which has a "Log" tab, and there you will find the console output of the container, which could have some messages related to the stop that will help you troubleshoot.