Proposals for Docker support

It’s ok for me I merge to alpha just I wonder for mode_host be I hope some user will test and say if it’s not ok.

Just another question for me we need to add apt-get update ad begin of dockerfile.

Alright, I’ll fix it if someone complains. :grin:

I don’t think we do, it’s the very first operation of step_1.

For those who are following the thread, two additional PRs were sent.

https://github.com/jeedom/core/pull/1641 [Sorry, I messed up the name]
https://github.com/jeedom/core/pull/1642

After that, I guess we can start discussing about the init.sh. :wink:

1 J'aime

Ok I forget there is an update in install.sh, so for him https://github.com/jeedom/core/pull/1642 why remove volume and expose ?

Bonjour @Loic

Je vois que mon dernier PR https://github.com/jeedom/core/pull/1643 ne passe pas un des tests dockercloud:
image
Quand je clique sur Details, j’ai un Oops error 404.

Est-il possible de savoir ce qui cloche ?

Voila l’erreur :
Step 8/14 : ADD install/OS_specific/Docker/supervisord.conf /etc/supervisor/conf.d/supervisord.conf

ADD failed: stat /var/lib/docker/tmp/docker-builder028338427/install/OS_specific/Docker/supervisord.conf: no such file or directory

Cool.
Quel est le rapport avec mon PR?

Aucun c’est pas de ta faute

Bonjour @Rpi

Je vois que vous avez de bonnes connaissances avec Docker :sunglasses::+1:

Pour ma part j’ai réalisé un tuto pour utiliser Jeedom sur Synology en mode docker

https://community.jeedom.com/t/tuto-installation-de-jeedom-sur-synology-avec-docker-en-mode-host/5290/13

Je prépare un autre tuto pour une utilisation de Jeedom en mode Docker avec un réseau macvlan

Je vous soumets un problème Docker - mappage des ports USB

Alright Loic (thanks for the SSL by the way, much appreciated).

We now have two simple but different Docker files: Dockerfile & Dockerfile_full. The only difference between them is mariadb (cf. IV) but there is a lot of complexity behind this difference.

$ diff -u Dockerfile Dockerfile_full
--- Dockerfile	2020-04-08 12:45:44.168001611 +0200
+++ Dockerfile_full	2020-04-08 12:39:23.933512476 +0200
 COPY install/install.sh /tmp/
-RUN sh /tmp/install.sh -s 1
-RUN sh /tmp/install.sh -s 2
-RUN sh /tmp/install.sh -s 4
-RUN sh /tmp/install.sh -s 5
-RUN sh /tmp/install.sh -s 8
-RUN sh /tmp/install.sh -s 11
+RUN sh /tmp/install.sh

The difference between the two appeared to be problematic over the past months because the Dockerfile instance was often broken due to init.sh steps naming, missing mariadb client, packages missing. Which is bad for the community.

So I think it would be better if only one remained. What do you think?

PROS to have mariadb in the container (Dockerfile_full):

  • finer control from Jeedom (start/stop, parameters…);
  • easier to setup (Jeedom knows the credentials…);
  • fine-tuned packagin for the end user (smoother to install…);
  • identical to the normal OS install (maintenance easier in theory).

PROS not to have mariadb in the container (Dockerfile):

  • big blob instead of nicely separated containers;
  • clean design separating the database and the client (Jeedom);
  • probably nicer for people taking care of their database infrastructure themselves;
  • we don’t execute all the steps in install.sh

So here it is. Which one do you prefer?

Dockerfile looks cleaner to me, but honestly, for your company, Dockerfile_full seems a lot easier to maintain as it gives a complete bundle to your users that is very close to the normal installation.

Hello
Thank for your analyse, if we need to chose than it’s Docker_full. So we can remove docker without mariadb

By the way I begin to develop a package manager inside jeedom core the purpose is to simplify install.sh, install.sh juste install need package to start and pass the work to packages.php which install missing package.

Cool. There you go: https://github.com/jeedom/core/pull/1660
Man, we did so much cleanup!

I am not sure I understood what you meant about the package manager, but let us know if you need help or advice. :slight_smile:

Thank I juste merge PR.

For package manager the idea it’s install.sh script juste install minimal needed package and pakacge manager add other package. The purpose it’s to unify install and update (like for database). I juste add to json file new needed package and on install or update package manage do that it need to do .

Alright, let us know if you need code review on your work!

By the way, you’ve probably seen it, but you need to update your CI since the Dockerfile has changed location. :wink:

New cleanup PR. https://github.com/jeedom/core/pull/1661

Hi @Rpi
I tried several docker images for a jeedom build under Raspbery pi3+ but without any success… I often get the following error:

standard_init_linux.go:211: exec user process caused "exec format error"

trying nricheton/jeedom-optimized:latest on hub.docker repo, or also https://hub.docker.com/r/jeje/jeedom-nginx
I also tried with some alpine-gninx-php image, but it seems that jeedom is not compatible with alpine. I hope you can help ?

Bonjour @Loic

J’ai fait un nouveau tuto pour installer jeedom avec un Dockerfile et docker-compose

lors de mes tests je n’ai pas réussi à installer Jeedom avec le fichier \jeedom-v4\install\OS_specific\Docker\init.sh tel qui l’est proposé sur github https://github.com/jeedom/core/blob/V4-stable/install/OS_specific/Docker/init.sh

Je l’ai donc modifié

Peux tu me dire ce que tu en penses ?

Quid du fichier supervisord.conf. Je ne vois pas où il est utilisé ?

Hello all,

I missed this discussion on Docker, and I just noticed the latest changes discussed here were pushed and one of them broke my jeedom installation and my Docker images
(I’m the author of nricheton/jeedom-optimized which pre-installs several dependencies : https://github.com/nricheton/jeedom-docker-optimized)

Here is my feedback :

- APACHE_PORT :
This env. variable was used mainly for plugins which requires to use network broadcast (Homebridge for instance). Internally this is for the avahi daemon and service discovery.

When you want to use these plugins, you have to launch docker image in host networking mode. In that case, you cannot redirect ports so you NEED to be able to change apache port if you already expose port 80 somewhere.

Please restore APACHE_PORT, without it you cannot use homebridge in jeedom with docker with another http server (TLS proxy for instance). In the meantime, I’ll do a workaround in my images.

- MODE_HOST :
Not sure what it was doing, +1 for removal

- SSH
+1 for removing SSH access to images. Preferred way is docker exec -it bash

- Maria/Mysql
+1 for removing DB from container.

- Image management
In the docker mindset, images are versioned and you are expected to redeploy images on frequent basis, at least for security fixes. You should be able to destroy / recreate image at will without any impact.

With the plugin/marketplace system, plugins should be installed and updated on docker volumes so they can persist when image is recreated.

But in an ideal world, jeedom files (except configuration) should be included in docker image, tagged with versions. I didn’t go on this path yet.

My current strategy is to at least install most plugin dependencies in Docker image, so you don’t have to launch dependency install for every plugin when you create a new image. This is the reason behind the image nricheton/jeedom-optimized. (+ dist-upgrade, frequent rebuilds for security)

** -@Pifou**
You should try nricheton/jeedom-optimized:rpi-latest instead of nricheton/jeedom-optimized:latest. It is compiled for Raspberry

** Jeedom on docker ** :
On my side, I have no issue with all my plugins on docker (wave, mobile, homebridge, etc…).

Thanks !

Nicolas

Hi Nicolas, thanks for your feedback :slight_smile:

@Rpi gave the right method, you can launch as many containers as you want, each of them using the internal port 80, but change the outcome port using the mapping parameter ( docker run -p 8080:80 …) or the docker-compose configuration.

… but it didn’t : the jeedom image install and launch its own mariaDB instance, and does not use any other external mariaDB container :confused: this is why I don’t use the official jeedom image until now, I try to have several distinct containers.

I tried your dockerfile project but didn’t manage, and had an unexpected error. Now I started a new Dockerfile project without using the official jeedom image, but using the official php.apache image. Same strategy as your, that is, install almost dependancies in the dockerfile, and also the current jeedom source from git.

This works for me but I didn’t try with several specific plugins, nor with host mode.

I didn’t try the final step, but it may be the good way to add a shared volume with a jeedom backup, then the final step will import and install the backup (backup restore) and run jeedom with every configuration and plugins already installed.

Bonsoir

Tu devrais utiliser le réseau macvlan à la place du mode Host :wink:

Hi,

This doesn’t work in host networking, you don’t have internal port since you are using the host network stack directly. Docker refuses to use -p in this configuration.

I got the answer with my tests this evening. Without it, sudo doesn’t work (or is very slow) when in host networking (see: https://askubuntu.com/questions/59458/error-message-sudo-unable-to-resolve-host-none). To support this mode, we must ensure the same hostname is defined in /etc/hostname and /etc/hosts. Maybe this can be patched directly in the image without the need of an env var.
-1 for direct removal.

You can, and should setup an external DB with official image. :slight_smile:

From your previous post, it seems you used the wrong tag (not the one for raspberry). I run this image on rpi3+ & 4.

Je testerai, mais toutes les docs homebridge/docker imposent le mode host, je n’ai pas cherché plus loin pour l’instant :slight_smile:

Nicolas

Bonjour Nicolas,

T’embête pas à écrire en anglais … on est à 99% en France ici :blush:

Pour ce qui est de Homebridge, j’utilise le plugin jeedom sur mon installation docker en réseau macvlan
et cela marche nickel :wink: