[tuto] Docker : jeedom FROM scratch

Tags: #<Tag:0x00007f282e09e360> #<Tag:0x00007f282e09e180>

Bonjour,

Récemment on a remarqué la disparition de l’image jeedom:lastest ( qui ne marchait pas ) et de plus, le tag par défaut jeedom:latest n’existe pas non plus… Il y a déjà plusieurs posts sur ce forum pour monter un jeedom sur docker mais ça ne marchait pas chez moi, l’erreur la plus courante étant un problème d’architecture :frowning: et pour cause: une image docker est par définition liée à l’architecture (le matériel) sur lequel elle est compilée!

J’ai donc du rechercher une image compatible sur mon RPI3b+ qui est du ARM32v7 pour refaire mon jeedom, et j’ai utilisé l’excellente image php, qui se décline à l’infini ou presque selon nos besoins:

  • architecture (elles y sont toutes)
  • version de php évidemment (là aussi, elles y sont toutes)
  • avec serveur apache ou sans (le mode CLI, mais aussi FPM)
  • et même la version linux support (alpine, debian stretch ou buster…)

Bref, le choix du roi! Voici pour info le lien docker hub et la liste des tags disponibles

Je choisi la version php:7.3-apache-buster (mais le même dockerfile est possible avec FROM php:7.3-apache-stretch pour une image proche des boxs officielles), j’ajoute les packages debian et les extensions php nécessaires à jeedom, et puis c’est tout :smiley:

… enfin, pas tout à fait : comme on veut aussi installer jeedom - tant qu’à faire - j’ajoute un 1er step pour télécharger la source depuis Github, en choisissant la version (v3 ou v4). Cela en fait un dockerfile multi-stage, le résultat du 1er step est transmis au 2eme. Voici le fichier dockerfile :

# download jeedom source from github
FROM alpine AS jeedom-src

# version jeedom: master ou release=v3, V4-stable
RUN apk update && apk add --no-cache git && \
   git clone https://github.com/jeedom/core.git -b master /app

# php7.3 + apache + debian 10 buster jeedom
FROM php:7.3-apache-buster

LABEL version="jeedom v4-buster"

# Installation des paquets
# 	ccze          : couleur pour les logs
# 	wget          : téléchargement
#   libzip-dev zip: pour l'extension php zip
#   sudo          : pour les droits sudo de jeedom
#   python*       : pour certains plugins

RUN apt-get update && apt-get install -y \
	apt-utils \
	wget \
	ntp \
	locales \
	ccze \
	cron \
	python python-pip python3 python-dev python3-pip python-virtualenv \
	libzip-dev zip \
	systemd gettext duplicity librsync-dev \
	sudo && \
# add php extension
    docker-php-ext-install pdo pdo_mysql zip && \
# add the jeedom cron task
	echo "* * * * *  /usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null" > /etc/cron.d/jeedom && \
# add sudo for www-data
    echo "www-data ALL=(ALL:ALL) NOPASSWD: ALL" > /etc/sudoers.d/90-mysudoers && \
# Reduce image size
    apt-get clean && rm -rf /var/lib/apt/lists/*

COPY --chown=www-data:www-data --from=jeedom-src /app/ /var/www/html/

Et ensuite ? il vous faut à minima une base de données, que j’ai nommée mariadb dans la commande suivante, je n’ai pas trouvé de version « universelle » donc pour mon RPI j’utilise celle de yobasystem car l’image officielle n’est pas compatible

Builder et démarrer les 2 conteneurs:

docker  build -t jeedom .
docker run --name mariadb -d yobasystems/alpine-mariadb
docker run --name jeedom --link mariadb:db -d jeedom

Ensuite ? Jeedom a la bonne idée de s’auto-configurer donc vous pouvez directement aller sur la page d’accueil : ici le « hostname » = db (c’est l’alias que j’ai utilisé dans la commande run)
jeedom_setup
Si la database est up, Jeedom va alors l’initialiser, et aussi installer quelques éléments supplémentaires… Ce qui prend encore un certains temps…
jeedom_success

On a fini :slight_smile: J’ajoute un fichier docker-compose.yml pour automatiser un peu plus les 2 containers.

version: '2'

services:
    jeedom:
        container_name: jeedom
        build : ./
        privileged: false
        pid: "host"
        cap_add:
             - SYS_PTRACE
        tty: true
        hostname: jeedom
        restart: unless-stopped
        ports:
            - "80:80"

    db:
        container_name: db
        image: mariadb
        restart: unless-stopped
        env_file:
            - ./.env

    adminer:
        container_name: adminer
        image: adminer
        ports:
            - "8080:8080"

code complet sur mon github

Attention , on a ici un jeedom dans la boîte, donc peut être incompatible avec certains plugins, je vous incite donc à relire les tutos concernant la création du network docker macvlan

2 J'aimes

Salut,
Je ne connaissais pas les stages sous dockerfile. Merci.
Au final ton conteneur est une alpine ou une Debian? Car je vois 2 from, alpine et Debian.
Hate de tester ça.

Le conteneur final est bien une debian (buster ou stretch selon le 2e FROM) et le 1er FROM ne sert qu’à faire git clone et remplir dans /app qui sera le /var/www/html du 2e, donc le « build » en quelque sorte de l’application php :slight_smile:

J’ajoute le lien github contenant les fichiers Dockerfile et docker-compose.yml :


ainsi que les images sur le docker hub:
https://hub.docker.com/repository/docker/pifou25/jeedom

J’ai réussi à connecter github et docker hub, ainsi à chaque commit ça déclenche un build ( et même 2, un sous debian 10 buster et un sous la 9 stretch, selon la branche) … pour moi ça n’a guère d’intérêt, mais ça serait intéressant pour @Jeedom-Team pour automatiser le build d’une image docker officielle à chaque commit d’une nouvelle relase :slight_smile:

La base est bonne mais attention dans ta gestion tu ne tiens pas compte lors d’une mise a jour de l’image des dépendances et des packages qui sont installés par les plugins

comment tu déclenchés l’ensemble de mise a jour des dépendances , le relancement des services a la fin ?

Non, en effet ce n’est que une base, de toute façon chaque plugins installent ses propres dépendances, c’est automatique. Enfin si, j’ai mis quelques dépendances ( en particulier python & co ) mais le but c’est surtout d’avoir le jeedom core, une image docker stable.

Par contre, à chacun de se faire une sauvegarde de son image docker après installation des plugins, ça peut être utile et je ne pense pas que jeedom le gère dans son backup (?)

Faut que la philosophie de docker c’est pas de faire des images qui deviennent des VM :wink:

Ce qu’il faudrait c’est un backup de jeedom ( si le volume persistant est /var/www ok mais dans ce cas tu ne peux plus fournir une image contenant une mise a jour du core … )

Lors de la restauration il faudrait que l’ensemble des dépendances se lancent ( mais pas en même temps sinon Apt va devenir fou ) et relance a la fin les services quand on refait ou relance une image et ou le contenaire …

Ok alors en vrai, je ne connais pas vraiment les VM ( et du reste je suis assez nouveau sur docker aussi :smiley: )
Dans mon build, il n’y a pas de volume persistant, donc en fait, la sauvegarde de l’image docker suffit à la fois pour jeedom (core & plugins) et les dépendances, il ne manquera que le backup de la bdd.

Je suis parti sur le même principe.

J’ai créé mon image sur la base de Debian Buster, jeedom v4 et avec un réseau macvlan.
et sans volume persistant, à l’exception du répertoire Backup

Pour la sauvegarde complète, je transforme mon conteneur en image.
et je sauvegarde l’image sur un disque ou une clé USB
Si besoin je peux restaurer mon image en conteneur

Vous perdez totalement le coté image / contenaire multiple voir scalable et avec update auto de l’image a chaque mise a jour …

Bref c’est tout sauf du docker… un peu de lecture :slight_smile:https://www.lemondeinformatique.fr/actualites/lire-containers-ou-vm-comment-faire-le-bon-choix-64793.html

PS : L’image jeedom ne devrait pas inclure ni la BDD, ni php tout ca devrait dans d’autres images linker pour ne pas se farcir les mises a jour de toute l’image alors qu’il y a que jeedom par exemple.

Jeedom c’est l’application, si tu n’inclu pas jeedom dans l’image jeedom ce n’est pas une image jeedom, c’est une simple image linux apache server… qui se crée en 1 seule ligne. ça parait donc logique de mettre jeedom dans l’image jeedom :slight_smile: ou sinon à la limite dans un volume partagé, donc dans le « host » mais dans ce cas aucun backup du jeedom core ?
Mon installa donc bien 2 containers: Jeedom et mariadb.

J’ai vu des exemples avec 3 containers: un serveur nginx, configuré en mode « reverse proxy », un autre pour php en mode CLI + l’application jeedom (pas de serveur apache) et le 3eme pour la BDD. Mais à priori apache ne permet pas ce genre de séparation.

J’ai déjà lu ce genre de discours sur la mauvaise utilisation de Docker.

Sauf que :

  • L’équipe jeedom ne maintient plus les images sur le docker Hub
  • La séparation des services ; apache, php, mariaDB ne se fait pas aussi facilement que cela qu’on a pris la peine d’aller voir le processus d’installation de Jeedom.
  • Docker est un peu capricieux avec les services systemctl

Alors on fait au mieux.

Qu’est-ce que cela peut bien faire de ne pas utiliser la philosophie de Docker.
Du moment que le conteneur tourne avec un minimum de CPU et de RAM.

Pour finir, on attend toujours que les « spécialistes » de docker créé des tutoriels pour nous aider …

1 J'aime

Bonjour,
Je t’invite à aller lire les nouvelles modifications apportées par Jeedom sur leur image docker.

C’est un choix de jeedom de ne pas respecter les principes de docker…C’est leur bébé, je respecte ce choix même si j’aurais aimé autrement. :cry:
Donc, les utilisateurs font ce qu’ils peuvent pour avoir du jeedom sous docker avec la matière que jeedom fournit.
C’est bien de repréciser les best practices mais il faut rester dans le contexte jeedom aussi. Si la matière n’est pas top (prévue pour docker) à la base, il ne faut pas s’attendre aussi à des miracles. :roll_eyes:

Le principe des tutos est de donner différentes pistes pour du Jeedom/Docker. Pas de donner des cours sur Docker ou d’imposer sa solution. :innocent:
Je considère que qq un qui se lance dans un installation Jeedom/docker, non conseillé par jeedom, sait ce qu’il fait et a un minimum de connaissance sur docker. :nerd_face:

Bonne réponse zaibakker, Sauf que ce « pré-requis » ou contrainte n’est pas mis en avant, et qu’il ne permet pas l’usage des :latest avec des mises a jours des images en auto ( comme le propose https://github.com/containrrr/watchtower ) par exemple.

Pour les images il faudrait prévoir :
Mariadb
PHP
Et ngnix / jeedom

Avec un link du tout et juste sortir le port 80 du container jeedom.

Pour le volume il faudrait uniquement faire une resortie du dossier plugins et thème / widget

Après lors du démarrage ( je ne crois pas que ce soit possible c’est aussi pour ça que jeedom ne propose pas d’image !! Dites vous bien qu’il y a quand même une raison) . Il faudrait pouvoir forcer la possibilité de faire un contrôle de l’ensemble des dépendances du dossier plugins

Avec un Split des containers et les apt-get des plugins ça risque d’être tendu et de provoquer la réinstallation de l’ensemble des packages PHP par exemple et la tout l’intérêt de docker s’effondre.

Donc c’est bien de donner des pistes mais si le but c’est de mettre tout le monde dans le fossé !!! Je vous laisse gérer ensuite les utilisateurs qui viendront se plaindre que jeedom ne fonctionne plus !! Sauf que la ça sera pas le tuto qui sera mis au clou mais jeedom directement !

On est tous impatient de lire ton prochain tuto pour savoir comment il faut faire :wink:

oui @PHB_fr j’insiste aussi sur le fait que c’est juste un autre tuto, pas l’image officielle ou l’install officielle, comme dit @zaibakker, ceux qui vont le tenter savent un minimum ce qu’il en est. Et je t’invite volontier à l’améliorer :slight_smile:

Comme je disais, j’ai déjà séparé en 2 containers (mariaDB d’un côté, le reste du monde de l’autre) et si l’on veut séparer en 3, la bonne séparation c’est celle ci:

  • Mariadb
  • nginx seul en mode reverse-proxy (ports 80 et 443)
  • PHP (en mode CLI) + jeedom + toutes les dépendances dans un 3e container

Dans ce cas il suffirait de modifier le FROM de mon docker file : FROM php:7.3-apache-buster par FROM php:7.3-fpm-buster par exemple (FPM pour FastCGI Process Manager) mais par contre il faut ajouter nginx avec sa configuration spécifique que je ne connais pas.

J’ai parfois eu des erreurs systemctl lors de l’install jeedom sous docker, vu dans les logs… Mais ça n’a pas d’impact, je veux dire ça n’empêche pas jeedom de s’installer & démarrer, c’est quoi ce systemctl et quel est le problème ?

1 J'aime

Bonne approche @pifou pifou ta séparation ça serait effectivement une bonne ( voir très bonne ) base.

Il me semble que les scripts jeedom lors de l’installation cherche a relancer des services d’où le systemctl ( apache ou d’autre service pour être sûr qu’il soit actif au démarrage ? ) c’est peut être une explication au problème ?!?

@Didier3L je vais pas faire une image docker ou quoique ce soit. A la base jeedom n’a pas du tout une orientation pour fonctionner sur ce mode je vais pas m’amuser a aller contre nature. Quand je dis qu’un rond rentre pas dans un carré c’est un constat pas besoin d’être architecte ou menuisier en coupant la pièce pour la faire rentrer !. Il suffit juste d’un peu de bon sens et de connaître l’environnement qu’on utilise ( ici docker ).

Si tu veux un jour faire une image docker ‹ propre › il fautdrait commencer a travailler sur jeedom ( déjà un relancement automatique des dépendances de tous les scripts seraient une avancé et ça en amont de la création d’une image )

( Ça veut dire aussi chercher dans la bdd de jeedom s’il y a un moment de savoir qu’on part d’une nouvelle image pour que tout se relance, cherche un bdd en base ou via un volume ? )

Merci pour tes conseils

Mais mon conteneur fonctionne parfaitement et je ne rencontre pas les problèmes que tu cites

Un conteneur qui fonctionne chez toi, c’est bien… un conteneur qui pourrait fonctionner chez tout le monde, c’est mieux :slight_smile: les bonnes pratiques vont nous aider à atteindre ce but! (enfin si on y arrive)

Alors moi, je n’utilise plus ce script dans mon conteneur : j’utilise la base PHP+Apache, j’ajoute un max de dépendances pour Jeedom, et puis c’est tout :smiley:
Ensuite, Jeedom à la 1ere exécution nous demande les paramètres de connexion à la bdd (donc il faut l’avoir installée dans un autre conteneur), et c’est la qu’il installe des trucs en plus que je n’ai pas encore réussi à mettre dans dockerfile :


Par ailleurs, mon build ne lance pas le cron, il s’ensuit que jeedom croit qu’il n’est pas démarré et je dois lancer manuellement les taches (dans le menu « moteur de tâches »)

Une image ‹ propre › ne doit pas forcément avoir toutes les dépendances des plugins, il suffit pour ça d’aller dans la page ‹ santé › de jeedom, voir et relancer les dépendances des plugins KO et le tour est joué.

Je viens de voir que Loïc a fait une image d’installation ISO de jeedom

Il faudrait peut être regarder dedans voir s’il y a des scripts un peu plus spécifique. il le semble avoir lu que lors de la restauration d’un backup jeedom relance les dépendances des plugins c’est plutôt une bonne nouvelle il faudrait dans l’image de contrôler voir s’il y a un fichier de backup dans un volume , restaurer le fichier et le modifier pour ne pas le relancer a chaque démarrage.

Une image ISO ce n’est pas docker, quoique l’objectif est le même: dans les 2 cas, on veut générer une image propre, qui s’installe tout seul -ou presque-, charge ensuite à l’utilisateur d’importer son backup (backup jeedom avec les données et les plugins)

Mais une image ISO, c’est pour graver directement sur une carte microSD, rien à voir avec docker et il n’y a pas non plus de volume partagé, il faut importer ton backup dans jeedom manuellement.