Advantages of "classic install" over docker




I was wondering why most of yunohost applications were packaged to be installed directly on the system, and not using docker (or equivalent). I can see advantages in both methods, but is there more ?

With docker: isolation from other app, probably more secure, and prevent conflicts

Without docker: probably more performances, which is a big plus on hardware like raspberry pi

From those advantages, I would say that it could be better to use dockerized app. Can someone give me more insight in why app are mostly not using docker ?


Je me demandais pourquoi la plupart des applications yunohost étaient packagées pour être installées directement sur le système, et n’utilisaient pas docker (ou équivalent). Je vois des avantages dans les deux façon de faire, mais y en a-t-il d’autres ?

Avec docker: isolation des autres applications, donc probablement plus sécurisé, et prévient les potentiels conflits.

Sans docker: plus de performance, ce qui est important pour les machines comme le raspberry pi.

Avec ces avantages, je dirais qu’il serait mieux d’utiliser des application dockerisées. Quelqu’un aurait-il plus d’informations là dessus ?


I would say there some other raisons, at least for me.

  • The first one is that docker doesn’t work on a 32b processor. But for self hosting, it’s can be common to use an old computer that uses a 32b proc.
  • Too much isolation is not always what we want, there some applications linked between them. And also many applications which use standard directories shared between them. Especially for media directories.
  • Docker is a black box… The idea here is not to hide the operation of our applications, but to keep it as open as possible.
    And we want to allow our users to modify and adapt the application to their use cases.

Je dirais qu’il y a d’autres raisons, du moins pour moi.

  • La première est que docker ne fonctionne pas sur un processeur 32b. Mais pour l’auto-hĂ©bergement, il peut ĂŞtre courant d’utiliser un vieil ordinateur qui utilise un proc 32b.
  • Trop d’isolement n’est pas toujours ce que nous voulons, il y a des applications liĂ©es entre elles. Et aussi de nombreuses applications qui utilisent des rĂ©pertoires standards partagĂ©s entre elles. SpĂ©cialement pour les dossiers de mĂ©dias.
  • Docker est une boĂ®te noire… Il ne s’agit pas ici de masquer le fonctionnement de nos applications, mais de les garder aussi ouvertes que possible.
    Et nous voulons permettre à nos utilisateurs de modifier et d’adapter l’application à leurs cas d’utilisation.


I get the argument of having more connexion between applications. But I don’t get what you mean by “Docker is a black box”. Indeed, modifying the application require an extra step, but it is still feasible, I am wrong ?

Je comprend l’argument d’avoir plus liens entre applications. En revanche je ne comprend pas ce que tu entends par “Docker est une boîte noire”. Effectivement modifier l’application requière une étape supplémentaire, mais c’est toujours faisable non ?


Let’s say if you want to install, for example, wordpress, without YunoHost it will be a directory with wordpress, a nginx config and maybe php.

With YunoHost, it will be mainly a directory, a nginx config and a php config. Anyone who know how to install a php app, will know how his wordpress has been set up.
That means also, if anyone want to modify his wordpress, it’s as simple as a manual installation.

And that’s a good thing ! YunoHost is, and should stay, only a way to simplify the installation of your services.

If we provide wordpress in a docker container, an user can’t know how we built it, and what’s going to happen when he will install it. He can’t simply read the script to understand where the app is going to be installed.
If he want to modify something in his app, it’s not going to be as simple as a simple install.
He can’t simply change a file, he has to enter inside the container, running, to find how this app has been built to hope to change a file.

I don’t really like the idea to give a black box to our users, and just say, trust us, “We’re not evil”.
I like to give a simple script, easy to read, transparent, and be able to say to our users, don’t trust us, check the code !

Disons que si vous voulez installer, par exemple, wordpress, sans YunoHost ce sera un répertoire avec wordpress, une configuration nginx et peut-être php.

Avec YunoHost, ce sera principalement un répertoire, une configuration nginx et une configuration php. Toute personne qui sait comment installer une application php, saura comment son wordpress a été installé.
Cela signifie aussi que si quelqu’un veut modifier son wordpress, c’est aussi simple qu’une installation manuelle.

Et c’est une bonne chose! YunoHost n’est, et devrait rester, qu’un moyen de simplifier l’installation de vos services.

Si nous fournissons wordpress dans un conteneur docker, un utilisateur ne peut pas savoir comment nous l’avons construit, et ce qui va se passer quand il l’installera. Il ne peut pas simplement lire le script pour comprendre où l’application va être installée.
S’il veut modifier quelque chose dans son application, ce ne sera pas aussi simple qu’une simple installation.
Il ne peut pas simplement changer un fichier, il doit entrer dans le conteneur, en cours d’exécution, pour trouver comment cette application a été construite pour espérer changer un fichier.

Je n’aime pas vraiment l’idée de donner une boîte noire à nos utilisateurs, et dire simplement, faites nous confiance, “We’re not evil”.
J’aime donner un script simple, facile à lire, transparent, et être capable de dire à nos utilisateurs, ne nous faites pas confiance, vérifiez le code!


I’m not trying to convince you of using Docker (even if I came to like it).
But the argument of “It’s a black box and there’s not user-readable script” is not a good one. Here’s why.

The creation a docker image is defined in a readable file, usually named Dockerfile.
This file defines resources (download, files to add to the image,…) and commands. And you can use more script files just as resources.

You also can add “mounts” to provide the container access to the host. Such mounts could allow the container to:

  • discuss with Yunohost (html overlays,…)
  • Save persistant config and data

Such mounts (and also network port binds) can be defined with Docker Compose in a Yaml file.

A Docker Yunohost app could then be defined as:

  • the Dockerfile
  • the list of volume mounts and network ports to expose (Docker Compose file)
  • eventually more scripts to make the Dockerfile less monolithic

Well… Where is the black box here ? :wink:

EDIT: I could go further by explaining the advantages of encapsulation:

  • Security (a security breach in an app will stay in the app)
  • Easier network management (which app uses which port ? Just do docker ps)
  • Easier data management (where are config and data stored ? Just do docker ps. Want to change that ? Change the docker compose config file.)
  • Multiple instances of a specific app (but with different ports and mounts)
  • Keep the “usual install guidelines” of each app, without having to customize them or risk any conflicts between apps.
  • A lot of apps already provide Dockerfiles, you would just have to write the Docker Compose config.


Well personally, I wouldn’t say that it’s a black box, but I think it surely does add another layer of complexity in a system that’s already complex - with no game-changing feature imho.

There clearly are some advantages to encapsulation, but some of them are already covered (at least partially) or achievable (e.g. know which app uses which port). Surely the current situation is not clean and perfect, and we geeks/needs do like nice little fancy boxed functionalities which look like silver bullets. But from a pragmatic point of view and the what-does-the-end-user-get-at-the-end point of view, so far, imho it’s not worth the cost of the additional complexity. E.g. I’m guessing sending a mail from an encapsulated app becomes harder, which in turns takes more time in terms of integration. Not mentioning of course the cost of migrating the existing app base.

For instance, one may think that docker solves the problematic of “moving” an app (the change_url feature) by making it trivial, but my understanding is that the real complexity lies in the fact that some apps (e.g. Wordpress I think ?) hard-code some things like permalinks in its DB ? (though I might be mistaking here)

Also I’d really like to know some day what’s the overhead for a practical example (say, Wordpress) in terms of CPU / RAM / HDD, this considering that YunoHost is designed to be able to run on ARM boards with as low as 512Mo of RAM, 8 Go of HDD, and maybe even internet connectivity as low as 100 ko/s.


I’ll only answer to performance here:

Docker performance is the same as native. It’s based on the kernel features CGroups and Namespaces. The “native” execution is just the default namespace.
The only visible overheads are

  • network latency (but we’re talking microsecs here, not millisecs),
    • NO network throughput performance issue though
  • and, of course, disk usage.


Well, performance-wise, I understand processes achieve “native” performance. Nevertheless, you get to instanciate multiple instances of processes that wouldn’t have been needed (e.g. multiple mysql, postgresql, redis, etc.), which has necessarily an impact on overall performance.
For the same reasons, monitoring your system gets much more complicated with that multiplication of processes.
It’s of course a balance to find between maintainability, security, performance, etc. but in my opinion we certainly can’t assert docker is a better solution for YunoHost, especially since we target low/medium-profile hardware (among others) :wink:


That’s not always true, it only depends on how you manage your tools.

MySQL is often used as a docker container itself, and other containers connect to it thanks to the volumes. That’s the idea behind Docker Compose: you can “compose” the docker containers together. (There are also Docker Swarm, and others)

Monitoring the system is not more difficult either:
As Docker is no virtualization, htop in the host shows contained processes too !
And htop in a container only shows processes of this container, of course.

As I said my point is not to convince you to drop everything and run to Docker. But as some apps are difficult to install (Gitlab…) but provide a Docker installation, that wouldn’t be a good thing to completely close yourself from Docker.


Well, while the Compose mechanism exists, I guess there are still plenty of Docker apps out there that won’t use it to communalize database apps (for instance). And monitoring several database applications is still more complex that only one :wink:

Yet, I can reassure you that we’re not closing anything, as it’s a community-driven project :slight_smile:
There are already YunoHost community apps using Docker and I guess there always will.
Just don’t hold your breathe until an app using Docker gets the official label :wink:


I guess there are still plenty of Docker apps out there that won’t use it to communalize database apps (for instance)

Dockerfiles are customizable, you just have to remove the mysql install :wink: