Cette histoire de thin provisionning reste trop obscur de mon point de vue et ne me semble pas appropriée dans mon cas de figure qui est, pour rappel, la mise en place d'un serveur web (php / mariadb / html5 / js / ...) assez basique, devant accueillir un nombre à ce jour indéterminé de site.

Je me demande donc à aujourd'hui si il est pertinent de faire un conteneur par site OU un conteneur pour plusieurs sites OU une VM par site (là je doute très très fortement au vu de la conso de ressources ...) OU une VM pour plusieurs sites. Sachant que je dois prendre en compte le fait qu'il soit possible que l'hôte soit amené à évoluer (donc changement d'offre en cours d'année pour un serveur hôte avec plus de ram ou cpu plus perf par exemple).

N'ayant jamais utilisé de conteneur (il va falloir que je me lance pour me faire mon propre avis, c'est sûr), j'ai un gros doute 😅

Alors j'aurais tendance à dire :

  • si les sites ne nécessitent pas beaucoup d'écriture (genre un site qui n'évolue pas beaucoup, bloc, site informatif) => container
  • si les sites nécessitent beaucoup d'écriture (une base de données mise à jour par plein de users en même temps, genre jeu en ligne) => vm
    Dans tous les cas, il faut bien comprendre que les containers lxc ne sont pas des containers docker, ils se comportent comme une vm complète, donc niveau administration système, ça ne change (presque) rien.

Par défaut, je mettrais plusieurs sites par container/vm, avec une gestion des virtualhosts pour gérer l'accès à chaque site (assez simple à mettre en oeuvre, que ce soit pour apache ou nginx), sauf si tu dois assurer que chaque "client" ait des ressourcées dédiées. Tout dépend aussi de la fréquentation des sites, s'il y a un "gros" site qui consomme beaucoup, tu voudras peut être l'isoler, mais tu verras ça à l'usage.

    Merrick merci beaucoup pour ces infos, notamment en ce qui concerne la différenciation entre les sites sans trop d'accès disque et ceux qui font tout l'inverse.

    Je n'ai jamais utilisé docker c'est pour cela que l'histoire de "conteneur" de proxmox me rebutait un peu mais comme tu dis, il ne s'agit pas de la même chose donc je vais me lancer dans un test sur un site actuellement en prod sur un dédié (sans proxmox). Cela va me permettra de voir les performances à minima.

    Après je me pose une autre question concernant les conteneurs de proxmox, au moment de la création il y a une case à cocher "unprivilged container" qui semble indiquer que le conteneur n'aura pas les droits root. C'est une option réellement intéressant car j'imagine que cela limite fortement le champ d'action à l'intérieur du conteneur ? Ou alors j'ai mal compris ce que j'ai lu 🙂.

      J'utilise en parallèle Proxmox (CT LXC) et Docker, c'est le pied pour un particulier. J'aime bien les CT parce qu'ils sont plus légers et ils se transfèrent tout aussi rapidement qu'une VM, de mon point de vue. Je mets par exemple un CMS en CT et la base de données sous Docker.

        Aerya du coup si je comprends tu fais de la virtualisation docker dans le CT LXC ?! Ou alors le docker se situe où si ce n'est pas dans le CT LXC ?

        Je demande ça car dans ma réflexion je me disais qu'il serait peut être pas mal de monter, pour mon projet, un CT LXC "dédié" à être le serveur SQL voire même une VM pour ça vu que selon Merrick la VM serait plus adaptée pour l'écriture (enfin attention je déforme peut être un peu ses propos), plutôt que d'avoir un serveur sql par CT.

              Tu ne déformes pas mes propos, c'est moi qui me suis mal exprimé : le LXC gère (à mon goût) assez mal les gros input disque, tu prends plein de latence. Si tu écris raisonnablement, tu n'auras pas ce problème. Après, la limite est difficile à définir...
              Après, tu peux très bien faire du docker dans lxc, mais il faut dans ce cas créer ton lxc avec une option particulière (que je n'ai plus sous la main, mais google te le dira vite).

              qo_op J'ai les deux en parallèle, sur l'hôte. Mais tu peux aussi lancer du Docker dans un CT LXC.

                Pour aller un tout petit peu plus loin dans les perfs LXC :

                steph@forumtest:~$ df -h                                                                                                                             
Filesystem      Size  Used Avail Use% Mounted on                                                                                                     
/dev/loop4       30G  2.5G   26G   9% /                                                                                                              
[ ... ]                                                                                                               
steph@forumtest:~$ mount                                                                                                                             
/backup/images/102/vm-102-disk-0.raw on / type ext4 (rw,relatime,data=ordered)

                Le disque / est monté en mode "loop". Voici un test de perf :

                root@forumtest:~# time sh -c "dd if=/dev/zero of=/test.tmp bs=4k count=200000 && sync"                                                               
200000+0 records in                                                                                                                                  
200000+0 records out                                                                                                                                 
819200000 bytes (819 MB, 781 MiB) copied, 5.87151 s, 140 MB/s                                                                                        
                                                                                                                                                     
real    0m14.978s                                                                                                                                    
user    0m0.033s                                                                                                                                     
sys     0m1.436s

                Soit 14 secondes pour écrire 780 Mo (avec un TRES grosse latence sur le "sync").
                Si je lance la même commande sur une VM sur le même hôte, avec les mêmes cpu/ram (et chargée un peu de la même façon) :

                root@log:~# time sh -c "dd if=/dev/zero of=/test.tmp bs=4k count=200000 && sync"                                                                     
200000+0 records in                                                                                                                                  
200000+0 records out                                                                                                                                 
819200000 bytes (819 MB, 781 MiB) copied, 1,00877 s, 812 MB/s                                                                                        
                                                                                                                                                     
real    0m1,125s                                                                                                                                     
user    0m0,139s                                                                                                                                     
sys     0m0,849s

                Soit... plus de dix fois plus rapide !
                Pour finaliser, j'ai mis en place une infra zabbix pour superviser l'hôte et toutes les VM/LXC, et la db mysql était sur un lxc. Au final, j'avais tellement d'IO wait que zabbix ne pouvait pas fonctionner. Dès que j'ai porté la db sur une vm, c'était immédiat.

                Voici un test avec le CT de mon blog (sur du SSD):

                df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0       49G  4.8G   42G  11% /

mount
/var/lib/vz/images/101/vm-101-disk-0.raw on / type ext4 (rw,relatime,data=ordered)

time sh -c "dd if=/dev/zero of=/test.tmp bs=4k count=200000 && sync"  
200000+0 records in
200000+0 records out
819200000 bytes (819 MB) copied, 0.540632 s, 1.5 GB/s

real	0m2.505s
user	0m0.120s
sys	0m0.426s

                Je ne suis pas en ssd, cela vient certainement de là...

                @Merrick

                Sur CT Proxmox, veuillez modifier la configuration de votre CT depuis votre host Proxmox pour vous amuser sur docker.

                nano /etc/pve/lxc/XXX.conf

                --> Rajouter à la fin :

                lxc.autodev: 1
lxc.hook.autodev: sh -c "mknod -m 0666 ${LXC_ROOTFS_MOUNT}/dev/fuse c 10 229"
lxc.cgroup.devices.allow: c 10:200 rwm
lxc.apparmor.profile: unconfined

                Redemarrer le CT ...

                De mon coté, j'ai les memes resultats qu'@Aerya du test de vitesse sur un LXC sur SSD.

                cd /tmp

time sh -c "dd if=/dev/zero of=/test.tmp bs=4k count=200000 && sync"

200000+0 enregistrements lus
200000+0 enregistrements écrits
819200000 bytes (819 MB, 781 MiB) copied, 0,580235 s, 1,4 GB/s

real    0m1,739s
user    0m0,033s
sys     0m0,555s

                Un hetzner en auction :

                CPUIntel Core i7-2600
                HDD2x HDD SATA 3,0 TB
                RAM4x RAM 4096 MB DDR3

                C'est une bonne machine ça 😉 Les HDD entreprise donnent de meilleurs performances chez Hetzner.

                Je suis en HDD aussi et voici l'hôte :

                time sh -c "dd if=/dev/zero of=/test.tmp bs=4k count=200000 && sync"
200000+0 records in
200000+0 records out
819200000 bytes (819 MB, 781 MiB) copied, 0.602086 s, 1.4 GB/s

real    0m5.505s
user    0m0.055s
sys     0m0.555s

                Un CT :

                time sh -c "dd if=/dev/zero of=/test.tmp bs=4k count=200000 && sync" 
200000+0 records in
200000+0 records out
819200000 bytes (819 MB, 781 MiB) copied, 0.762989 s, 1.1 GB/s

real    0m4.989s
user    0m0.077s
sys     0m0.753s

                Le serveur testé est un xeon E3 1220 avec deux hdd de 4to en raid1 et 32go de ram.

                Bonsoir tout le monde 🙂

                Mes premiers tests sont plutôt concluants maintenant je me demande si j'ai fais les bons choix, je m'explique.

                Tout d'abord je suis donc, suite à vos différents retours, parti sur des conteneurs. Maintenant que j'ai testé et que j'ai pu faire quelques comparaisons entre les CT et les VM de mon côté, je suis rassuré par les CT, ça fonctionne plutôt pas mal.

                Niveau pare-feu je n'utilise pas PFSENSE qui semble être installé par défaut mais UFW que j'ai déjà utilisé et que je sais un peu utiliser. Peut être que c'est une erreur mais ne connaissant pas PFSENSE je verrai ça plus tard. J'ai donc bloqué tous les ports en entrée sauf ceux dont j'ai besoin bien évidemment ^^

                En ce qui concerne les CT je les ai mis sur un réseau local en 192.x.x.x/24 et j'arrive bien à les atteindre (ping), que ce soit via l'hôte ou entre eux (excepté par hostname mais bon là faut que je me documente un peu plus).

                J'ai monté un CT qui gère la partie base de données (sous mariadb) et un CT contenant un premier site (type e-commerce) sous nginx.

                C'est là par contre que je doute : Pour faire en sorte que le premier nom de domaine pointe bien sur le CT e-commerce, j'ai mis nginx sur l'hôte et je lui fais faire du reverse-proxy. J'ai un gros doute sur le fait de donner ce rôle à l'hôte. Des avis ?

                Globalement ça fonctionne vraiment bien, nettement mieux que sur la kimsufi (qui était aussi moins perf que le serveur que j'ai pris). Reste le doute concernant l'hôte et la partie sécurité de cet ensemble, je me demande si ça tient la route.

                Voilà si jamais vous avez eu le courage de me lire et que vous avez des avis/suggestions je suis tout ouïe !! Merci par avance.

                Je n'installe rien sur l'hôte à part quelques règles IPtables. Le principe étant de pouvoir changer d'hôte à la volée justement du fait de l'utilisation de containers. Mon proxy est sous Docker, tu pourrais le mettre sous LXC.

                  Aerya c'est très juste, merci pour ce retour 😁