NixOS VS Docker (compose)

NixOS

Si quelque chose casse, il est facilement possible de revenir en arrière parce qu'on peut apply une config juste sur l'instant et pas de façon permanente.
La modularité du langage Nix est très complète, on peut config de A à Z le système ainsi que les services hébergés.

L'apprentissage du langage Nix est plutôt difficile au début.
Le nombre de paquets nix n'est que de 50 000 ce qui veut dire qu'il est possible de ne pas trouver des logiciels dans les repos.
Une floppée de packages sont outdated et/ou recoivent une mise à jour assez tardive parce qu'il y a moins de mainteneurs que sur Docker et aussi parce que un grand nombre de packages ne sont pas gérés par le créateur du logiciel.
NixOS ne fonctionne pas sur OpenVZ et sur LXC son installation est plutôt compliquée voire impossible.

Impossible de ne pas trouver son bonheur grâce aux 2 700 000 images disponibles sur le Docker Hub.
La plupart des images populaires recoivent un support officiel du créateur du logiciel (nouvelle versions disponible très rapidement ainsi que les versions de sécurité).
L'apprentissage de l'écriture du docker-compose.yml est très facile parce que la documentation se tient sur une seule page : https://docs.docker.com/compose/compose-file/ et il existe beaucoup de tutoriels pour apprendre comment l'utiliser.
De nombreuses images préfaites pour un besoin spécifique sont disponible, par exemple faire tourner un serveur PaperMC directement sans se soucier de devoir configurer java ni de télécharger le bon .jar manuellement.
La mise en place de la mise à jour automatique et le redémarrage automatique des services est très facile (afin de garantir une bonne sécurité) grâce à par exemple watchtower.
Il est possible de déployer/gérer ses services sur plusieurs VPS en même temps grâce à Docker Swarm.
Docker fonctionne sur n'importe quel OS et distribution Linux (même sur Windows).

Le docker daemon (service de Docker tournant en arrière plan) consomme environ 50MB à 100MB de RAM.
Une image Docker prend (beaucoup) plus de place que juste le binaire du logiciel lui même parce qu'elle doit contenir les librairies ainsi que d'autres fichiers nécessaire à son fonctionnement. Dans ce cas cela dépend si le mainteneur a bien fait son job ou non.
Il faut régulièrement cleanup Docker parce que quand une image ou un container n'est plus utilisé sa place allouée sur le disque est toujours présente. Cette tâche peut être automatisée par exemple par un autre service Docker comme docker-system-prune.

(Relatif spécialement à Caddy) caddy-docker-proxy propose une gestion super facile de la configuration de caddy directement dans la config du service.