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.
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.
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.
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
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.
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?
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.
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
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.
Spaceman_Spiff:
marcel_erkel: