Proposals for Docker support

Matériel Jeedom - Hardware Docker DIY (Faire soi-même)
1

All,

There is no easy way to exchange on GitHub, so I am taking the discussion here.

Here we go.

Introduction

I feel Docker is not getting the love nor the care it deserves. There is no manifesto around this use case, documentation is scarce and the changes on GitHub seem to oscillate in different directions. I am proposing here a couple changes around three big principles:

  1. Make the Docker use easier for everyone.
  2. Respect the containerization Docker philosophy.
  3. Enforce the security of the Jeedom product.

I will go through a list of ideas and proposals. Feel free to comment them.

I. Debian

The Docker image of Jeedom MUST run on Debian stretch. The Dockerfile should therefore have the following FROM directive:

FROM debian:stretch

Using « debian:latest » is dangerous since a single update on dockerhub can break the installation.

More info:

https://www.reddit.com/r/docker/comments/alvkzk/do_you_use_the_latest_tag_why_or_why_not/

II. Apache

PHP execution is deeply tied with the Jeedom core. It is therefore perfectly logical to ship Apache2 with the container. However, there are a couple things that should not be handled by the container:

  1. Changing the listening port should be done via Docker run (-p 80:…) or docker-compose (ports: - « 80:… »). It means we can get rid of APACHE_PORT, this is done at the layer above.
  2. SSL should be handled by another reverse-proxy container (such as nginx).

More info:

III. SSH

The current installation is a bit dangerous. By default, the container has a sshd server running, the root password is hardcoded, and root is allowed to ssh! That is a real public risk as we can safely assume most of Jeedom installations are easily compromised. Moreover, SSH is never needed on a Docker installation because you can always « docker exec bash ».

We can fix all this by simply removing OpenSSH from the container, and with it SHELL_ROOT_PASSWORD, ROOT_PASSWORD, motd, bashrc.

Please note this has also the sweet advantage of limiting the attack surface of the product, which is always the first thing to consider when doing security.

:red_circle: Note: if you can ssh as root your Jeedom instance using Mjeedom96 as a password, fix it ASAP. :red_circle:

More info:
https://jpetazzo.github.io/2014/06/23/docker-ssh-considered-evil/

IV. MySQL (mariadb)

There shouldn’t be a MySQL server running inside the docker. That is directly following the philosophy of containerization. Another one should be spawned via docker-compose.

We can directly pull a mariadb container.

More info:

V. Jeedom

That is debatable and your opinion is important.

The role of the Docker image is to setup the scene for the later Jeedom installation. Jeedom is not exactly installed during build, but during the CMD phase of the Dockerfile.

Do we want Jeedom to be already installed in the image before it starts? Or not? Doing so would allow us to have Docker images for different versions of Jeedom: 4.0.1, 4.0.2, and so forth. It may be useful for testing and debugging.

Personnally, I don’t quite like the idea to wget the install.sh script from GitHub and trigger step 6 (install/OS_Specific/Docker/init.sh). Why not making sure all steps from 1 to 12 are done before starting the instance?

Finally, do we need .dockerinit and MODE_HOST?

  1. I don’t like the fact that we allow fingerprinting of the Docker installation. This installation should not be different from any other installation.
  2. I could not understand the purpose of MODE_HOST…

VI. Revamp documentation

All is in the title.

https://jeedom.github.io/documentation/installation/fr_FR/index#tocAnchor-1-22

VI. In the future…

Many other things… Stop using root user, get rid of all the chmod 777, stop generating « tr -cd ‹ a-f0-9 › » passwords… But that is not exclusive to Docker.

Alright, that’s it, let me know what you think. Especially you Jeedom official maintainers.

I can of course take care of the implementation.

Thanks.

NB: Loïc, you should seriously consider Core/TLS checks: remove all occurences of --no-check-certificate by pierrecdn · Pull Request #1577 · jeedom/core · GitHub, you put all your users at risk here and that will one day kill your business. Do it before any news website publishes it.

2 « J'aime »
2

Thank for your proposal be to be honnest we don’t want for now user on docker for many reason :

  • support can not handle this plateform
  • we don’t have time to test core or official plugin on docker
  • we have many plugin does not handle correctly docker (due to usb device for example)
  • we have many plugin witch never work on docker (due to broadcast for example)

However we work on private docker repo to solve all this issue (with some of your return already add) but for now we don’t recommand jeedom on docker. But it slow very slow because we are some team we lot of works

For the PR 1577 I work on it but for you it’s simple because you known how to configure linux but 75% of hour user don’t known how to connect in ssh and obviously how to deal with certificat issue. So with your PR 75% can not install jeedom and we get lot of ticket it’s not possible.

3

Hey, I’m ok with not having Docker advertised as an official solution and I perfectly understand this choice! You said you’re busy, just know you have two hands willing to touch install.sh/Dockerfile/init.sh. Jeedom is a great open source project, feel free to use your Community!

Let’s say I am knowledgeable of Docker and system security, and I am offering my help. What do you think? :slight_smile:

Credit where it’s due, it’s not my PR. :slight_smile:

I think we should not disable security and make Jeedom vulnerable because some people will have issues. Security is of paramount importance. We should educate and support people, not leave their houses vulnerable. Trust me, one day you’ll regret this. All it takes is one article to frighten people away from your company and hurt your business. And that’ll be the end for you. And for us. :worried:

4

For the pr i will see with team if we can handle very hudge support ticket on that and stop all other project and evolution to manage this problem.

For Docker we love that community help us but in Real life accept this type of pr it’s increase our work. We prefer do less ans good. Dev team it’s 2 people we don’t have time to test Docker en release a version of jeedom fully compatible. But i note community want that and i will try to add this in roadmap.

5

Understood, thanks!

Again, I was not saying you guys should support it, just that with your guidance we can probably work towards a better yet still unsupported Docker support. Another solution would be to fork the repository, but I don’t like this.

Anyway, see ya. Happy confinement.

6

Tout Can porpose a pr but for now i prefer don’t touch install.sh

7

Oh, alright!!!

But do you agree with everything I proposed above?

8

I am on with 1,2,3.

For 4 it’s discutable for me WE need 2 version on with mariadb inside Docker and one not. Why ? To make easy installation and jeedom check mariadb process and can restart it if needed.

  1. install Can be done on Docker build. Just informe toi we use Docker/k8s to deploy test image rapidly for dev si WE need to pass backup file and restore it on Docker start only one (it’s Also why WE need Docker with mariadb built in)

  2. WE are currently review all our documentation to translate it si it’s possible.

  3. for now i don’t want to touche install.sh

9

Perfect. I’ll shoot a PR with 1, 2 & 3!

We’ll see later about 4 & 5. :slight_smile:

I guess I’ll have to work on alpha. Since I’m directly discussing with you, it would be great if:

  • you could document the different branches and how they work (alpha, beta, release, stable, V4-stable, V4-release);
  • tag the commits on which you release (looks like you used to do it until 3.1).

Best,

10

Alpha yes for now branche it’s little complicatide but it’s on peut roadmap to improve.

For tag it’s not possible it’s toi work for out team

11

There you go. I tried not to touch install.sh but it seems two problems needed to be fixed (maria-db & the step names).

I’m not sure I understood why you cannot tag the repo when you make a release. That would be great for tracability.

Have fun!

1 « J'aime »
12

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.

13

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.

Docker 123 · Pull Request #1641 · jeedom/core · GitHub [Sorry, I messed up the name]
[Docker] Realign Dockerfile_full with Dockerfile · Pull Request #1642 · jeedom/core · GitHub

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

1 « J'aime »
14

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 ?

15

Bonjour @Loic

Je vois que mon dernier PR Improved widget replacement usability by jpty · Pull Request #1643 · jeedom/core · GitHub 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 ?

16

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

17

Cool.
Quel est le rapport avec mon PR?

18

Aucun c’est pas de ta faute

19

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 d'un port avec cle Bluetooth HCI

20

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.