There is no easy way to exchange on GitHub, so I am taking the discussion here.
Here we go.
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:
- Make the Docker use easier for everyone.
- Respect the containerization Docker philosophy.
- Enforce the security of the Jeedom product.
I will go through a list of ideas and proposals. Feel free to comment them.
The Docker image of Jeedom MUST run on Debian stretch. The Dockerfile should therefore have the following FROM directive:
Using « debian:latest » is dangerous since a single update on dockerhub can break the installation.
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:
- 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.
- SSL should be handled by another reverse-proxy container (such as nginx).
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.
Note: if you can ssh as root your Jeedom instance using Mjeedom96 as a password, fix it ASAP.
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.
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?
- I don’t like the fact that we allow fingerprinting of the Docker installation. This installation should not be different from any other installation.
- I could not understand the purpose of MODE_HOST…
VI. Revamp documentation
All is in the title.
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.
NB: Loïc, you should seriously consider https://github.com/jeedom/core/pull/1577, you put all your users at risk here and that will one day kill your business. Do it before any news website publishes it.