Moving to Docker

[akbooer]

@toggledbits said in Moving to Docker:

if the openLuup filesystem is all on a separate volume, is the benefit to what remains worth building and maintaining a container distribution? Seems like the container wouldn't really contain much.

Well, that's exactly right. Just the Lua and necessary libraries, if my (limited) understanding is correct.

@rafale77 said in Moving to Docker:

if you need to update the z-way version or run some security updates to the libraries in it... not so easy.

I wouldn't dream of trying to do that. Whilst my openLuup system would have the ZWay plugin, it wouldn't contain Zwave.me software and it wouldn't be directly connected to the hardware, either.

@toggledbits said in Moving to Docker:

as more people try to use the product coming from Vera, few are Linux administration experts, so getting the product up and running with as few clicks (or keystrokes) as possible is definitely a benefit.

Exactly the point (and indeed I'm no Linux expert.) The container which @vwout has made appears to satisfy this condition.

@toggledbits said in Moving to Docker:

All I would ask is that it not be constrained in that way

To be clear, I'm not proposing to change anything in terms of openLuup. I simply want to decommission some old hardware and consolidate my IT architecture.

[vwout]

Hi all, @akbooer asked me to join this community - so far I was only active on MCV. I am the author of the Docker image for openluup that is referred to in this thread.

I quickly read the complete thread. Most of the comments contain valid statements.
Personally I would not avoid containers as the pest - in fact, you can't ;). Containers exist for a long long time (at least in the Linux kernel) and play an important role for isolation of processes/networks/filesystems. Docker has made this system significantly easier to use and understand. By now also Windows supports containers and (in the latest builds even without HyperV virtualization) can even run Linux containers. This begins to fade the most significant difference between VMs and containers away, this being virtualization (for VMs) versus isolation (containers). Opposed to VMs, containers are very lightweight (try creating a VM that runs openLuup in under 7MB :D). A container does not contain a kernel and does not have an operating system. It also cannot run on itself.

Maybe some of you experienced the 'dll hell' - the issue where the installation of an application breaks another application, because one overwrites a shared library of the other. This is what you can prevent by packaging applications and one of the reasons for things like snap, flatpack and docker to emerge.

So as @toggledbits mentioned, a (well written) container indeed does not contain much. A docker container basically provides the 'batteries included' concept. This makes it very easy to get started with a new application like openLuup. In order to get the same experience with a VM, you'd need a pre-build image, or an automation system like Ansible, Puppet or Chef - tools that not every newbee is likely to master.

There is no general 'better' when it comes to VMs verses contains and in many cases both are used, each for their own specific benefits, one of which is personal preference.
When you, like @akbooer, want to consolidate your setup on a not highly powerfull NAS, a container is the way to go.

[akbooer]

Very pleased that you could join us...

...I hope you find this place more than just another sink of your valuable time! (Let's face it, there are probably enough forums around.)

A number here found their interests diverging from the discussions in the other place, as it abandons Vera and struggles, in much the same old way, with new hardware and firmware. We're not just about openLuup as a replacement for Vera – so much more, in fact, and there are advocates of a number of alternatives, and hybrid systems.

I, for one, will value any contribution you can make here.. not least because I really want to get openLuup on Docker up and running

I've loaded the Docker app, and your (alpine) image, for a start. Somewhat at a loss of what to do next, but I need to read the documentation thoroughly.

Anyway, welcome again.

[rafale77]

Just excited to have a new valuable member and a new option to install openLuup so that more can use and contribute.
As long as it doesn't become the only way. I was just sharing my experience on containers. Indeed it has its use case, a great way to start. It's not for everyone and like anything, should not be abused...

[RHCPNG]

I'm using the docker of vwout for a while now. I've asked for several additions to the docker and vwout has been very helpful. I think a docker container is ideal for me. Problem solving is easier, because the different applications are containerized. It's easy to start an additional dev/test environment and needs fewer resources than a complete VM. Updating is also easier, when the docker is maintained actively of course.

But of course, everyone has to decide what works best for him/her. Dockers are here to stay, that's for sure. I think you're going to like it, @akbooer .

Thanks for the docker again, @vwout! Great support. I have had no problems with it.

[akbooer]

@rhcpng

Ooh, super – another Docker expert.

I'm really stuck. I think that there's a vital piece of documentation that I haven't found/read. Whether this is Synology, or Docker, or GitHub/vwout, I'm not sure...

• I have Docker installed in Synology
• I have the (alpine) version of openLuup installed and running (apparently)
• but I can't access it at all or work out where the openLuup files go.

I think this is something to do with the method of persisting data:

docker-compose.yml

and whilst I understand that there are (probably) some commands to be run:

docker run -d \
       -v openluup-env:/etc/cmh-ludl/ \
       -v openluup-logs:/etc/cmh-ludl/logs/ \
       -v openluup-backups:/etc/cmh-ludl/backup/ \
       -p 3480:3480
       vwout/openluup:alpine

I don't know where that goes either.

So I feel stupid, and stuck. (Nice, in fact, to understand how others feel when approaching something new.)

Any pointers, anyone?

[RHCPNG]

@akbooer
I'm far from an expert, but have some experience with it yes. I haven't composed a container through yaml yet.

You first need to define/create the volumes, that's when you can state where the volumes should be "placed" and where the data resides. This can be a local directory or a nfs mount for example. Default, it creates a dir in the docker dir.

If you are not a Linux expert, like me (although I can manage), I would advise installing Portainer first. It gives you a nice GUI for managing your dockers. Far easier than doing everything through command line.

[kfxo]

@akbooer said in Moving to Docker:

• but I can't access it at all or work out where the openLuup files go.

You are using the synology docker package to create and deploy your container, correct? At minimum, to get the container accessible, change the port settings to 3480(local):3480(container). Then you should be able access it at http://YourSynologyIP:3480/

[akbooer]

@kfxo said in Moving to Docker:

You are using the synology docker package to create and deploy your container, correct?

Yes, that's correct for now. I need also to investigate Portainer, apparently.

@kfxo said in Moving to Docker:

change the port settings to 3480(local):3480(container).

OK, I was looking for where to do that, but I guess, I'll look harder. Thanks.

[akbooer]

... Oh, THOSE settings!

Thanks again.

[akbooer]

It's MAGIC !

I particularly like the look of this...

This instills a sense of wonder in me... I mean, I know (almost) exactly how openLuup works, but to see it wrapped in a container running on a NAS, seems rather special. "Hats off" ("chapeau?") to those who have engineered this, not least @vwout.

One is never quite finished, however.

I understand that to make any changes last across container/NAS restarts, I need to make the volumes external to the container, as per the above yaml. So this is my next step.

Any further insights welcomed. Perhaps Portainer is that next step?

[RHCPNG]

I'm not familiar with the docker GUI of Synology, maybe that's good enough. But Portainer is widely used for managing docker containers. I like it. It is quite easy to create volumes and the sorts.

[kfxo]

@akbooer said in Moving to Docker:

I understand that to make any changes last across container/NAS restarts, I need to make the volumes external to the container, as per the above yaml. So this is my next step.

Any further insights welcomed. Perhaps Portainer is that next step?

You cannot create named volumes through the synology GUI. You will need to use portainer or you can ssh into your synology and run the manual commands as outlined by vwout/openluup

You can also do this manually. Start by creating docker volumes:

docker volume create openluup-env
docker volume create openluup-logs
docker volume create openluup-backups

Create an openLuup container, e.g. based on Alpine linux and mount the created (still empty) volumes:

docker run -d
-v openluup-env:/etc/cmh-ludl/
-v openluup-logs:/etc/cmh-ludl/logs/
-v openluup-backups:/etc/cmh-ludl/backup/
-p 3480:3480
vwout/openluup:alpine

[kfxo]

@akbooer
I have been messing with this today. I do not currently run openluup through docker so this may not even be the best way to do this but it is what I did to get it up and running and with the ability to easily see and manipulate all openluup files within "File Station" on the synology.

I created three folders on my synology:
/docker/openLuup/cmh-ludl
/docker/openLuup/logs
/docker/openLuup/backups

Then I created three volumes with a bind to the created folders
'openluup-env' bound to '/volume1/docker/openLuup/cmh-ludl'
'openluup-logs' bound to '/volume1/docker/openLuup/logs'
'openluup-backups' bound to '/volume1/docker/openLuup/backup'

I used portianer but you can ssh into your synology and use the command line to create these volumes with the binds, see this

Then I created the container using portainer making sure to set the correct ports and volume mappings, which can also be done in the command line with

docker run -d \
       -v openluup-env:/etc/cmh-ludl/ \
       -v openluup-logs:/etc/cmh-ludl/logs/ \
       -v openluup-backups:/etc/cmh-ludl/backup/ \
       -p 3480:3480
       vwout/openluup:alpine

Hope this helps.

Edit: The binds are not necessary, I only did it to make it easy to access the files. Without the bindings, the volumes are somewhat hidden on synology that is not easily accessible for example at '/volume1/@docker/volumes/openluup-env/_data'

[RHCPNG]

Good explanation, this is where it comes down to. But in the end, you probably want the bind to make your data persistent and, more important, easy acccessible.

[akbooer]

I'm still struggling with this. I've manually created some external folders, but can't get the multi-line command to work.

@vwout, following my new experience with AlpineWSL on a PC (which I assume to be something very similar to Docker) I created the whole of the cmh-ludl folder as one single external volume. This is really convenient. Is it possible to make the same configuration for a Docker image?

[mrFarmer]

Hi @vwout, can your docker image also be used on the arm64 platform (Pi4)? If not, how would I go about building one? I think with an Unbutu docker and then use the same setup as on a plain Pi.

I am setting up some new things on a Pi4 and came along this (https://github.com/SensorsIot/IOTstack) to use Dockers on a Pi. Looks like a very quick way to (re)build an environment from a basic starting point. Especially the split between user data and all else looks attractive.

Cheers Rene

[akbooer]

Why would you want to do that? It’s not as though installing Lua is difficult. What am I missing?

[RHCPNG]

@akbooer said in Moving to Docker:

I'm still struggling with this. I've manually created some external folders, but can't get the multi-line command to work.

@vwout, following my new experience with AlpineWSL on a PC (which I assume to be something very similar to Docker) I created the whole of the cmh-ludl folder as one single external volume. This is really convenient. Is it possible to make the same configuration for a Docker image?

I don't know what AlpineWSL is, but you can make a volume for your cmh-ludl folder and map it in vwout's docker container.

This is what it looks like in portainer, like a mapping. Really convenient, like you said.

[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.)