Aucun c’est pas de ta faute
Bonjour @Rpi
Je vois que vous avez de bonnes connaissances avec Docker 
Pour ma part j’ai réalisé un tuto pour utiliser Jeedom sur Synology en mode docker
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 d'un port avec cle Bluetooth HCI
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. 
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. 
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 Docker Hub
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 core/install/OS_specific/Docker/init.sh at V4-stable · jeedom/core · GitHub
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
@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 
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
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: Error message "sudo: unable to resolve host (none)" - Ask Ubuntu). 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.
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
Nicolas
Bonjour Nicolas,
T’embête pas à écrire en anglais … on est à 99% en France ici 
Pour ce qui est de Homebridge, j’utilise le plugin jeedom sur mon installation docker en réseau macvlan
et cela marche nickel
Dear @Rpi, I love this thread and I will bookmark and follow it!
To my mind, as I already said since months (in legacy forum), containerization of Jeedom is a piece of larger/deeper limitations caused by the way Jeedom is developed. Your initial message highlights the OS level, but in fact at application level (php) there is also a lot of missing best practices that complexify application maintenance and hurt security sometimes. You spoke about git and branches / tag misconfigured also… and I agree.
Jeedom v4 look like Drupal 7 : we speak about « Drupalism », we can speak about « Jeedomism » : both are powerful tools with a steep learning curve and some « home made local » practices.
To my mind, before speaking about containerization Jeedom itself must be cleaned, secured, and standardized. A part of that is to use English in source code, except if Jeedom want to limit its audience to France which is sad, to my mind (pour ta Remarque @Didier3L 
).
To reuse the Drupal parrallel look at the huge change between v7 and v8 (custom codes to Symfony) vs change between v8 and v9 (simple update) : that should be an inspiration for Jeedom.
Maybe we can dream of such destiny for Jeedom v5 ?!
@Loic : where is the « Jeedom v4 Docker » project today? Abandonned? This thread was not updated since lot of months…
To conclude I like the job done in v4, in good way to be standardized. But there is still a long way to go before we get to something packaged. things are changing quickly, and I fear that this beautiful French application will be abandoned by the community in favor of, for example Home Assistant.
Thanks
1 « J'aime »
Hello,
I understand your point of view unfortunatly I don’t have the competence (and the time) to do or understand this work. We use jeedom in docker mode from some specific need (demo, saas, formation…) but not for real home automation usage.
… do you mean, migration of the complete Jeedom with Symfony framework ?
I didn’t know about Drupal story, but it should have been a huge work with a consequent team, how many developpers ?
Anyway, about the topic, I was looking for a way to have the « best » contenerized Jeedom service, but until now I end up with the simplicity.
Next try I will use a base of phusion/baseimage-docker instead of the official debian docker image, that is too slim and is missing several usefull demons…
Alors celle la c’est la meilleure 
Aucun risque
2 « J'aime »
There have never been so many new Jeedom users since Jeedom V4
Couldn’t agree more! We are accepting PRs (alpha branch) 