[SOLVED] Openhab Docker or not?

If you plan on running other services on the RPi there are indeed some benefits. And with the more ram options on the RPi 4, running the services in Docker is a perfectly reasonable way to run these services in a controlled and isolated manner.

I wouldn’t do so on anything less than 2Gb RAM because Containers do increase the ram requirements slightly.

Now this is prompts a question, why? That really isn’t how containers are supposed to work. I could see changing it to install the services (OH, Mosquitto, frontail, etc) as containers but I can’t imagine how running openHABian in a container itself makes sense. As a VM, yes, but not as a container.

If you are not planning on using this machine for any other purpose than to run the stuff that openHABian installs, there benefits to running in a container are minimal. If you will be running other stuff, the isolation between processes offered by containers is useful.

Ok, this wasn’t meant to be a general statement.
But the benefit-cost ratio isn’t great especially if you’re a Docker newbie like the OP. And you can’t run openHABian then.

Now to contradict myself in the next statement …

It’s for the purpose of automated testing of the openHABian code. Clearly not targeted at end users.

:+1 that’s a good use for a container. Though I can imagine it’s very difficult. A typical container doesn’t even have an initialization daemon like systems running. For testing purposes have you considered using Vagrant and a VM for testing? It might be easier over all.

1 Like

Why? Just start with a Debian container.
https://hub.docker.com/_/debian

Indeed, and systemd needs to run as PID 1 else systemctl spits errors. But I think I’m getting there.

Container != Virtual Machine. That Debian image has just enough of the OS to run a single process in the foreground. That is how containers are mean to be used: one process per container.

It’s actually a lot of work and not at all easy to get a container to run more than one process because a lot of the supporting system daemons like systems are not available.

1 Like

Thank you for your suggestions. As the RPi 4 runs hotter than I would like, I spun up a VM to dockerize Openhab and other stuff.

It is taking longer than I expected, mainly because I would like to decouple Openhab and python, so need to rework all my exec binding.

You could look into LXC or LXD containers. Those give you more of a ‘VM like’ experience and still give you the quick startup times of a container because they share the kernel of the host. You can create snapshots as well so you can easily revert back.

Many moons ago I was using Xen on Ubuntu Server 6.06 LTS (because it supported PCI forwarding) and later KVM to run VMs. I then learned about and switched to LXC containers because they are much lighter than VMs. Then Docker came along.
I plan to reinstall my server next week (Ubuntu Server 14.04 LTS is EOL since April) and intend to use a number of LXD containers and run Docker, Kubernetes and OKD (OpenShift) in them. Not sure yet if that is going to work. If not, I can always spin up a KVM VM as a last resort.

Anyway, this is all a bit off-topic of course.

It would be nice to read about your setup and experience you made, when you are done.
A Setup bases on LXD/LXC, Docker, Kubernetes and OKD sounds interesting.

If you got the time maybe create a post about this setup :slight_smile:

Why decouple? Use HABApp and get the best of both worlds!

Perhaps some of us want things more closely coupled with OH like Jython. I know the differences of Python 2 vs 3 but it adds complexity to depend on an external, independently developed application layer.

1 Like

You do have the option of bringing them even closer together using Jython. Look into JSR223 Jython rules.

1 Like

That’s why I am asking him “why decouple” He clearly has the use case of different python scripts (probably with python libraries) he can’t run with JSR223. So I am suggesting to keep it closely coupled.

t.b.h JSR223 is way more complicated. I don’t like to hijack this thread so it would be nice if you come over to the HABApp thread and we’ll get a discussion going?

With the helper libraries it is no more complicated than Rules DSL any more.

1 Like

Thank you everyone for your ideas.

I have looked into this option before, but since openhab was not in a container before, it was much simpler to use CPython. With containers, Jython seems to be a good option and will definitely look into that again.

Have you had a chance to try it? If I pip install a package, would it store in userdata folder inside openhab, or it’s in a separate place (like /usr/local/jypthon etc)?

The scripts I wrote will most likely work on Jython. The reason I choose Cpython was “just in case” the library I want to use don’t exist on Jython. I do like the idea that everything in the container runs Java underneath, heck I even converted some of my python scripts to Java classes in order to dockerize my setup. The only concerns now is Jython 3.X seems to be in development for a while.

That’s a very interesting idea. I have something similar in my setup where I have a wsgi site interacting with Openhab rest API. Let me explore this more.

One limitation is you can’t pip install libraries to make them available. You can however download the libraries and put them in the conf/automation/lib/python folder.

I think most of us are eagerly awaiting when we can move to a newer Java where GraalVM will be available and we don’t have to rely on Jython coming out with a 3 version.

Interesting. Is that a limitation for using Jython in Openhab? or Jython can’t use pip at all? I read somewhere that Jython does support ensurepip, or at the very least, you can easysetup pip for Jython.

Yes, this would be awesome!

Thanks,
Joe

For simple use cases this might be true. But if you try rule inheritance, scheduling function calls, rule creation on the fly, rule parametrization through yml files etc. it gets ugly rather quickly.
Maybe you can try it out and we’ll discuss your experiences ? I’d be really happy about it.

To get back to topic:
@goodfore:
It’s super easy to spin up an HABApp container alongside an Openhab container.
Maybe give it a try - migrating your python script should be effortless.
Use a python IDE and you get syntax highlighting. You might even like it :wink:

That is luckily not correct :slight_smile: You can use pip when you use the full jython-installer.jar.

Assuming Jython is installed in /openhab/conf/automation/jython you can exec bash in the running container.

Then go to and execute /openhab/conf/automation/jython/bin/jython -m pip install <package(s) to install>

For example to install the python-dateutil package:

root@marcel-desktop:/openhab/conf/automation/jython/Lib/site-packages# /openhab/conf/automation/jython/bin/jython -m pip install python-dateutil
Downloading/unpacking python-dateutil
  Downloading python_dateutil-2.8.0-py2.py3-none-any.whl (226kB): 226kB downloaded
Downloading/unpacking six>=1.5 (from python-dateutil)
  Downloading six-1.12.0-py2.py3-none-any.whl
Installing collected packages: python-dateutil, six
Successfully installed python-dateutil six
Cleaning up...
root@marcel-desktop:/openhab/conf/automation/jython/Lib/site-packages# ls
 certifi		       dateutil		    _markerlib		     python_dateutil-2.8.0.dist-info   setuptools			  six.py
 certifi-2019.6.16.dist-info   easy_install.py	    pip			     README			       setuptools-14.3.2.dev0.dist-info   urllib3
 chardet		       idna		    pip-1.6.dev1.dist-info   requests			      'six$py.class'			  urllib3-1.25.3.dist-info
 chardet-3.0.4.dist-info       idna-2.8.dist-info   pkg_resources	     requests-2.22.0.dist-info	       six-1.12.0.dist-info
root@marcel-desktop:/openhab/conf/automation/jython/Lib/site-packages# 

I haven’t tried actually using them, but the installation of packages using pip seems to work fine.

2 Likes

Interesting. Is that a limitation for using Jython in Openhab? or Jython can’t use pip at all? I read somewhere that Jython does support ensurepip, or at the very least, you can easysetup pip for Jython.

The answer is beyond my expertise.

Spaceman_Spiff:

For simple use cases this might be true. But if you try rule inheritance, scheduling function calls, rule creation on the fly, rule parametrization through yml files etc. it gets ugly rather quickly.
Maybe you can try it out and we’ll discuss your experiences ? I’d be really happy about it.

Well, none of those things are possible in Rules DSL and none of those are things I would expect even the typical OH user to ever do. So it’s kind of a false comparison.

  • rule inheritance: for the “average” user moving from Rules DSL, they would be expected to use Rule Templates rather than inheritance. Inheritance as a concept is already too complicated for the average user.
  • scheduling function calls: Creating timers using OH Timers or Python timers is equally as easy as is done in Rules DSL
  • rule creation on the fly: I’ve not done this myself yet but all indications are this too is very easy. And you can disable Rules programatically as well so instead of needing an (if some Item is of state X) in a Rule, you can just disable the Rule.
  • Rules DSL also works in Python IDEs, I use VSCode with the most popular Python extension.

Spaceman_Spiff:

Maybe you can try it out and we’ll discuss your experiences ? I’d be really happy about it.

I’m unlikely to try it out because my main focus is on supporting new and non-technical users. As such, even my experiments with JSR223 Jython Rules is a stepping stone to UI created Rules (i.e. Rules that get stored in the JSONDB). When the new UIs get released with the graphical rule builder this is how most new/non-technical users will be developing their rules so that is where I need to have expertise and knowledge. I can and will continue to tell people about your HABApp but for me it would be a dead end.

marcel_erkel:

but the installation of packages using pip seems to work fine.

Cool. I remember seeing Scott post a reply to a thread that it wasn’t possible. I’ve not the experience or expertise to verify that and I may be completely miss remembering the post.