Runnng Openhab2 in a docker

Thanks so much.
Could you also share your frontail docker setup?

Sure thing.

sudo docker run --name frontail-openhab -it -p 9001:9001 -d -v /opt/openhab/userdata/logs:/logs -v /opt/frontail/ui:/ui --restart=always mthenw/frontail --theme dark --ui-highlight --ui-highlight-preset /ui/frontail-preset.json /logs/openhab.log  /logs/events.log

Sorry for putting it all on one line. Docker run spits out an “invalid reference format” error when I split it up neatly like I did for Grafana above. I don’t know why, but putting it all on one line fixes it.

I set this up to use openHAB’s highlights but with the dark theme. To use the highlights, you’ll need to create /opt/frontail/ui and in it place the following file: https://github.com/openhab/openhabian/blob/master/includes/frontail-preset.json

Note that this setup also relies on openHAB being run in a Docker container and keeping its files inside /opt/openhab. If this isn’t your OH directory you’ll need to adjust obviously.

1 Like

Thank you again Sir!

1 Like

This looks interesting Actually to fit in with the newest Linux filesystem standards /srv/openhab would be more appropriate for a mix of file types.

After seeing this post I decided to play around with Compose. Instead of running it from the command line, I started the stacks using Portainer’s editor.

I now have six stacks running and I love the simplicity and elegance. Even better, next time I start clean with my server it should be even more painless.

I still stand behind my original advice and suggest new Docker users learn the system with simple containers started with docker run but Compose really takes it to the next level!

2 Likes

Perhaps you should submit updates to the official documentation.

I’d be open to that.

Are you referring to the lack of a compose option on the Docker install page? I’d be happy to add a generic Compose file and explanation.

I also noticed that the page still references a Docker container run as a systemd service. From what I understand, that’s a bit obsolete and doesn’t really have any benefits.

I have found the documentation really lacking.

The Docker documentation is on Docker Hub in addition to the openHAB web site.

Can you explain what “working with stacks” mean and how it simplifies the setup?
I understand the new version of portainer is kubernates enabled. Is it anything like that?

that very depends 
 it’s not black&white 
 I use compose only for containers which have to coexist together 
 like influx+chronograf and stuff like that
having multiple containers at one wrapper is pain in the ass when you need to update one of them.
Before doing stacks one need to think it thru a bit, but yes it’s convenient in some ways

having openhab + mosquitto + nodered in one stack is
 silly

1 Like

A single capability will often involve a number of different applications. For example, a typical openHAB “stack” might include:

  • openHAB
  • FronTail
  • Mosquitto
  • InfluxDB

Each of those applications would be running in it’s own Docker container. By using Docker compose (or similar tools) you have one file that defines all four of those containers and will bring them up in the proper order and with the proper run parameters.

I wouldn’t go that far. It depends on the intent and how the individual user wants to manage their own system. There is no multi-developer DevOps situation going on here. It’s one person trying to deploy one set of systems in a way that makes the most sense for them. It may not be a best practice but I wouldn’t call it silly. For many people, working out of one file is convenient and makes more sense for them.

Pardon my newbie limited knowledge about dockers.
It sure does make it easier to deploy initially all the docker containers that are related as a start.
So if I need to stop the openhab docker, back up , remove the tmp and cache folders before I update to the newer version, how would I do so with docker compose? do I also need to stop all the other docker containers in the compose file and reload in total? Can I just remove a single docker container and get a new image and start up that particular new container?
I am comfortable using portainer 1.24 for managing my docker containers for all home automation related containers.

Backup is no different than with regular docker. Either enter the container and run the backup script, or backup the volume where the conf and userdata is preserved outside the container. Clearing the cache during an update is already handled by the container itself so there’s nothing you need to do. If you want to do it manually, you’d do it just like you do with any other docker deployment.

No. Docker Compose is really just a way to control the startup of a number of services and control the order they start up in. It’s not really any more than that. It doesn’t change where and how the data is stored or what the container does once it’s already started.

Probably, though typically when you are using compose, you treat the group of containers as a single unit. You wouldn’t typically mess with just one and leave the others running. That’s sort of the point. It lets you treat two or more containers as a single “thing”.

1 Like

maybe it’s too strong to call that silly, let’s call it bad practise then :slight_smile:

this is exactly the point where you think about stack in a wrong way because you figured out that for OH update you need to remove whole stack and run it again - as it should be, but for mismatched application it is not convenient. It can be indeed done separately, but then you are loosing what stack is doing.

So use stack for things which needs one or another to live, like grafana+grafana-image-renderer or influxdb+chronograf etc. basically everywhere you have dependancy.

But what kind of dependancy has got mqtt server with openhab? zero, because mqtt is needed even when openhab is restarting as devices are communicating to it, so another systems like nodered can still be operational. Having OH,nodered,mqtt and basically any other automation software in one stack is 
 bad practise.

what’s dependency between medusa,lms or sickrage? none, only thing “common” is they handle different mediafiles, these should not be stacked, no reason for that, and so on, so on

@rlkoshak explained it better than I could, so I’ll leave it at that.

I have no experience with Kubernetes, so I’m sorry to say I can’t compare them. I’m not afraid of the command line by any means, but I do like being able to make small adjustments to my containers without the complexity of finding my text file and keeping track of the changes. I don’t find rebooting extra containers to be a big deal at all.

I think that’s a matter of opinion. I don’t claim to be an expert, and rather claim the opposite. But, I don’t see the harm in organizing similar containers in a stack, especially since, at least in my case, they are interdependent. I have them configured to exit and restart gracefully and nothing on my server is broken by a container restarting.

Yes you can actually.

This brings the whole stack down and then up:

docker-compose stop
docker-compose up -d

But this only does for the serviced named openhab in the stack:

docker-compose stop openhab
docker-compose up -d openhab
2 Likes

If you make the changes for the upgrade and then run docker-compose up, it will apply only the changes you’ve made so you don’t need to bring the whole stack down.